AI의 '확신도 95%'는 검증이 아니다: LLM 환각과 답변 보류 설계

 

AI에게 답변과 함께 확신도를 적어 달라고 하면 “95% 확신합니다”라는 숫자를 받을 수 있다. 이 숫자가 있으면 결과가 한층 과학적으로 보인다. 그러나 그 점수가 어떤 데이터에서 검증되었는지, 무엇이 맞을 확률인지, 틀렸을 때도 높은 점수를 내는지 확인하지 않았다면 단지 생성된 표현일 수 있다. 확신을 숫자로 썼다는 사실은 답변을 검증했다는 뜻이 아니다.

 

업무용 AI 에이전트에서 중요한 것은 무조건 자신 있게 답하는 능력만이 아니다. 근거가 부족하면 질문을 좁히고, 확인할 도구가 있으면 조회하고, 확인할 수 없으면 그 범위를 남기는 능력도 필요하다. 답변을 보류하는 설계는 모델의 부족함을 가리는 장식이 아니라, 잘못된 단정이 실제 업무로 이어지는 것을 줄이는 실행 방식이다.

 

이 글은 LLM 환각, 신뢰도 보정, 선택적 응답, 답변 보류를 연결해 설명한다. OpenAI의 환각 연구 해설과 언어모델 자기 평가에 관한 원논문 초록, 한컴테크와 Deskroom의 한국어 기술 글을 비교했다. 자료 확인 기준일은 2026년 10월 25일이다. 제목의 95%와 본문의 평가 수치는 개념 설명을 위한 가정이며 특정 제품에서 직접 측정한 결과가 아니다.

 

핵심은 숫자를 없애자는 것이 아니다. 의미를 정의하고 검증한 점수는 유용할 수 있다. 다만 모델이 말로 제시한 자신감, 다음 토큰의 확률, 검색 유사도, 실제 정답률은 서로 다른 값이다. 이를 구분하고 답할 수 없는 상황의 다음 행동을 정해야 AI 에이전트의 품질을 현실적으로 평가할 수 있다.

확신 있는 말투와 보정된 확률은 다르다

“확실합니다”라는 표현은 문장의 스타일이다. “95%”라는 숫자도 별도의 검증이 없다면 같은 범주에 머물 수 있다. 모델은 사용자가 숫자를 요구했기 때문에 자연스러워 보이는 점수를 생성할 수 있다. 단정적인 어조와 외부 평가에서 확인한 신뢰성을 같은 것으로 취급하면 높은 확신의 오답을 놓치기 쉽다.

 

신뢰도 보정, 영어로 calibration은 예측한 확률과 실제 결과의 빈도가 잘 맞는지 다루는 개념이다. 어떤 평가 집단에서 0.8 정도의 신뢰도를 준 답변들을 모았을 때 실제로 약 80%가 맞는다면 그 구간의 보정이 괜찮다고 볼 수 있다. 여기서 중요한 것은 답변 하나의 문장이 아니라 충분한 사례를 모아 비교한 관계다.

 

그렇다고 80%라고 표시된 특정 답변이 80%만큼 참이라는 뜻은 아니다. 보정은 정해진 데이터 집단과 평가 조건에서 확인하는 성질이다. 정답 기준이 무엇인지, 질문 분포가 어떤지, 부분적으로 맞는 답을 어떻게 처리했는지에 따라 해석이 달라진다. 개별 사용자는 자신이 받은 답의 근거도 확인할 필요가 있다.

 

언어모델이 자기 정답 가능성을 평가할 능력이 전혀 없다고 단정하는 것도 맞지 않다. 2022년 연구인 Language Models (Mostly) Know What They Know는 적절한 형식의 과제에서 자기 평가와 보정의 가능성을 보고한다. 동시에 새로운 과제로 옮길 때의 보정 어려움도 설명한다. 가능성이 있다는 결과와 아무 프롬프트로 받은 숫자가 신뢰할 만하다는 주장은 다르다.

 

따라서 확신도 기능을 제품에 넣으려면 먼저 점수의 대상을 정의해야 한다. 답변 전체의 사실성이 맞는지, 특정 수치가 원본과 일치하는지, 검색 근거가 질문에 충분한지, 도구 호출이 성공했는지 구분하자. 여러 의미를 하나의 95%로 합치면 사용자는 무엇을 믿어도 되는지 알기 어렵다.

