독자 = API나 모델 출력을 업무 프로그램에 연결하는 개발자; 독후 지식 = JSON 추출 결과를 운영 처리(프로덕션)로 넘기기 전의 검증 코드와 합격/불합격 기준.
Grok 4.6과 Kimi K2.5를 JSON 추출로 비교하려면, 단순히 보기 좋게 정돈된 출력만으로는 판별할 수 없습니다. 구문 분석이 가능한지(Parseability), 값의 타입이 계약대로인지(Type Adherence), 값을 입력 자료로 뒷받침할 수 있는지(Source Grounding)를 나누어 확인해야 합니다. 이 중 어느 하나라도 무너지면, 후속 업데이트 처리에서 잘못된 담당자나 기한이 확정값으로 저장될 수 있기 때문입니다.
본 메모에서는 합성한 비품 대여 기록을 소재로 비교 조건과 작은 검증기를 정리합니다. 샘플은 검증 코드의 동작 예시이며, 어느 한쪽 모델이 생성한 결과가 아닙니다. 2026년 10월 26일에 확인한 Kimi 공식 모델 목록에는 kimi-k2.5는 8월 31일부로 제공 종료라고 기재되어 있습니다. 따라서 현재 시점의 공식 API로 동일 조건의 신규 호출을 할 수 있다고 간주하기 어렵습니다. 이용 경로와 실제 Model ID는 실험 시작 시 재확인해 주십시오.
비교 대상 문서는 다음과 같은 짧은 기록으로 합니다.
관리표 R-184. 대여품은 USB-C 측정기. 반납 예정일은 2026-11-03. 신청 부서는 검사팀. 담당자 이름은 기록되어 있지 않음.
이 입력에서 추출할 수 있는 것은 관리표 번호, 품명, 반납 예정일, 신청 부서입니다. 담당자 이름은 불분명하므로, 부서명으로부터 추측하여 채워 넣어서는 안 됩니다. 프롬프트에 “JSON만 반환하라”고 적을 수는 있지만, 그것만으로 서버 측의 구조화 출력 스키마가 유효해지는 것은 아닙니다. 제공 경로가 JSON Schema나 structured output을 지원하는지, 대상 모델이 그 기능을 수용하는지는 별도로 조사해야 합니다.
모델과 서비스 경로도 기록합니다. 제품명이 같더라도 API의 Model ID, 제공자(Provider), 추론 설정(Inference Settings), 최대 토큰(Max Tokens), 구조화 출력 옵션이 다르면 동일 조건의 비교가 아닙니다. 모델 사양이나 제공 상황 확인처로 Grok 계열 모델의 Crazyrouter 목록과 Kimi 공식 모델 목록을 사용하고, 실행 시 응답에 포함된 Model ID를 별도로 저장합니다. 후자의 경우 K2.5의 제공 종료 정보가 있으므로, 과거의 모델 카드만 보고 현행 API 이용을 전제로 삼지 않는 것이 중요합니다.
아래는 Python 3.10 이상, 표준 라이브러리만으로 동작하는 최소 예시입니다. input_text와 candidate는 작성한 합성 샘플입니다. 먼저 파싱(Parse)하고, 다음 스키마(Schema), 마지막으로 입력 근거를 확인합니다.
import json
from datetime import date
input_text = """관리표 R-184. 대여품은 USB-C 측정기.
...
"""
실행 결과는 `PASS`입니다. 값을 `2026-11-30`으로 변경하면 입력에 없는 날짜로 실패하고, 담당자를 `사토`로 하면 근거 없는 보완으로 실패합니다. 이는 검증기를 합성 예시로 실행한 결과이며, 모델 API의 응답이나 정확도 측정은 아닙니다. 실제 프롬프트에서 모은 출력을 `candidate`에 넣을 경우, 동일한 평가 코드, 동일한 항목 정의, 동일한 입력 집합을 사용하여 모델별로 원본 출력을 저장해야 합니다.
세 단계는 의미가 다릅니다. 구문 검사는 후속 프로그램에서 열릴 수 있는지, 타입 검사는 필드의 계약을 지키는지, 근거 검사는 값이 원 자료에 연결되어 있는지를 나타냅니다. 구문의 성공률만 비교하면 가장 위험한 '깨끗하지만 잘못된 정보가 담긴 JSON'을 놓치게 됩니다. 정규화가 필요한 날짜나 표기 오류는 기대하는 변환 규칙을 사전에 준비하고, 원문과의 대응 관계를 별도로 보관해야 합니다.
여기는 태스크 정의에 포함하고 싶은 부분입니다. `null`은 '이 필드는 존재하지만 자료로부터 값을 확정할 수 없음', 빈 문자열(empty string)은 '문자는 있으나 의도적으로 비어 있음', `unknown`은 API 계약에서 열거값으로 정한 상태를 나타낼 수 있습니다. 이 세 가지를 섞으면, 화면상으로는 미입력처럼 보이지만 후단 동기화 처리에서는 '확인된 빈칸'으로 해석할 수 있습니다. 담당자가 기록되지 않은 상태를 부서명으로부터 보완하기보다는, 알지 못하는 상태(unknown state)를 유지하고 필요하다면 별도의 필드에 근거나 확인 태스크를 남기는 것이 더 안전합니다. 비교 시에는 결측값의 표현을 모델에게 맡기지 말고, 스키마와 평가기로 고정해야 합니다. 제품 측에서 미제공 값을 어떻게 처리하는지에 맞춰, API로 보낼 값과 화면에 표시할 문구를 분리하는 것도 유효합니다.
먼저, 필수 키 누락, 타입 불일치, 자료에 없는 값의 세 가지 유형을 개별적으로 계산합니다. 다음으로, 동일한 입력 집합에서 사람이 수정한 건수와 시간을 기록합니다. 담당자나 금액처럼 오보완이 중대한 항목의 경우, 근거가 불분명한 확정값이 단 1건이라도 나온 설정은 후보군에서 제외하는 등, 선행적으로 '중단 조건'을 정할 수 있습니다. 이 중단 조건을 충족하는 후보들만을 가지고 수정 시간, 가격, 응답 시간을 비교합니다. 실제 측정값이 없다면 '우위'라고 언급하지 않으며, 품질과 비용은 '검증 필요' 상태로 둡니다.
현재 Kimi 공식 API의 `kimi-k2.5`는 제공 종료가 안내되고 있으므로, 공식 API 간의 현재 직접 비교라는 결론을 내릴 수는 없습니다. 과거 저장된 출력을 비교하는 경우에도, 취득일이나 설정이 다르다면 동일 조건 실험이라고 부를 수 없습니다. 사용 가능한 Kimi 경로가 발견되면, 모델 ID와 제공자를 기록한 후, 동일한 입력/계약/평가기(evaluator)로 재실행하는 것이 판단의 시작점입니다.
JSON 추출에서는 파싱 가능 여부, 계약 준수 여부, 입력 근거 확보 여부를 나누어 점수를 매깁니다. 미지의 값을 임의로 채우지 않는 동작은 외관상의 완성도보다 업무 데이터의 신뢰성을 좌우합니다. 실제 승자는 모델 이름만으로 결정되지 않습니다. Kimi K2.5를 포함하여 동일 조건의 현행 출력을 취득할 수 있는 경우에 한해, 같은 평가기로 비교하고 근거 없는 확정값을 허용하지 않는 운영 기준을 충족한 후보군 중에서 선택해야 합니다.
- Python: 3.10 이상 가정, 추가 패키지 없음
- 명령어:
`python validate_json.py`
- 합성 샘플: 경로, 근거 없는 날짜, 미기록 담당자
- 결과: 기준 예시
`PASS`
불법적인 날짜 및 담당자 보완은 `FAIL`
- 모델 API 출력, 레이턴시(Latency), 요금: 실측 확인 필요
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
