구조화된 추출 (structured extraction)을 위해 "그저 JSON 스키마를 강제하면 끝난다"라는 댓글을 계속 보고 있습니다.

만약 당신이 진정으로 "LocalLLaMA"를 하고 있다면, 즉 자신만의 언어 모델 (LM)을 구축하거나 미세 조정 (fine-tuning)을 하고 있다면, 해결책은 사소합니다. llguidance와 같은 스키마 제약 디코더 (schema constrained decoder)를 적용하기만 하면 쉬운 부분은 끝납니다....
호스팅된 LLM들도 유사한 메커니즘을 가지고 있지만, 이곳은 r/LocalLLaMA이므로 그 부분은 무시하겠습니다.
하지만 그 모든 JSON의 의미론 (semantics)은 어떻게 될까요? 그렇게 쉽지 않습니다.

저는 이에 관한 논문을 작성했습니다: https://doi.org/10.5281/zenodo.20075999. 오픈 소스이며, 많은 완화 방법과 접근 방식이 다뤄져 있습니다. 하지만 저는 어려운 데이터셋을 공개적으로 실행해보고 싶었고, 실패할 수도 있습니다. 사실 이미 조금 실패했습니다.
공개 사항: 저는 valjson PyPI 패키지를 사용하며, 이는 MIT 라이선스이고 무료입니다. 유료 티어나 잠긴 기능이 없습니다. 또한 저는 까다로운 사례들을 위한 컨설팅을 운영하고 있으며, 이 시리즈의 마지막 단계는 제가 결과는 공개하지만 코드는 공개하지 않는 방법을 사용합니다. 그 외에 이 포스트나 연결된 저장소(repo)에서 제한된 것은 없습니다. 모든 수치는 커밋된 파일로부터 재현 가능합니다.

작업 내용. 실제 M&A 합병 계약(MAUD 데이터셋)에서 92개의 거래 시점 필드 (deal-point fields)를 추출하여 계약당 하나의 JSON 객체로 만드는 것입니다. 디코딩 시점에 엄격한 JSON 스키마 (JSON Schema)가 강제되므로, 모든 출력은 구조적으로 스키마를 준수합니다. 계약에서 다루지 않는 각 필드는 null이어야 합니다. 이것은 제가 30년 동안 접해본 것 중 가장 높은 품질의 어노테이션 (annotation) 중 하나입니다. 변호사들에 의해 수행되었기 때문에 엄청난 비용이 들었을 것입니다.

