데이터시트 추출 에이전트는 “맞혔는가”보다 “열어봤는가”를 먼저 봐야 한다

문서 추출 에이전트를 운영에 넣는 팀은 평가 기준을 조정해야 한다. 최종 추출값의 fidelity, 즉 원문과 값이 일치하는지만 보는 방식으로는 부족하다. 최소 합격 조건은 “정답을 냈는가”가 아니라 “필수 근거 문서를 실제로 열람했고, 올바른 도구와 인자로 그 과정을 수행했는가”여야 한다.

이 결론은 품질관리 취향의 문제가 아니다. 제공된 논문 초록에 따르면, 내부 추출 서비스 모델 검증 중 한 모델이 데이터시트를 열지 않고도 fidelity 검사를 통과한 사례가 있었다. 구조화 출력 제약이 도구 사용을 조용히 비활성화했고, 모델은 조작된 출처 텍스트로 답했다. 이 실패는 최종값 비교가 아니라 per-tool trace에서만 드러났다.

여기서 핵심은 “그 모델이 나빴다”가 아니다. 에이전트형 추출 파이프라인에서는 정답과 신뢰 가능한 실행이 분리될 수 있다. 우연히 맞힌 값, 학습 또는 문맥에 남은 값, 그럴듯하게 생성한 출처는 fidelity 점수에서 성공처럼 보일 수 있다. 그러나 내부 문서 추출 서비스에 필요한 것은 값 하나의 우연한 일치가 아니라 재현 가능한 근거 사용이다.

평가 단위를 출력에서 실행 궤적으로 옮겨야 한다

문서 추출 에이전트의 평가는 두 층으로 나눠야 한다.

첫째, 최종 출력 평가는 계속 필요하다. 추출값이 원문과 맞는지, 스키마를 지켰는지 확인해야 한다. 다만 이것은 충분조건이 아니라 마지막 검문에 가깝다.

둘째, 실행 궤적 평가가 별도로 필요하다. TRAJECT-Bench 관련 연구는 최종 정확도 외에 도구 선택 정확도, 인자 정확도, 의존성과 순서 충족 여부 같은 trajectory-level 진단을 보고한다고 설명한다. 문서 추출에 적용하면 질문은 더 구체적이다.

모델이 데이터시트 열람 도구를 호출했는가. 올바른 문서, 페이지, 쿼리 같은 인자를 넣었는가. 검색 다음 열람, 열람 다음 파싱, 파싱 다음 구조화 출력처럼 필요한 순서와 의존성을 지켰는가. 도구 호출이 실패했을 때 재시도나 대체 경로가 있었는가.

제공된 근거만으로 문서 열람 도구 호출률이나 잘못된 문서 호출률의 표준 산식, 합격 기준을 확정할 수는 없다. 따라서 특정 임계값을 업계 표준처럼 말하면 안 된다. 그러나 운영 의사결정에는 내부 규칙을 세울 수 있다. 필수 근거 문서 접근 trace가 없는 실행은 fidelity가 높아도 자동 승인하지 않는다. 사람 검토 또는 실패 처리로 보내야 한다.

구조화 출력은 보증 장치이지만, 근거 사용의 증거는 아니다

구조화 출력은 추출 서비스에 유용하다. downstream 시스템이 다룰 수 있는 JSON 형태를 강제하고, 누락 필드나 타입 오류를 줄이는 데 도움이 된다. 하지만 구조화 출력이 곧 문서 기반 추론을 보장하지는 않는다.

제공된 API 문서 근거에 따르면, 도구와 응답 형식 조합이 호환되지 않으면 요청이 거부되거나 JSON 제약 샘플링이 적용되지 않을 수 있다. 병렬 함수 호출이 생성될 때 제공한 스키마와 일치하지 않을 수도 있다. 안전 거부나 토큰 제한 때문에 스키마를 끝까지 따르지 못하는 경우도 가능하다.

다만 구조화 출력 제약이 항상 도구 사용을 비활성화한다고 일반화할 근거는 없다. 논문 초록의 사례는 “그런 실패가 실제로 발생할 수 있고, 최종값 검사로는 놓칠 수 있다”는 증거다. 그러므로 대응도 과장할 필요가 없다. 구조화 출력을 버릴 것이 아니라, 구조화 출력 검증과 도구 실행 trace 검증을 서로 다른 통제 장치로 둬야 한다.

실무적으로는 최종 JSON에 source_text나 page 필드를 넣는 것만으로 충분하지 않다. 모델이 그 필드를 생성할 수 있기 때문이다. 신뢰할 수 있는 증빙은 모델 출력 안의 주장보다 실행 로그에 남은 도구 호출 기록이다.

내부 서비스의 합격 판정 규칙

문서 추출 에이전트를 제품 또는 사내 업무흐름에 붙이는 팀에는 다음 판정 규칙이 보수적이면서도 실행 가능하다.

추출 요청 하나를 하나의 trace로 묶는다. 데이터시트 검색, 문서 열람, 파싱, 구조화 출력 검증 같은 각 도구 호출은 하위 span 또는 이벤트로 기록한다. 로그와 결과는 trace_id, span_id로 연결한다. 최종 추출값만 저장하지 말고 “어떤 도구가 어떤 인자로 호출됐고, 성공 또는 실패했는지”를 품질 판단에 포함한다.

자동 승인 조건은 세 가지로 나눈다. 첫째, 필수 문서 열람 도구가 호출되어야 한다. 둘째, 호출 인자가 작업 대상 문서와 맞아야 한다. 셋째, 그 이후의 추출값이 원문과 맞아야 한다. 이 셋 중 하나라도 빠지면 “정답처럼 보이는 출력”일 수는 있어도 “감사 가능한 추출”은 아니다.

NIST AI RMF 관련 근거도 이 방향과 맞다. 운영 중 AI 시스템과 구성요소의 기능·행동을 모니터링하고, 위험을 정기적으로 식별·추적하기 위한 접근과 문서화를 요구한다. Playbook은 AI 시스템 프로세스와 결과의 로깅, 개발 과정의 추적 가능성 같은 감사 가능성 메커니즘을 언급한다. 다만 제공된 근거만으로 도구 호출 로그의 필수 필드, 보존 기간, 접근권한, 민감정보 마스킹 정책까지 확정할 수는 없다. 내부 문서 원문이나 민감정보를 로그에 불필요하게 복제하지 않도록 별도 설계가 필요하다는 수준까지만 말할 수 있다.

편집자의 판단은 단순하다. 데이터시트 추출 에이전트를 평가할 때 fidelity 단독 지표를 승인 기준으로 쓰지 않는다. per-tool trace를 남길 수 없는 파이프라인은 고신뢰 추출 서비스로 분류하지 않는다. 그리고 trace가 있더라도 필수 문서 열람, 올바른 인자, 실행 순서가 확인되지 않은 결과는 자동화 성공이 아니라 조사 대상이다.

Aionda

문서 추출 에이전트 평가는 실행 로그부터

데이터시트 추출 에이전트는 “맞혔는가”보다 “열어봤는가”를 먼저 봐야 한다

평가 단위를 출력에서 실행 궤적으로 옮겨야 한다

구조화 출력은 보증 장치이지만, 근거 사용의 증거는 아니다

내부 서비스의 합격 판정 규칙

다음으로 읽기

참고 자료

업데이트 받기