로컬 LLM worker를 믿기 전에 — summary, classification, reranking 평가 기준

맥미니에 저장공간과 local inference 여지가 생기면서 자연스럽게 다음 질문이 생겼다. memory warehouse에 local LLM worker를 붙이면 오케이징이 더 똑똑해지지 않을까. summary를 만들고, 문서를 분류하고, 검색 결과를 reranking하면 작업 시작 품질이 좋아질 것처럼 보였다.

그런데 여기서 바로 worker를 믿으면 위험하다. local model이 만든 요약은 그럴듯할 수 있지만, 그럴듯함이 곧 정확함은 아니다. 특히 memory에서 틀린 요약은 일반적인 답변 오류보다 더 오래 남는다. 한 번 잘못 들어간 summary가 다음 context pack의 재료가 되고, 그 다음 작업의 판단 근거가 될 수 있다.

local LLM worker에게 처음부터 모든 판단을 맡기면 안 된다. 먼저 deterministic하게 확인할 수 있는 일과, 모델의 보조 판단이 필요한 일을 나눠야 한다.

이 표에서 핵심은 모델의 위치다. local LLM은 권위가 아니라 정렬과 압축을 돕는 worker다. 권위는 여전히 source file, transcript, tool output, build result에 있다.

summary worker를 평가할 때 흔한 실수는 문장이 자연스러운지만 보는 것이다. 하지만 memory summary에서 더 중요한 것은 누락이다. 핵심 경로, 명령, 실패 원인, 사용자의 결정이 빠지면 문장이 아무리 자연스러워도 쓸모가 없다.

좋은 요약은 원문을 대체하지 않는다. 원문으로 돌아가는 길을 짧게 만든다. 이 기준이 없으면 summary는 retrieval aid가 아니라 hallucination cache가 된다.

classification도 마찬가지다. 모델에게 "이 문서가 무슨 내용인지 분류해줘"라고 던지는 것은 쉽지만, label set이 없으면 결과가 매번 흔들린다. 오늘은 workflow, 내일은 ops, 모레는 automation이라고 부르면 검색과 통계가 오히려 지저분해진다.

그래서 local worker를 붙이기 전에 먼저 오케이징의 label set을 작게 잡아야 한다. 예를 들면 memory, workflow, automation, discord, voice, architecture, study, career, academic 정도다. worker는 이 label set 안에서만 고르게 하고, 애매하면 needs_review로 보내는 편이 낫다.

reranking은 특히 조심해야 한다. 검색 결과를 더 예쁘게 정렬하는 대신, 중요한 source를 아래로 밀어버릴 수 있다. 오케이징 memory에서는 "그럴듯한 문서"보다 "실제로 작업에 필요한 문서"가 더 중요하다.

그래서 reranking 평가에서는 top-1의 자연스러움보다 top-k recall을 먼저 본다. 예를 들어 SEOJing build workflow를 찾는 query라면 package.json, turbo.json, 관련 skill reference가 후보 안에 살아 있어야 한다. 모델이 블로그 글만 위로 올리고 실제 script를 밀어내면 실패다.

local LLM worker는 오케이징을 더 빠르게 만들 수 있다. 하지만 memory의 권위를 모델에게 넘기는 순간 구조가 약해진다. 지금 단계에서 worker가 할 일은 source를 대체하는 것이 아니라 source에 더 빨리 도달하게 만드는 것이다.

그래서 먼저 평가 기준을 세운다. summary는 누락을 본다. classification은 label set을 먼저 둔다. reranking은 recall을 지켜야 한다. 이 세 가지를 통과하기 전까지 local LLM worker는 자동 판단자가 아니라 draft worker로만 둔다.