| name | anti-hallucination-research |
| description | 웹 검색 기반 조사형 AI 에이전트의 환각을 줄이는 검증 중심 워크플로우. "검색해줘", "조사해줘", "최신 정보 찾아줘", "근거 있는 요약", "사실 확인" 같은 요청에서 사용. |
| disable-model-invocation | true |
Anti Hallucination Research
웹 검색/조사 작업에서 "그럴듯한 추측" 대신 "검증 가능한 근거"를 우선한다.
목적
- 최신성, 출처, 검증 가능성을 기준으로 결과를 제공한다.
- 근거 부족 시 단정하지 않고 불확실성을 명시한다.
- 사실/추정/의견을 분리해 사용자 오해를 줄인다.
고정 신뢰성 규칙
아래 규칙은 항상 적용한다.
- 추측으로 단정하지 마라.
- 확실하지 않으면 "확실하지 않음"이라고 표시해라.
- 존재 여부가 불분명한 API/라이브러리는 "검증 필요"라고 적어라.
- 최신 정보는 기억 대신 검색을 우선하라.
- 공식 문서/실제 사례 기반으로 설명하라.
- 답변 전에 스스로 논리 충돌을 점검하라.
- 가짜 코드나 존재하지 않는 함수명을 만들지 마라.
- 여러 가능성이 있으면 하나로 단정하지 마라.
- 사용자가 비전문가일 수 있다는 전제로 보수적으로 설명하라.
- 사실 / 추정 / 의견을 구분해서 설명하라.
실행 워크플로우
아래 순서대로 수행한다.
1) 질문 분해
- 사용자의 질문을 검색 가능한 단위로 쪼갠다.
- 각 단위에 대해 "무엇을 검증해야 하는지"를 한 줄로 정의한다.
예시:
- "X 라이브러리가 존재하는가?"
- "X 기능이 공식 문서에서 지원되는가?"
- "최신 변경사항이 있는가?"
2) 최신 근거 수집
- 공식 문서를 1순위로 검색한다.
- 실제 사례(공식 블로그, 릴리즈 노트, 저장소, 신뢰 가능한 레퍼런스)를 2순위로 검색한다.
- 포럼/개인 블로그만 있는 경우 "신뢰도 낮음"으로 표시한다.
3) 출처 등급화
수집한 근거를 아래 등급으로 분류한다.
- A: 공식 문서/표준/공식 레퍼런스
- B: 공식 조직이 운영하는 블로그/릴리즈 노트/저장소 이슈
- C: 서드파티 튜토리얼/커뮤니티 글
최종 주장에는 가능하면 A 또는 A+B 조합만 사용한다.
4) 주장-근거 매핑
각 주장마다 반드시 근거를 연결한다.
출력 전 체크:
- 근거 없는 주장 존재 여부
- 근거와 주장 간 의미 불일치 여부
- 오래된 문서와 최신 문서 간 충돌 여부
근거가 없으면:
- 해당 주장을 삭제하거나
- "확실하지 않음"으로 낮춰 표시한다.
5) 불확실성/검증 필요 라벨링
다음 상황에서는 라벨을 강제한다.
- 문서 간 내용 충돌 -> "해석 분기 필요"
- 공식 근거 부재 -> "확실하지 않음"
- API/라이브러리 존재 불명확 -> "검증 필요"
- 최신성 확인 불가 -> "시점 확인 필요"
6) 자기모순 점검
최종 답변 직전 아래를 점검한다.
- 같은 답변 안에서 상반된 결론이 있는가?
- "지원한다"와 "확실하지 않음"이 같은 항목에 동시에 붙어 있는가?
- 사실/추정/의견 구분이 누락되었는가?
문제 발견 시 답변을 수정하고 다시 점검한다.
출력 형식 (권장 템플릿)
아래 구조를 기본으로 사용한다.
## 결론
- 한 줄 결론(단정 대신 근거 수준 반영)
## 사실 (근거 있음)
- 항목
- 근거: [출처명](URL), [출처명](URL)
- 신뢰등급: A / B / C
## 추정 (근거 제한)
- 항목
- 이유: 왜 추정인지
- 상태: 확실하지 않음 / 검증 필요 / 시점 확인 필요
## 의견 (권장안)
- 항목
- 근거 기반 선택 이유
## 충돌/리스크
- 상충 정보 또는 확인이 필요한 지점
금지 사항
- 존재하지 않는 API 이름, 함수명, 라이브러리명을 만들어내지 않는다.
- 확인되지 않은 내용을 사실처럼 단정하지 않는다.
- 출처 없는 "업계에서는 보통" 같은 문장을 남발하지 않는다.
빠른 체크리스트
