Stop Building Models. Start Building Systems.
Author: Anish Kumar (Scribd) | Source: tech.scribd.com | Published: 2026-07-11
한 줄 요약
모델도 프롬프트 품질도 비용도 시간이 지나면 변한다 — 그래서 지속되는 자산은 특정 프롬프트나 모델이 아니라 Fast Model → Judge Model → SME Review → Ingest → Iterate라는 반복 가능한 human-in-the-loop 프로세스다.
핵심 주장/내용
- 핵심 가설: 하나의 완벽한 프롬프트나 특정 모델에 묶인 일회성 시스템 대신 반복 가능한 프로세스에 집중. 그 프로세스를 두 개의 대규모 프로젝트(SlideShare, Scribd)에 적용해 이식성을 확인했다
- Step 1 — 프롬프트를 건드리기 전에 입력을 표준화하라. 일관된 문서 “snippet” 개념(
doc_id, title, pdf, language, 선택적 메타데이터)으로 모든 워크플로가 같은 방식으로 시작. 프롬프트가 단순하고 안정적이 되고, 배치 사이징이 예측 가능해지고, 프로젝트마다 “문서를 모델에 어떻게 먹이지?”를 다시 쓰지 않게 된다 - Step 2 — fast model 대량 패스 (breadth first): 값싸고 빠르게 후보 라벨을 대규모로 생성. label + 짧은 rationale을 요구하는 이유 — SME 리뷰가 빨라지고, judge 평가가 더 신뢰할 만해지고, 프롬프트 실패 디버깅이 극적으로 쉬워진다
- Step 3 — 배치 추론 (지루하게 유지하라): 대규모 데이터셋에서는 비동기 배치 추론이 속도를 여는 “지루한” 선택. JSONL 요청 파일을 제출하고 돌려두고 나중에 결과를 받는다. 일반적으로 실시간 추론보다 50% 저렴하고, 움직이는 부품이 적고, 타임아웃/재시도 두통이 적고, 실행 재현이 쉽고, 배치 레벨에서 병렬화·모니터링이 쉽다
- Step 4 — 버저닝과 함께 전부 저장: raw와 파싱된 출력을 실행 메타데이터(프롬프트 버전, 모델명/버전, 실행 타임스탬프, doc_id, label/rationale)와 함께 저장. 이것이 반복을 “vibes 기반” 연습이 아니라 측정하고 회귀 테스트할 수 있는 것으로 만든다
- Step 5 — judge model 패스: 더 높은 성능 모델이 샘플을 검토해 fast model에 동의하는지 결정. 명시적으로 동의/비동의 + 짧은 rationale + 비동의 시 수정된 라벨을 낸다. judge는 SME의 대체가 아니라 SME 주의를 가장 가치 높은 케이스에 집중시키고, 실패 패턴을 더 빨리 표면화하고, 반복을 위한 측정 가능한 비동의 신호를 만드는 수단
- Step 6 — Google Sheets를 통한 SME 루프: judge 비동의(고우선순위)와 동의 건의 소규모 랜덤 샘플(spot check)을 export. 여기가 human-in-the-loop이 확장되는 지점 — SME에게 전부 라벨링하라고 하는 게 아니라 작고 가치 높은 슬라이스를 검증하라고 한다. 수정을 다시 Databricks로 ingest하고 golden dataset을 버저닝
- 샘플링 전략 — 왜 작은 golden dataset만으로는 안 되나: 작은 golden set은 실제 코퍼스보다 깨끗하고, 롱테일 엣지 케이스가 빠져 있고, 이미 이해하는 예시 쪽으로 편향되어 있다. 그래서 코퍼스의 1%를 sanity check 검증 슬라이스로, 0.1% 랜덤 샘플을 judge 리뷰로 쓴다. 이것이 잡는 것: 희귀 콘텐츠 패턴, golden 데이터에 과소 대표된 언어·포맷, 큐레이션된 예시에서 안 드러나는 프롬프트 모호성, drift로 인한 예상치 못한 “UNKNOWN” 급증. 랜덤 샘플링으로 부족하면 rationale과 비동의에서 보이는 패턴(문서 타입/포맷, 길이, 언어)으로 층화
- 프롬프트 엔지니어링을 취약하지 않고 반복적으로: 비동의를 프롬프트 개선의 “학습 데이터”로 사용 — 정의 명확화, 타겟 예시 추가(조심스럽게), 출력 포맷 규칙 강화, 모호성·엣지 케이스 혼동 축소. 시간이 지나며 비동의율 하락, SME 수정률 하락, 1% 검증 슬라이스의 예상 못한 실패 감소가 보여야 한다
- 필요한 지표는 단순하다: fast vs judge 비동의율, judge 비동의 건에 대한 SME 수정률, 처리량(잡/일당 문서 수), 반복 추세. “완벽한 지표”가 목적이 아니라 반복을 측정 가능하게 만드는 것이 목적
- 흔한 실패 모드: ① 자신만만하게 틀린 답 → 컨텍스트를 포착하고 큰 비동의를 SME 리뷰에 우선 배치 ② Google Sheets가 병목이 됨 → 시트 스키마를 엄격히 유지, 배치를 작게 export, 여러 시트로 리뷰 병렬화 ③ 배치 재시도/부분 실패 → 배치 요청을 idempotent하게 유지하고 실패한 배치만 재시도, 배치별 중간 결과 저장
주요 수치 / 사실
- SlideShare: 수천만 개 슬라이드쇼(~25M)를 성인 관련 콘텐츠 카테고리로 분류
- Scribd: 수억 개 문서(~350M)를 엔지니어 1명 + SME(어노테이션) 1명 + 데이터 사이언티스트 1명이라는 소규모 교차기능 팀으로 약 2개월 만에 스캔
- 배치 추론이 실시간 대비 일반적으로 50% 저렴
- 샘플링: 검증 1%, judge 0.1%
- 스택: Databricks(데이터 소싱·오케스트레이션) → 배치 LLM 호출 → Google Sheets(SME 검증) → Databricks로 ingest → 반복. 작은 팀이 빠르게 움직이려면 익숙한 도구를 쓰라
- SME 리뷰 시트 컬럼 권장:
doc_id,snippet,fast_label,fast_rationale,judge_agree,judge_label,judge_rationale,sme_label,sme_notes,reviewer,review_ts - 복제 순서: 입력 표준화 → 100~1k 어노테이션 문서로 fast-model 소규모 probe → 더 큰 슬라이스로 배치 warmup → 0.1%에 judge → 비동의를 Sheets로 → SME 리뷰 → 버저닝된 golden dataset으로 ingest → 프롬프트 반복, 1%로 검증, 스케일업
관련 위키
- LLM-as-Judge
- LLM Evaluation
- Human-in-the-Loop Labeling
- Data Quality and Validation
- Data Engineering FinOps
- Idempotency
Source: 원문 보기