메인으로
지유 · 최고기술책임자(CTO) · 오늘의 기술 칼럼

환각을 세지 말고 나누기: 유형별 감사의 설계

환각률 하나로 뭉뚱그리면 무엇을 고쳐야 할지 알 수 없습니다. 없는 근거를 만든 것과 있는 근거를 잘못 붙인 것은 다른 고장이며, 대책도 다릅니다. 유형별 감사의 구조를 살펴봅니다.

초록 법률 AI의 신뢰성을 이야기할 때 가장 흔히 쓰이는 수치는 환각률입니다. 그러나 이 하나의 숫자는 서로 다른 고장을 같은 칸에 넣습니다. 존재하지 않는 조문을 만들어 낸 답변과, 실재하는 판례를 엉뚱한 쟁점에 붙인 답변은 원인도 대책도 다릅니다. 최근 연구는 환각을 유형으로 나누어 감사하고, 유형별로 다른 탐지 경로를 두는 방향을 제안합니다. 이 칼럼은 법률 도메인에서 의미 있는 유형 구분이 무엇인지, 각 유형이 파이프라인의 어느 단계에서 생기는지, 그리고 그 대응을 어떻게 배치해야 하는지를 정리합니다.

환각률이 낮아졌다는 보고를 받으면 안심이 되지만, 그 숫자만으로는 다음에 무엇을 해야 할지 알 수 없습니다. 줄어든 것이 어떤 종류의 오류인지 모르기 때문입니다. 실제로 법률 답변에서 발생하는 잘못은 성격이 크게 갈립니다. 어떤 답변은 존재하지 않는 조문 번호를 만들어 냅니다. 어떤 답변은 실재하는 판례를 인용하지만 그 판례가 다루지 않은 쟁점에 붙입니다. 또 어떤 답변은 근거를 정확히 인용하고도 그 근거가 지지하지 않는 결론으로 건너뜁니다. 세 가지는 사용자에게 비슷하게 보이지만 시스템 안에서는 전혀 다른 곳에서 생깁니다. 첫째는 생성 단계의 문제이고, 둘째는 검색과 귀속의 문제이며, 셋째는 추론의 문제입니다. 뭉뚱그린 지표는 이 셋을 한 칸에 넣어 개선의 방향을 지웁니다. 오늘은 그 칸을 나누는 작업을 다뤄 보겠습니다.

핵심 기술 개념

유형화된 환각 감사

오류를 하나의 비율로 세는 대신 발생 원인에 따라 분류해 각각의 빈도와 심각도를 따로 기록하는 방식입니다. 어느 단계를 고쳐야 하는지가 지표에서 바로 드러나게 만드는 것이 목적입니다.

귀속 오류(misattribution)

인용한 근거 자체는 실재하지만 그 근거가 해당 주장을 뒷받침하지 않는 경우입니다. 존재 검증만으로는 걸러지지 않으며, 근거 본문과 주장 사이의 내용 대조가 있어야 탐지됩니다.

보정된 탐지

탐지기가 내놓는 확신도가 실제 정확도와 어긋나지 않도록 맞추는 작업입니다. 보정되지 않은 탐지기는 확신에 찬 오탐을 만들어 정상 인용을 제거하거나, 반대로 위험한 오류를 통과시킵니다.

기술 심층 분석

1

1. 세 가지 고장은 서로 다른 층에서 생긴다

법률 답변의 오류를 원인별로 나누면 대체로 세 층으로 정리됩니다. 첫째는 근거의 조작입니다. 존재하지 않는 조문 번호나 사건번호가 생성되는 경우로, 원인은 생성 단계에 있습니다. 둘째는 근거의 오귀속입니다. 실재하는 판례를 인용하지만 그 판례의 판시가 해당 쟁점과 무관한 경우로, 검색이 잘못된 후보를 올렸거나 생성이 컨텍스트 안의 엉뚱한 조각을 집은 결과입니다. 셋째는 추론의 비약입니다. 근거는 정확히 인용했는데 그 근거가 지지하지 않는 결론으로 넘어가는 경우입니다. 세 층은 같은 증상을 보이지만 대책이 다릅니다. 첫째는 존재 검증으로 완전히 막을 수 있고, 둘째는 내용 대조가 필요하며, 셋째는 근거와 결론 사이의 논리적 연결을 따로 검사해야 합니다. 환각률 하나로 보고하면 어느 층이 개선되었는지 알 수 없습니다.

2

2. 존재 검증으로 끝나지 않는 이유

많은 시스템이 인용의 실존 확인을 마치면 검증이 끝났다고 여깁니다. 그러나 존재 검증은 첫 번째 층만 막습니다. 실무에서 더 자주 그리고 더 은밀하게 나타나는 것은 두 번째 층입니다. 실재하는 판례가 인용되어 있으니 사용자는 확인 없이 신뢰하고, 사건번호를 눌러 원문을 열어 보는 사람은 드뭅니다. 그런데 그 판례가 다루는 쟁점이 다르면 답변의 결론은 근거를 잃습니다. 이 유형을 잡으려면 인용된 근거의 본문, 특히 판시 부분과 그 인용이 놓인 문장의 맥락을 대조해야 합니다. 저희 파이프라인이 인용 판례의 판시사항을 가져와 국소 맥락과 일치를 확인하는 것도 이 때문입니다. 존재만 확인하고 통과시키면 시스템은 실재하지만 무관한 근거로 그럴듯하게 포장된 답변을 계속 생산하게 됩니다.

3

3. 탐지기의 확신도를 믿을 수 있는가

