할루시네이션
더 좋은 모델을 쓰면 없어진다고 기대하기 쉽습니다. 줄어들기는 하지만 사라지지는 않습니다. 모델은 다음에 올 말로 그럴듯한 것을 고르는 방식으로 동작하고, 자기가 모른다는 사실 자체를 모릅니다. 그래서 모를 때도 자신 있게 말합니다.
한 문장으로
할루시네이션은 모델이 사실이 아닌 것을 사실처럼 말하는 현상이고, 고장이 아니라 작동 방식에서 따라 나오는 결과입니다.
하는 일
- 왜 생기나 — 확률로 이어 붙이는 방식에서 따라 나옵니다
- 어디서 잦은가 — 숫자, 인용, 사람 이름, 최신 정보
- 줄이는 방법 — 근거 문서를 함께 주기, 모르면 모른다고 하게 시키기
- 드러나게 하기 — 근거를 함께 표시해 사람이 바로 확인하게
- 사람이 봐야 하는 지점 — 금액 · 규정 · 대외 문서
- 사용자에게 알리기 — AI 가 만든 답임을 밝히기
하지 않는 일
- 모델을 고치는 일 — 쓰는 쪽에서 할 수 있는 일이 아닙니다
- 사실 데이터베이스 구축 — 그건 다른 작업입니다
- 법적 책임 판단 — 기술 문제가 아닙니다
이웃 개념과 헷갈리는 지점
- RAG관련 문서를 찾아 함께 넣어 주는 방식
- 가장 실용적인 대응입니다. 근거가 있으면 지어낼 여지가 줄고, 무엇을 보고 답했는지도 드러납니다.
- 근거 표시출처를 함께 보여 주는 것
- 틀림을 없애지는 못하지만 드러나게 만듭니다. 사람이 확인할 수 있으면 실무에서는 그것으로 충분한 경우가 많습니다.
- 컨텍스트질문과 함께 넣어 주는 자료
- 자료가 없으면 모델은 기억에서 꺼내 씁니다. 그 기억이 부정확할 때 지어내기가 나옵니다.
- 사람 검토내보내기 전에 확인하는 절차
- 기술로 못 없애는 부분을 절차로 덮는 방법입니다. 어디에 둘지는 틀렸을 때의 손해 크기로 정합니다.
언제 필요한가
이럴 때 필요합니다
- AI 답을 고객에게 그대로 보여 줄 때
- 금액이나 규정처럼 틀리면 안 되는 것을 다룰 때
- 답의 근거를 대야 할 때
- 왜 이런 답이 나왔는지 설명해야 할 때
아직 아니어도 됩니다
- 사람이 반드시 다듬는 초안 작성 용도라면 위험이 낮습니다
- 틀려도 손해가 없는 내부 참고용이라면 순위가 낮습니다
- 이미 근거 표시와 검토 절차가 있다면 더 할 것이 적습니다
여기서부터는 갈립니다
얼마나 자주 틀리는지는 질문 종류와 자료 상태에 따라 크게 달라져서 하나의 숫자로 말할 수 없습니다. 그리고 완전히 없애는 방법은 아직 없습니다. 연구가 계속되고 있지만 원리상 남는 부분이 있습니다. 그래서 설계는 “안 틀리게 만든다” 가 아니라 “틀렸을 때 드러나게 만든다” 쪽으로 잡는 편이 현실적입니다. 어디에 사람 검토를 둘지는 결국 틀렸을 때의 손해 크기로 정하게 되는데, 그건 기술 판단이 아닙니다.
자주 묻는 질문
모델은 사실을 찾아보는 것이 아니라 다음에 올 말로 자연스러운 것을 고릅니다. 자연스러움과 정확함이 대부분 겹치기 때문에 잘 맞는데, 겹치지 않을 때 자연스러운 쪽이 나옵니다. 그래서 틀려도 문장이 매끄럽습니다.
줄어듭니다. 다만 사라지지는 않고, 오히려 문장이 더 그럴듯해져서 알아채기 어려워지는 면도 있습니다. 모델을 올리는 것과 확인 장치를 두는 것은 같이 가야 합니다.
가장 효과가 큰 것은 답에 필요한 자료를 함께 넣어 주는 것입니다. 그리고 자료에 없으면 모른다고 답하게 지시하는 것입니다. 이 둘만으로도 체감 차이가 큽니다.
무엇을 답하느냐에 달렸습니다. 금액 · 규정 · 계약 같은 것은 사람이 확인하는 단계를 두는 편이 안전합니다. 안내나 요약처럼 틀려도 되돌릴 수 있는 것은 근거 표시와 함께 바로 보여 주는 경우가 많습니다.
서비스를 제공하는 쪽입니다. 모델을 만든 회사가 아니라요. 그래서 어디에 사람 검토를 둘지가 기술 결정이 아니라 사업 결정이 됩니다.
범위가 애매해도 괜찮습니다
지금 상황만 알려 주시면 필요한 범위와 대략의 규모를 짚어 드립니다.