토큰 확률을 답변의 진실 확률로 읽으면 안 된다

언어모델은 문맥에서 다음 토큰이 나올 확률을 다룬다. 이 값이 높다는 사실은 해당 표현이 그 문맥에서 모델에게 예측하기 쉬웠다는 뜻에 가깝다. 그 문장이 현실의 사실과 일치할 확률을 직접 측정한 값은 아니다. 잘못된 전제가 문맥에 들어 있으면 그 전제에 맞는 자연스러운 오답도 높은 확률로 이어질 수 있다.

 

정형화된 문장과 익숙한 표현은 모델이 쉽게 생성할 수 있다. 반대로 드문 제품 번호나 고유명사, 정확한 날짜는 맞는 답이어도 토큰 수준에서 낮은 확률을 가질 수 있다. 토큰 확률이 낮다는 이유만으로 문장이 틀렸다고 하거나, 높다는 이유만으로 사실 검증을 생략하면 성질이 다른 문제를 섞게 된다.

 

답변 길이의 영향도 있다. 여러 토큰의 확률을 곱하거나 합산하는 방식은 길이와 표현 방식에 민감하다. 같은 의미를 짧게 쓰는지 길게 쓰는지에 따라 점수가 달라질 수 있다. 문장 단위나 주장 단위로 어떤 값을 비교하는지 정하지 않으면 긴 답변이 불리하거나 유리해지는 효과를 오류 탐지 능력으로 오해할 수 있다.

 

확률 정보가 제공된다고 해도 이를 활용하는 별도 검증 절차가 필요하다. 어떤 점수 변환이 실제 오답을 구분하는지 평가하고, 언어와 도메인이 바뀌었을 때 성질이 유지되는지 확인해야 한다. 토큰 점수를 이용한 방법이 무용하다는 뜻이 아니라 그 점수를 정답 확률로 바로 이름 붙이지 말자는 것이다.

 

온도 설정도 같은 맥락에서 보자. 생성의 무작위성을 줄이면 출력의 변동을 줄이는 데 도움이 될 수 있지만, 일관된 오답을 제거한다는 보장은 없다. 온도를 낮추는 작업과 신뢰도 보정은 같은 개념이 아니다. 자주 같은 문장을 낸다는 사실만으로 해당 문장의 진실성이 확인되지는 않는다.

정답만 세는 평가가 추측을 유리하게 만들 수 있다

OpenAI는 2025년 9월 공개한 환각 연구 해설에서 훈련과 평가의 보상 구조를 중요한 원인으로 설명한다. 정답은 점수를 얻지만 오답과 모른다는 응답을 똑같이 0점 처리하면, 답을 모르는 경우에도 추측해서 맞힐 유인이 생길 수 있다는 것이다. 이는 모든 환각의 원인을 하나로 환원하는 설명이 아니라 평가가 장려하는 행동을 살펴보자는 관점이다.

 

가상의 객관식 시험에서 모르는 문제를 비워 두면 항상 0점이고 추측하면 가끔 점수를 얻는다고 하자. 정확히 맞힌 개수만 보면 추측이 유리해질 수 있다. 실제 업무에서는 잘못된 답을 자신 있게 제공하는 비용이 확인을 요청하는 비용보다 훨씬 클 수 있다. 시험의 점수와 제품의 효용이 같은 방향으로 움직이지 않는 이유다.

 

OpenAI 해설은 정답, 오류, 기권을 구분한다. 기권은 특정 답을 추측해 내놓지 않는 것이다. 이 세 가지를 나누지 않고 정답률 하나만 보면, 더 많이 답해 더 많이 틀리는 모델과 신중하게 일부만 답하는 모델의 차이가 가려질 수 있다. 운영 평가에도 적절한 보류를 별도 결과로 넣어야 한다.

 

그러나 모든 질문에 “모르겠습니다”라고 하면 오류가 적다는 이유로 좋은 시스템이 되는 것은 아니다. 사용자가 해결할 수 있는 업무까지 막아 버릴 수 있기 때문이다. 답변해야 할 질문에 답했는지와 답할 수 없는 질문을 적절히 보류했는지를 함께 봐야 한다. 보류 기능을 넣으면 평가의 범위도 넓어져야 한다.