유형별 탐지를 도입하면 곧바로 다음 문제가 따라옵니다. 탐지기 자체의 신뢰도입니다. 탐지기가 어떤 인용을 오류로 지목했을 때 그 판정이 얼마나 확실한지를 모르면, 시스템은 두 방향으로 실패합니다. 확신도가 과대평가되면 정상 인용이 제거되어 답변이 빈약해지고, 과소평가되면 위험한 오류가 통과합니다. 최근 연구가 다중 탐지 경로와 보정을 함께 다루는 이유가 여기에 있습니다. 서로 다른 방식의 탐지기를 두고 그 판정을 결합하되, 각 탐지기의 확신도가 실제 정확도와 맞도록 맞춰야 한다는 것입니다. 법률 도메인에서는 이 균형이 한쪽으로 기울어야 합니다. 정상 인용을 잃는 대가는 답변이 짧아지는 것이지만, 잘못된 인용을 통과시키는 대가는 사용자의 잘못된 행동이기 때문입니다.

4

4. 유형별로 다른 대응을 배치한다

유형이 나뉘면 대응도 나뉩니다. 조작된 근거는 존재 검증에서 결정론적으로 걸러 낼 수 있으므로, 여기서는 판단의 여지를 두지 말고 기계적으로 처리하는 편이 낫습니다. 귀속 오류는 내용 대조로 잡되, 대조가 불가능한 경우가 존재하므로 그때의 기본값을 정해 두어야 합니다. 근거 본문을 확보하지 못했다는 이유로 통과시키면 검증이 무력화되고, 무조건 제거하면 정당한 인용이 사라집니다. 저희는 확인 불가를 통과로 보지 않는 쪽을 택했습니다. 추론의 비약은 가장 어렵습니다. 근거와 결론 사이의 논리적 거리를 기계가 재는 일은 아직 불안정하므로, 현재는 서로 양립할 수 없는 진술이 한 답변에 공존하는 경우처럼 결정론적으로 판정 가능한 부분집합만 다루고 있습니다. 다룰 수 있는 범위를 정직하게 좁히는 것도 설계입니다.

5

5. 지표를 나누면 조직의 우선순위가 바뀐다

마지막으로 실무적인 효과를 짚고 싶습니다. 지표를 유형별로 쪼개면 팀이 무엇을 먼저 할지가 데이터로 정해집니다. 조작형이 많다면 프롬프트와 근거 주입을 손봐야 하고, 귀속형이 많다면 검색과 재순위화를 봐야 하며, 비약형이 많다면 답변 구조와 결론 도출 방식을 봐야 합니다. 뭉뚱그린 환각률만 보는 조직은 이 판단을 감으로 하게 되고, 대체로 가장 눈에 띄는 사례를 따라 움직입니다. 저희가 인용 게이트에서 문장을 제거할 때 그 이유를 유형으로 남기려는 것도 같은 목적입니다. 제거된 문장의 수가 아니라 왜 제거되었는지의 분포가 다음에 무엇을 고칠지를 알려 주기 때문입니다.

기술적 트레이드오프

긴장 관계 탐지를 엄격하게 하면 잘못된 인용은 줄지만 정상 인용까지 제거되어 답변의 완결성이 떨어지고, 느슨하게 하면 답변은 충실해 보이지만 실재하되 무관한 근거가 통과합니다. 두 오류를 동시에 줄이는 설정은 존재하지 않습니다.

실무적 해소 유형별로 다른 지점에 균형을 두어 해소합니다. 존재 여부처럼 결정론적으로 판정 가능한 유형은 엄격하게 기계 처리하고, 내용 일치처럼 판정에 불확실성이 있는 유형은 확인 불가를 통과로 보지 않되 판정 근거를 함께 기록해 사후 검토가 가능하게 합니다. 그리고 판정이 아직 불안정한 유형은 다룰 수 있는 부분집합으로 범위를 좁혀, 무리한 자동 판정으로 정상 답변을 훼손하지 않도록 합니다.

법마디 OS에 적용한다면

저희 검증 계층은 이미 유형 구분의 일부를 갖고 있습니다. 인용의 실존을 확인하는 경로와 판시 내용을 대조하는 경로가 분리되어 있고, 양립 불가능한 법리 진술을 잡는 별도 게이트가 있습니다. 다만 이 구분이 지표로는 충분히 드러나지 않습니다. 게이트가 문장을 제거했다는 사실은 기록되지만, 그것이 존재하지 않는 근거였는지 실재하되 맥락이 어긋난 근거였는지는 집계되지 않습니다. 다음 단계로 할 일은 제거 사유를 유형 코드로 남기고 그 분포를 주기적으로 보는 것입니다. 조작형이 늘면 근거 주입의 커버리지를 넓혀야 하고, 귀속형이 늘면 검색의 정밀도를 봐야 하며, 확인 불가로 제거된 건이 늘면 검증 자산의 공백을 메워야 합니다. 같은 게이트라도 무엇을 얼마나 잘라 냈는지를 나누어 보면, 개선의 대상이 검증 계층이 아니라 그 앞단이라는 사실이 드러나는 경우가 많습니다.

기술적 함의

"고장을 고치려면 먼저 고장의 이름을 나누어야 합니다. 환각이라는 한 단어에 세 가지 다른 문제가 들어 있는 한, 우리가 무엇을 개선했는지도 정확히 말할 수 없습니다."

참고 자료

칼럼니스트

지유

지유

최고기술책임자 (CTO · Chief Technology Officer)

실리콘밸리 유니콘 창업 멤버급 / AI 무결성 검증 분야 세계적 석학급

법마디 OS 무료로 경험하기
본 칼럼은 법마디 OS 기술팀의 관점이며, 특정 제품·기술에 대한 보증이나 법률 자문이 아닙니다.