어떤 훈련(training)을 거치기 전에 구조(문법, grammar)와 문서화(정의, definitions)가 무엇을 제공하는가

우리의 본능은 LLM의 출력이 기대에 미치지 못할 때 더 크고 새로운 모델에 돈을 지불하는 것이지만, 두 가지 간단한 해결책이 있습니다:

• 문서화 (Documentation): 이는 모델이 작업을 이해하는 방식에 작용하며, 사전 훈련(pre-training)에서 제외되었던 니치 도메인(niche domain)에 속하기 때문에 추론 시간(inference time)에 의미론(semantics)을 주입합니다. 본 실험에서의 문서화는 주요 HR 및 급여 회사들의 문서를 통합한 API 스타일의 문서화입니다.
• 문법 (Grammar): 이는 모델의 출력에 작용하며, 모델이 거스를 수 없는 스키마(schema)입니다. 우리는 20개 필드의 스키마를 공식적인 문법으로 컴파일하여 디코딩을 제약합니다. 각 단계에서 샘플러는 문법이 허용하는 토큰만 선택할 수 있으므로, 모델은 잘못된 JSON이나 스키마가 허용하는 범위를 벗어난 값을 출력하지 않습니다.

우리는 공식 계약서부터 비공식 이메일 교환 및 회의록에 이르기까지 264개의 급여 합의서(payroll agreements)로 실험을 진행했습니다. 각 문서에는 수동으로 검증된 정답(gold answer)이 연결되어 있었습니다.

설정 (Setup):

• 모델: Qwen2.5-Instruct, llama.cpp에서 실행
• 모델 크기: 3B 및 14B
• 양자화 (Quantization): Q8_0, 공개된 fp16 가중치를 사용하여 llama.cpp의 convert_hf_to_gguf로 로컬 양자화 수행.

우리는 각 모델을 네 번씩 실행했습니다. 이는 우리가 테스트했던 두 가지 조합 각각에 대한 것입니다: 필드 이름만 사용하는 경우 대 전체 정의를 사용하는 경우, 그리고 자유 디코딩(free decoding) 대 문법 제약 디코딩(grammar-constrained decoding). 이로써 총 2,112개의 추출 결과가 나왔습니다.

우리가 발견한 것은 다음과 같습니다:

• 문서화가 문법을 대체한다. 정의(definitions)가 갖춰지자, 14B 모델은 92%의 필드와 31%의 레코드에서 정확도를 보였다.
• 문법이 문서화를 대체하지는 못한다. 문법은 향상되지만, 관습(convention)을 가르칠 수는 없다.
• 문서화가 없는 문법은 해로울 수 있다 – 문서가 다루지 않은 질문에 답을 강요하기 때문이다. 계약서가 특정 정책에 대해 아무것도 언급하지 않을 때도, 모델은 여전히 값을 선택해야 하며 — 올바른 답이 '없음(null)'이었던 경우 50번이나 잘못된 값을 선택했다. 정의를 사용하자 이 오류는 완전히 사라졌다.

필드 정확도 점수(92%)만 보면 모델들이 거의 완벽해 보일 수 있다. 하지만 레코드가 올바르려면 스무 개 필드 전체가 모두 맞아야 하며 — 그 테스트를 통과하는 레코드는 3분의 1도 안 된다. 문제의 원인은 이름이 있다: 병목 현상(bottlenecks). 다음 게시물에서 이에 대해 논할 것이다.