국내 기술 글에서도 보상 구조와 지식 경계를 다루는 논의를 확인할 수 있다. 다만 특정 연구의 조건을 모든 강화 학습이나 모든 모델의 보편적 성질로 일반화해서는 안 된다. 연구가 제시한 문제의식과 실험에서 확인한 범위를 구분하고, 우리 서비스의 평가가 어떤 행동을 보상하는지 직접 점검하는 편이 실용적이다.

답변 보류는 무응답이 아니라 다음 행동의 선택이다

답변 보류를 대화의 종료로만 생각하면 사용성이 나빠지기 쉽다. 사용자가 원하는 것은 모델의 겸손한 태도 자체보다 문제를 해결할 경로다. 보류가 필요한 이유와 해결 가능한 다음 행동을 함께 제시해야 한다. 모르는 정보가 무엇인지 명확히 밝히는 것이 첫 단계다.

 

예를 들어 구매한 상품의 환불 가능 여부를 묻는데 구매 시점과 계약 종류가 없다면, 모든 정책을 추측해 설명하기보다 필요한 조건을 물을 수 있다. 제품의 현재 가격이 필요하고 조회 도구가 있다면 최신 값을 조회할 수 있다. 근거 자료에 해당 항목이 없고 조회 수단도 없다면 확인할 수 있는 범위와 없는 범위를 나누어 답할 수 있다.

 

이 행동들은 서로 다르다. 확인 질문은 입력의 빈칸을 채우는 일이고, 추가 검색은 근거를 확보하는 일이며, 담당자 연결은 시스템 밖의 판단으로 넘기는 일이다. 단순 보류는 지금 주어진 조건에서 답을 확정하지 않는 선택이다. 하나의 low_confidence 상태만으로 모두 처리하면 다음 단계가 불분명해질 수 있다.

 

또한 불확실성 때문에 답하지 않는 것과 권한이 없어서 실행하지 않는 것은 구분해야 한다. 정확한 답을 알고 있어도 해당 데이터를 제공할 권한이 없을 수 있다. 반대로 조회 권한이 있어도 정보가 부족해 답을 모를 수 있다. 승인 필요, 정책상 제한, 지식 부족을 한 종류의 거절로 합치지 않는 편이 좋다.

 

좋은 응답은 확인된 내용, 확인되지 않은 내용, 필요한 추가 정보를 짧게 연결한다. “현재 문서에는 일반 계약의 조건만 있고 기업용 연간 계약의 예외는 확인되지 않습니다. 계약 종류와 구매일이 있으면 적용 규정을 좁힐 수 있습니다”처럼 말할 수 있다. 이 문장은 근거 부족을 숨기지 않으면서 사용자가 다음에 무엇을 해야 하는지 알려 준다.

불확실성의 원인을 나눠야 올바르게 대응할 수 있다

첫 번째 원인은 입력의 모호함이다. “지난달 실적”이라는 요청에서 매출인지 주문 수인지, 어느 조직의 실적인지 알 수 없을 수 있다. 이때 더 큰 모델이나 더 긴 추론을 사용해도 사용자의 의도가 저절로 확정되지는 않는다. 필요한 질문을 골라 묻는 것이 더 직접적인 해결일 수 있다.

 

두 번째는 근거의 부재다. 문서에 없는 정보나 아직 공개되지 않은 일정, 외부 시스템에서 조회하지 못한 값을 모델이 기억만으로 채우려 하면 오류가 생길 수 있다. 추가 정보가 실제로 존재하고 접근 가능한지부터 확인해야 한다. 검색을 반복한다고 존재하지 않는 정답이 만들어지는 것은 아니다.

 

세 번째는 근거의 충돌이다. 여러 문서가 서로 다른 조건과 날짜를 제시할 수 있다. 이때는 관련 문서를 많이 찾았다는 사실보다 어떤 규정이 어떤 대상에 적용되는지를 확인해야 한다. 최신 문서가 과거 계약에도 적용되는지 알 수 없다면 충돌 자체를 드러내는 것이 나을 수 있다.

네 번째는 해석과 계산의 실패다. 근거가 충분해도 단위 변환이나 예외 적용, 수치 계산을 틀릴 수 있다. 이 경우에는 입력을 다시 묻기보다 계산 도구나 규칙 검증, 근거와 주장 간 대조가 적절할 수 있다. 모델이 높은 자신감을 보였다는 이유로 이러한 검증을 건너뛰지 말아야 한다.

 

