AI가 긴 법률 문서에서 환각을 일으키는 이유
및 모든 필드 검증 방법

법무팀은 이미 대규모로 이 실험을 실행하고 있습니다. ILTA의 2024년 기술 설문조사에서 응답 기업의 37%가 업무 작업에 생성형 AI를 사용한다고 보고했으며, 이는 전년 대비 22포인트 증가한 수치입니다. 응답자들이 꼽은 주요 용도는 리서치(73%), 요약(70%), 초안 작성(69%)이었습니다 (ILTA). 요약은 바로 이 문서가 다루는 문제를 만드는 작업입니다. 조작된 값이 탄생하는 지점, 가장 먼저 영향을 받는 필드, 그리고 문서가 한 번에 읽기에 너무 길 때 "모든 필드 검증"이 실제로 의미하는 바를 설명합니다.

조작된 값은 어디서 오는가

환각 필드는 모델이 실제로 읽지 않았지만 해당 위치에 일반적으로 나타나는 내용을 바탕으로 재구성하고, 실제로 읽은 값과 동일한 확신을 가지고 반환하는 값입니다. 어시스턴트에게 180페이지 분량의 계약서에서 책임 상한선, 통지 기간, 준거법을 추출하라고 요청하면 깔끔한 행을 돌려줄 것입니다. 상한선은 상한선처럼 보입니다. 통지 기간은 반올림된 숫자입니다. 준거법은 이런 거래에서 일반적으로 선택하는 것입니다. 이러한 것 중 어느 것도 값이 문서에 있다는 것을 증명하지 못합니다. 소스를 놓친 모델은 자신이 소스를 놓쳤다는 사실을 알지 못하기 때문입니다.

구매자들은 이미 바로 이 점에 대해 불안해하고 있습니다. AI 공급업체 실사에 관한 r/legaltech 스레드에서 한 리뷰어는 증거를 요청했지만 아무것도 받지 못했다고 설명했습니다: "공급업체들은 '99% 정확도'를 주장하지만, 실사 중 증거를 요청하면 기본적으로 '직접 테스트해 보세요'라고 말합니다." (r/legaltech). 불만은 도구가 쓸모없다는 것이 아닙니다. 검증 부담이 구매자에게 떨어지는데 검증할 기준이 없다는 것입니다. 이 문서의 나머지 부분은 그 부담을 실제로 실행할 수 있는 검증으로 바꾸는 방법에 관한 것입니다.

긴 법률 문서가 실제로 처리되는 방식

400페이지 분량의 문서를 읽을 수 있다고 말하는 도구는 대개 더 작은 읽기들을 이어 붙인 파이프라인을 말하며, 그 이어 붙이는 과정에서 값이 바뀌곤 합니다. 모델은 사람처럼 읽지 않습니다. 텍스트는 토큰으로 분할되어 컨텍스트 창, 즉 모델이 한 번에 보유하고 고려할 수 있는 고정된 텍스트 양에 배치됩니다. 문서가 해당 창보다 길면 시스템은 세 가지 해결 방법 중 하나를 사용하며, 그 각각은 전체 문서를 더 작은 대리물로 대체합니다.

이러한 단계 중 어느 것도 버그가 아닙니다. 이것이 긴 문서가 처리되는 방식입니다. 핵심은 이러한 방법 중 하나라도 사용되면 도구가 더 이상 계약서를 읽는 것이 아니라는 점입니다. 도구는 계약서를 대신하는 더 작은 무언가를 읽는 것이며, 그 대리물의 공백이 바로 조작된 값이 들어가는 지점입니다. 긴 문서 읽기의 한계에 대한 자세한 내용은 AI가 다중 페이지 PDF로 할 수 있는 것과 없는 것 가이드에서 다룹니다. 이 분야가 처음이라면 계약 데이터 추출이 실제로 무엇인지에 대한 설명이 오류 유형을 살펴보기 전에 기본기를 다져 줍니다.

압축이 무작위 오류가 아닌 그럴듯한 오류를 만드는 이유

압축된 보기에서 값이 누락되면 모델은 빈칸으로 두지 않습니다. 해당 유형의 문서에 가장 적합한 값으로 그 자리를 채우는데, 이는 주의 깊은 독자도 눈치채지 못할 종류의 오류입니다. 연구자들은 이러한 패턴을 세부 환각이라고 부릅니다. 출력은 구조적으로는 대체로 정확하지만, 결과를 좌우하는 매개변수(임계값 숫자, 단위, 범위, 의무의 강도("shall" 대 "should"), 그리고 이를 촉발하는 조건)를 조용히 왜곡합니다. 긴 규제 문서를 대상으로 한 연구에 따르면 이러한 세부 수준의 정확도는 컨텍스트가 커질수록 저하되며, 오류율은 짧은 입력에서 0.22에서 긴 입력에서 0.36으로 64% 악화됩니다(arXiv).

