검색 증강 자체 재인식(Self-Recall) - 파트 6: 아무 효과 없었던 미세 조정과 이를 MCP 서버로 배포하기
요약
본 글은 검색 증강 자체 재인식(RE-call)의 최종 단계로, 임베더 미세 조정이 불필요했음을 발견한 경험을 공유합니다. RE-call 엔진은 MCP 서버(`recall_mcp`) 형태로 배포되어 Claude와 같은 에이전트가 일급 도구로서 직접 메모리에 질의할 수 있게 합니다.
핵심 포인트
- 파인튜닝 전, 기본 모델로 충분한지 먼저 검증하는 것이 중요합니다.
- RE-call은 MCP 서버를 통해 Claude 등 에이전트의 일급 도구가 됩니다.
- Postgres 기반 하이브리드 검색과 정직성 가드를 결합하여 메모리를 관리합니다.
- 검색 결과에는 신뢰도 판결, 출처, 유효성 등의 메타데이터가 포함됩니다.
검색 증강 자체 재인식(Retrieval-Augmented Self-Recall)의 파트 6 (피날레). 코드: RE-call. 파트 5: 전이되지 않은 간격 임계값(the gap threshold that didn't transfer).
저는 자체 도메인에 맞춰 임베더(embedder)를 미세 조정(fine-tuned)하며 성공을 기대했습니다. 저는 이를 홀드아웃 쿼리(held-out queries)로 제대로 측정했습니다.
개선된 점은 정확히 '0'이었습니다. Δ+0.00 MRR. Δ+0.00 nDCG@10. 이는
파인튜닝(Fine-tuning)은 기본 모델이 이미 사용자의 어휘를 포괄하지 못할 때 도움이 됩니다. 만약 이미 포괄하고 있다면, 아무것도 얻을 수 없습니다. GPU 시간을 쓰기 전에 자신이 어떤 영역에 있는지 아는 것이 중요합니다.
'0.00'이라는 결과가 바로 그 가치입니다. 이 값은 제 코퍼스(corpus)가 이미 범용 임베더(general-purpose embedder)에 의해 충분히 포괄되었음을 알려주었습니다. 이는 제가 필요하지 않은 파인튜닝 파이프라인을 피하게 해주었고, 언제 실제로 필요한지 정확히 알려주었습니다. 부정적인 결과를 습관적으로 묻어버리는 팀들은 이처럼 중요한 발견들을 놓치고 비싼 방식으로 재학습합니다.
배포: MCP 서버
아무도 연결할 수 없는 엔진은 논문일 뿐입니다. RE-call은 표준 입출력(stdio)을 통해 작동하는 MCP(Model Context Protocol) 서버인 **recall_mcp**로 배포됩니다. 따라서 Claude — 데스크톱, 코드 또는 모든 MCP 클라이언트 — 가 자체 메모리에 도구로서 직접 질의할 수 있게 됩니다.
이것은 적용된 시리즈와 연결 고리를 완성합니다. 세 가지 계층이 있습니다:
- 인간 편집 가능한 메모리: 사용자가 직접 관리하는 일반 마크다운 파일(Claude Code 시리즈의 두 파일 메모리 시스템).
- 검색 엔진: RE-call: Postgres 기반 하이브리드 검색 및 정직성 가드(honesty guards) 포함.
- MCP 서버: 에이전트가 런타임에 계층 2에 도달하는 방식, 즉 일급 도구(first-class tool)로서의 역할입니다.
그리고 설계 원칙은 적용된 시리즈에서 그대로 가져왔습니다: 정직성 신호는 도구의 구조화된 출력 안에 포함되어야 합니다. 에이전트가 메모리에 질의할 때, 응답은 단순히 순위가 매겨진 목록이 아닙니다. 모든 검색 결과에는 신뢰도 판결(trust verdict)(ok / superseded / expired / …), 보정된 신뢰도, 출처(provenance), 유효성이 포함되며, 그 결과는 gap_warning, 최신성(freshness), 그리고 명시적인 abstained + 이유를 담고 있습니다. 에이전트는
- 아키텍처 (Architecture) (파트 2) — 에이전트 메모리가 전용 벡터 DB를 필요로 하지 않기 때문에 순전히 Postgres만을 사용한 하이브리드(hybrid) 밀집(dense) + 희소(sparse) 검색 방식.
- 가드레일 (Guards) (파트 3) —
gap_warning, 최신성(freshness), 그리고 반(反)재소송(anti-re-litigation). 메모리가 수행하지만 검색 인덱스는 할 수 없는 세 가지 기능입니다. - 평가 (Evaluation) (파트 4) — MRR과 함께 측정되는 '잘못된 자신감률(false-confident rate)', 왜냐하면 중요한 실패는 순위 지표가 볼 수 없는 것이기 때문입니다.
- 발견 사항 (Findings) (파트 4–6) — 하이브리드 방식 + 재순위 지정(rerank)은 약한 임베더(embedders)에게만 비용을 벌어다줍니다; 하드코딩된 기권(abstention) 임계값은 조용한 지뢰밭이며; 그리고 미세 조정(fine-tuning)은 레짐 의존적이라서 기본 모델이 이미 커버하는 코퍼스에서는 정확히 아무 가치도 없습니다.
이 발견 사항 중 두 가지는 부정적인 결과입니다. 이것은 의도된 것입니다. 자신의 한계를 아는 영역에서는, 정직한 '널(null)' 값이 가장 귀중한 것이며 — 여기에 있는 모든 것은 공개적이고 재현 가능하며 150개의 테스트 스위트로 커버됩니다. 이 중 49개의 DB 관련 테스트는 실제 Postgres를 대상으로 실행되므로, 제 말만 믿으실 필요가 없습니다.
읽고, 실행하고, 부수기 (Read it, run it, break it)
전체 엔진은 오픈 소스입니다: RE-call (MIT). 클론하여 자신의 코퍼스에 연결하고, 제 임계값을 포함하여 어떤 것을 신뢰하기 전에 자신의 임베더의 보정(calibration)을 확인하십시오.
그리고 만약 응용 트랙에서 오셨다면, Claude Code, Beyond the Prompt에서 이 모든 것이 분노 속에서 사용되는 곳을 보실 수 있습니다. 에이전트가 매 세션 시작 시 읽는 메모리이며, 방금 내부 구조를 읽으신 엔진에 의해 뒷받침됩니다.
끝까지 읽어주셔서 감사합니다. 만약 이를 기반으로 구축하시거나 제가 틀린 부분을 발견하신다면, 꼭 들려주시길 바랍니다.
그리고 이것은 수사학적 마무리가 아닙니다. Part 1에 달린 댓글들에서 이미 제가 틀린 부분을 두 번이나 찾아주셨고, 그 수정 사항들이 v0.3으로 배포되었습니다. 이는 임계값(threshold)이 감지할 수 없는 근접한 오류(near-miss)를 위한 함의(entailment) 단계이자, 어떤 타임스탬프보다도 뛰어난 쓰기 시간 초월(write-time supersession)입니다. 댓글 작성자들의 이름이 찍힌 기록들은 시리즈 후속편에서 확인하실 수 있습니다.
Retrieval-Augmented Self-Recall의 대단원입니다. 코드: RE-call. 에이전트 메모리를 구축하는 것, 아니면 그런 일을 하는 사람을 고용하는 것? 이 시리즈는 제 답변의 장문 버전입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기