비즈니스 AI 어시스턴트의 환각 현상 줄이는 방법 (그리고 프롬프트에 '절대 지어내지 말라'는 것이 충분하지 않은 이유)

closiqode.com에서 프랑스어로 처음 발행된 기사를 바탕으로 각색됨.

생성형 AI 어시스턴트에서 모든 환각 현상을 제거할 수는 없습니다. 할 수 있는 것은 그 발생 빈도를 낮추고, 검증되지 않은 답변이 중요한 결과를 초래하지 않도록 보장하는 것입니다.

실제적으로 이는 여섯 가지 요소를 결합해야 함을 의미합니다: 좁은 범위 설정(narrow scope), 검증된 출처(validated sources), 명시적 거부(explicit refusal), 엄격한 테스트(hard tests), 인용(citations) 및 인간의 통제(human control).

프랑스 데이터 보호 기관(CNIL)은 이를 간단하게 설명합니다: 생성형 모델은 지식 기반이 아닙니다. 그 확률론적 논리는 틀리지만 그럴듯한 결과를 만들어낼 수 있습니다. 진정한 위험은 눈에 보이는 오류가 아니라, 아무도 확인해 보려고 생각하지 않는 설득력 있는 답변입니다.

1. 범위를 좁히라 (Narrow the scope)

어시스턴트가 모든 것을 답하려고 할수록, 원래의 역할에서 더 멀리 벗어나게 됩니다.

허용되는 주제, 금지된 주제, 사용자는 누구인지, 어시스턴트가 무엇을 할 수 있는지 명확히 작성해야 합니다.

좋은 거절(refusal)은 유용합니다. 이는 무엇이 빠졌는지 알려주거나, 어떤 출처를 제공해야 하는지 제안하거나, 사람에게 인계하는 방식으로 이루어집니다. 사용자가 여전히 그 답변을 사실로 받아들일 수 있다면, 모호한 "확신하지 못한다"는 말만으로는 충분하지 않습니다.

최소한의 지침은 다음과 같지만, 이 지침만으로는 아무것도 보장할 수 없다는 점을 기억해야 합니다. 작동하는지 증명하는 것은 4단계의 테스트입니다.

Answer only from the provided excerpts.
If the excerpts do not contain the answer, say so explicitly,
list what information is missing, and suggest who to ask.
...

4. 까다로운 질문 테스트하기

테스트 세트는 다음을 포함해야 합니다:

• 모호한 질문(ambiguous questions),
• 누락된 정보(missing information),
• 모순되는 출처(contradictory sources),
• 특이한 표현(unusual wording),
• 경계 사례(edge cases).

명백한 경우에만 테스트된 시스템은 잘못된 신뢰도를 느끼게 합니다.

최소 프로토콜

1. 예상 답변과 예상 출처가 포함된 실제 질문을 수집합니다.
2. 불가능하거나, 범위를 벗어난(out-of-scope) 또는 의도적으로 오해를 유발하는 질문을 추가합니다.
3. 모든 중요한 질문에 대해 여러 가지 표현으로 테스트합니다.
4. 검색 관련성(retrieval relevance)과 출처 충실도(answer faithfulness to the source)를 개별적으로 점수화합니다.
5. 모델, 프롬프트 또는 코퍼스 변경 후 전체 테스트 세트를 다시 실행합니다.

테스트 케이스는 다음과 같이 간단할 수 있습니다:

{
  "question": "휴가 신청은 며칠 전에 제출해야 하나요?",
  "expected_source": "hr-procedures-v3.pdf, section 2",
...

여기에 코퍼스에 답변이 포함되어 있지 않기 때문에 expected_behavior가 refuse인 형제 케이스(sibling case)를 추가합니다.

5. 민감한 결정은 맹목적으로 자동화하지 마라

어시스턴트는 준비하고, 검색하고, 요약하거나, 라우팅할 수 있습니다. 하지만 모든 결정이 인간의 개입 없이 이루어져야 한다는 의미는 아닙니다.

통제(control)와 결과(consequence)를 일치시키세요:

6. 출처를 보이게 유지하기

정보의 중요도가 높을 때는 사용자에게 해당 정보가 어디서 왔는지 확인할 수 있도록 해야 합니다.

인용은 실제로 사용된 문서, 필요하다면 그 버전을 가리켜야 하며, 인용된 구절이 생성된 문장을 정말로 뒷받침하는지 확인해야 합니다. 참고 자료가 존재한다는 것이 그것이 올바른 자료라는 증거는 아닙니다.

7. 운영 환경에서 오류 모니터링하기

출시가 작업의 끝은 아닙니다. 답변에 플래그를 지정할 수 있는 방법을 추가하고, 데이터 보호 규칙을 준수하면서 진단에 필요한 내용을 유지하며, 모든 사고를 새로운 테스트 케이스로 전환해야 합니다.

유용한 지표들을 추적하세요: 출처 없는 답변, 적절한 거부(refusal), 인간의 수정, 코퍼스 외부 질문(out-of-corpus questions) 및 오류 심각도. 만족도 점수만으로는 신뢰성을 측정할 수 없습니다.

고치기 전에 진단하기

모든 오류가 모델에서 발생하는 것은 아닙니다. 어시스턴트를 확실하게 수정하려면, 어떤 단계에서 실패했는지 찾아야 합니다:

단독으로 작동하지 않는 것들

• 다른 통제 장치 없이 프롬프트에

단독으로 작동하지 않는 것들

• 다른 통제 장치 없이 프롬프트에

더 강력한 모델만 충분할까요?
비즈니스 프로세스의 신뢰성을 보장하기에는 부족합니다. 출처(Sources), 범위(Scope), 테스트 및 통제(Tests and controls)가 여전히 필요합니다.

어디든 경고 문구를 붙여야 할까요?
경고문이 시스템 설계를 대체할 수는 없습니다. 사용자는 한계점을 이해해야 하지만, 민감한 결정은 주로 차단되거나 검증되어야 합니다.

좋은 어시스턴트는 항상 답변하지 않습니다

답변하지 말아야 할 때를 아는 것도 중요합니다.

저는 프랑스의 독립 개발자 Fabien Kost입니다 (ClosiQode). 저는 검증된 문서에서 답변하고, 답변을 찾을 수 없을 때는 그렇게 밝히는 비즈니스 AI 어시스턴트를 구축합니다. 제가 어떻게 설계하는지에 대한 더 자세한 내용은 여기 (프랑스어)를 참고하세요.

출처(Sources) (프랑스어): CNIL, 생성형 AI 시스템 사용에 관한 질의응답 및 생성형 AI 배포에 대한 첫 번째 지침।