LLM 환각

LLM 환각은 생성된 내용이 허구이거나, 이용 가능한 근거로 뒷받침되지 않거나, 모델이 사용해야 하는 출처와 일치하지 않는 현상입니다. 만들어 낸 사실이나 인용을 포함하면서도 유창하고 확신에 찬 표현으로 보일 수 있습니다. 실무에서는 응답이 설득력 있게 들리는지가 아니라 답변의 각 주장에 근거가 있는지 확인해야 합니다.

작성: Ai Flowi · 게시일 2026-10-11

용어는 작업마다 다르게 쓰이므로 확인할 실패를 정의해야 합니다. 외부 사실이 틀린 것과 제공된 문서에 모순되는 요약은 서로 다른 결함입니다. 둘 다 중요하지만 진단하고 수정하는 데 필요한 근거가 다릅니다.

허구, 근거 없는 주장, 출처와 모순되는 출력

허구의 세부 사항은 존재하지 않는 정책 식별자처럼 확립된 근거가 없는 내용을 도입합니다. 근거 없는 주장은 제공된 자료가 입증하지 않는 사실을 주장합니다. 다른 곳에서는 우연히 사실일 수 있지만 해당 응답은 이를 정당화하지 못했습니다. 모순은 적용 가능한 출처의 명시적인 내용과 충돌합니다.

누락도 별도의 실패 유형입니다. 제한 사항을 빠뜨리면 포함된 문장들이 각각 근거를 갖추어도 답변이 오해를 일으킬 수 있습니다. 만들어 낸 문장이 없으면 완전한 응답이라고 가정하지 말고, 주장 확인과 함께 누락도 확인해야 합니다.

명시적으로 허구를 요청한 작업에는 만들어 낸 세부 사항이 정당하게 포함될 수 있습니다. 허구를 사실처럼 제시하거나 답변이 작업의 근거 범위를 벗어날 때 실패가 발생합니다. 창작과 출처 기반 정책 답변에 같은 사실성 기준을 적용해서는 안 됩니다.

출처가 있는 가상 질문

가상의 출처 메모에는 ‘열람실은 직원이 잠금을 해제한 뒤에 문을 엽니다. 방문자는 공용 책상을 사용할 수 있습니다. 자료 보관함은 직원만 사용할 수 있습니다’라고 적혀 있습니다. 질문은 방문자가 자료 보관함을 열어도 되는지입니다. 제공된 출처는 제한 사항을 직접 명시합니다.

이 표는 오류 빈도가 아니라 실패 분류를 보여 줍니다. 관련성 문제도 드러납니다. 공용 책상에 관한 정확한 문장이 실제 보관함 질문을 회피할 수 있습니다. 근거와 질문에 대한 응답성을 따로 검토해야 합니다.

그럴듯한 생성이 근거를 넘어설 수 있는 이유는 무엇인가요?

언어 모델은 학습한 패턴과 요청을 바탕으로 텍스트를 생성하며, 본질적으로 검증 시스템은 아닙니다. 안내 데스크에서 열쇠를 요청하는 것처럼 익숙하게 들리는 절차는 출처에 아무런 언급이 없어도 정책 답변의 문체에 어울릴 수 있습니다.

모호한 지침은 빈틈을 채우도록 유도할 수 있습니다. 작업은 완전한 절차를 요구하지만 메모에는 제한 사항만 있다면 모델이 패턴을 완성하려 할 수 있습니다. 출처가 제공할 수 없는 세부 사항을 요구하는 대신 허용 가능한 ‘알 수 없음’ 응답을 정의해야 합니다.

생성 전에 문맥에서 실패할 수도 있습니다. 검색이 잘못된 보관함의 정책을 찾거나 제한 문장을 제외하거나 오래된 답변을 이력에 남길 수 있습니다. 이러한 오류가 잘못된 응답을 정당화하지는 않지만 원인을 파악하면 모든 결함을 프롬프트 작성 문제로 취급하는 일을 막을 수 있습니다.

응답을 판단하기 전에 근거를 확인합니다

먼저 실제로 모델에 전달된 출처를 확인합니다. 답변 요청이 다른 구절을 받았다면 데이터베이스에 올바른 정책이 있다는 사실만으로는 충분하지 않습니다. 출처 식별자, 버전, 인용문을 보관하여 실제 문맥과 답변을 비교할 수 있게 해야 합니다.

