Hermes Agent로 Dify RAG 유사도 0.54 → 0.80 승인형 개선 루프 만들기

소개

시도하고자 했던 것

저는 전통 한국 명리학(사주 분석)을 AI로 디지털 보존하는 프로젝트를 6개월째 풀타임으로 진행하고 있습니다. LangGraph 11노드 파이프라인이 Dify RAG를 호출하여 통변 근거를 검색하는데, 현재 의미 유사도 평균이 0.5395입니다. 목표는 0.80이지만, 60갑자(일주) × 4단계 분석 = 240개 조합을 사람이 수동으로 진단하는 건 비현실적이었습니다.

그 이유

Hermes Agent의 Cron 자동실행과 스킬 자가진화 기능을 활용하면, 240개 조합을 매일 새벽 자동 순찰하고 약점을 리포트하는 "승인형 품질 개선 루프"를 만들 수 있겠다고 판단했습니다. 핵심 원칙은 명확합니다 — 자동 진단은 에이전트가, 최종 반영은 사람이 승인하는 구조입니다.



진행 방법

3.1 사용한 도구

3.2 평가를 3층위로 분리했습니다

처음에는 단일 semantic similarity만 추적했는데, 낮은 점수가 "검색이 잘못된 건지, 답변 생성이 잘못된 건지, 운영 문제인지" 구분이 안 됐습니다. 그래서 평가를 세 층위로 나눴습니다.

Retrieval 층위 — Dify가 가져온 문서가 질문에 적합한지 (문맥 관련성), 240셀 중 0.50 미만 비율이 얼마인지 측정합니다.

Generation 층위 — 답변이 검색된 근거에 충실한지 (근거성), 원래 질문에 적합한지 (답변 관련성), 기준 통변문과의 의미 유사도를 봅니다.

Operation 층위 — API 호출 지연시간, 실패율, query당 비용을 모니터링합니다.

TruLens의 RAG Triad(문맥 관련성 + 근거성 + 답변 관련성) 개념을 수기 평가에 적용했고, 자동화 도구(RAGAS/DeepEval)는 다음 Phase에서 검토할 예정입니다.

3.3 저품질 셀 원인 분해

3.4 Step 1 — RAG 품질 히트맵 자동 생성

60갑자 × 4단계 분석의 RAG 검색 품질을 자동 측정하는 Hermes 스킬을 만들었습니다. 각 일주 × 4단계로 Dify를 호출(240회)하고, relevance score를 기록한 뒤, 이전 결과와 비교합니다. 출력물은 240셀 히트맵(JSON + 마크다운)과 하위 10개 셀 리포트입니다.

4단계 분석의 표준 질의 템플릿은 이렇게 설계했습니다:

3.5 Step 2 — Hermes Cron 매일 새벽 자동 실행

매일 04:00 KST에 자동 실행됩니다. DB 조회 → Dify 호출 → 매트릭스 생성 → JSON 저장 → 이전 비교 → Telegram 알림 → 로그 기록. API 호출 실패 시 해당 셀만 'N/A' 처리하고 나머지는 계속 진행합니다.

3.6 Step 3 — 쿼리 + Retrieval 설정 A/B 테스트

하위 10개 취약 셀에 대해 쿼리 변형 5종과 retrieval 설정 변형을 함께 실험했습니다. 처음에는 쿼리 문구만 바꿔봤는데, 실제로는 Top K·rerank·metadata filter 같은 retrieval 설정이 품질에 더 큰 영향을 미쳤습니다.

전체 240셀에 모든 변형을 적용하면 비용이 급증합니다. 하위 10개 셀만 집중하되, 비용·지연시간도 함께 기록하는 것이 현실적이었습니다.

3.7 Step 4 — 3대 자료 계통 교차 검증

매주 토요일 03:00에 프로젝트의 3대 자료 계통 간 일관성을 자동 측정합니다. 같은 일주에 대해 세 계통이 서로 다른 해석을 내놓으면(일관성 < 0.5) 모순 의심 리포트가 올라오고, 높으면(> 0.8) 통변 신뢰도 높음으로 판정합니다.

3.8 3층 데이터셋 설계

더미 DB는 커버리지 분석에 유리하지만, 최종 품질 판단은 골드셋 + 실DB 기준입니다. 데이터 분리 원칙은 절대 준수했습니다.

결과와 배운 점

기대 효과

위 수치는 목표치입니다. 실측 결과에는 측정일·데이터셋 버전·모델 버전·비용을 함께 기록합니다.

꿀팁 5가지

1. 스킬의 쓰임새를 좁게 잡아라 — "RAG 품질 개선"이 아니라 "60갑자 히트맵 생성"처럼 좁게 만들어야 자동 호출이 정확했습니다.

2. memory에는 포인터만, 자료는 DB로 — 240셀 원본은 PostgreSQL에, memory에는 "최신 리포트 경로"만 저장했습니다. 처음에 둘 다 넣었다가 동기화 지옥을 경험했습니다.

3. 더미 DB는 커버리지 진단용으로만 — 60갑자 전체를 빈칸 없이 점검하는 데 유용하지만, 최종 품질 판단은 골드셋 + 실DB 기준으로 해야 했습니다.

4. A/B 테스트는 retrieval 설정까지 확장하라 — 쿼리 문구보다 Top K·rerank·metadata filter가 품질에 더 큰 영향을 미칠 수 있었습니다.

5. 자동 반영보다 승인 루프를 유지하라 — Hermes가 제안하고, 사람이 승인한 뒤 반영. 명리학 통변은 해석 체계가 중요하므로 자동 반영은 위험합니다.

시행착오

Dify API를 240회 연속 호출했더니 rate limit에 걸렸습니다. 0.5초 sleep + exponential backoff을 넣어서 해결했습니다.

쿼리 변형을 10종 이상 만들었더니 비용이 급증했습니다. 5종 이하 + retrieval 설정 변형 병행이 현실적이었습니다.

memory와 PostgreSQL에 이중 저장했더니 동기화 문제가 생겼습니다. PostgreSQL을 정본으로, memory는 포인터만 두는 것으로 정리했습니다.

단일 유사도만 추적했을 때는 검색 실패와 생성 실패를 구분할 수 없었습니다. 3층위 평가로 전환하니 원인 분해가 가능해졌습니다.

< 앞으로의 계획 >

도움 받은 글 (옵션)

• DECK 스터디장 — Hermes 메가진화 소개 영상 (스킬 자가진화·장기 메모리)

• Hermes 공식 문서 — Installation & Quickstart, Security

• Dify 공식 문서 — Knowledge Retrieval, Retrieval Settings

• TruLens — RAG Triad (Context Relevance, Groundedness, Answer Relevance)

• Es et al. (2023) — RAGAS: Automated Evaluation of RAG

• 한바둑 프로젝트 보고서 v2.0, 더미DB 구축보고서 v1.3