긴장되는 부분. X/Twitter 인수 공시(https://www.sec.gov/Archives/edgar/data/1418091/000119312522120461/d310843dex21.htm)를 한번 살펴보세요. MAUD에 있는 것은 아니지만 형식이 같습니다. 우리는 다음 JSON 스키마(https://github.com/validjson/MAUD/blob/main/data/combined/schema.json)를 추출하려고 시도할 것입니다.

저는 이 문제를 원본 .csv 주석(https://github.com/TheAtticusProject/maud/blob/main/data.zip)에서 수행된 방식처럼 계약서의 발췌본을 분류하는 대신, 전체 계약서에서 JSON으로 매핑하는 방식으로 훨씬 더 현실적이고 훨씬 더 어렵게 만들었다는 점에 유의하십시오.

평가. 15개의 홀드아웃 (held-out) 계약서, 1,380개의 필드 셀 (field cells). 제가 중요하게 생각하는 두 가지 수치는 다음과 같습니다: 필드별 정확도 (per-field accuracy), 그리고 환각률 (hallucination rate) = 계약서에 답이 없는 셀에서 모델이 얼마나 자주 답을 지어내는지의 비율입니다. 두 번째 수치는 스키마 검증 (schema validation)으로는 절대 확인할 수 없는 수치입니다.

베이스라인 (GPT-5.5). 전체 계약서 → 90.7% 정확도 (1,251 / 1,380 필드). 약 20K 토큰 윈도우 (token windows)로 청킹 (chunking)하고 청크별 JSON을 병합했을 때의 정확도는 90.0% (1,242 / 1,380)를 유지합니다. 환각은 별개의 더 좁은 범위의 수치입니다. 계약서가 비워둔 110개의 셀(1,380개 중 정답(gold)이 null인 경우)에 대해서만 측정되었습니다: 전체 계약서 모델은 그중 37 / 110 (33.6%)에 대해 답을 지어냈으며, 청킹을 사용하면 이 수치가 17 / 110 (15.5%)로 떨어집니다. 좋습니다, 스키마와 강력한 폐쇄형 모델 (closed model)을 사용하면 약 90%를 얻을 수 있습니다. 이는 매우 어려운 작업처럼 보이기 때문에 저를 놀라게 했습니다. 하지만 이를 신뢰하기 전에 아래의 오염 (contamination) 주의 사항을 확인하십시오.

그 다음 저는 동일한 프롬프트, 동일한 청크, 동일한 모든 설정을 사용하여 오픈 모델 (Qwen 2.5 32B)로 교체했습니다. 저는 먼저 ~80–85%의 정확도와 유사한 환각률을 가질 것이라고 추측을 등록해 두었습니다. 제 예측은 크게 틀렸습니다:

100% 스키마 유효 (schema-valid). 약 70% 오답. 또한 무작위도 아닙니다 — 그 메커니즘은 다음과 같습니다:
78개의 청크 중 약 23개에서 모델은 단 하나의 ~20K 토큰 슬라이스(slice)로부터 92개 필드 전체에 대한 추측을 쏟아내는데, 이 슬라이스에는 92개 필드 모두에 대한 근거가 포함될 가능성이 전혀 없습니다. 이러한 추측들은 실제 근거를 가지고 있는 청크와 모순됩니다 — GPT-5.5의 7건 대비 293건의 청크 간 충돌 (cross-chunk conflicts)이 발생하며, 병합 과정에서 손실됩니다.

문제의 한 예: 한 계약서에서 "특정 이행 (specific performance)" 필드와 관련된 5개의 청크가 모두 답변을 제출했지만, 그중 어느 것도 "specific performance"라는 문구를 포함하지 않았습니다. 모델이 법적 판결을 지어낸 것입니다. 해당 계약서 전체에 걸쳐 92개의 필드 중 72개가 서로 다른 청크로부터 모순된 값을 받았습니다.

핵심은 이것입니다: JSON 스키마 (JSON Schema)는 모든 필드에 값을 강제로 채워 넣을 수는 있습니다. 하지만 근거가 없을 때 모델이 null을 출력하도록 가르칠 수는 없습니다. 언제 기권(abstain)해야 하는지를 아는 것이 실제적인 격차이며, 이는 검증기 (validators)에게는 보이지 않습니다.

시도하시기 전에 한 가지 주의사항을 말씀드리겠습니다: MAUD는 2023년부터 공개되어 있었으므로, GPT-5.5의 90% 성적 중 일부는 실력이 아니라 오염 (contamination)일 수 있습니다. 이것이 오픈 모델의 결과(result)를 바꾸지는 않지만, 제가 90%라는 수치를 절대적인 진리로 취급하지 않는 이유입니다. 오염 교체 테스트 (contamination swap-test)를 계획 목록에 넣어두었습니다.

다음 진행 단계: 표준 LoRA 미세 조정 (fine-tuning) (E2, 현재 실행 중), 그다음 모델에게 null이라고 말하도록 가르치는 것이 실제로 격차를 줄이는지 확인하기 위한 기권 재라벨링 (abstention relabeling) 미세 조정 (E2a), 그리고 상업적 방법 (E3, 결과만 공개) 순으로 진행됩니다. 각 단계는 실패할 수도 있습니다. 결과가 나오는 대로 게시하겠습니다 — 리포지토리(repo) 주소는 여기입니다:
https://github.com/validjson/MAUD

실시간 스코어보드, 지금까지의 오픈 단계(E0–E1)를 위한 하네스 (harness), 그리고 가공되지 않은 예측/정답 (raw prediction/gold) 파일들이 있습니다 — 모델이나 API 없이도 모든 수치를 직접 재계산할 수 있습니다 (REPRODUCE.md 참조). 다만 E2 단계부터는 모델과 GPU가 필요할 것입니다.

예측, 비판, 그리고 "방법이 틀렸다"는 의견 모두 환영합니다 — 특히 프롬프트 (prompt)가 문제라고 생각하신다면 더욱 그렇습니다 (비교를 깔끔하게 하기 위해 모델 간에 프롬프트를 의도적으로 동일하게 유지했지만, 이에 대해 사람들이 어떻게 생각하는지 궁금합니다).

제출자: /u/Skiata
[link] [comments]