RKA 추출: LLM은 codex(Qwen 아님) + SMART 스코프 축소 + truncation 안전

핵심 사실 (검증됨, commit eb9e773)#

.env RKA_LLM_PROVIDER=codex → rka/core/llm.py:complete()가 _complete_codex → chatgpt.com/backend-api/codex/responses(GPT-5.5). RKA_LLM_OPENAI_BASE_URL=localhost:8001(Qwen)은 provider=openai일 때만 씀.
추출=codex, 회의 전사 교정=Qwen(H100 localhost:8001) 으로 분리. batch_run도 setdefault codex.
codex는 큰 프롬프트(16.5K)에 매우 느림(측정 247초/호출). Qwen은 동일 프롬프트 28초(9배). 품질은 핵심 결정 동급, codex가 관계까지 더 뽑음.
⚠️ 검증 공백: 2026-08-07~2026-09-10 기간 자동 검증이 chatgpt HTTP 401/404/429 오류로 실패. codex 엔드포인트·인증 변경 가능성 있으므로 수동 재확인 권고.

15개 샘플 감사 결과 GROUNDED 13/OVER-REACH 1/WRONG-TYPE 1/HALLUCINATION 0. evidence 충실.
conf = LLM 자기보고(prompt 규칙: 확정 결정만 高, needed/계획 低) + extractor._cap_thin_orphan_entities가 연결없는 고아를 0.45로 캡.

extractor.py LLM 호출이 max_tokens=4000이라 제안 많으면 JSON 잘림 → 파싱실패 → 조용히 0 suggestions. 4000→12000 + _salvage_truncated_json(잘린 배열 복구) + llm.py finish_reason=length/response.incomplete 감지·경고 추가.

문제: known_entities 90~99개(~7K블록, user prompt 16-18K). 활용률 낮음(문서당 실제 ~3-6개 사용).
해법: LLM 노출용 known_entities만 축소(확정노드 uuid 전량 유지 + 타입별 캡: Decision12/Task15/Experiment·Dataset·Asset3, Project/Person/Problem 무제한, target 64). name_index/known_by_id는 full 유지 → resolver 링크 전혀 안 상함.
결과: gdrive 99→53(16.4K→7.6K tok), notion 91→47(17.7K→8K). end-to-end Qwen 검증: 엔티티가 기존 rka:sug_ 노드로 정상 해소, truncation 없음.
naive top-50은 위험(2차타입 전멸+확정노드 7개 손실+truncation). RKA_SCOPE_KNOWN_CAP로 조정.

Qwen 단일패스에 "관계 강조 블록"(provenance 제외, Decision↔Project/Person/Problem 유도, evidence 필수) 넣으면 관계 0→6 grounded. 단 Qwen 변동성 있음. 별도 관계보강 프로세스는 과함 — 프롬프트 튜닝으로 충분.
⚠️ 2026-07-01 당시 미커밋 상태로 기록됨. 커밋 여부 재확인 필요.

verdict: revise
note: 2026-08-07~09-10 자동 검증 API 오류(401/404/429) 연속 발생으로 revalidation 신뢰도 저하. 핵심 커밋 기반 주장은 유효하나 codex 엔드포인트 수동 재확인 및 관계 프롬프트 커밋 여부 확인 권고. revalidation 섹션 대거 정리.

verdict: ok
note: 검증일(09-10)로부터 3일 경과, 코드 주장은 commit eb9e773에 고정되며, codex 엔드포인트 불안정 우려는 노트 본문에 이미 명시되어 있음.