如果语料库是您构建一次然后完成的静态资产，则此部分可能会很短。然而，在处理不断变化的数据的环境中（IT 公司服务计划、知识库、API 文档等），语料库质量管理成为 RAG 管道中最重要的部分。
| 类别 | 解释 | 例子 |
|---|---|---|
| 缺乏信息（差距） | 语料库中没有主题 | 新推出功能的计划尚未得到体现。 |
| 信息过时 | 以前正确但现在不正确的信息 | 去年的 API v1 文档仍然存在，但目前是 v2 |
| 信息冗余 | 同一内容在多个来源重复 | 语料库中存在功能相同的规划文档v1、v2、v3。 |
其中，信息腐败最为危险。差距被揭示为“没有搜索结果”，但腐败信息是“搜索结果可用但错误”，因此 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 公司环境中，文档不断更新。每次都进行完全重建效率低下，因此需要增量更新策略：
策略一：基于时间戳的增量同步
[변경 감지]
최종 동기화 시각 이후 수정된 문서만 추출
(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) 的过期
为经常更改的文档设置 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
▼
수렴 완료
收敛条件：
在Saju项目中，方法是“在线搜索和收集数据”，但在IT公司，数据来源有所不同：
| 步 | 沙州项目 | IT公司申请 |
|---|---|---|
| 间隙检测 | 批量搜索20个关键查询 | 自动从用户查询日志中收集分数 < 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) 具有相同的结构，并并行执行五个子代理 (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 → 排除原文保存原则：
子代理不会汇总搜索结果并按原样传递原始文本。协调员负责解释。这种分离保证了核电厂报价的准确性。