LLM이 뽑은 이름, 날짜, 관계를 원문에서 다시 확인해야 한다면, LangExtract처럼 각 구조화 값에 원문 span과 offset을 연결하는 방식이 단순 JSON 생성보다 안전합니다. 핵심은 모델의 답을 신뢰하는 것이 아니라, 사람이 원문 근거로 되돌아갈 수 있는 검증 경로를 남기는 데 있습니다. 다만 근거 위치가 붙어도 해석 오류와 누락은 남으므로 스키마, 청킹, 후처리 기준을 함께 설계해야 합니다.
LLM 추출값이 원문 어디서 왔는지 확인하려면: LangExtract
왜 JSON 값보다 원문 위치가 더 중요할까?
LangExtract는 자유 형식 문서에서 정의한 스키마에 맞춰 정보를 추출하고, 결과를 원문의 위치와 연결하는 라이브러리로 소개됩니다. 추출값만 저장하면 잘못된 결과를 찾기 어렵지만, 근거 구간이 함께 있으면 검토자가 해당 문장을 바로 비교할 수 있습니다.
이 연결이 환각을 없애는 것은 아닙니다. 모델이 잘못된 구간을 근거로 고르거나 문맥을 과하게 해석할 수 있습니다. 따라서 span이 실제 원문과 일치하는지, 추출값이 span 안에 직접 존재하는지, 스키마 타입에 맞는지를 후처리에서 검사해야 합니다.
예를 들어 계약서에서 날짜를 뽑았더라도 그것이 계약일인지 종료일인지 구분하지 못하면 값 자체는 원문에 있어도 결과는 틀립니다. span은 숫자가 어디에 있었는지는 보여 주지만, 필드의 의미를 올바르게 선택했다는 사실까지 증명하지 않습니다. 검토 화면에서는 추출값과 주변 문장을 함께 보여 주고, 같은 값이 여러 위치에 있을 때 선택 근거를 확인할 수 있어야 합니다.
offset은 원문이 바뀔 때도 주의해야 합니다. 추출 뒤 텍스트를 정규화하거나 문단을 다시 조립하면 저장된 위치가 다른 문장을 가리킬 수 있습니다. 원문 버전과 offset 기준을 함께 보관하고, 화면에 표시하기 직전에 실제 substring이 일치하는지 검사해야 추적 가능성이 유지됩니다.
스키마와 예시는 어디까지 구체화해야 할까?
실무에서는 모델 선택보다 추출 규칙을 먼저 고정하는 편이 낫습니다.
- 필요한 엔티티와 관계만 좁게 정의합니다.
- 값이 없는 경우를 빈 값과 추정 값 중 어떻게 표현할지 정합니다.
- 긍정 예시뿐 아니라 추출하면 안 되는 반례를 준비합니다.
- 같은 문구가 여러 번 나올 때 어느 위치를 택할지 규칙을 둡니다.
- 사람이 검토할 최소 신뢰 조건을 정합니다.
원문에 포함된 Python 예시는 예상 추출값과 실제 모델 설정이 완성되지 않은 조각이므로 이 글에서 실행 가능한 예제로 재포장하지 않습니다. API 키 이름, 모델 식별자, 스키마 형식은 사용 시점의 저장소 문서와 대조해야 합니다.
스키마가 넓을수록 한 번에 많은 정보를 얻을 수 있지만, 서로 비슷한 필드 사이의 경계가 흐려집니다. “인물” 하나보다 당사자, 담당자, 인용된 인물을 나누려면 각 역할의 포함, 제외 조건을 예시에 명시해야 합니다. 값이 없을 때 모델이 문맥으로 보완하지 않도록 “원문에 직접 근거가 없으면 비움” 같은 규칙도 필요합니다.
예시는 문서의 문체와 난도를 반영해야 합니다. 쉬운 긍정 사례만 주면 괄호, 표, 중복 언급, 부정문에서 실패할 수 있습니다. 같은 표현이 추출 대상인 경우와 아닌 경우를 나란히 두고, 관계의 두 끝점과 근거 span이 모두 필요한지 정하면 검수 기준이 선명해집니다.
긴 문서는 왜 단순 청킹만으로 처리할 수 없을까?
LangExtract는 긴 문서를 청크로 나누고 병렬 처리하거나 여러 번 통과시키는 방식을 지원하는 것으로 소개됩니다. 병렬화는 시간을 줄일 수 있지만 호출량과 속도 제한을 늘리고, 경계에 걸친 문맥을 놓칠 수 있습니다. 다중 패스는 재현율을 높일 여지가 있지만 같은 항목이 중복될 수 있습니다.
그러므로 청크 사이에 겹치는 구간을 두고, offset을 기준으로 중복을 병합하며, 관계의 두 대상이 서로 다른 청크에 놓인 사례를 별도 테스트해야 합니다. 전체 문서의 필수 항목 수와 청크별 결과 수가 일치하는지도 기록하면 누락을 찾기 쉽습니다.
겹침 구간은 경계 누락을 줄이지만 같은 항목이 두 번 나오는 원인이 됩니다. 문자열이 같다는 이유만으로 합치면 서로 다른 사람이나 날짜를 하나로 만들 수 있고, 위치만 다르다는 이유로 남기면 중복이 늘어납니다. 필드 유형, 원문 위치, 주변 문맥을 함께 사용해 병합 규칙을 정해야 합니다.
다중 패스 결과가 서로 다를 때 처리 방식도 미리 정해야 합니다. 한 번이라도 나온 값을 모두 채택하면 재현율은 높아질 수 있지만 근거 없는 결과가 늘고, 모든 패스가 동의한 값만 남기면 드문 항목을 놓칠 수 있습니다. 오류 비용이 큰 필드는 불일치를 사람 검토 큐로 보내고, 낮은 위험의 필드는 합의 규칙으로 처리하는 식의 구분이 필요합니다.
설치 전에 어떤 검증 세트를 만들어야 할까?
원문에 제시된 설치 스냅샷은 다음 한 줄입니다.
1
pip install langextract
패키지 버전과 Python 환경이 명시되지 않았으므로 이 명령만으로 재현 가능한 전체 절차라고 볼 수는 없습니다. 먼저 20~50개의 짧은 문서를 사람이 라벨링하고, 완전 일치, 부분 일치, 근거 없는 추출, 누락을 나눠 측정하는 편이 좋습니다. 의료, 법률, 금융 문서처럼 오류 비용이 큰 영역에서는 근거가 있더라도 최종 검토를 자동화해서는 안 됩니다.
검증 세트에는 정상 문서뿐 아니라 값이 없는 문서, 같은 값이 반복되는 문서, 관계가 청크 경계를 넘는 문서를 섞어야 합니다. 완전 일치율 하나만 보면 일부만 맞은 긴 span과 완전히 근거 없는 값을 구분하기 어렵습니다. 필드별 누락과 오추출, 잘못된 offset, 타입 오류를 나눠야 수정할 지점이 보입니다.
도입을 보류할 조건도 정할 수 있습니다. 원문을 조금만 바꿔도 offset이 깨지거나, 필수 필드 누락이 사람 검토에서 자주 발견되거나, 비용을 줄이기 위한 청킹이 핵심 관계를 반복해서 끊는다면 자동 입력 단계에 바로 연결하면 안 됩니다. 반대로 제한된 스키마에서 근거 위치가 안정적으로 맞고 사람이 빠르게 확인할 수 있다면 검토 보조부터 시작할 수 있습니다.
오류 비용에 따라 사람 검토를 어떻게 나눌까?
모든 추출값을 같은 방식으로 검토하면 비용이 커지거나 중요한 오류를 놓칩니다. 문서 식별자처럼 원문 문자열과 완전히 일치해야 하는 필드는 자동 비교를 먼저 하고, 계약 당사자처럼 문맥에 따라 역할이 달라지는 필드는 주변 문장과 함께 사람이 확인할 수 있습니다. 관계 필드는 두 대상과 관계 표현의 근거가 모두 있는지 봐야 합니다.
검토 우선순위에는 누락 비용과 오추출 비용을 따로 반영합니다. 필수 날짜를 놓치는 것이 큰 문제인 업무는 재현율을 우선하고 불일치를 검토 큐로 보낼 수 있습니다. 반대로 존재하지 않는 의무 조항을 추가하는 것이 더 위험하면 원문에 직접 표현된 값만 통과시키고 추론된 값은 보류해야 합니다.
수정 기록도 학습 자료와 운영 로그를 구분해 남깁니다. 사람이 바꾼 값, 원래 span, 수정 이유를 저장하면 반복 오류를 찾을 수 있지만, 검토 결과를 자동으로 다음 학습에 넣을 때는 개인정보와 잘못된 수정의 확산 가능성을 확인해야 합니다. 한 사람의 수정이 곧 정답이라는 가정도 위험합니다.
정기 점검에서는 문서 유형별 누락률과 근거 없는 추출률, 검토 시간을 비교합니다. 새 양식이나 긴 문서에서만 오류가 늘면 모델 전체를 교체하기 전에 스키마 예시와 청크 경계를 조정할 수 있습니다. LangExtract의 원문 연결은 이런 분석을 가능하게 하는 기반이지 사람 검토가 필요 없다는 결론이 아닙니다.
파이프라인을 다른 모델이나 공급자로 바꿀 때는 같은 라벨 세트와 스키마를 유지합니다. 값 정확도만 좋아지고 offset 일치가 나빠질 수도 있으며, 호출 비용을 줄이는 대신 긴 문서 누락이 늘 수도 있습니다. 모델명보다 필드별 정확도, 근거 위치, 재현성, 검토 시간을 한 표에서 비교해야 합니다.
출력 저장소에는 추출 스키마 버전과 원문 해시 또는 문서 버전을 함께 남기는 것이 좋습니다. 규칙이 바뀐 뒤 과거 결과를 새 결과와 섞으면 같은 필드명이 다른 의미를 가질 수 있습니다. 재추출이 필요한 문서를 구분하고 어떤 규칙으로 값이 만들어졌는지 감사할 수 있어야 합니다.
자동화 범위는 검토 결과에 따라 단계적으로 넓힙니다. 처음에는 값과 span을 제안만 하고, 안정된 필드만 후속 시스템에 전달하며, 고위험 필드는 계속 승인을 요구할 수 있습니다. 모든 필드를 한꺼번에 자동 입력하는 것보다 오류 비용에 맞춘 점진적 도입이 안전합니다.
원문을 삭제하거나 수정해야 할 때는 연결된 추출값과 검토 기록의 보존, 삭제 정책도 함께 적용해야 합니다. 근거 문서 없이 값만 남으면 나중에 정확성을 감사할 수 없습니다.
모델과 공급자 선택, 최신 사용법은 GitHub 저장소, Google Developers Blog 소개, PyPI 패키지 페이지에서 사용 시점에 확인해야 합니다.
함께 읽으면 이해가 이어지는 글
- RAG 답이 틀릴 때 LLM보다 PDF를 먼저 의심해야 하는 이유: RAGFlow — RAGFlow의 문서 이해형 수집 구조를 표, 레이아웃, 읽기 순서 중심으로 살펴보고, 검색 품질을 평가하는 실무 절차와 운영 비용을 정리합니다.
- 민감한 문서를 NotebookLM에 올리기 어렵다면? Open Notebook 점검표 — Open Notebook의 문서 Q&A, 요약, 다중 화자 오디오 기능을 살펴보고 로컬 LLM을 써도 외부 전송이 남을 수 있는 지점과 설치 전 확인 사항을 정리합니다.
- 알리바바 Wan 3.0 공개 베타 개시, 문서 입력으로 30초 AI 비디오 원컷 생성 — 알리바바 클라우드가 차세대 비디오 생성 AI 모델인 Wan 3.0(통의완상 3.0)의 공개 베타 테스트를 시작했습니다. 기존 15초에서 2배 늘어난 최대 30초 단일 샷 비디오 생성을 지원하며, PDF와 PPT 등 오피스 문서와…
표지 1 —
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.