마지막으로 도구 장애와 지식 부족도 나누자. 주문 조회가 시간 초과된 것은 주문이 존재하지 않는다는 뜻이 아니다. 조회 실패를 근거로 환불 불가라고 단정하면 시스템 상태를 업무 사실로 바꾸게 된다. 오류의 종류에 맞는 재시도와 안내, 대체 경로를 정해 두면 불확실성을 더 정확하게 다룰 수 있다.

검색 점수와 출처 링크는 정답 보증서가 아니다

RAG를 붙이면 외부 근거를 참고할 수 있지만 검색 결과가 있다는 사실만으로 질문에 답할 수 있는 것은 아니다. 벡터 유사도와 BM25 점수, 재랭커 점수는 각 검색 방식이 계산한 관련성 신호다. 일반적으로 이를 곧바로 답변 정답 확률로 읽을 수는 없다. 점수의 의미와 분포가 질의와 인덱스에 따라 달라질 수 있다.

 

상위 문서의 점수가 높아도 제품 버전이나 적용 지역이 다를 수 있다. 예외 조항이 다른 청크에 있어 누락되었을 수도 있다. 하나의 답에 여러 근거가 필요한 질문인데 한 부분만 검색되었을 수도 있다. 관련 문서를 찾는 것과 답변에 필요한 조건을 모두 충족하는 것을 나눠 봐야 한다.

 

출처 링크 역시 검증의 출발점이다. 문서가 존재한다는 사실과 문서가 해당 주장을 지지한다는 사실은 다르다. 정확한 문서의 잘못된 절을 인용할 수도 있고, 숫자는 맞지만 단위를 틀릴 수도 있다. 핵심 주장과 근거 구간을 대응시키고 날짜와 대상, 예외를 확인하는 단계가 필요하다.

 

답변 보류 기준을 설계할 때는 단순한 검색 점수 임계값 외에 업무상 필수 근거를 함께 고려할 수 있다. 적용 대상과 시행일이 있어야 답할 수 있는 질문이라면 해당 항목이 확인되었는지 검사한다. 어떤 검사가 가능한지는 문서 구조와 도메인에 달려 있다. 사람이 정한 체크 항목도 오류가 있을 수 있으므로 실제 사례로 검증해야 한다.

 

자료를 제공하면 자기 평가가 더 유용해질 가능성은 있다. 2022년 자기 평가 연구 초록도 관련 자료가 문맥에 있을 때 지식 보유 가능성 예측이 달라지는 결과를 설명한다. 하지만 근거가 있다는 이유로 모든 점수가 자동 보정되는 것은 아니다. 새로운 문서 유형과 언어에서는 자체 평가가 필요하다.

여러 번 같은 답을 했다는 사실도 독립 검증은 아니다

동일한 질문에 여러 번 답하게 하고 일치하는 답을 고르는 방법은 변동을 살피는 데 유용할 수 있다. 그러나 같은 모델이 같은 잘못된 지식이나 같은 잘못된 근거를 반복해서 사용하면 여러 응답이 모두 같은 방향으로 틀릴 수 있다. 일관성은 정확성과 관련될 수 있는 신호이지만 정확성 자체는 아니다.

 

특히 프롬프트와 검색 문서가 동일하다면 응답들의 오류가 서로 독립이라고 가정하기 어렵다. 열 번 같은 답이 나왔다고 독립된 전문가 열 명이 다른 자료로 확인한 것과 같아지지는 않는다. 단순 다수결의 숫자가 커질수록 사실이 더 확실해진다고 설명하면 검증의 강도를 과장할 수 있다.

표현이 다르다는 이유만으로 의견이 다르다고 볼 수도 없다. “반품 가능 기간은 30일”과 “구매 후 한 달 안에 신청”은 비슷하게 들려도 정확한 의미는 다를 수 있다. 여러 샘플을 비교하려면 문장 표면뿐 아니라 주장과 조건을 구분해야 한다. 의미를 묶는 과정 자체에도 오류가 생길 수 있다.

 

