Slogs LLM Wiki 검색은 어떻게 기억을 찾아내는가

Slogs LLM Wiki의 검색 흐름을 EmbeddingGemma, pgvector, 그래프 신호, Retrieval Diagnostics 관점에서 설명합니다.

Slogs LLM Wiki GraphRAG search flow

LLM Wiki에서 검색은 단순히 “키워드가 들어간 문서를 찾는 일”이 아니다. Agent가 다음 행동에 쓸 수 있는 기억을 찾아야 한다. 그래서 Slogs LLM Wiki의 검색은 세 가지 신호를 함께 본다.

사용자의 질문이 어떤 의미를 갖는지
저장된 기억의 의미 벡터가 얼마나 가까운지
기억 사이의 카테고리, 태그, 관련 항목 연결이 어떤 그래프를 이루는지

이 글에서는 Slogs LLM Wiki의 검색 흐름을 GraphRAG 관점으로 정리한다.

1. 질문을 임베딩으로 바꾼다

검색의 첫 단계는 질문을 임베딩 벡터로 바꾸는 것이다. Slogs에서는 서버 로컬의 EmbeddingGemma 모델을 사용하도록 정책을 잡았다. 외부 hosted API에 매번 보내는 구조가 아니라, 서버 내부에서 재현 가능한 임베딩을 만들기 위해서다.

이 선택에는 장점이 있다.

API 키가 검색 경로에 끼지 않는다.
로컬 운영 환경에서 검색 품질을 반복 측정하기 쉽다.
장애 원인이 네트워크/API/과금 이슈로 퍼지지 않는다.

물론 로컬 모델을 쓰면 배포 크기와 초기 로딩 시간이 늘어난다. 그래서 Slogs는 모델 호출을 핵심 경로로 인정하고, 실패 시 조용히 다른 검색으로 우회하는 방식을 피한다. 검색 품질을 보장하려면 실패가 드러나야 한다.

2. pgvector로 가까운 기억 후보를 고른다

임베딩이 만들어지면 PostgreSQL의 pgvector를 통해 가까운 기억 후보를 찾는다. pgvector는 PostgreSQL 안에서 vector 타입과 유사도 검색을 사용할 수 있게 해주는 확장이다.

이 단계는 seed retrieval에 가깝다. 처음부터 “정답”을 하나 고르는 것이 아니라, 의미적으로 가까운 후보 묶음을 만든다.

후보를 너무 많이 가져오면 Agent에 전달되는 문맥이 커지고, 너무 적게 가져오면 중요한 기억이 빠진다. 그래서 Slogs MCP 도구는 기본 limit을 작게 잡고, 필요할 때만 좁은 query/categoryPath/minRelevancePercent로 다시 조회하게 한다.

3. 그래프 신호로 후보를 다시 본다

GraphRAG의 핵심 아이디어는 문서 조각을 벡터로만 보지 않고, 지식 간의 관계를 함께 활용하는 데 있다. Slogs LLM Wiki도 이 방향을 따른다.

예를 들어 어떤 기억이 slogs/llm-wiki/graphrag 카테고리에 있고, 다른 기억이 slogs/deployment/wasm-aot에 있다면 둘은 모두 Slogs 프로젝트 기억이지만 적용 맥락은 다르다. 같은 단어가 들어 있어도 categoryPath가 다르면 Agent가 다르게 해석해야 한다.

그래서 categoryPath는 단순 분류 라벨이 아니다. 검색 범위를 좁히고, 기억의 적용 영역을 판단하는 구조 정보다.

좋은 categoryPath는 대체로 이렇게 생겼다.

project/domain/topic
project/feature/decision
preference/domain/project
codex/mcp/slogs

반대로 general, misc, notes 같은 경로는 나중에 검색을 어렵게 만든다. 주제를 알 수 있으면 구체적으로 저장해야 한다.

4. Retrieval Diagnostics로 검색 품질을 본다

Agent 검색에서 가장 위험한 상황은 “검색을 했지만 사실상 실패한 것”을 성공으로 착각하는 것이다. 결과가 0개였거나, 상위 결과가 엉뚱하거나, 너무 넓은 범위를 훑어서 쓸모없는 문맥만 가져왔는데도 Agent가 그럴듯하게 답하면 기억 시스템은 오히려 위험해진다.

그래서 Slogs LLM Wiki 응답에는 Retrieval Diagnostics를 붙인다.

result count
effectiveLimit
categoryPath
minRelevancePercent
elapsedMs

Agent는 이 값을 보고 조회가 충분했는지 판단해야 한다. 결과가 부실하면 query를 바꾸거나, categoryPath를 좁히거나, limit을 조정해서 다시 조회한다. 검색이 느리거나 결과가 너무 크면 그 자체도 신호다.

5. search와 recall은 다르게 쓴다

Slogs MCP에서 llm_wiki_search와 llm_wiki_recall은 일부러 역할이 다르다.

search는 후보 선별 도구다. 제목, 요약, 태그, categoryPath 정도만 보고 “무엇을 읽을지”를 고른다.

recall은 실제 답변이나 구현에 적용할 compact context를 가져온다. 그래서 더 많은 문맥을 반환하지만, 기본 limit은 작게 유지하는 편이 좋다.

전체 원문이나 raw provenance가 필요하면 read를 쓴다. 이렇게 해야 Agent가 필요한 만큼만 읽고, 근거가 필요한 순간에는 정확한 항목을 열 수 있다.

운영 관점의 결론

GraphRAG는 화려한 이름보다 운영 규칙이 중요하다. Slogs LLM Wiki에서 실제로 중요했던 것은 다음 네 가지였다.

로컬 임베딩 모델을 검색의 공식 경로로 둔다.
pgvector로 의미 후보를 안정적으로 뽑는다.
categoryPath와 관련 항목을 그래프 신호로 쓴다.
Retrieval Diagnostics로 검색 품질을 Agent가 판단하게 한다.

이 구조가 있어야 Agent는 “기억을 검색했다”에서 멈추지 않고, “쓸 수 있는 기억을 회수했다”에 가까워진다.

참고 링크

Microsoft GraphRAG: https://microsoft.github.io/graphrag/
pgvector: https://github.com/pgvector/pgvector
EmbeddingGemma: https://ai.google.dev/gemma/docs/embeddinggemma
Ollama API: https://github.com/ollama/ollama/blob/main/docs/api.md