다들 지저분한 인보이스나 계약서에서 필드 추출 어떻게 안정적으로 하고 있음?

한 번의 모델 호출로 모든 걸 다 하길 기대하는 것보다 단계를 나누는 게 훨씬 안정적임. 파싱, 추출, 그리고 스키마 검증 순으로 하면 실패 원인을 디버깅하기가 훨씬 쉬워짐. 가장 큰 난관은 보통 '해피 패스'가 아니라 예외적인 문서들임.

나도 정확히 이 고민을 했었는데, 2단계 접근법 덕분에 제정신을 차릴 수 있었음. 단일 패스 방식은 잘 되다가도 안 될 때가 있는데, 안 될 때는 어디서 잘못됐는지도 모른 채 틀린 합계만 쳐다보게 됨.

먼저 깔끔한 마크다운 덤프를 얻으면 추출 과정이 거의 지루할 정도로 쉬워짐. 파서가 지저분한 표와 이상한 간격을 다 처리해주니까 필드 추출은 레이아웃을 파악할 필요 없이 필요한 것만 가져오면 됨.

초반에 나를 힘들게 했던 건 …라고 가정했던 거임.

네가 말한 그 분할 방식이 우리도 결국 정착한 방식이야. 우린 건설/단열재 송장을 다루는데, 단일 비전 패스 방식은 괜찮아 보였지만 독일식 1.180,50이 1180.50으로 나오는 걸 누군가 발견했거든. 이제는 먼저 레이아웃을 파싱해서 깔끔한 md로 만들고, 그 다음에 엄격한 스키마를 적용해서 텍스트 전용 추출 패스를 돌려. 프롬프트 튜닝보다 훨씬 도움 된 건 산술적 검증이야. 품목 합계 vs 순액 vs 부가세 vs 총액을 비교하는 거지. 합계가 안 맞으면 JSON을 믿는 대신 문서를 플래그 처리하는데, 이게 대부분의 오류를 잡아내...

2단계 분할 방식이 맞음. 내가 덧붙이자면 추출 단계보다 검증 단계가 훨씬 중요함. 송장은 자체 체크섬이 있어서 산술적 대조를 통해 오류를 많이 잡아낼 수 있음. 계약서는 그런 게 없으니 필드 간 일관성을 확인해야 함. 예를 들어, 발효일이 종료일보다 앞선지, 명시된 기간이 갱신 조항과 일치하는지, 서명란의 당사자 이름이 일치하는지 등을 확인해야 함.

2단계 방식이 딱 맞음. 아직 언급 안 된 거 하나 추가하자면, 추출 단계에서 그냥 JSON 프롬프팅을 쓰는 대신 instructor나 outlines 같은 제약 생성(constrained generation)을 쓰면 hallucination이 확 줄어듦. 모델이 스키마에 없는 필드명을 지어낼 수도 없고, float를 요구했는데 string을 뱉을 수도 없음. 만능은 아니지만 raw prompting에서 발생하는 오류 유형들을 싹 없애줌.