추가 모델을 검증자로 쓰는 방법도 한계가 있다. 검증자가 같은 잘못된 근거를 받거나 자연스러운 설명에 높은 점수를 주면 오류를 그대로 통과시킬 수 있다. 가능하면 원본 데이터 조회나 계산 검사처럼 다른 종류의 확인을 결합하는 편이 좋다. 모델을 하나 더 호출했다는 사실만으로 독립적인 사실 확인이 완료되지는 않는다.

 

검증을 무한히 반복하는 것도 해법이 아니다. 추가 호출의 비용과 지연이 늘고, 근거가 부족한 문제에서는 새 정보 없이 설명만 길어질 수 있다. 확인할 수 있는 것과 없는 것을 구분하고 호출 예산과 종료 조건을 정해야 한다. 추가 확인이 실패했을 때 보류하는 경로가 있어야 반복이 목적이 되는 상황을 줄일 수 있다.

선택적 응답은 오류와 응답 범위를 함께 측정한다

선택적 응답은 모든 요청에 답하는 대신 정한 기준을 충족한 요청에 답하는 구성이다. 이때 자주 함께 보는 개념이 커버리지와 선택적 위험이다. 이 글에서 커버리지는 전체 평가 요청 중 시스템이 답변한 비율, 선택적 위험은 답변한 요청 안에서 틀린 비율로 정의한다. 답변과 보류를 무엇으로 분류했는지 먼저 고정해야 한다.

 

가상의 평가 요청이 100개라고 하자. 시스템이 80개에 답했고 그중 8개가 틀렸다면 커버리지는 80%, 답변한 집단의 오류율은 10%다. 기준을 더 엄격하게 해서 50개에 답하고 2개가 틀리면 커버리지는 50%, 해당 집단의 오류율은 4%다. 이 수치는 계산 예시이며 실제 모델 성능이 아니다.

 

두 번째 시스템의 응답 오류율이 낮아졌지만 사용자 요청을 더 많이 보류했다. 따라서 오류율 4%만 보고 무조건 더 좋다고 결론 내릴 수는 없다. 보류된 요청 중 원래 쉽게 답할 수 있던 것이 얼마나 있는지, 사람이 처리할 부담이 얼마나 늘었는지 살펴봐야 한다. 응답 범위와 위험을 함께 비교해야 선택이 의미를 갖는다.

 

임계값을 바꾸면서 이 관계를 살펴보면 운영 지점을 고를 수 있다. 다만 기준을 엄격하게 한다고 항상 오류가 깔끔하게 줄어드는 것은 아니다. 점수가 실제 오류를 잘 구분하지 못하면 어려운 질문을 남기고 쉬운 질문을 보류할 수도 있다. 점수의 순위 품질과 보정 품질을 구분해 평가해야 한다.

 

또한 답할 수 없는 질문에 대한 적절한 보류를 별도로 본다. 질문 자체에 정보가 없거나 평가 범위 밖인 사례를 넣지 않으면 시스템이 모를 때 어떻게 행동하는지 알 수 없다. 모든 평가 문제가 답을 갖고 있으면 보류의 가치를 측정하기 어렵다. 실제 사용에서 발생하는 모호함과 자료 부재를 평가군에 반영해야 한다.

보정은 숫자 하나보다 평가 집단과 조건의 문제다

확신도 점수를 검증할 때는 질문 유형별로 나눠 보는 편이 좋다. 쉬운 FAQ가 많은 전체 평균은 좋아도 날짜 조건이나 계산이 필요한 질문에서는 과신할 수 있다. 한국어 업무 용어, 영문 제품 코드, 부정 표현, 예외 규정이 섞인 입력을 따로 확인하면 평균 뒤의 실패를 발견하기 쉽다.

보정을 요약하는 방법으로 구간별 예상 신뢰도와 실제 정답률의 차이를 볼 수 있다. 확률 예측과 실제 결과의 오차를 다루는 Brier score 같은 지표도 사용할 수 있다. 다만 어느 지표도 혼자서 도메인 적합성을 보장하지 않는다. 구간을 나누는 방식과 표본 수, 정답 기준에 따라 해석이 달라질 수 있다.

 

확률 점수의 품질과 답변 품질도 다르다. 항상 낮은 확률을 주면 과신은 줄어 보일 수 있지만 유용한 답을 구분하는 데 도움이 되지 않을 수 있다. 모든 요청에 비슷한 점수를 주는 모델은 전체 평균에 맞아 보여도 개별 요청의 우선순위를 정하는 능력이 약할 수 있다. 보정과 구분 능력을 함께 보자.

 