법률 업무에서 이는 단순한 표면적 오류가 아닙니다. "Shall" 대 "should"는 의무가 필수인지 여부를 결정합니다. "제4.2조에 규정된 경우를 제외하고"와 같은 한정어가 누락되면 좁은 예외가 일반 규칙으로 바뀝니다. 대체된 상한선은 고객의 노출 범위를 바꿉니다. 각각은 실제 값처럼 읽히기 때문에 검토를 통과합니다. 스탠포드 평가는 여기서 인용할 가치가 있는 기준을 제시합니다. 추출된 값은 조작된(문서에 전혀 없는 경우) 또는 잘못 근거된(텍스트는 존재하지만 도구가 주장하는 내용을 말하지 않는 경우)일 수 있습니다. 후자는 소스가 실제이고 필드가 근거가 있는 것처럼 보이기 때문에 잡아내기가 더 어렵습니다.

압축이 가장 먼저 깨뜨리는 필드

압축은 모든 필드를 동일하게 손상시키지 않습니다. 잘못 반환될 가능성이 가장 높은 필드는 그럴듯한 대체 값을 생성하기 쉽고 육안으로 발견하기 어려운 필드입니다. 이는 법률 문서에서 작고 예측 가능한 집합입니다.

이 필드들의 공통점을 주목하세요. 각 필드에는 지루할 정도로 정확한 값과 지루할 정도로 틀린 값이 있습니다. 그래서 빠른 훑어보기로는 놓치기 쉽습니다. 따라서 확인 순서가 중요한 이유이기도 합니다. 노출을 초래하는 오류가 발생하는 숫자 필드와 의무 조항부터 시작하세요.

개정본과 수정 표시는 별도로 검토해야 합니다. 대체된 수치가 스캔된 서명본에 또렷하게 남아 있을 수 있으며, 부분만 보는 모델은 어떤 버전이 우선하는지 신뢰할 만한 방법으로 알 수 없습니다. 법률 문서에서는 같은 필드가 정당하게 여러 번 나타나며, 서로 다른 값으로 반복되는 경우가 바로 압축이 가장 취약하게 처리하는 부분입니다.

"모든 필드 검증"이 실제로 요구하는 것

긴 문서에서 모든 필드를 검증한다는 것은 각 추출된 값을 소스의 특정 위치에 다시 연결하여, 잘못된 값이 읽히는 방식이 아니라 가리키는 위치에 의해 발견되도록 하는 것을 의미합니다. 문서를 다시 읽는 것은 도구의 목적을 무색하게 만들며, 잘못 근거된 값이 통과하는 경로이기도 합니다. 텍스트를 대체한 값이 텍스트만큼 그럴듯해 보이기 때문입니다. 이러한 검증이 가능하려면 두 가지가 충족되어야 합니다. 즉, 원하는 필드를 정확히 알고 있어야 하며, 도구가 각 값의 출처를 보여줄 수 있어야 합니다.

열 정렬, 행 수, 누락 필드 감사, 숫자 및 날짜 검증, 수동 수정 대신 재추출이 필요한 경우를 포함한 광범위한 검증 절차는 7단계 추출 QA 체크리스트에 정리되어 있습니다. 검토 게이트가 파이프라인에서 어디에 위치해야 하는지는 인간 중심 워크플로우에서 다룹니다. 또한 여러 문서를 동시에 검사할 때는 문서 간 일관성 워크스루에서 한 시트에서 비교하는 방법을 보여줍니다. 이러한 각 항목이 전제하는 바, 그리고 압축이 중요하게 만드는 점은 모든 값이 그 출처로 거슬러 올라갈 수 있어야 한다는 것입니다.

이 검증으로 여전히 할 수 없는 것

근거 확인은 값이 어디서 왔는지 알려줍니다. 하지만 해당 조항이 집행 가능한지, 이후 수정으로 효력을 유지하는지, 클라이언트가 어떻게 대응해야 하는지는 알려주지 않으며, 어떤 추출 도구도 이를 바꾸지 않습니다. 소스 위치는 증거이지 법적 결론이 아닙니다. 도구는 "90일"이 섹션 12.3에 나타난다는 것을 보여줄 수 있습니다. 업로드하지 않은 사이드 레터 이후에도 그 통지 기간이 여전히 적용되는지는 알려줄 수 없습니다.

일부 오류는 도구의 범위를 완전히 벗어납니다. 핵심 수치가 별첨, 사전 수정안, 또는 업로드에 포함되지 않은 사이드 레터에 있다면, 아무리 근거를 확인해도 찾을 수 없습니다. 찾을 수 있는 것이 없기 때문입니다. 전체 패키지를 보내시고, 동일한 계약이 여러 파일로 제공되는 경우 검토 전에 조각들을 하나의 레코드로 합치세요. 원본이 품질이 낮은 스캔이라면 그 위의 모든 레이어가 문제를 물려받습니다. 따라서 깨끗한 판독은 우수한 OCR에서 시작되며, 법률 문서에는 고유한 요구 사항이 있으므로 법률 문서용 OCR 가이드에서 다룹니다. 그리고 빈 칸은 실패가 아닙니다. "없음"으로 보고된 필드는 행을 채우기 위해 만들어낸 그럴듯한 값보다 안전합니다. 다음 사람이 테이블을 신뢰하는 대신 문서를 확인하도록 안내하기 때문입니다.