다음으로 응답을 사실 주장으로 나누고 각각을 뒷받침하는 자료에 연결합니다. 인용은 한정 조건까지 포함하여 주장이 성립함을 보여 주는 구절을 식별해야 합니다. 실제 문서의 링크라고 해서 그 근처에 놓인 모든 문장을 뒷받침하지는 않습니다.

마지막으로 답변이 질문에 응답하고 의도한 범위를 유지하는지 확인합니다. ‘직원 전용 보관함’을 ‘직원 전용 열람실’로 바꾸어서는 안 됩니다. 과도한 일반화는 출처의 단어를 재사용하더라도 정책을 바꿀 수 있습니다.

문제를 확인하는 카탈로그 인터페이스

Knowledge Base 가이드는 확인할 출처 자료를 검색하는 방법을 설명합니다.

근거 형식화는 Parser 문서를, 생성 설정은 Language Model 참조 문서를 참고합니다.

자료실 예시에서는 책상에 관한 문장만이 아니라 전체 메모를 기준으로 보관함 주장을 평가해야 합니다. 응답이 열쇠 요청 경로를 만들어 냈는지, 규정 식별자가 출처에 있는지, 보관함 질문에 답했는지도 확인합니다. 이들은 별개의 판단입니다. 허구의 식별자를 제거해도 허용되지 않은 접근 주장은 수정되지 않습니다.

LangWatch Evaluator는 contexts, input, output, expected_output에서 Message를 받습니다. evaluator_name과 api_key가 필요하며, evaluation_result를 JSON으로 반환합니다. 카탈로그 설명에는 평가 엔드포인트가 언급되어 있지만 이용 가능한 평가기 목록이나 사실성 점수의 정의는 없습니다.

카탈로그에 문서화되어 있으나 Ai Flowi가 운영 환경에서 테스트하지 않았습니다

카탈로그에는 평가기 인터페이스가 기록되어 있습니다. 자료실 답변을 채점하려면 생성용 인증 정보뿐 아니라 본인의 평가 서비스 계정과 API 키도 필요하며, 각 제공업체가 자체 사용료를 청구합니다.

평가의 한계와 흔한 실수

자동 평가기는 제공된 문맥, 평가 기준, 구현에 따라 달라집니다. 답변 모델과 똑같이 불완전한 근거를 받으면 누락된 제한 사항을 놓칠 수 있습니다. 이 작업에서 평가 결과를 유의미하게 취급하기 전에 작성자가 만든 소규모 사례 모음으로 평가기의 판단을 확인해야 합니다.

JSON이 파싱되거나 인용이 있거나 다른 모델이 동의한다는 이유만으로 응답이 정확하다고 판단해서는 안 됩니다. 이러한 점검은 유용한 신호일 수 있지만 사실적 근거는 주장과 적용 가능한 자료를 비교해야 확인할 수 있습니다. 변동성이 낮은 응답도 같은 근거 없는 세부 사항을 일관되게 반복할 수 있습니다.

평가기 사례 모음에는 의도적으로 오해를 유도하는 답변을 포함합니다. 예를 들어 ‘메모가 방문자의 공용 책상 사용을 허용하므로 방문자는 자료 보관함을 열어도 됩니다’라는 답변입니다. 첫 절에는 근거가 있지만 결론은 제한 사항과 충돌합니다. 평가 기준에서 결론과 누락된 한정 조건을 확인하지 않으면 공통 단어에만 집중하는 채점기가 이 응답을 인정할 수 있습니다.

진단된 실패에 맞추어 수정해야 합니다. 만들어 낸 규정 식별자는 해당 참조를 제거하고 인용의 존재 여부를 확인해야 합니다. 잘못된 보관함 결론은 주장한 허용 범위를 제한 사항과 비교해야 합니다. 책상에 관한 회피성 답변에는 질문에 대한 응답성 점검이 필요합니다. 거부한 모든 답변을 막연히 부정확하다고 설명하는 것보다 이러한 차이를 기록하는 편이 유용합니다. 이 글은 측정된 환각 발생률을 제공하지 않습니다.

관련 용어와 구현 자료

LLM 그라운딩은 주장과 구절을 연결하는 검토표를 설명합니다. 프롬프트 엔지니어링은 더 명확한 작업 경계를 설명합니다. 기존 아키텍처 가이드, Agent 참조 문서, 사용 사례는 애플리케이션 설계를 다룹니다. 모델의 답변을 실행 성공의 근거로 취급하지 말고 이 자료로 주변 시스템을 확인해야 합니다.