임계값이나 점수 변환을 정한 평가 자료와 최종 성능을 확인할 자료는 나누는 편이 좋다. 같은 사례에 맞춰 기준을 계속 조정한 뒤 그 사례에서 좋은 결과를 보고하면 실제 개선을 과대평가할 수 있다. 모델과 프롬프트, 검색 구성과 문서 버전도 함께 남겨야 나중에 비교가 가능하다.

 

운영 환경의 변화도 중요하다. 상품이나 규정이 바뀌고 새 유형의 질문이 들어오면 이전 평가에서 맞았던 점수 관계가 흔들릴 수 있다. 점수 0.9가 언제나 같은 의미를 유지한다고 가정하지 말자. 변경 이후 대표 평가군과 실제 사례를 다시 확인하고 보류 정책도 함께 점검해야 한다.

한국어 업무 에이전트의 답변 경계를 만드는 예시

가상의 고객지원 에이전트가 “작년에 산 기업용 상품도 지금 환불되나요?”라는 질문을 받았다고 하자. 이 요청에는 구매일의 정확한 시점, 상품과 계약 종류, 적용 약관이 필요할 수 있다. 모델에게 답과 확신도만 요구하면 익숙한 일반 환불 정책을 설명하고 높은 점수를 붙일 수 있다. 먼저 필요한 조건을 확인하는 구조가 더 직접적이다.

 

시스템은 확인된 항목과 누락된 항목을 구분할 수 있다. 상품이 정확히 식별되는지, 계약 시점이 있는지, 관련 약관을 조회할 권한이 있는지 확인한다. 누락된 정보가 답에 영향을 준다면 짧은 확인 질문을 한다. 이미 대화나 인증된 업무 시스템에 있는 정보를 매번 다시 묻지 않도록 하는 것도 중요하다.

 

필요한 입력이 확보되면 관련 약관과 예외를 조회하고 적용 기간과 대상을 대조한다. 규정이 충돌하거나 특정 계약의 예외가 확인되지 않으면 단정하지 않는다. 여기서 보류 이유는 모델이 막연히 불안해서가 아니라 필요한 판단 조건이 충족되지 않았기 때문이다. 운영자가 실패를 조사할 때도 이 구분이 도움이 된다.

 

답변 가능한 상태라면 확인한 근거와 조건을 함께 제시한다. “구매일과 계약 유형에 맞는 약관에서 해당 조항이 확인된다”는 식으로 적용 기준을 드러낼 수 있다. 단, 정책 설명과 실제 환불 실행은 다르다. 답이 맞을 가능성에 관한 점수가 변경 작업의 권한을 자동으로 부여하지는 않는다.

 

추가 조회가 실패하면 미확인과 불가를 구분한다. 주문 서버가 응답하지 않는 상황에서 “환불할 수 없습니다”라고 말하는 대신, 현재 조회를 완료하지 못해 적용 여부를 확인할 수 없다고 안내할 수 있다. 이런 경로가 있어야 도구 장애가 사실 판단으로 위장되는 문제를 줄일 수 있다. 예시의 규칙은 실제 서비스 정책에 맞춰 구체화해야 한다.

프롬프트에는 겸손한 말투보다 실행 가능한 조건을 넣자

“모르면 모른다고 하라”는 지시는 유용한 출발점일 수 있지만 충분한 실행 규칙은 아니다. 무엇을 모른다고 판단해야 하는지, 추가로 확인할 수 있는 도구가 있는지, 답변의 어느 부분을 보류해야 하는지 정해 주지 않으면 응답이 일관되지 않을 수 있다. 말투를 조심스럽게 만드는 것과 잘못된 단정을 줄이는 것은 다르다.

 

예를 들어 “결론에 필요한 적용 대상과 날짜가 확인되지 않으면 단정하지 않는다. 대화에서 확인되지 않은 필수 조건을 질문한다. 근거에서 확인한 사실과 추정을 구분한다”처럼 기준을 구체화할 수 있다. 이 지시가 실제로 잘 작동하는지는 평가해야 하며, 문장만 추가했다고 준수가 보장되지는 않는다.

 

