AI 환각 잡기: B2B 팀을 위한 3가지 가드레일

실제 B2B 워크플로에서 AI 환각은 어떻게 나타나는가

환각은 모델이 자신감 있게 들리지만 틀린 답을 생성하는 현상입니다. B2B에서는 세 가지 전형적 형태로 나타납니다: (1) 지원 문의에 대해 존재하지 않는 주문 번호를 만들어내기, (2) 계약을 요약할 때 실제로 계약에 없는 날짜를 "인용"하기, (3) 정의된 집합 밖의 새로운 카테고리를 발명해 송장을 분류하기.

세 가지 모두 같은 패턴을 공유합니다: 확실한 근거를 찾지 못하면 모델은 공백을 채웁니다. 문제는 출력이 확신에 차 보인다는 점입니다 — 틀렸을 때조차. 단순히 "AI가 틀렸다"고 말하는 것만으로는 문제를 바로잡기 어렵습니다. 어디서 왜 틀렸는지 확인해야 합니다. 다음 세 가지 안전장치가 이를 돕습니다.

세 가지 가드레일: 출처, 규칙, 사람

출처 확인: 답변을 뒷받침하는 문서와 구절을 제시하고, 인용이 존재하는지만이 아니라 주장을 실제로 뒷받침하는지 확인합니다. 근거가 없거나 충돌하면 검토로 넘깁니다.

규칙 확인: 애플리케이션 코드에서 주문의 존재, 사용자 권한, 금액, 허용된 분류를 검증합니다. 형식이 올바르다고 사실까지 맞는 것은 아닙니다.

사람의 승인: 결제, 환불, 구속력 있는 메시지 전송 전에 권한 있는 담당자가 정확한 최종 출력을 확인해야 합니다. 변경된 출력은 재승인이 필요합니다. 보편적인 성공률은 없습니다. 정답, 오답, 출처 없는 사례로 잘못된 출력이 차단되고 검토 대기열의 항목이 담당자에게 전달되는지 시험하세요.

출시 전에 평가(eval) 프로세스를 구축하기

출력만 눈으로 확인해서는 AI 환각 발생률을 측정할 수 없습니다. 정답이 알려진 실제 사례 50~200개로 기준 테스트 세트를 만들고, 데이터 누락, 모호한 질문, 범위를 벗어난 요청 같은 예외 사례를 포함하세요. 프롬프트나 모델을 변경한 뒤에는 변경된 버전을 이 테스트 세트로 평가하고, 배포 전에 결과를 검토하세요. 최초 출시 때만 시험해서는 안 됩니다.

답변 정확도와 답변 보류율(abstention rate)을 따로 추적하세요. 답변 보류율은 모델이 답하지 않기로 선택하는 빈도이며, 그 선택이 적절했는지를 뜻하지 않습니다. 답변을 멈춰야 할 때 멈추는지, 정보가 충분할 때는 답변하는지도 별도로 검토하세요. 전혀 답변을 보류하지 않으면 위험이 커질 수 있지만, 보류율이 높다고 자동으로 더 안전한 것은 아닙니다. 오답과 불필요한 답변 보류의 비용, 검토 결과를 함께 고려해 임계값을 정하세요.

적대적 테스트는 일반 사례 테스트만큼 중요합니다. 존재하지 않는 대상에 관한 질문, 서로 다른 두 기록을 합치라는 요청, 원본 문서의 범위를 넘어선 추론 등 AI 환각을 유발할 수 있는 입력으로 시험하세요. 통제된 테스트에서 오류를 안전하게 처리하지 못한다면 실제 운영에서도 안전하게 처리할 것이라고 가정해서는 안 됩니다.

평가를 일회성 관문이 아니라 지속적인 절차로 운영하세요. 프롬프트, 모델 또는 문서 출처가 바뀌면 변경된 버전에서 평가 세트를 다시 실행하세요. 배포 전에 정확도, 답변 보류 빈도, 보류 판단의 적절성을 기준값과 비교하세요. 일반 소프트웨어의 회귀 테스트처럼 지속적으로 수행하되, 여기서는 로직과 판단의 품질을 모두 점검합니다.

어떤 작업에서 AI 환각 위험이 가장 높은가

자유 서술인지 구조화된 형식인지만으로 위험을 판단하지 마세요. 허용된 분류에 들어간 잘못된 회계 기록도 피해를 줍니다. 영향, 되돌릴 수 있는지, 데이터 민감도, 결과 이용자를 평가하세요. 초안 작성 흐름에 고객 연락이나 자금 이동과 같은 권한을 주어서는 안 됩니다.