작성일: 2026-07-15 목적: "현재 Hermes에 RAG를 설정한다는 것의 의미"에서 출발해, 실제 컨테이너를 실측하며 Hermes의 메모리/도구 구조를 규명하고, 문서 RAG 파이프라인 설계 결정까지 도달한 전 과정 기록. 성격: 학습/의사결정 기록 (실행계획은 별도 글 Hermes 문서 RAG 파이프라인 — 실행계획서).
1. 논의 흐름 (질문 → 결론)
| 순번 | 사용자 질문 | 도달한 결론 |
|---|---|---|
| Q1 | Hermes에 RAG 설정한다는 게 무슨 의미? | RAG=검색증강. 모델 재학습 아니라 "관련 조각을 찾아 프롬프트에 주입". Hermes 맥락에선 채널별 지식/문서 검색 계층 추가를 의미 |
| Q2 | Hermes가 RAG를 네이티브 지원? | setup 문서엔 없음. RAG는 "직접 구현 대상(수집·임베딩·벡터DB)"으로 명시·배제됨. 대신 memories/+skills/ 보유 |
| Q3 | 각 채널 봇이 대화메모리를 언제든 참조하는 구조? | 부분적으로 예. 내장 MEMORY.md는 always-active(자동 주입). 단 '항상 자동 회수'의 실동작은 provider 설정에 좌우 |
| Q4 | 설정/스킬 실측 확인 | 아래 2절 참조 |
| Q5 | 외부 provider 활성화 시 RAG 정보 범위 / 벡터DB 없이 가능? | 범위=프로필별 대화 유래 메모리. holographic은 로컬 SQLite로 벡터DB·API키 없이 가능 |
| Q6 | provider=대화메모리, skill=외부문서로 정리 가능? | 축을 "기억(provider) vs 능력(skill)"으로 잡는 게 정확 |
| Q7 | provider=LLM메모리, skill=필요시 사용? | 맞음. 단 "LLM의 메모리"가 아니라 "에이전트(봇)의 메모리" (모델은 stateless) |
| Q8 | provider 많이 켤수록 좋은가? | 아니오. 외부 provider는 동시 1개만. skill은 많아도 됨(서로 다른 능력) |
| Q9 | holographic는 md가 아니라 SQLite? | 맞음. /opt/data/memory_store.db. MEMORY.md를 대체가 아니라 보완 |
| Q10 | Mattermost 모든 대화·파일이 대상? | 아니오. 3개 관문(수신/저장/파일)이 있고 대부분 기본 비활성 |
| Q11 | 설정만 바꾸면 모든 대화·파일 RAG 가능? | 아니오. 대화 사실추출까지는 설정, "모든" 메시지/파일은 구축 필요 |
| Q12 | SQLite+FTS5+HRR란? SQLite만으론? | 3계층 분업(저장/키워드/의미). SQLite 단독은 정확매칭만 |
| Q13 | 문서 RAG 파이프라인 선택지 | A~E 5안 정리 (4절) |
| Q14 | 위 제안 모두 Mattermost 전제? | 아니오. 인제스트 통로와 질의 통로는 독립. A~E는 채널 무관 백엔드 |
| Q15 | 요구사항 확정 | 소스=드라이브+ERP+MM파일, 질의=Mattermost |
| Q16 | 최종 4개 결정 | ERP 실시간호출 / 부서스코프 / C안 / API임베딩 |
2. Hermes 메모리 아키텍처 — 실측 결과
실행 중인 hermes 컨테이너를 직접 조회해 확인한 사실.
2.1 내장 메모리 (항상 활성)
hermes memory설명: "Built-in memory (MEMORY.md/USER.md) is always active."- 즉 MEMORY.md/USER.md는 회수 트리거 없이 매 세션 컨텍스트에 자동 주입.
- 저장 위치(프로필별 격리):
- default →
/opt/data/memories/MEMORY.md(루트 = default 인스턴스) - sales →
/opt/data/profiles/sales/memories/MEMORY.md
- default →
- 실측: sales의 MEMORY.md 내용은
--clone으로 복제된 default의 Docker 인프라 노트였음 → 현재 각 봇은 채널 고유지식이 아직 없음(앞으로 축적).
2.2 외부 provider (동시 1개만, 현재 전부 비활성)
- 상태:
Provider: (none — built-in only)— default·sales 모두. - 설치된 플러그인 8개: byterover, hindsight, holographic, honcho, mem0, openviking, retaindb, supermemory.
- 제약: "Only one external provider can be active at a time." → 여러 개 동시 활성 불가. "많이 켤수록 좋다"는 틀림.
2.3 두 저장소 구분
| 저장소 | 내용 | 참조 방식 |
|---|---|---|
sessions/ |
대화 원문 | 같은 세션 내에서만 |
memories/MEMORY.md |
증류된 영속 사실 | 매 세션 자동 주입(항상) |
USER.md |
사용자 관련 사실 | 매 세션 자동 주입 |
- 별도
memory-graph/journey명령: 학습된 skill·메모리를 시간축으로 시각화.
3. Provider 상세 (실측 근거)
각 provider의 README/소스에서 확인한 저장 범위·인프라 요구.
| Provider | 저장·검색 | 인프라 | 비용 |
|---|---|---|---|
| holographic | 로컬 사실저장소, 개체해소, 합성회수 | 로컬 SQLite (요구사항 없음) | 무료 |
| mem0 | LLM 사실추출 + 의미검색 | 클라우드 (API키) | 유료 |
| honcho | cross-session 사용자 모델링, 세션요약 | 클라우드/자가호스팅 | 계정 |
| retaindb | 하이브리드검색(Vector+BM25+Rerank), 7가지 메모리유형 | 클라우드 | 월$20 |
| supermemory | — | 클라우드 (API키 필수) | 유료 |
3.1 holographic 심층 (소스 store.py 확인)
- 저장 경로:
$HERMES_HOME/memory_store.db(=/opt/data/memory_store.db) - 테이블:
facts,entities,fact_entities, FTS5 인덱스,memory_banks - 설정 기본값:
auto_extract=false(세션끝 자동추출 꺼짐),default_trust=0.5,hrr_dim=1024 - 도구:
fact_store(add/search/probe/related/reason/contradict/update/remove/list 9종),fact_feedback(신뢰점수 학습) - ⚠️
auto_extract=false기본 → 켜기만 해선 자동축적 안 됨. 봇이fact_store호출하거나 옵션을 켜야 함.
4. 핵심 개념 정리
4.1 SQLite + FTS5 + HRR (3계층 분업)
- SQLite = 저장소(그릇). 단독은 정확일치/
LIKE만 → 느리고, 순위 없고, 단어 안 맞으면 못 찾음. - FTS5 = SQLite 내장 전문검색. 역색인 → 빠른 키워드 검색 + 관련도(BM25) 순위. 단, 어휘 매칭("car"로 "automobile" 못 찾음).
- HRR(Holographic Reduced Representations) = 개념·관계를 고정 벡터(1024차원)로 인코딩 → 의미·연상·관계 검색. 외부 임베딩 모델 없이 자체 벡터 생성 → 인프라 0의 핵심.
- 결론: SQLite=담기, FTS5=단어검색, HRR=의미검색. 셋이 합쳐져야 'RAG처럼' 동작. holographic의 가치=한 파일 안에서 외부인프라 없이.
4.2 Provider vs Skill (기억 vs 능력)
- Provider = 봇(에이전트)의 기억. 자동으로 쌓이고 자동으로 프롬프트에 주입(수동적·상시). 모델을 갈아끼워도 유지(모델 아니라 프로필에 붙음).
- Skill = 봇이 필요할 때 호출하는 도구. 능동적. 문서읽기(obsidian/ocr-and-documents/llm-wiki)는 여러 skill 중 일부일 뿐.
- 주의: "LLM의 메모리"가 아님 — LLM은 stateless, 기억 주체는 Hermes.
- "많을수록 좋다"는 skill엔 해당(서로 다른 능력), provider엔 틀림(동시 1개, 겹치는 기능).
4.3 두 종류의 RAG
- ① 메모리 RAG(대화 기반) — mem0/honcho/holographic 등. 대화에서 추출된 사실 검색.
- ② 문서 RAG(외부 리소스) — PDF·위키·파일 색인. memory provider가 아니라 별도 skill/파이프라인.
5. "Mattermost 모든 것이 자동 대상인가" — 3개 관문 분석
Mattermost에 올라온 것이 자동으로 학습되지 않는 이유:
| 관문 | 설명 | 현재 상태 |
|---|---|---|
| ① 수신 | 봇은 멘션/DM + 허용사용자(MATTERMOST_ALLOWED_USERS)만 받음. 채널 전체 감청 아님 |
기본=멘션/DM. passive/listen-all 플래그 게이트웨이에 없음 |
| ② 저장 | 받은 것도 자동저장 아님. provider 꺼짐 + auto_extract=false |
봇이 저장 판단해야 |
| ③ 파일 | 업로드 파일은 memory 아닌 skill 영역. 자동 색인 파이프라인 없음 | 직접 구축 필요 |
→ "설정만으로 모든 대화/파일 RAG"는 불가. 대화 사실추출까지가 설정 한계, "모든" 메시지·파일 색인은 별도 구축.
6. 문서 RAG 파이프라인 선택지 (A~E)
| 방식 | 벡터DB | 임베딩 | 데이터 위치 | 메모리 | 난이도 | 규모 | |
|---|---|---|---|---|---|---|---|
| A | Skill만(obsidian/llm-wiki) | 없음 | 없음 | 로컬파일 | ~0 | ★ | 소 |
| B | holographic에 문서주입 | 내장SQLite | HRR자체 | 로컬 | 낮음 | ★★ | 소~중 |
| C | 임베디드 벡터스토어(sqlite-vec/Chroma) | 로컬 | 로컬/API | 로컬 | 중 | ★★★ | 중 |
| D | 클라우드 provider | 클라우드 | 클라우드 | 외부전송 | 낮음 | ★★ | 중~대 |
| E | 전용 벡터DB 사이드카(Qdrant/pgvector) | 컨테이너 | 로컬/API | 로컬 | 높음 | ★★★★★ | 대 |
- 파이프라인 4대 결정: ①인제스트 방식 ②청킹 ③임베딩 위치 ④벡터 저장 위치.
- 이 환경 병목=Docker VM 메모리 → E는 메모리 상향 없이 배제, A·B가 제약 적합, C가 품질 업그레이드 경로.
7. 통로 2개 구분 (중요한 개념 교정)
RAG엔 성격 다른 두 파이프가 있고 Mattermost는 하나에만 관여:
- ① 지식 인제스트 통로 — 문서가 저장소로 들어오는 길 (폴더/드라이브/크론/업로드훅). Mattermost 무관.
- ② 질의 통로 — 사용자가 묻고 답받는 길 (Mattermost/Slack/CLI/Telegram…). 현재 Mattermost.
- 지식베이스(무엇을 아는가)와 통로(어디서 대화하는가)는 독립. A~E는 채널 무관 백엔드.
8. 최종 요구사항 & 결정
- 지식 소스: 구글드라이브 + ERP/외부시스템 + Mattermost 업로드 파일 (전부)
- 질의 채널: Mattermost 통일 (부서별 봇)
- 4개 결정:
- ERP = 실시간 도구호출 (색인 안 함)
- 지식 범위 = 부서(dept) 스코프
- 저장소 = C안 (임베디드 벡터스토어)
- 임베딩 = API
- 추가 확정: 지식 격리 = 부서 수준(부서 내 민감파일은 색인 제외).
9. 다음 단계
- 실행계획서(Hermes 문서 RAG 파이프라인 — 실행계획서)의 확정필요 체크리스트(O1~O8 + ERP명세 + 메모리상향) 확정.
- 확정 후 writing-plans 단계로 상세 실행계획 수립 → 이후 Phase 0부터 구축.
- ⚠️ 본 세션에서는 개발 미착수 (사용자 지시).
부록. 프로젝트 불변 규칙 (기존 메모리)
- default 프로필 절대 삭제/변경 금지. 새 채널은 항상 프로필 "추가"로만.
- 채널당 별도 봇 계정/토큰 필수 (같은 토큰 재사용 시 중복 응답).
- Ubuntu에선
docker exec -u hermes로 실행 (root 소유권 함정).