답변 형식도 근거와 미확인 항목이 연결되게 만들 수 있다. 확인된 사실, 필요한 조건, 추가 확인 방법을 구분하면 사용자가 빈칸을 이해하기 쉽다. 그러나 항목이 구조화되어 있다는 사실 자체가 내용의 정확성을 보장하지는 않는다. 출력 형식 검증과 내용 검증은 각각 필요하다.

 

정확한 수치가 필요한 작업은 가능한 경우 원본 데이터와 계산 도구를 사용하도록 한다. 출처가 없는 숫자를 적당히 채우지 않게 하고, 단위와 기준일을 함께 확인한다. 계산 결과를 받았더라도 잘못된 입력이나 필터가 들어갔는지는 별도로 보아야 한다. 도구를 썼다는 문구보다 어떤 조건으로 무엇을 확인했는지가 중요하다.

 

또한 사용자 요청이 충분히 명확하고 근거가 확보된 일까지 반복해서 되묻지 않도록 해야 한다. 보류는 일을 피하는 기본 응답이 아니라 해결되지 않은 조건에 대응하는 선택이어야 한다. 이미 허용된 범위와 확인된 사실을 활용해 진행하고, 결론에 영향을 주는 부족한 정보에만 질문을 집중하는 편이 실용적이다.

운영에서는 보류의 품질과 복구 경로까지 확인하자

운영 로그에는 답변 여부만이 아니라 보류의 이유와 이후 결과를 구분해 남길 수 있다. 입력 부족, 근거 부재, 자료 충돌, 도구 실패, 권한 제한처럼 유형이 나뉘면 개선할 위치를 찾기 쉽다. 실제 고객 원문을 모두 저장할 필요는 없으며 진단에 필요한 정보와 개인정보 보호를 함께 설계해야 한다.

 

보류 뒤 사용자가 질문에 답했는지, 추가 검색으로 해결했는지, 담당자 연결이 필요했는지 살펴보자. 보류 자체는 적절했지만 안내가 불분명해 사용자가 포기했다면 제품 경험은 나쁠 수 있다. 오류를 줄이는 것과 문제 해결을 돕는 것을 함께 평가해야 한다. 보류 문장의 친절함만으로 완료를 판단하지 않는 것이 좋다.

 

중요한 업무에서는 틀린 단정의 영향을 별도로 고려할 수 있다. 사소한 설명의 누락과 잘못된 금액이나 권한 판단은 같은 비용을 갖지 않는다. 다만 영향을 평가한다고 모든 요청에 무조건 경고나 사람 승인을 넣을 필요는 없다. 업무 목적과 이미 부여된 권한, 확인 가능한 근거에 맞춰 대응을 조절해야 한다.

 

새로운 정책을 도입할 때는 기존 방식과 같은 질문군으로 비교하자. 답변한 집단의 오류율이 줄었는지, 답할 수 있는 요청을 과도하게 보류하지는 않는지, 추가 도구 호출과 지연이 늘었는지 확인한다. 개선 수치는 표본과 평가 기준을 함께 제시해야 다른 업무의 보장처럼 읽히지 않는다.

 

가장 피해야 할 것은 “확신도 필드를 추가했으니 신뢰성이 해결되었다”는 결론이다. 점수는 평가할 가설이고, 보류는 설계할 행동이며, 사실성은 확인할 결과다. 이 세 가지를 구분하면 프롬프트를 더 길게 쓰는 것만으로 해결되지 않는 문제를 운영 가능한 절차로 바꿀 수 있다.

자주 묻는 질문

Q. 모델이 95% 확신한다고 했으면 거의 맞는 것 아닌가요?

그 숫자가 무엇을 의미하고 어떤 자료에서 검증되었는지 확인해야 한다. 단순히 생성된 자기 보고 숫자는 실제 정답률과 일치한다고 보장되지 않는다. 특정 평가 집단에서 보정되었더라도 다른 업무와 질문 분포에서 다시 확인할 필요가 있다.

Q. 온도를 0으로 낮추면 환각이 없어지나요?

아니다. 출력의 무작위성이 줄어도 같은 오답을 일관되게 생성할 수 있다. 온도 조정은 정답 검증이나 확률 보정과 같은 작업이 아니다. 근거와 조건, 계산 및 실제 결과를 확인하는 과정이 필요하다.

Q. RAG 검색 점수가 높으면 바로 답해도 되나요?

