reduce-hallucination은(는) 무엇을 하나요?
심문 과학에서 지식 있는 증인에게 진실을 말하도록 유도하기 위해 사용되는 검증된 기법을 LLM 에이전트에 대한 표준 감사(audit)로 전환합니다. 각 LLM 노드는 증인입니다. 노드 간 핸드오프는 증언의 녹취록입니다. 사용자 수정 사항과 태스크 레코드는 물리적 증거입니다.
이론과 증거는 references/에 있습니다. 각 주장에 대한 인용 정보를 보려면 references/research-map.md를 읽으세요.
세 가지 철칙
- 증거 없는 비난 금지 (Wellman의 원칙). 모든 발견 사항은 그것이 대상으로 하는 실제 프롬프트, 스키마, 또는 출력을 인용해야 합니다. 인용문 없는 의심은 "확인 필요" 목록에 넣고, 발견 사항에 포함시키지 마십시오.
- 표면 신호는 진실을 증명하지 않습니다. 유창하고, 자신 있고, 상세한 텍스트가 간결한 텍스트보다 더 정확하지 않습니다. 사람들은 행동에서 기만을 읽어내는 데 있어 우연 수준의 성공률을 보입니다. 오직 내용만 판단하세요: 근거, 일관성, 인용된 범위가 존재하는지.
- 자기 수정에는 새로운 외부 신호가 필요합니다. 새로운 증거 없이 "확실합니까? 다시 확인하세요"는 정확도를 떨어뜨립니다. 모든 재확인은 검색된 결과 또는 검증기 출력을 주입해야 합니다.
좋은 인용의 세 가지 기둥
인용 품질은 난이도와 가치가 증가하는 순서대로 세 가지 검사로 분해됩니다:
| 기둥 | 질문 | 현재 상태 |
|---|---|---|
| 충실함 (Faithful) | 인용문이 말 그대로 실제이고, 주장이 날조되지 않았는가? | 대부분 해결 가능: 말 그대로 문자열 매칭 + 기권. |
| 관련성 (Relevant) | 출처가 질문과 주제가 일치하는가? | 대부분 해결 가능: 검색 품질 + 일관성 프로빙. |
| 지지함 (Supportive) | 출처가 주장을 지지하는가, 반박하는가, 중립인가? | 최전선. 어렵고, 드문 "반박" 클래스가 시스템에서 가장 취약한 부분입니다. |
실제로 존재하고 주제에 맞는 구절을 가리키지만 실제로 주장을 지지하지 않는 인용("잘못된 근거 제시")은 인용이 없는 것보다 더 나쁩니다. 잘못된 주장에 대한 신뢰를 조작하고 검토자의 유일한 작동 방어(내용 확인)를 무력화시키기 때문입니다. 백엔드에서 확인하지 않고 인용을 표시하는 것은 환각을 더 위험하게 만듭니다.
감사 프로토콜
1단계 — 각 증인 심문 (프롬프트 + 스키마 레드 플래그)
각 LLM 노드에 대해 레드 플래그 목록을 실행합니다. 각 플래그는 하나의 심문 위반입니다.
| # | 레드 플래그 (찾을 것) | 중요한 이유 | 피해 |
|---|---|---|---|
| R1 | null / unknown 옵션이 없는 열거형 필드; "X의 확인을 출력하라"는 일방향 지시. | 답변을 강요하면 순응(허위 자백 유사)이 발생합니다. | 강제 추측, 자신 있는 날조. |
| R2 | 산문이 기권을 허용("누락 시 null 사용")하지만 스키마에 null이 없음. | 스키마가 우선하며, 기권은 무효화됩니다. | 조용한 날조. |
| R3 | 프롬프트가 증거/인용을 요청하지만, 이를 확인하는 항목이 없음. | 확인 없이 말하는 것은 모델에게 더 설득력 있는 인용을 날조하도록 가르칩니다. | 가짜 앵커. |
| R4 | 방향성 지시: "보수적으로", "가정하라", "추론하라", "기본값으로". | 일방향 추정; R1과 결합하면 체계적 편향을 만듭니다. | 한 방향으로 치우친 출력. |
| R5 | 정의된 단위가 없는 집계 필드("총 연수", "전체 점수"). | 측정값은 잠그기 전에 단위가 선언되어야 합니다. | 정의 불일치가 추출 오류로 읽힘. |
| R6 | 작업과 무관하거나 인용 없는 추론 모델링을 하는 퓨삿 예제. | 예제는 "좋은" 답변에 대한 기대치를 설정합니다. | 잘못된 출력 스타일을 가르칩니다. |
| R7 | 프롬프트가 노드가 할 수 없는 일을 할 수 있다고 주장함. | 잘못된 전제. | 날조된 프로세스 서술. |
| R8 | 사용자 또는 상위 노드가 전달한 "사실"이 출처 태그 없이 진실로 사용됨. | 검증된 증거로만 대면하십시오. | 전제 오염. |
| R9 | 필수 슬롯과 빈 분기가 없는 템플릿. | 답변을 강요하는 템플릿 버전. | 빈 칸이 가장 가까운 값으로 채워집니다. |
| R10 | 새로운 증거 없이 공격적으로 작성된 재확인/재시도("당신은 틀렸습니다, 고치세요"). | 아첨이 정답을 뒤집습니다. | 정답이 무효화됨. |
각각을 다음 형식으로 기록하세요: 노드 | R# | 인용된 텍스트 | 한 줄 결과.
2단계 — 녹취록 감사 (노드 경계 / 데이터 흐름)
대부분의 파이프라인 환각이 여기서 발생합니다. 데이터 흐름을 그리고 각 가장자리를 확인하세요:
- 불확실성이 경계를 넘어가는가? 상위 단계의
confidence/missing_fields/null/ 참고 사항 — 하위 단계에서 이를 소비하는가, 아니면 템플릿이 이를 단정문으로 평탄화하는가? "사장된" 불확실성을 찾으세요: 생성되었지만 읽히지 않음. - 출처(provenance)가 손실되는가? 상위 단계 추론이 "가정/추론됨"이라고 인정한 값이 하위 단계에서 표시 없는 사실이 됩니다. 스키마는
stated | inferred | absent를 전달해야 합니다. - 사실 범주가 교차하는가? 사용자나 문서가 주장한 것처럼 렌더링된 구성 또는 요구 사항 데이터.
- 집계값의 단위가 변경되는가? 상위 단계의 "총 의사 경력"이 하위 단계의 "X 타이틀로서의 경력"이 됨.
- LLM이 결정론적 계산을 수행하는가? 날짜 계산, 합계, 카운트는 프롬프트에서 코드 단계로 이동해야 합니다.
3단계 — 물리적 증거 매칭 (태스크 레코드가 존재할 때)
- 샘플 태스크(사용자 수정 또는 실패가 있는 것을 선호)에 대한 중간 노드 출력을 가져옵니다.
- 최종 출력을 각 노드의 중간 출력 및 원시 입력과 필드별로 비교합니다. 진실이 처음 손실된 경계를 찾습니다.
- 이전에 일관되지 않은 진술을 찾습니다: 동일한 필드가 노드 간에 스스로 모순됨.
- 수정 사항이 방향성이 있는 경우(체계적으로 한 방향), 1단계 R4 방향성 지시를 재확인하세요. 무작위 오류는 입력 품질을 더 가리킵니다.
- 정직하게 분류하세요: "출처에 없었던 정보"(프로세스 격차, 환각 아님) vs "입력에 있었지만 잘못 진술된 정보"(실제 환각).
4단계 — 순위별 수정 (ROI 기준)
계층 1 — 프롬프트 / 스키마 (구조적 변경 없음)
- 각 R1/R2 →
null/unknown열거형 + 비난을 줄이는 한 줄("X는 정확하고 예상된 답변입니다")을 추가합니다. - 각 R9 → 템플릿에 빈 분기를 추가합니다(단정문이 열린 질문이 됨).
- 각 R5 → 단위를 분할하거나 범위
{floor, ceiling}를 출력합니다. - 각 R3 → 하중 지지 필드에
{value, source, evidence_quote}삼중항을 추가합니다.
계층 2 — 결정론적 코드 검증기 (LLM 비용 제로)
| 검증기 | 확인 사항 |
|---|---|
| 열거형 화이트리스트 | 필드 값이 허용된 집합에 있는지. |
| 인용문 문자열 매칭 | evidence_quote가 인용된 출처에 그대로 존재하는지. 없으면 거부 또는 다운그레이드. |
| 교차 필드 일관성 | 합계가 일치하는지. missing_fields가 채워진 값과 모순되지 않는지. |
| 단위 계산 | 날짜 차이/합계는 코드에서 수행. LLM은 의미론적 추출만 수행. |
| 종료 계약 | 모든 사용자에게 보이는 사실 슬롯이 비어 있지 않고 허용된 출처 필드에서 왔는지. |
사용자에게 보이는 내용을 생성하는 모든 노드 앞에 배치하세요. 실패 시, 대체 플래그를 작성하고 열린 질문 또는 사람에게 전달하세요.
계층 3 — LLM 교차 검사 노드 (LM vs LM)
- 검토 중인 출력과 출처 문서만 받는 별도의 노드(오염시키는 맥락은 제외).
- 작업을 반박하도록 구성: "반박해 보세요: 이 출력의 모든 주장이 출처 문서로 추적됩니까? 그렇지 않은 주장을 나열하세요."
{verdict, offending_claims[]}를 출력합니다. 높은 중요도 흐름의 경우, 재정렬하여 다시 질문하고 일관성 투표를 수행합니다.- 비용: 태스크당 +1 LLM 호출 — 사용자에게 보이는 종료 지점 또는 높은 중요도 결정에만 게이트하세요.
5단계 — 보고서
# 환각 감사 — {agent}
## 한 줄 평결
## 증거 개요 (감사된 노드 / 버전 / 태스크 샘플 / 수정 샘플 + 방향)
## 발견 사항 (각각: 위치 | R# | 인용된 텍스트 | 결과 | 수정 #)
## 데이터 흐름 맵 및 사장된 채널
## 수정 권장 사항 (계층 1/2/3, 각각 제거하는 발견 사항 태그)
## 확인 필요 (충분한 증거가 없는 의심 + 이를 얻는 방법)
## 정직한 경계 (프로세스 격차인 수정과 환각인 수정, 이 감사가 다루지 않은 것)
지지함(Supportiveness) — 최전선 (선택적 확장)
충실함 + 관련성은 기본입니다. 열린 문제는 지지함입니다: 인용된 출처가 주장을 지지하는지, 반박하는지, 중립인지. 연구에서 얻은 두 가지 참고 사항:
- **입장(stance) + 정도(degree)**로 모델링하세요. 세 가지 입장(수반 / 반박 / 중립)은 부분적 또는 조건부 지지를 놓칩니다. 이는 규제 및 법률 텍스트의 대부분입니다. "부분/조건부" 플래그를 추가하여 사람 검토로 보내세요.
- 지지함은 의도(intent)에 상대적입니다. 동일한 구절이 "우리는 준수합니다"를 지지하고 "우리는 격차가 있습니다"를 반박할 수 있습니다. 사용자가 주장하는 내용에 따라 다릅니다. 입장이나 의도가 불확실할 때, 지지하는 출처와 반박하는 출처 모두를 표면화하고 사용자가 선택하게 하세요. 방향을 평결이 아닌 검토를 초대하는 플래그로 제시하세요.
상기 사항
- 프롬프트가 "충격적으로 나쁘다"면, 먼저 자동 생성된 상용구인지 확인하세요(Role/Objective/Task의 반복이 그 신호입니다). "이 생성기의 체계적 문제"가 에이전트당 동일한 결함을 나열하는 것보다 낫습니다.
- 하나의 에이전트 내에서 대비: 어떤 필드는 깨끗하고 어떤 필드는 실패하는지. 그 차이가 보통 답입니다(
unknown옵션이 있는 필드는 깨끗한 경향이 있습니다). - 보고서를 평이한 언어 편집 단계로 돌리세요: 발견 사항은 이론을 읽지 않은 사람도 읽을 수 있어야 합니다.
관련 스킬
신뢰할 수 있고 명확한 커뮤니케이션을 위한 작은 오픈 에이전트 스킬 계열의 일부입니다:
- reduce-hallucination — LLM 에이전트 감사; 근거 제시, 인용, 기권.
- better-doc — 클래식 스타일 + 스마트 브레비티.
- numbers — 숫자를 의미 있게 만들고, 깔끔하게 표시합니다.