コーパスが一度構築して終わる静的な資産であれば、このセクションが短くてもよい。しかし、変更されるデータを扱う環境 - IT会社のサービス企画書、Knowledge Base、API文書など - ではコーパス品質管理がRAGパイプラインで最も重要な部分となる。
| タイプ | 説明 | 例 |
|---|---|---|
| 情報部材（Gap） | コーパスにはそのトピックがありません | 新発売機能の企画書がまだ未反映 |
| 情報腐敗(Staleness) | 以前は正しかったが、今は間違った情報 | 昨年はAPI v1ドキュメントが残っていますが、現在はv2 |
| 情報の重複(Redundancy) | 同じ内容が複数のソースで繰り返される | 同機能の企画書v1、v2、v3が全てコーパスに存在 |
このうち情報腐敗が最も危険である。 Gapは「検索結果なし」と明らかになるが、腐敗した情報は「検索結果はあるが間違っている」ので、LLMが自信を持って間違った答えを出す。
新しい文書を追加するときは、既存のコーパスとコサインの類似度で比較します。
# 신규 청크 vs 기존 청크 유사도 행렬
sim_matrix = new_embeddings @ existing_embeddings.T # (new × existing)
# 각 신규 청크의 최대 유사도가 threshold(0.92) 이상이면 중복
for i, row in enumerate(sim_matrix):
if row.max() >= 0.92:
dup_count += 1
判定基準：
duplicate（追加しない）partial（レビュー後追加）new（すぐに追加）コーパスが大きくなると、異なるソースで同じ内容が重複する可能性があります。
python scripts/dedup.py --self-dedup data/chunks_meta.jsonl --threshold 0.95
隣接チャンク（オーバーラップによる自然な類似）を除いて、異なるソースファイル間0.95以上の類似度のみを報告。
IT会社環境では、文書が絶えず更新されます。リビルド全体を毎回実行するのは非効率的であるため、増分更新戦略が必要です。
戦略1：タイムスタンプベースの増分同期
[변경 감지]
최종 동기화 시각 이후 수정된 문서만 추출
(Confluence: lastModified, Git: git log --since, 파일시스템: mtime)
│
▼
[기존 청크 제거]
해당 소스의 기존 청크를 chunks_meta.jsonl에서 삭제
│
▼
[신규 청킹]
변경된 문서만 chunk.py로 재처리
│
▼
[증분 인덱싱]
신규 청크만 임베딩 생성 → 기존 embeddings.npy에 append
BM25 인덱스는 전체 재구축 (in-memory 방식이므로 빠름)
戦略2：バージョン管理ベースの交換
文書にバージョンがある場合（計画書v1→v2→v3）：
[신규 버전 감지]
v3 문서가 들어옴
│
▼
[이전 버전 청크 삭제]
source가 "기획서_v1", "기획서_v2"인 청크를 모두 제거
│
▼
[신규 버전 청킹 + 인덱싱]
v3만 코퍼스에 남김
これにより、「情報腐敗」の問題を構造的に防止することができる。以前のバージョンをアーカイブに保存しますが、検索対象から除外します。
戦略3：TTL（Time-To-Live）ベースの有効期限
頻繁に変更される文書（週間報告、スプリント企画など）にはTTLを設定：
# 청크 메타데이터에 만료 시각 추가
{
"chunk_id": "sprint_plan_0001",
"source": "2026_Q1_sprint_plan.md",
"expires_at": "2026-04-01T00:00:00", # 분기 종료 시 만료
...
}
# 검색 시 만료된 청크 필터링
results = [r for r in results if r.get("expires_at", "9999") > now()]
コーパスの情報が現実と矛盾することを自動的に検出する方法:
方法1：定期的なギャップ検索（このプロジェクトで使用）
コアクエリセットを定義し、定期的に検索してスコアの変化を追跡します。
쿼리: "결제 API v3 엔드포인트"
- 1주 전 score: 0.85 (정상)
- 현재 score: 0.45 (급락) → 문서가 삭제되었거나 변경됨 → 알림
方法2：ユーザーフィードバックループ
RAGベースのボットが答えたとき、「助けになりましたか？」ボタンを追加：
方法3：交差検証
同じトピックに複数のソースがある場合、答えが矛盾する場合はフラグ：
소스 A: "결제 타임아웃은 30초"
소스 B: "결제 타임아웃은 60초"
→ 모순 감지 → 어느 것이 최신인지 확인 필요
コーパスは時間が経つと必ず劣化する。新しい質問が出て、既存の情報が古い、空の領域が明らかになる。これを人が手動で管理すれば持続不可能である。 「ギャップを探して→埋めて→検証する」サイクルを自動化しなければRAGが時間が経つほど良くなる。
┌───────────────────────────────────────────┐
│ │
▼ │
Step 1: 갭 분석 │
(핵심 쿼리 배치 검색, score < 0.75 = 갭) │
│ │
▼ │
Step 2: 자료 수집 │
(수집 에이전트 병렬, 온라인 검증 소스만) │
│ │
▼ │
Step 3: 출처 검증 + 중복 검사 │
(출처 없는 파일 삭제, dedup.py) │
│ │
▼ │
Step 4: 인덱스 리빌드 │
(chunk.py → embed.py) │
│ │
▼ │
Step 5: 검증 (동일 쿼리 재검색) │
│ │
▼ │
Step 6: 수렴 판단 │
모든 쿼리 score ≥ 0.75? ──No──────────────────────┘
│
Yes
▼
수렴 완료
収束条件：
社主プロジェクトでは「オンラインで資料を検索して収集」する方式だが、IT会社では資料ソースが異なる。
| ステップ | 社主プロジェクト | IT会社の適用 |
|---|---|---|
| ギャップ検出 | 20のコアクエリバッチ検索 | ユーザークエリログでscore <0.5のクエリを自動収集する |
| 資料収集 | オンライン検索エージェント | Confluence/Notion/Git 同期スケジューラ |
| ソース検証 | URLの有無を確認 | 文書所有者・最終修正日確認 |
| 重複チェック | コサイン類似度 0.92 | 文書IDベースの重複防止+コサイン類似度 |
| リビルド | 全体の再チャンキング+再賃金 | 増分更新（変更分のみ） |
| 検証 | 同じクエリの再検索 | A / Bテスト（以前のインデックス対新しいインデックス） |
具体的なシナリオ：サービス計画書RAG
[매일 02:00 크론잡]
↓
Confluence API로 최근 24h 내 수정된 페이지 목록 조회
↓
수정된 페이지: 기존 청크 삭제 → 신규 청킹 → 증분 임베딩
삭제된 페이지: 기존 청크 삭제
신규 페이지: 청킹 → 임베딩 → 추가
↓
BM25 인덱스 재구축 (in-memory라 30초 이내)
↓
검증 쿼리 셋 실행 → 이전 점수 대비 급락 항목 알림
ギャップ分析の鍵は、「このクエリに対して良い結果が出なければならない」という期待クエリセットをうまく設計することです。
// 이 프로젝트의 갭 쿼리 (20개)
[
"오행 상생상극 생극제화",
"지장간 투출 통근 격국",
"십성 식신 상관 정관 편관",
"용신 억부 조후 통관",
"궁합 천간합 오행 배합",
...
]
IT環境では：
// 서비스 Knowledge Base 갭 쿼리 예시
[
"결제 API 타임아웃 설정값",
"iOS 앱 최소 지원 버전",
"신규 가입 프로모션 할인율",
"장바구니 상품 최대 개수",
"개인정보 보유 기간 정책",
...
]
各クエリに対して期待スコアしきい値を設定し、定期的に検証します。しきい値を満たさないクエリが発生すると、その領域の文書が不足または変更されたことを示す信号です。
사용자: "1990-05-15 14:30 남자 사주 봐줘"
│
▼
┌─────────────────────────────────┐
│ saju-analysis (오케스트레이터) │
│ Phase 1: saju.py 실행 → JSON │
│ Phase 2: 5개 서브에이전트 병렬 │
│ Phase 3: 결과 통합 → .md 출력 │
└─────────┬───────────────────────┘
│ Agent() × 5 (parallel)
┌─────┼─────┬──────┬──────┐
▼ ▼ ▼ ▼ ▼
saju- saju- saju- saju- saju-
profile structure dynamics fortune timeline
│ │ │ │ │
│ 각 에이전트가 search.py로 RAG 검색
│ (주제당 2~3개 쿼리, 총 ~30회 이내)
│ │ │ │ │
└─────┴─────┴──────┴──────┘
│
각자 원문 인용 기반 분석 작성
│
▼
오케스트레이터가 통합·중복 제거
│
▼
output/YYYY-MM-DD_이름_일주_사주.md
相性分析(gunghap-analysis)も同じ構造で5つのサブエージェント(gunghap-mind-energy, gunghap-ilji, gunghap-destiny, gunghap-yongsin, gunghap-timeline)を並列実行する。四週間分析と相性分析の両方が同じRAG検索プロトコルに従う。
各サブエージェントは同じ規則に従います。
検索コマンド：
.venv/bin/python scripts/search.py \
"갑목(甲木) 인월(寅月) 조후용신" \
"궁통보감(窮通寶鑑) 갑목 봄" \
"甲木 寅月 用神" \
--top-k 3 --mode hybrid --json
結果活用基準：
score ≥ 0.6→高信頼。原文を必ず引用score 0.3~0.59→条件付き（該当トピックの唯一の結果であれば含む）score < 0.3→除く原文保存原則：
サブエージェントは検索結果を要約せず、原文をそのまま配信します。オーケストレーターは解釈を担当します。この分離により、原子力発電所からの見積もりの正確性が保証されます。