Archive pre-refactor interview notes and add current deep-dives on architecture evolution, issue-derived stories, and evidence gates.
2.6 KiB
2.6 KiB
RAG Breadcrumb Embedding 验收说明
1. 改动是什么
索引路径现在构造 embedding 文本时,不只使用 chunk 内容,还会把结构上下文拼进去:
Title: {title}
Path: {breadcrumb}
Content:
{content}
Milvus 中存储的 content 字段仍然保留原始 chunk 内容。这样展示和证据输出保持干净,而向量本身携带章节语义。
2. 为什么必须重新索引
Embedding 是索引时物化的。已有向量是用旧的 content-only 文本生成的,所以只有代码变化并不会改变线上检索结果。
验收关键点:
只改代码 != live retrieval 已变化
代码改动 + 重新索引 + live query report = 行为验收完成
3. 如何验证
- 启动 Spring Boot 应用。
- 通过现有索引路径重新索引知识库。
- 运行:
python scripts/eval_rag_live_acceptance.py
脚本输出:
eval/rag-retrieval/reports/live-post-reindex.json
eval/rag-retrieval/reports/live-post-reindex.md
默认覆盖:
- breadcrumb 敏感的 RAG chunk context query。
- 需要章节路径的诊断流程问题。
ERR_TIMEOUT精确错误码检索。- MySQL 连接池排障。
- AIOps payment-service 延迟告警检索。
4. 看什么结果
对 breadcrumb 敏感 case:
- top candidates 是否暴露预期
title。 - top candidates 是否暴露预期
breadcrumb。 - 命中内容是否能看出所属章节。
对核心排障 case:
- 结果数量是否稳定。
- top candidates 是否仍然命中核心文档。
- 没有因为拼接 title/breadcrumb 导致核心检索退化。
5. 面试回答
如果被问:你怎么验证 breadcrumb 参与 embedding 后真的生效?
我把 deterministic regression 和 live acceptance 分开。
离线 fixture baseline 不依赖服务,可以做稳定回归。
但 embedding 改动只会影响新生成的向量,所以我另外加了 live post-reindex acceptance 脚本。
脚本会调用真实 /api/search/similar,对 breadcrumb 敏感、排障和 AIOps query 生成 JSON/Markdown 报告。
这样能证明代码改了,也能证明 live vector collection 已经刷新。
如果被问:为什么脚本不自动 reindex?
reindex 会修改向量库,而且依赖环境中的知识库数据。
我把 reindex 保持为显式动作,验收脚本只做读取验证。
这样如果检索没有改善,我能区分是代码问题、索引未刷新,还是运行时检索行为问题。
6. 后续增强
- 将 live acceptance 结果加入面试 Demo 输出。
- 增加 breadcrumb hit rate 统计。
- 对同章节 chunk 做邻居扩展,进一步利用 breadcrumb。