PPS 문서-AI 파이프라인 · 병목 진단 & 최적화

OCR·LLM 병목 진단과 2026 최적 해결방안

대상 jodal-eval-ai/pps-mono-repo · RFP↔제안서 평가 파이프라인 · 실측 2026-07-13 · 개인용(noindex)

TL;DR

OCR 병목은 해결됨 — 자체 Chandra 9B 40s/page → Datalab 2.2s/page (약 18×), chandra pod 종료로 비용도 제거.
남은 최대 병목 = LLM 구조화 — 큰 RFP(751K)를 섹션마다 전문(~15K tok) 재전송하는 설계. Prompt caching으로 90% 절감 가능.
부차 이슈: FP8 JSON 잘림(guided-JSON로 해결), knowledge-hub 동기 telemetry 10s timeout(비동기화).
2026 해법: Prompt caching · 모델 티어링(OpenRouter) · Structured outputs · 전체-PDF Datalab · telemetry 비동기화.

1병목 진단 (실측)

구간	실측	근본 원인	상태
LLM 구조화 (RFP structure)	섹션경계 호출 건당 14~18K tok × 3~21s, 다수	RFP 전문(~15K)을 매 섹션 호출마다 재전송 — O(섹션수×전문)	최대 병목
OCR (제안서 PDF)	Chandra 40s → Datalab 2.2s/page	자체 VLM 페이지당 지연	해결
FP8 품질	JSON `Unterminated string` 발생	FP8 양자화 + free-form JSON 생성	개선 필요
knowledge-hub	메타저장 10s read timeout	동기 telemetry가 크리티컬 패스에	개선 필요

핵심

OCR을 잡고 나니 진짜 병목은 큰 RFP의 LLM 구조화로 드러남. 이는 문서 크기 탓이 아니라 같은 본문을 반복 전송하는 설계 탓 — 캐싱으로 구조적 해결 가능.

2OCR 병목 해결 사례 (완료)

Chandra(self-host vLLM 9B)에서 Datalab 호스티드 OCR로 전환. 코드 무수정(OpenAI-vision→Datalab shim), document_ocr·hwpx_vision·rfp_image_analysis 3개 purpose 리포인트.

항목	Chandra 9B (before)	Datalab (after)
밀집 페이지 처리	40.1s	2.2s (서버 runtime)
658p 제안서 추정	~5.5시간	~30~40분
GPU pod	A6000/L40S 상시 ($0.49/hr)	불필요 (종료)
모드	BF16 VLM	base(`output_format=html`) · 필요시 `use_llm`

32026 최적 해결방안 (ROI 순)

🥇 P1. Prompt / Context Caching 최대 ROI

RFP 15K 토큰을 섹션마다 재전송 → 캐싱 시 ~90% 토큰·지연 절감. 프롬프트를 [RFP본문(고정 prefix)] + [섹션쿼리(가변 suffix)]로 배치.

자체 vLLM(kanana): 이미 켠 --enable-prefix-caching이 동일 prefix KV 재사용 → 지금 구조에서 즉효
OpenRouter/API: Anthropic cache_control · OpenAI 자동 캐싱 · Gemini context caching

🥈 P2. 모델 티어링 + OpenRouter 탄력 라우팅

단일 kanana pod에 기계적 작업까지 몰림 → 역할별 분리. SSOT agent-model-settings.service.ts의 purpose별 provider만 교체.

작업 유형	추천 티어	이유
기계적 추출 (섹션경계·TOC·값)	Gemini 3 Flash / GPT-mini (OpenRouter)	빠름·저렴·고동시성·콜드스타트 0
판단성 분석 (tech-match·SWOT·평가)	강한 모델 (kanana / Claude / Gemini Pro)	추론 품질 우선

🥉 P3. Structured Outputs (JSON 신뢰성)

FP8 JSON 잘림 제거 — vLLM guided_json(grammar-constrained) 또는 OpenRouter response_format=json_schema. → Unterminated string 0, 섹션 누락·재시도 제거.

P4. OCR 전체-PDF batch + 선택적 balanced

Datalab /convert에 전체 PDF 1잡 submit(서버측 병렬) → 658잡 → 1잡
force_ocr=false: 텍스트 레이어 있는 페이지 OCR 스킵
use_llm=true는 배점표·표 페이지에만 선택 적용(hybrid)

P5. Telemetry를 크리티컬 패스에서 분리

knowledge-hub 메타저장 10s timeout이 워커를 stall → fire-and-forget 비동기 큐로(이미 PG 폴백 있음). KH connection pool·워커 스케일 병행.

4목표 아키텍처 (2026)

문서 → [Datalab whole-PDF OCR, force_ocr=auto] ─┐ ├→ [prompt-cached · structured-output LLM] RFP → [prefix-cache 구조화] ────────────────────┘ ├ 기계적: OpenRouter Gemini Flash (병렬) └ 판단: kanana / Claude (guided_json) telemetry = async fire-and-forget (비크리티컬)

예상 효과: RFP 구조화 5~10× (prefix cache + 티어링) · OCR 18× (완료) · JSON 재시도 0 · 워커 stall 제거

5모델 리서치 (2026, 검증 진행 중)

진행 중

deep-research 하네스(5각도 병렬 웹서치 → 3표 적대검증)로 조사 중. 아래는 검증 단계에서 확인된 초기 소견이며, 최종 인용 리포트로 이 문서를 갱신 예정.

OCR / VLM — 한국어 문서 (KO-VLM-Benchmark)

폐쇄형 우위: Gemini-3-pro KO-VQA 92.6%, Gemini-2.5-pro KO-VDC 97.5% — 한국어 문서 OCR/VLM에서 압도적
오픈소스 격차: Qwen2.5-VL-32B KO-VQA 61.8%, VARCO-VISION-2.0-14B 55.5% — Gemini 대비 ~30pt 낮음 → 자체 호스팅 OCR 품질 한계 시사
KO-OCRAG(OCR+시각맥락): Gemini-2.5-pro 65.31 vs 최상위 오픈소스 Qwen3-VL-8B 56.26

→ 정확도 최우선이면 Gemini 계열 OCR, 비용·온프렘 제약이면 Datalab(전용 OCR 파이프라인) 또는 Qwen3-VL. LLM·임베딩(KURE/BGE-M3/Qwen3-Embedding) 비교는 최종 리포트에 반영.