충실도 게이트(Faithfulness gate): 대부분의 팀이 건너뛰는 에이전트 계층
요약
AI 에이전트의 환각 문제를 해결하기 위해 응답이 검색된 컨텍스트에 근거하는지 검증하는 '충실도 게이트(Faithfulness gate)' 도입을 제안합니다. 이는 모델의 크기를 키우는 대신, 응답 내 원자적 주장을 추출하여 컨텍스트와 대조함으로써 프로덕션 환경의 신뢰성을 높이는 핵심 전략입니다.
핵심 포인트
- 충실도는 정답지 없이 검색된 컨텍스트만으로 검증 가능함
- 응답에서 원자적 주장을 추출해 컨텍스트와 대조하는 방식 사용
- 임계값(Threshold) 설정을 통해 사용자 경험과 정확도 사이의 균형 조절
- 단순히 더 큰 모델을 쓰는 것보다 검증 계층을 두는 것이 효과적임
한 B2B SaaS 팀은 지난 분기에 고객으로부터 화가 난 이메일을 받았습니다. 고객의 어카운트 팀이 회사의 AI 어시스턴트에게 자신들의 플랜에 SSO가 포함되어 있는지 물었습니다. 어시스턴트는 그렇다고 답했습니다. 고객의 IT 팀은 이를 설정하기 위해 이틀을 소비하며 지원 팀에 문제를 에스컬레이션(escalate)했고, 어시스턴트가 틀렸다는 사실을 발견했습니다. SSO는 Enterprise 티어에 포함되어 있었습니다. 고객은 Pro 티어를 사용 중이었습니다. 어시스턴트는 문서를 검색했지만 어떤 티어에 SSO가 포함되어 있는지에 대한 결정적인 정보를 찾지 못했고, 학습 데이터(training data)에서 그럴듯해 보이는 내용을 바탕으로 유창한 답변을 생성했습니다. 사용자는 그것이 환각(hallucination)인지 알 방법이 없었습니다.
해결책은 "더 나은 모델"이 아니었습니다. 더 큰 LLM(Large Language Model)이었다면 동일한 불충분한 컨텍스트(context)를 가지고 더 자신 있게 환각을 일으켰을 것입니다. 해결책은 첫날부터 있었어야 할 계층, 즉 에이전트의 응답을 사용자에게 전달하기 전에 해당 응답이 검색된 컨텍스트에 실제로 근거(grounded)하고 있는지 확인하는 충실도 게이트(faithfulness gate)였습니다. 이는 프로덕션(production) AI 에이전트를 위한 가장 레버리지가 높은 개입 중 하나입니다. 대부분의 팀은 고객이 불만을 제기하기 전까지는 실패 모드(failure mode)가 보이지 않기 때문에 이를 건너뜁니다.
충실도(Faithfulness)가 실제로 측정하는 것
충실도는 단 하나의 질문으로 정의됩니다: 에이전트의 응답이 에이전트가 검색한 컨텍스트에 의해 뒷받침되는 주장을 하고 있는가? 만약 에이전트가 지식 베이스(KB)를 검색하여 "Pro 티어는 기본 기능 X, Y, Z를 포함합니다. Enterprise 티어는 X, Y, Z와 SSO를 포함한 고급 기능 A, B, C를 포함합니다"라는 내용을 찾았다면, "귀하의 Pro 플랜에는 SSO가 포함되어 있습니다"라고 답하는 것은 불충실(unfaithful)한 것입니다. 검색된 컨텍스트가 해당 주장을 뒷받침하지 않기 때문입니다.
이는 "응답이 정확한가(is the response correct)"와는 다릅니다. 정확성(Correctness)은 정답(ground truth)을 필요로 합니다. 반면 충실도(Faithfulness)는 오직 검색된 컨텍스트만을 필요로 합니다. 이는 인간의 개입(human in the loop) 없이도 확인할 수 있습니다.
작동 방식: 응답에서 원자적 주장(atomic claims)을 추출하고, 각 주장을 검색된 컨텍스트와 대조하여 점수를 반환합니다. 임계값(threshold) 미만일 경우, 해당 응답은 불충실한 것으로 간주되어 사용자에게 전달되어서는 안 됩니다.
게이트가 실제로 작동하는 방식
패턴은 간단합니다:
- 에이전트(Agent)가 검색된 컨텍스트(context)를 기반으로 응답을 생성합니다.
- 별도의 LLM 호출(
사소하게 근거가 부족한 표현이 포함되어 있더라도 정당한 응답을 거부하지 않으면서, 대부분의 확신에 찬 환각(hallucination)을 잡아냅니다. 0.70에서 0.85 사이: 더 허용적인 설정입니다. 사용자가 스스로 검증할 수 있는 내부 도구(internal tools)나, 너무 많은 응답을 거부하여 사용자 경험(UX)을 해칠 수 있는 초기 단계 제품에 사용하세요. 0.70 미만: 사실상 비활성화된 상태입니다. 고객 대상 서비스(customer-facing)에는 권장되지 않습니다. 저희가 협업한 팀은 B2B SaaS 분야에 있었습니다. 초기에는 임계값(threshold)을 0.88로 설정하고 거부율(응답의 약 6%)을 모니터링했으며, 일주일 후 거부율이 사용자 경험에 너무 공격적이라고 판단되어 0.85로 조정했습니다.
게이트가 실패했을 때 대처 방법: 응답이 충실도 검사(faithfulness check)를 통과하지 못할 경우 에이전트(Agent)에게는 세 가지 옵션이 있습니다:
- 보강된 컨텍스트(augmented context)로 재시도: 에이전트가 실패 원인을 반영한 쿼리(query)로 다시 검색합니다. 때로는 원래의 검색(retrieval)이 불충분했을 수 있으며, 두 번째 시도가 누락된 컨텍스트를 찾아낼 수 있습니다. 최대 두 번까지만 재시도하세요. 그 이상 루프(loop)를 돌지 마십시오.
- "이 질문에 대해 확신을 가지고 답변할 수 없습니다."라고 반환: 한계를 솔직하게 밝히는 방식입니다. 이는 팀이 해결할 수 있는 실제 제품 문제(불충분한 문서화, 모호한 쿼리 등)를 드러내 줍니다. 확신에 찬 틀린 답변을 내놓는 것보다 훨씬 낫습니다.
- 사람에게 전달(Escalate to human handoff): 에이전트가 검색된 컨텍스트를 첨부하여 질문을 상담원에게 전달합니다. "모릅니다"라는 답변이 허용되지 않는 고객 대상 시스템에서 유용합니다.
프로덕션 팀은 이 세 가지를 모두 배포합니다. 먼저 재시도하고(비용이 저렴하며 종종 해결됨), 저위험 상황에서는 솔직한 "모릅니다"로 폴백(fallback)하며, 고위험 상황이나 반복되는 질문에 대해서는 사람에게 전달합니다.
해당 팀을 위해 저희가 배포한 내용: 기존 시스템은 문서를 기반으로 한 RAG(Retrieval-Augmented Generation) 방식의 고객 지원 에이전트였습니다. 저희는 다음을 추가했습니다:
- 모든 응답에 대해 GPT-4o-mini를 판정 모델(judge model)로 사용하는 충실도 검사(Faithfulness check) 적용
- 프로덕션 응답을 위한 0.85의 임계값(threshold) 설정
- 첫 번째 응답이 검사를 통과하지 못할 경우, 보강된 검색(augmented retrieval)을 통한 1회 재시도
- 솔직한 폴백("저희 문서에서 해당 특정 정보를 찾을 수 없습니다.")
두 번 실패한 응답에 대해서는 "상담원에게 연결해 드릴까요?"라고 제안합니다. 모든 충실도 검사(faithfulness check) 실패 사례를 기록하여, 팀이 패턴을 검토하고 문서 커버리지(documentation coverage)를 개선할 수 있도록 합니다. 고객이 보고한 오답은 첫 달에 60% 감소했습니다. 충실도 게이트(faithfulness gate)가 추상적인 의미에서의 정확도(correctness)를 향상시킨 것은 아닙니다. 그저 시스템이 잘못된 답변을 고객에게 자신 있게 전달하는 것을 막았을 뿐입니다. 솔직한 "모릅니다"라는 응답에 대해서는 초기에는 (사용자들이 불쾌해하지 않을까?) 하며 우려했지만, 결과적으로는 긍정적인 반응을 얻었습니다. 사용자들은 빠른 답변을 원한다고 생각할 때조차 오답보다는 "모릅니다"를 선호합니다. 예상치 못한 이점은 검사 실패 로그(failed-check log)였습니다. 팀은 이제 문서가 자신 있게 답변할 수 없었던 모든 질문의 목록을 갖게 되었습니다. 이것이 문서 백로그(documentation backlog)가 되었습니다. 6개월이 지난 시점에서, 고객 보고 이슈는 게이트 도입 전 기준치 대비 80% 감소했는데, 이는 부분적으로는 게이트 덕분이고, 부분적으로는 게이트를 통해 드러난 문서 개선 작업 덕분이었습니다.
게이트만으로는 충분하지 않을 때
충실도 게이트는 한 가지 특정한 실패 모드, 즉 검색된 컨텍스트(retrieved context)에 의해 뒷받침되지 않는 주장을 방지합니다. 하지만 다음과 같은 사항은 잡아내지 못합니다:
- 잘못된 컨텍스트 검색: 만약 RAG 파이프라인이 잘못된 문서를 가져왔다면, 응답은 잘못된 소스에는 충실할 것입니다. 이에 대한 평가(eval)가 필요합니다.
- 오래된 컨텍스트: 6개월 전에는 정확했지만 지금은 쓸모없어진 문서에는 충실할 것입니다. 버전 관리(versioning)와 최신성 추적(freshness tracking)이 필요합니다.
- 미묘하게 틀린 추론: 컨텍스트에 의해 뒷받침되는 주장이라 하더라도, 그 사이의 추론(inference)이 유효하지 않을 수 있습니다. 더 강력한 평가, 어쩌면 인간의 검토(human review)가 필요합니다.
게이트는 프로덕션 신뢰성(production reliability)을 위해 필요하지만 충분하지는 않습니다. 이는 가장 영향력이 큰 단일 개입(intervention)이지만, 유일한 개입은 아닙니다.
Sapota의 권장 사항
사실 관계를 다루는 프로덕션 에이전트(고객 지원, 내부 지식, 컴플라이언스, 오류 발생 시 비용이 발생하는 모든 분야)를 위한 지침:
- 응답 경로(response path)에 충실도 게이트(faithfulness gate)를 추가하십시오.
- 비용을 낮게 유지하기 위해 저렴한 판별 모델(judge model, 예: GPT-4o-mini, Haiku)을 사용하십시오.
- 임계값(threshold)을 0.85로 설정하여 시작하고, 거부율(rejection rate)에 따라 조정하십시오.
- 1회 재시도(retry-once) 및 정직한 폴백(honest-fallback) 정책을 구현하십시오.
- 문서 개선을 위해 모든 실패 사례를 기록하십시오.
인프라 비용은 응답당 약 $0.001입니다. 고객이 보고하는 오류의 감소율은 첫 달에 통상적으로 40~60%에 달합니다. 이는 프로덕션 단계의 B2B 에이전트에게 선택 사항이 아닙니다. 데모를 제품으로 바꾸는 계층입니다.
만약 당신의 에이전트가 자신 있게 틀린 답을 내놓고 있다면
만약 당신의 팀이 AI 어시스턴트의 잘못된 답변에 대한 고객 보고를 받았고, "더 나은 모델로 교체하겠다"는 조치로도 해결되지 않았다면, 누락된 계층은 거의 확실히 충실도 검사(faithfulness checking)입니다.
Sapota는 기존 에이전트에 충실도 검사를 추가하고, 과거 보고 데이터를 바탕으로 임계값을 보정하며, 재시도 및 폴백 로직을 작동 가능한 PR(Pull Request) 형태로 전달하는 1주일 단위의 구현 엔게이지먼트(implementation engagement)를 제공합니다. 우리는 고객 지원 에이전트, 내부 지식 베이스, 컴플라이언스 도구를 대상으로 이 작업을 수행해 왔습니다.
에이전트가 내놓았던 잘못된 응답 사례 몇 가지를 준비하여 AI 엔지니어링 페이지를 통해 문의해 주십시오. 진단 과정(diagnostic conversation)을 통해 충실도 격차(faithfulness gap)와 게이트가 노출하는 데 도움이 될 문서 격차(documentation gaps)를 모두 파악할 수 있습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기