검색 점수는 관련성을 나타내는 신호이며 보통 최종 답변의 정답 확률이 아니다. 제품과 날짜, 적용 범위, 예외가 맞는지와 필요한 근거가 모두 있는지 확인해야 한다. 출처 링크가 있다는 사실만으로 주장 전체가 검증되지는 않는다.

Q. 여러 번 같은 답이 나오면 사실이라고 봐도 되나요?

같은 모델과 근거를 반복 사용하면 오류도 반복될 수 있다. 일관성은 진단 신호가 될 수 있지만 독립 검증을 대신하지 않는다. 원본 조회나 계산 검사처럼 다른 종류의 확인을 함께 고려하는 편이 좋다.

Q. 보류를 많이 하면 더 신뢰할 수 있는 AI인가요?

보류가 늘면 답변 집단의 오류가 줄 수 있지만 해결 가능한 요청까지 막을 수 있다. 응답 범위와 답변한 집단의 오류율, 적절한 보류와 불필요한 보류를 함께 평가해야 한다. 보류 이후의 문제 해결 경로도 중요하다.

Q. 모든 답변에 확신도 숫자를 보여 주는 편이 좋은가요?

검증되지 않은 숫자는 오히려 잘못된 신뢰를 만들 수 있다. 사용자가 의미를 이해하고 실제 평가로 유용성이 확인된 경우에 활용하는 것이 좋다. 확인한 근거와 적용 조건, 남은 불확실성을 명확히 보여 주는 방식이 더 직접적인 상황도 있다.

신뢰할 수 있는 AI는 모를 때의 행동도 설계되어 있다

LLM의 확신은 말투, 생성 확률, 검색 점수, 자기 평가, 실제 정답률이라는 서로 다른 층위에서 나타난다. 숫자가 붙었다고 같은 값이 되지는 않는다. 무엇을 측정하는지 정의하고 실제 업무 자료에서 확인해야 점수가 의사결정에 도움이 된다. 검증하지 않은 95%는 검증의 대체물이 될 수 없다.

 

답변 보류도 단순한 거절이 아니다. 필요한 조건을 묻고, 확인 가능한 정보를 조회하고, 확인할 수 없는 부분은 분명하게 남기는 행동이다. 답해야 할 때는 답하고 모를 때는 해결 경로를 제시하는 구조를 평가해야 한다. 신뢰할 수 있는 AI 에이전트의 품질은 정답을 만드는 순간과 답을 확정하지 않는 순간을 함께 설계할 때 높아진다.

원자료와 국내 기술 블로그 참고 자료

OpenAI, Why language models hallucinate. 2025년 9월 5일 공개. 추측을 보상할 수 있는 평가 구조와 정답, 오류, 기권을 구분하는 관점을 확인했다. 발표 당시 특정 모델의 평가 수치를 현재 서비스의 보장된 성능으로 인용하지 않았다. 원문: https://openai.com/index/why-language-models-hallucinate/

Saurav Kadavath 외, Language Models (Mostly) Know What They Know. 2022년 논문 초록에서 언어모델 자기 평가와 보정의 가능성, 새로운 과제에서의 보정 어려움을 확인했다. 특정 형식의 실험 결과를 모든 자기 보고 확신도의 신뢰성으로 일반화하지 않았다. 원문: https://arxiv.org/abs/2207.05221

 

한컴테크, 최신 논문 분석을 통한 LLM의 환각 현상 완화 전략 탐구. 2025년 7월 17일 게시. 지식 경계와 답변 보류, 검색과 검증을 연결하는 국내 기업 기술 블로그의 전개를 비교했다. 소개된 개별 논문의 성능 수치를 이 글의 자체 실험 결과나 모든 모델의 결과로 사용하지 않았다. 원문: https://tech.hancom.com/llm-hallucination-reduction-research/

최신 논문 분석을 통한 LLM의 환각 현상 완화 전략 탐구

 

Deskroom, LLM의 환각, 피할 수 없다면 관리하세요. 2025년 9월 7일 게시. 환각 연구를 기업 데이터와 업무 해석의 문제로 연결하는 설명 형식을 비교했다. 학습 방식에 대한 해석과 제품 설명은 원자료의 주장 및 보장과 구분했다. 원문: https://blog.deskroom.so/platform/why-language-models-hallucinate