이 의무는 도구로 이전되지 않습니다. ABA 모델 규칙 1.1, 주석 8은 관련 기술의 이점과 위험을 변호사의 역량 의무 안에 포함시키며, 약 40개 미국 관할권에서 해당 언어의 버전을 채택했습니다(ABA). 실무자들도 같은 방식으로 읽습니다: "AI가 변호사로서의 제 책임을 없애주지 않습니다. 내 이름이 들어간 사건이라면 인용문을 찾아 읽어야 합니다." (r/legaltech). 도구를 비교할 때, 검토용 추출기와 블랙박스를 구분하는 질문은 모든 필드에 대해 소스 위치를 반환하는지 여부입니다. 깨끗한 테이블만 반환하는 도구는 대조할 수 있는 근거를 제공하지 않으며, 이는 e-디스커버리 플랫폼과 필드 추출 비교 또는 소규모 법률 팀을 위한 문서 추출 옵션을 검토할 때 기억할 가치가 있습니다.

자주 묻는 질문

AI 도구가 긴 법률 문서에서 짧은 문서보다 더 많이 환각을 일으키는 이유는 무엇인가요?

긴 문서는 모델이 한 번에 보유할 수 있는 텍스트 양을 초과하기 때문에, 시스템이 전체를 읽는 대신 요약하거나 검색합니다. 압축된 보기에서 누락된 값은 해당 위치에 일반적으로 나타나는 내용으로 재구성됩니다. 장문 컨텍스트 문서에 대한 연구에 따르면 입력이 길어질수록 세부 수준의 정확도가 전체 정확도보다 더 빠르게 저하됩니다.

더 큰 컨텍스트 창이 문제를 해결할 수 있나요?

임계값을 높일 뿐, 제거하지는 않습니다. 문서는 여전히 창을 초과할 수 있고, 채팅형 어시스턴트는 계속 진행하기 위해 오래된 텍스트를 요약하며, 한도에 도달하기 전에도 컨텍스트가 커질수록 모델 성능이 저하됩니다. 큰 창은 보장이 아닌 여유 공간으로 취급하세요.

중요한 필드만 검증하고 나머지는 건너뛰어도 되나요?

전부 검증하거나 전부 건너뛰는 대신 위험에 따라 필드를 선택하세요. 숫자, 의무 조항, 발효일 대 개정일 같은 버전에 민감한 필드는 면밀한 확인이 필요하며, 위험도가 낮은 메타데이터는 빠르게 확인할 수 있습니다. 어떤 필드가 중요한지에 대한 결정은 도구에 맡기지 말고 사전에 정하고 문서화해야 합니다.

전체 계약서를 읽지 않고 추출된 계약 값을 어떻게 검증하나요?

소스 근거를 활용하세요. 도구가 원본 페이지에서 각 값의 위치를 표시하게 한 다음, 문서를 다시 읽는 대신 값이 표시된 위치에 실제로 있는지 확인하세요. ImageToTable.ai에서 리뷰 모드는 추출된 셀의 소스 영역을 강조 표시하며, 처리 후 자동으로 주석을 달도록 문서를 설정할 수 있습니다.

AI 계약 추출이 검토 없이 사용할 수 있을 만큼 정확한가요?

당사 도구를 포함한 어떤 도구도 법적 또는 재정적 노출이 있는 문서에서 필드 수준 출력을 확인해야 하는 필요성을 제거하지 않습니다. 당사의 추출은 인쇄된 테이블 데이터에서 최대 99% 정확도를 달성하며, 책임 있는 워크플로우는 여전히 위험도가 높은 필드를 소스와 대조합니다. 어떤 공급업체의 "환각 없음" 주장도 인용이 없는 정확도 수치에 적용하는 것과 동일한 회의적인 시각으로 대하세요.

필드가 비어서 반환되면 어떻게 해야 하나요?

조항이 실제로 없는지 확인하고, 없다면 비워 두세요. "없음"으로 표시된 빈 칸은 행을 채우기 위해 지어낸 그럴듯한 값보다 더 유용합니다. 다음 작업자가 표를 신뢰하는 대신 문서를 직접 확인하도록 안내하기 때문입니다.

진짜 중요한 테스트

법률 AI 워크플로우의 유용한 척도는 첫 실행에서 표가 얼마나 잘 만들어지는지가 아닙니다. 표의 어떤 셀이든 한 단계만에 페이지의 정확한 위치로 이동할 수 있는지가 중요합니다. 압축은 모든 긴 문서 해결책이 계약서를 더 작은 대체물로 바꾸기 때문에 그 단계를 필요하게 만듭니다. 소스 근거는 그 단계를 가능하게 합니다. 가장 틀리고 싶지 않은 필드부터 시작해 도구가 그 필드로 이동시킬 수 있는지 확인하세요.