AI 知识库项目

主题导航： 内部系统与客服增强检索篇｜对应专项面试题

1. 项目摘要

项目类型：真实的结构化 AI 学习知识库；RAG 在线问答服务属于下一阶段可实施设计；
一句话目标：把分散的 AI 概念、项目案例和面试经验沉淀为可检索、可复习、可验证、可持续演进的知识系统；
主要用户：准备中高级 AI 应用工程师、AI 后端工程师及相关岗位面试的学习者；
当前技术载体：Markdown、YAML Frontmatter、Mermaid、教学图片、Codex Skill、Git；
演进技术：文档解析、结构化切块、Embedding、BM25、向量检索、RRF、Reranker、LLM、评测集和 Trace；
最关键难点：单一事实源、知识依赖、内容质量、索引新鲜度、引用可信度、检索评测和权限边界；
证据边界：仓库已经实现文档治理、目录、模板和 Skill 工作流，但没有实现在线 API、向量数据库、Reranker、监控平台或经过实测的效果指标。

1.1 30 秒项目结论

AI 知识库不等于“把文档丢进向量数据库”。当前项目先以 Markdown 和 Git 建立可版本化的知识源，用统一元信息、中文目录、前置依赖、项目案例和面试追问保证内容可学习、可复用；下一阶段再以这些文档为唯一事实源，构建“离线摄取与版本发布 + 在线混合检索与带引用回答”的 RAG 服务，并通过分层评测证明召回、回答、引用、拒答和系统稳定性，而不是用几个演示问题判断效果。

1.2 面试官为什么问

这个项目能同时考察：

是否把知识库理解为“内容治理 + 检索系统 + 生成系统 + 评测运营”，而不是单一向量库；
是否能区分语料缺失、解析失败、召回错误、上下文错误和模型生成错误；
是否理解 RAG、微调、长上下文、全文搜索和确定性工具的边界；
是否能处理文档更新、删除、索引切换、缓存失效、权限隔离和提示注入；
是否能用真实文件、版本、评测样本和 Trace 支撑项目表达，而不是虚构指标。

1.3 小白版项目故事

小林要在面试前回答“RAG 为什么会引用旧制度”，却发现笔记散在多个文件里：同一条规则有新旧两个版本，搜索结果只给标题，回答也没标明出处。他把这件事想成建设一间应急资料室：资料管理员只接收经过登记的最新版制度，目录员既按制度编号查找，也按问题含义找相近材料，复核员从候选资料中挑出真正相关的段落，答疑员只能依据已取出的材料作答并标注柜号、版本和页码；如果没有足够材料，就明确说“当前无法确认”。当旧制度撤回时，管理员还要同步撤销目录卡和复印件，避免继续被查到。

生活场景到技术机制的映射

生活场景元素	技术对象或动作
登记后的最新版制度	Git 快照中的权威 Markdown 与 `DocumentVersion`
按制度编号查目录	BM25 等关键词检索
按问题含义找材料	Embedding 与 Dense Retrieval
复核员筛选候选资料	RRF、去重与 Reranker
柜号、版本和页码	`document_id`、版本、`section_path` 与 Citation
门禁卡	身份上下文、ACL 过滤与召回后二次授权
撤销目录卡和复印件	Tombstone、索引切换与缓存失效
“当前无法确认”	证据不足时的拒答或澄清
借阅和答疑登记簿	`QueryTrace`、`EvalCase` 与反馈闭环

回到真实机制，当前仓库已经具备的是权威文档、元信息、目录、模板、Skill 与 Git 版本治理；BM25、Dense、Reranker、Citation 校验和在线 Trace 仍是待实现的 RAG 演进设计。这个故事解释了“先治理可信资料，再检索、复核、作答和留证”的职责分工，但它忽略了概率检索与生成的不确定性、Token 预算、并发长尾、提示注入以及多版本发布的一致性，因此不能代替后文的双链路架构、版本清单和分层评测。

2. 背景、目标与边界

2.1 业务背景

AI 学习内容分散在概念笔记、代码示例、项目经验、面试题和故障复盘中。只保存零散笔记会出现四类问题：同一知识点有多个冲突版本；能找到名词却无法解释原理；知道方案却说不清工程边界；文档写完后没有练习、追问和复盘，无法判断是否真正掌握。

因此，项目先解决知识工程问题：建立统一目录、标准文档结构、元信息、依赖关系、项目证据和质量状态。智能检索是建立在可信内容之上的服务层，不能替代源内容治理。

2.2 功能目标

当前知识治理层的目标：

按 AI 基础、机器学习、深度学习、LLM、RAG、Agent、AI 工程、系统设计、项目和面试组织内容；
每个完整主题形成“面试结论 → 概念边界 → 原理 → 实现 → 项目 → 权衡 → 追问 → 总结”的学习闭环；
用 Frontmatter 记录难度、文档质量、学习状态、前置知识和关联主题；
通过相对链接维护单一事实源，避免在题库和项目文档中复制大段知识；
通过 Skill 统一系统讲解、模拟面试、题库、项目分析和文档维护流程；
让目录、文档、图示、代码和项目证据都能被核查。

下一阶段 RAG 服务层的目标：

增量摄取 Markdown，并保留标题层级、代码块、表格、来源版本和文档状态；
支持关键词与语义混合召回、过滤、融合、重排和父子块展开；
根据 Token 预算构造上下文，生成带可核验引用的回答；
在证据不足、版本冲突或权限不足时拒答或请求澄清；
建立固定评测集、发布门禁、Trace、灰度和回滚能力；
支持文档新增、修改、删除和撤权后索引与缓存及时收敛。

2.3 成功标准

当前知识治理层至少满足：

总目录只链接真实文件，新增文档后同步更新；
重要文档具备合法 Frontmatter、目录、总结和依赖关系；
同一知识点优先更新已有主文档，不产生相互冲突的副本；
项目结论能区分真实证据、可实施设计、工程建议和示例假设；
文档质量状态与个人掌握状态分开记录。

RAG 服务不能以“能回答几个问题”验收，至少需要证明：

必要证据能否进入 Top-k 与最终上下文；
回答是否正确、忠实于证据并给出有效引用；
无答案、冲突、过期和越权问题能否正确拒答；
文档更新、删除和回滚是否反映到可查询版本；
版本、延迟、Token、成本和失败原因能否追踪；
变更是否通过固定评测集、影子或灰度验证。

所有数值阈值都需要在真实实现后建立基线，本文不虚构准确率、QPS、延迟、成本或收益。

2.4 输入、输出与主要数据

输入：

AI 知识主题、项目代码与配置、实验结果、面试回答和故障证据；
Markdown 正文、YAML Frontmatter、Mermaid、图片和相对链接；
查询文本、用户身份、会话上下文、过滤条件和反馈；
语料、解析器、Embedding、索引、检索器、Prompt 和模型版本。

输出：

结构化知识主题、项目案例、题库、复盘和学习路线；
带来源、版本和段落定位的检索结果；
有证据的回答、引用或明确拒答；
文档质量、学习状态、评测结果、Trace 和待修复任务。

核心实体包括 Document、DocumentVersion、Chunk、IndexManifest、QueryTrace、EvalCase 和 Feedback。其中源 Markdown 是事实源，Chunk、向量和答案缓存都是可重建的派生数据。

2.5 明确边界

这不是通用网盘：核心是可学习、可解释、可追问的 AI 知识；
这不是向量数据库项目：向量索引只是检索组件；
这不是微调项目：RAG 提供动态外部事实，微调主要改变模型行为或任务能力；
这不是把全部文档塞进长上下文：长上下文不能自动解决权限、更新、噪声、成本和引用；
这不是让 LLM 自动判定事实源：模型生成不能覆盖仓库中的权威文档和版本规则；
当前仓库不是已上线问答服务：没有运行时证据的能力只能写为设计和演进计划。

3. 当前系统与演进架构

3.1 当前组件职责

组件	当前职责	边界
`AGENTS.md`	定义回答、证据、文档和交付规则	不保存具体知识正文
根 `README.md`	项目说明与入口导航	不承担知识库总索引
`docs/README.md`	唯一总目录、学习路线与状态看板	只链接真实文件
`docs/01～11`	知识主题、项目、面试和排障文档	一个文件聚焦一个主要主题
`docs/_templates`	统一知识主题与项目案例结构	模板不能代替实际内容
`docs/assets`	保存教学图片和其他持久化资源	精确公式和代码仍以正文为准
`ai-knowledge-interview` Skill	路由讲解、面试、题库、工程分析和落盘流程	不虚构项目事实或指标
Git	记录内容版本与变更	Git 提交不代表学习已经掌握

图 1：当前知识生产与复习闭环

替代文本： 用户输入主题或项目证据后，Skill 根据意图检查仓库和事实，按模板生成文档与图示，更新总索引并执行结构验证；后续学习、面试和复盘反馈再次进入知识维护流程。

图表加载中…

读图结论： 当前项目的核心不是在线问答，而是把输入、证据、结构化文档、索引和复盘连成可持续维护的知识闭环。

3.2 技术栈、框架、库与组件清单

当前仓库已经存在 Markdown、索引、模板和 Skill；下表中的在线 RAG 组件属于演进参考架构，不能表述为已上线事实。

技术点 ID	技术点/环节	类型	采用方案	链路职责	版本/证据边界
TP-01	权威知识源与解析	内容格式 + 版本组件	Markdown + Frontmatter + Git + 结构化解析器	提供可审查正文、元数据、链接关系、内容哈希和变更历史	Markdown/Git 为当前仓库事实；解析服务与在线摄取是设计方案，需由代码和回归证明
TP-02	检索与排序	索引/模型组件	BM25 + Embedding 混合召回、RRF/去重、可选 Reranker	兼顾精确术语与语义问法，输出带文档、块和索引版本的证据	组件组合不绑定具体产品；是否启用 Dense/Rerank 由固定查询集实测决定
TP-03	索引发布与可观测	元数据/发布/观测组件	IndexManifest + 候选索引评测 + 原子别名切换 + Run Trace	防止半成品上线，绑定语料、解析、切块、模型、索引和查询证据	当前是演进设计；原子性、回滚和重放边界必须通过故障注入与实现证据验证

3.3 横向选型对比

技术点 ID	候选方案	优点	缺点/代价	适用场景	不适用场景	选择结论与依据
TP-01	Markdown + Git	差异、审查、链接和版本清晰，适合开发者协作	非技术编辑体验和复杂权限工作流有限	技术知识库、代码同仓、审查优先	大量业务编辑、复杂审批和富媒体协作	当前仓库继续作为单一事实源；编辑门槛成为主瓶颈时评估 CMS 前台
TP-01	CMS/数据库作为权威源	可视化编辑、审批和细粒度权限更易建设	导出、版本差异、代码同仓和可移植性更复杂	多角色内容运营、审批密集	小团队技术文档或需离线 Git 审查	只有内容运营需求超过双向同步成本时迁移，并保留可审计导出
TP-02	仅 BM25/关键词检索	可解释、精确术语稳、成本和延迟较低	同义改写与语义召回弱	API、错误码、文件名、专有名词查询	自然语言改写多、词面不重合	作为强基线保留；目标查询已覆盖时不引入额外复杂度
TP-02	混合检索 + Rerank	召回互补、排序可按任务优化	多索引、延迟、模型成本与评测治理增加	企业问答、跨表达检索、引用要求高	小语料、长上下文直接读取更简单	仅在 Recall、排序及端到端引用指标均有可复现收益时采用
TP-03	原地增量更新可读索引	链路短、存储开销较小	中途失败可能暴露混合版本，回滚与归因困难	可容忍短暂不一致、索引可快速重建	权限、合规或答案必须可重放	不用于正式可读版本；最多作为隔离环境中的构建过程
TP-03	候选索引 + Manifest + 原子切换	版本、门禁、回滚和归因边界清楚	双份存储、构建时间和发布治理成本更高	权威知识、权限过滤、稳定引用	极小临时索引且没有版本要求	生产演进优先；必须通过构建失败、切换失败和回滚演练验证

3.4 RAG 演进架构

RAG 服务增加两条相互独立但通过版本清单连接的链路：离线侧把权威 Markdown 构建为可查询索引，在线侧只读取已经通过质量门禁的索引版本。

图：架构｜知识源、离线索引与在线问答双链路

替代文本： 离线链路从 Git 中的 Markdown 快照开始，经过解析、质量检查、结构切块、关键词和向量索引、评测门禁后原子发布；在线链路接收用户与身份信息，执行带过滤的混合召回、融合、重排和上下文构造，再由 LLM 生成带引用回答，过程写入 Trace 和反馈闭环。

图表加载中…

读图结论： 权威文档、索引和在线回答必须由版本门禁连接；索引构建失败时保留旧版本，在线回答不能读取半成品索引。

3.5 技术调用流程

图：技术调用流程｜索引发布后的一次权限检索与回答

替代文本： 发布器先验证候选 IndexManifest 并原子切换可读版本；用户查询时 API 传入可信身份，检索编排器读取同一版本执行权限过滤、BM25 与 Dense 召回、融合和 Rerank，再由 LLM 依据证据生成并校验引用。索引门禁失败时保留旧版本，证据不足或权限不通过时拒答或请求澄清。

图表加载中…

读图结论： 发布时只暴露通过门禁的完整索引版本，查询时身份、索引版本、证据和引用沿同一 Run 传递；任何一层证据不足都不能伪装成正常回答。

该流程把离线发布和在线查询连接在同一个 index_version 上，避免文档、向量、权限元数据和引用来自不同版本。

3.6 离线摄取调用链

text

Git 快照
  -> 发现新增、修改、删除文件
  -> Frontmatter 与相对链接校验
  -> Markdown 结构化解析
  -> 标题感知切块与父子关系
  -> 内容哈希和稳定 Chunk ID
  -> BM25 与 Embedding 批量构建
  -> 完整性、抽样查询和权限测试
  -> 生成 IndexManifest
  -> 原子切换索引别名

增量任务的幂等键至少绑定：

text

(document_id, content_hash, parser_version, chunk_policy_version, embedding_model_version)

同一键重复执行应得到相同派生数据；删除文件要产生 Tombstone 和缓存失效事件，不能只从目录中隐藏链接。

3.7 在线查询调用链

text

API / 用户问题
  -> 可信身份与权限上下文
  -> 查询分类、规范化和必要的改写
  -> 版本、类别、文档状态与 ACL 过滤
  -> BM25 与 Dense 并行召回
  -> RRF 融合、同源去重、Reranker
  -> 父段落展开和 Token 预算
  -> LLM 依据证据生成
  -> Claim 与 Citation 校验
  -> 回答、拒答或请求澄清
  -> 保存脱敏 Trace 与反馈

精确术语、错误码、文件名和 API 名优先保留关键词检索；自然语言同义问题由 Dense 补召回。Query Rewrite 只能在保留原查询和关键约束校验的前提下启用。

3.8 内容与索引状态

内容质量状态沿用文档元信息：

text

draft -> reviewed -> stable

个人学习状态单独维护：

text

todo -> learning -> review -> mastered

索引状态是另一条机器生命周期：

text

DISCOVERED -> VALIDATING -> INDEXING -> CANDIDATE -> READY
                      \-> FAILED
READY -- source changed --> STALE -> INDEXING
READY -- deleted/revoked --> TOMBSTONED

doc_status 决定内容质量策略，learning_status 只表示个人掌握进度，二者都不能代替访问权限。索引是否可读由 IndexManifest 和发布门禁决定。

4. 核心技术方案

4.1 知识源治理

Markdown 和 Git 作为唯一事实源，原因是内容易审查、差异可追踪、链接可检查、版本可回滚，也能同时服务人工阅读和机器解析。每篇重要文档通过 Frontmatter 提供：

title、category 和 level；
doc_status 与 learning_status；
updated、tags、prerequisites 和 related；
文件路径、Git 版本和内容哈希形成稳定来源身份。

题库、学习计划和项目案例只链接知识主题，不复制完整原理。这样修改 RAG 指标定义时只更新主文档，避免多个答案相互冲突。

4.2 解析与结构化切块

初始版本只处理仓库中的 Markdown，减少多格式解析噪声。切块不使用单一固定字符数，而是：

以标题层级形成文档树；
保持列表、代码块、表格和公式的结构完整；
子块用于精确检索，返回时补充父标题与必要父段落；
过长章节再按 Token 和语义边界递归切分；
overlap 只用于边界补偿，并在候选阶段同源去重。

每个 Chunk 至少保留：

json

{
  "chunk_id": "stable-id",
  "document_id": "docs/05-rag/01-RAG基础链路.md",
  "document_version": "content-hash-or-git-sha",
  "section_path": ["5. 原理剖析", "5.2 端到端数据流"],
  "content": "...",
  "token_count": 0,
  "category": "rag",
  "doc_status": "draft",
  "acl": ["..."],
  "parser_version": "...",
  "chunk_policy_version": "..."
}

4.3 混合检索、融合与重排

检索采用分层方案：

BM25 召回精确术语、缩写、文件名、API 和错误码；
Dense Retrieval 召回自然语言同义表达；
Metadata Filter 约束分类、状态、版本和权限；
Reciprocal Rank Fusion（RRF）融合不可直接比较的排名；
对有限候选使用 Cross-Encoder Reranker；
同源去重和多样性控制后再进入上下文构造。

BM25、Dense、RRF、Reranker 和 MMR 的公式与实现由 RAG 检索优化维护，本项目只定义它们在完整系统中的职责和失败降级关系。

4.4 上下文、引用与拒答

最终上下文不是“Top-k 原样拼接”，而是：

先核对 Chunk 对应的原文、版本和权限；
去除重复或冲突证据，并显式标记版本差异；
在 Token 预算内保留问题、系统规则、证据和输出空间；
为每段证据分配稳定 Citation ID；
要求答案中的可验证 Claim 映射到 Citation；
证据不足时输出拒答原因和可继续提供的信息。

“有引用”不等于“引用正确”。必须分别评估引用是否指向真实来源、来源是否支持对应 Claim、引用版本是否当前有效。

4.5 版本、一致性与幂等

一次可重放回答至少绑定以下版本：

text

corpus_snapshot
parser_version
chunk_policy_version
embedding_model_version
index_version
retrieval_config_version
reranker_version
prompt_version
generation_model_version
policy_version

新索引先写候选空间，通过完整性、检索、安全和性能门禁后再原子切换别名。发布失败继续服务旧版本，不在可读索引中原地写一半。缓存键要按缓存层分别包含查询、内容/索引版本、检索配置和由可信服务计算的权限指纹；最终答案缓存还需包含上下文哈希、Prompt、模型和会话边界。

4.6 核心数据模型

实体	关键字段	用途
`Document`	path、title、category、status、acl	权威文档身份与治理属性
`DocumentVersion`	content_hash、git_sha、updated_at	追踪内容变更与回滚
`Chunk`	section_path、content、parent_id、token_count	检索、引用和上下文构造
`IndexManifest`	corpus、parser、embedding、retrieval versions	定义一个可发布索引制品
`QueryTrace`	request_id、filters、candidates、context、versions	重放线上问题
`EvalCase`	query、answerable、gold evidence、claims、risk	离线门禁与回归
`Feedback`	trace_id、label、comment、review_status	把真实失败转成评测样本

高基数的 request_id、原始问题和候选明细进入 Log/Trace，不作为无界 Metric 标签。敏感正文按最小必要原则保存、脱敏和设置保留期。

4.7 最小查询伪代码

python

def answer(query, identity, session):
    scope = auth_service.resolve(identity)
    manifest = index_registry.current_ready()
    normalized = query_router.normalize(query)

    sparse, dense = parallel_retrieve(
        query=normalized,
        filters={
            "entitlements": scope.fingerprint,
            "policy_version": scope.policy_version,
            "index_version": manifest.version,
        },
    )
    candidates = rrf_and_dedupe(sparse, dense)
    candidates = authorize_again(candidates, scope)
    ranked = rerank_with_timeout(normalized, candidates)
    context = build_context(ranked, token_budget=session.token_budget)

    if not has_sufficient_evidence(context):
        return refuse_with_references(context)

    draft = llm_generate(query, context)
    return validate_claim_citations(draft, context)

该伪代码表达控制边界，不代表当前仓库已有可运行服务。生产实现还需要认证、限流、并发、超时、重试、熔断、审计、测试和供应商适配。

5. 关键权衡

决策	选择	备选方案	选择原因	代价与风险
权威知识源	Markdown + Git	CMS、数据库	审查、版本和回滚清晰	非技术编辑体验有限
内容组织	单一事实源 + 相对链接	多文档复制答案	降低冲突和维护成本	阅读时需要跨文档跳转
切块	标题感知的父子块	固定长度	兼顾定位和上下文完整	解析器更复杂
检索	BM25 + Dense + RRF	仅 Dense	兼顾精确词与语义召回	延迟、索引和调参成本增加
重排	有限候选 Cross-Encoder	全库重排、无重排	提升精排能力且成本可控	模型超时或领域不匹配会降级
知识更新	RAG 增量索引	微调模型权重	新鲜、可引用、易回滚	依赖摄取和索引一致性
发布	候选索引 + 原子切换	原地更新	避免半成品索引在线可见	需要双份存储与版本治理
回答策略	引用与证据不足拒答	总是生成完整答案	降低无依据断言	会增加拒答和交互成本

5.1 性能与成本

文档未变化时复用解析和 Embedding 结果，避免全量重建；
BM25 与 Dense 并行，Reranker 只处理受限候选；
为查询改写、候选数、上下文和模型输出设置预算；
Reranker 超时可降级到融合排名，主模型超时可返回检索结果或稍后重试；
记录每阶段延迟、Token、调用次数和缓存命中，不能只看端到端均值；
先用评测证明质量收益，再决定是否引入更昂贵的模型或多查询扩展。

5.2 安全、权限与隐私

ACL 必须进入每一路检索的候选可见性边界，不能先全库 Top-k 再过滤；
召回后仍做二次授权，防御索引、缓存和策略传播错误；
检索到的文档是非可信数据，其中的指令不能覆盖系统规则；
缓存键包含完整权限指纹和策略版本，撤权与删除事件主动失效；
Trace 最小化保存正文，对用户问题、项目经历和私有资料脱敏；
高风险结论不能仅依赖语言模型，应跳转权威文档或确定性工具确认。

5.3 可维护性与演进

组件接口应围绕稳定契约，而不是绑定某个向量库或模型供应商。解析、Embedding、检索、重排和生成版本独立发布、独立评测、独立回滚；否则一次模型升级会迫使全链路同时变化，无法判断质量波动来自哪一层。

6. 实现难点与故障处理

6.1 失败模式矩阵

现象	主要根因层	诊断证据	修复与验证
总目录有文档但搜索不到	发现、解析或索引	source path、parse status、chunk count、index version	重放失败任务；确认当前版本 Chunk 可检索
精确术语零召回	分词或只走 Dense	query type、analyzer、BM25 candidates	修规范化与词法索引；跑精确实体查询集
同义问题召回差	Embedding 或语料表达	Dense candidates、同义分桶 Recall	调整 Embedding/查询路由；控制变量复测
Top-k 都是重复段落	overlap 与同源去重	source/section 分布	降 overlap、去重或 MMR；同时检查 Recall
命中旧文档	增量删除、别名或缓存版本	content hash、index alias、cache key	Tombstone、主动失效、切换版本；旧 Chunk 不可见
检索正确但回答错误	上下文或生成	final_context、Prompt/model version	固定上下文重放；分别回归忠实度和正确性
引用存在但不支持答案	Claim-Citation 映射	claim、citation、原文版本	引用校验与人工样本；报告 precision/coverage
无答案问题被强答	拒答门禁弱	answerability、candidate score、context	加无答案集和最小证据门禁；复测误拒与漏拒
用户看到无权文档	ACL 或跨域缓存	entitlement、policy、candidate audit	停流量、清缓存、修 pre-filter；越权与撤权回归
p50 正常但 p99 激增	队列、Reranker 或重试放大	分 Span 尾延迟、队列深度、重试数	限并发、超时降级、熔断；观察长尾恢复

6.1.1 RAG 演进故障演练：半成品索引被提前切为可读

本卡是面向后续在线 RAG 的工程演练，不代表当前仓库已经实现或发生过该事故。

现象与影响：新文档部分可检索、部分缺失，删除内容仍能命中；同一查询在不同节点得到新旧混合引用，答案无法重放。
定位证据：检查 Index Manifest、预期/实际 Chunk 数、失败分区、内容哈希、索引别名、节点缓存和查询返回的 index_version。
根因：增量构建直接写入可读索引，发布动作没有完整性门禁和原子切换；失败重试又与旧批次交错。
临时止损：冻结新索引写入，把别名固定回最近健康版本，清理受影响缓存并标记相关回答不可作为权威证据。
长期修复：构建隔离的候选索引，Manifest 绑定语料、Parser、Chunk、Embedding、ACL 和索引版本；门禁通过后原子切换，删除使用 Tombstone 并支持回滚。
回归验证：注入分区失败、重复事件、删除和切换中断，验证候选不提前可见、旧版本可恢复、查询只返回单一版本引用。
防复发：发布前执行数量/哈希/ACL 对账和金标查询；监控索引新鲜度、版本混用、失败批次与别名变化，所有发布保留审计记录。

6.2 推荐排查顺序

遇到“回答不对”时按以下顺序保留证据，不要直接换模型：

固定 request_id、身份、时间和完整版本清单；
确认权威文档中是否真的存在当前答案；
检查解析文本、标题层级、表格、代码和 Chunk 是否正确；
检查每路召回、过滤、融合、重排和去重结果；
检查最终送给模型的真实上下文是否包含必要证据；
固定上下文重放 Prompt 与模型，判断是否为生成忠实度问题；
检查 Citation 映射、缓存、权限和版本是否正确；
将根因样本加入回归集，再灰度验证修复。

6.3 超时、重试、降级和兜底

解析失败按文档隔离，不让一篇坏文档阻塞整个索引；
Embedding 批任务只重试明确可恢复错误，并使用幂等键；
索引构建失败保留旧可读版本，不切换半成品；
一路检索超时仍可使用另一路，响应标记 degraded；
Reranker 超时退回 RRF 排名，不能无限重试放大尾延迟；
LLM 失败时可返回经过授权的检索结果与引用，不伪造完整答案；
权限服务不可用时默认拒绝私有内容访问，不使用旧身份猜测；
删除和撤权传播失败触发高优先级告警，并允许停用相关缓存或索引。

6.4 典型故障复盘格式

text

现象与影响
-> request_id 与版本
-> 权威语料是否正确
-> 解析、索引、检索、上下文、生成哪一层失败
-> 临时止损与回滚
-> 根因修复
-> 离线、影子、灰度和线上验证
-> 新增回归样本与告警门禁

7. 评测、监控与验证

7.1 离线评测集

每个 EvalCase 至少记录：

原始问题、查询类型、语言和目标主题；
answerable 及无答案原因；
必要文档、必要 Chunk、允许版本和权限身份；
权威答案 Claim 与对应证据；
是否属于精确实体、多证据、否定、时效、冲突或攻击样本；
语料、索引、检索、Prompt、模型和 Judge 版本；
人工标注说明与复核状态。

门禁集与日常调参集分离，避免反复针对同一批题优化造成评测泄漏。线上失败样本经过脱敏和人工确认后才能进入回归集。

7.2 分层指标

层级	重点指标	不能证明什么
数据与摄取	parse failure、chunk count、index lag、删除传播	不能证明检索相关
检索	Recall@k、Hit@k、MRR、nDCG、权限命中	不能证明最终答案正确
上下文	必要证据覆盖、重复率、冲突率、截断率	不能证明模型忠实使用证据
生成	correctness、groundedness、citation precision/coverage	不能单独证明系统稳定
拒答	abstention precision/recall、误拒率	拒答率高不等于更安全
系统	p50/p95/p99、错误率、Token、成本、降级率	均值不能解释长尾和质量
安全	越权命中、撤权传播、注入攻击通过率	不能用普通质量集替代

指标公式、Judge 校准与版本矩阵由 RAG 评测与生产工程作为单一事实源维护。

7.3 Trace、日志与告警

一个可重放 Trace 至少保存：

request_id、时间、身份的脱敏引用和权限策略版本；
raw query、normalized query 与 Query Rewrite；
每路候选的 ID、rank、score、过滤原因和索引版本；
融合、去重、重排后的候选；
最终真实上下文、Token 分配和引用映射；
Prompt、模型、缓存、降级和重试版本；
回答、拒答原因、延迟、Token 与人工反馈。

指标用于趋势和告警，Trace 用于单请求重放，Log 用于结构化事件；三者不能互相替代。

7.4 测试策略

单元测试：Frontmatter、链接、Markdown 解析、Chunk ID、过滤和引用映射；
集成测试：新增、修改、删除、回滚、索引切换和缓存失效；
检索回归：精确术语、同义、多证据、否定、版本和无答案；
安全测试：同租户不同文档权限、跨租户、撤权、提示注入和缓存隔离；
故障注入：解析失败、Embedding 限流、一路检索超时、Reranker 超时、LLM 失败；
性能测试：文档批量摄取、并发查询、候选 K、上下文长度和尾延迟；
人工评审：校准自动 Judge，重点复核高风险与分歧样本。

7.5 最小验收清单

[ ] 同一知识点只有一个权威主文档，关联内容通过链接引用；
[ ] 文档新增、修改、删除后，目录与目标索引版本一致；
[ ] 查询能返回真实来源、版本和段落定位；
[ ] 必要证据缺失时不依赖模型记忆强答；
[ ] 检索、上下文、生成、引用和拒答可以分层评测；
[ ] 可从 request_id 重放完整候选和版本；
[ ] 越权、撤权、删除和缓存隔离测试通过；
[ ] 发布失败可继续服务旧版本并完成回滚；
[ ] 所有效果、延迟和成本数字都来自可核验实测。

8. 实施路线与复盘

8.1 当前已验证能力

当前仓库已经具备：

项目规则、根导航和唯一知识库总索引；
按领域组织的 AI 知识主题、项目案例和面试文档；
知识主题与项目案例模板；
难度、文档质量、学习状态、前置和关联元信息；
Mermaid 与教学图片的资源约定；
面向讲解、模拟面试、题库、项目分析和文档沉淀的 Skill；
Git 版本记录和“真实证据优先、禁止虚构指标”的项目表达规则。

这些能力可以通过本仓库文件直接核查；它们构成 RAG 之前的知识治理底座。

8.2 第一阶段：结构化知识治理

目标是继续完善内容，不引入在线服务：

统一 Frontmatter、标题层级、链接和总结；
补齐 AI 工程与故障排查主题；
建立链接、元信息和文档结构自动检查；
用真实学习和面试反馈更新 learning_status；
将重复内容合并到单一事实源。

8.3 第二阶段：检索型 MVP

先实现不依赖 LLM 的检索闭环：

Markdown 解析与标题感知切块；
BM25 或本地全文搜索；
结果返回文档、章节和原文片段；
增量更新、删除和索引版本；
固定查询集与 Hit@k/Recall@k 基线。

这样可以先证明内容和检索是否正确，避免把生成流畅度误当成检索质量。

8.4 第三阶段：可引用 RAG

在检索基线稳定后增加：

Embedding 与 Dense Retrieval；
BM25 + Dense + RRF；
有限候选 Reranker；
Token 预算、引用映射和证据不足拒答；
检索、回答、引用与拒答分层评测；
完整版本清单和 Query Trace。

8.5 第四阶段：生产化

身份、ACL、撤权和缓存隔离；
候选索引、影子、灰度和原子回滚；
限流、超时、重试、熔断和降级；
在线指标、人工复核与失败样本回归；
成本预算、隐私保留期和安全测试。

8.6 当前未验证边界

截至本文更新，仓库中没有可核验的：

在线 API、Web 界面、用户系统和多租户认证；
文档解析服务、Embedding 服务、BM25/向量索引和 Reranker；
在线 LLM 问答、引用校验、缓存和权限过滤；
自动评测流水线、CI 门禁、监控、Trace、灰度和回滚；
准确率、召回率、QPS、延迟、Token、成本、用户量和业务收益。

因此，面试时可以真实介绍当前知识治理、Skill 和文档工作流，也可以说明 RAG 演进设计；只有完成代码、测试和实测后，才能把对应能力表达为“我实现并验证了”。

9. 面试表达

9.1 30 秒项目介绍

我建设了一个面向 AI 技术学习和面试的结构化知识库。当前以 Markdown 和 Git 为唯一事实源，通过统一模板、Frontmatter、知识依赖、项目案例和面试追问管理内容，并用 Skill 约束讲解、证据核查和文档维护流程。下一阶段会把它扩展为可评测 RAG：离线做版本化解析、切块和索引，在线做带权限的 BM25/Dense 混合召回、RRF、重排、引用和拒答，并把检索、生成、引用和系统指标分层验证。当前我只把已落地的文档治理写成真实能力，不把尚未实现的在线服务或指标当作项目成果。

9.2 2～3 分钟完整表达

可以按以下顺序展开：

背景目标：AI 知识分散且容易重复，学习者能看到名词但难以形成原理、项目和面试闭环；
核心约束：内容要可审查、可版本化、可检索，项目数据必须真实，文档质量和个人掌握度不能混为一谈；
当前方案：Markdown/Git 作为事实源，docs/README.md 作为唯一索引，Frontmatter 维护状态和依赖，模板统一主题与项目结构，Skill 负责意图路由和证据约束；
关键权衡：优先解决知识治理，再引入智能检索；题库和项目链接主文档而不复制内容；
RAG 演进：离线版本化摄取和原子发布，在线混合召回、融合、重排、引用与拒答；
故障处理：按语料、解析、索引、召回、上下文、生成和引用逐层重放，不能直接换模型；
验证方式：检索、答案、引用、拒答、安全和系统指标分开，变更经过固定评测集和灰度；
结果边界：当前仓库证明的是知识治理和 Skill 工作流，在线 RAG 的效果要等实现和实测后再陈述。

9.3 个人贡献表达规则

只把自己实际完成并能出示文件、提交、测试或报告的内容写成个人贡献；
设计但未实现的部分使用“我设计了”“计划按以下阶段实现”；
团队共同完成时明确自己的模块、决策和验证范围；
没有实测数字时说明验收指标和采集方法，不用估算值装饰项目；
准备至少一个“问题 → 证据 → 根因 → 修复 → 验证 → 防回归”的真实复盘再参加项目深挖。

10. 递进追问

10.1 问题

为什么先做 Markdown 知识治理，而不是直接接向量数据库？
AI 知识库与普通文档站、全文搜索、长上下文和微调分别有什么区别？
为什么要同时使用 BM25 和 Dense Retrieval？RRF 与 Reranker 各解决什么问题？
文档修改或删除后，如何保证原文、Chunk、向量、缓存和引用最终一致？
检索命中正确文档但回答仍然错误，你会怎样定位？
如何证明引用真的支持答案，而不是模型随便附了一个来源？
如果系统支持多租户，怎样防止检索和缓存造成越权？

10.2 回答要点

先治理再索引：错误、重复、无版本的源内容会被检索放大；事实源、元信息、依赖和状态是 RAG 的前置条件。
方案边界：文档站服务人工导航；全文搜索擅长精确词；RAG 动态取证并生成；长上下文仍有成本、噪声和权限问题；微调主要改变行为而非持续更新事实。
检索分工：BM25 保留精确术语，Dense 处理语义同义，RRF 融合不可比分数，Reranker 对有限候选做更强相关性判断。
一致性：内容哈希和稳定 ID、Tombstone、候选索引、原子别名、版本化缓存键、删除/撤权主动失效和端到端回归。
分层定位：检查 final context 是否包含必要证据，再固定上下文重放 Prompt/model，区分上下文截断、冲突、指令和生成忠实度。
引用验证：将答案拆 Claim，对每个 Claim 做证据蕴含和版本核对，报告 citation precision/coverage，并用人工样本校准自动 Judge。
权限边界：可信服务生成完整权限指纹，每路检索 pre-filter，召回后二次授权，缓存按权限和策略版本隔离，撤权主动失效并建立越权回归。

11. 证据与关联文档

11.1 当前证据状态

范围	状态	可以如何表述
结构化 AI 知识文档	已有仓库文件	已建设并可核查
总目录、模板、元信息和状态规范	已有仓库文件	已建立治理规则
AI 知识与面试 Skill	已有 Skill 和配置	已建立意图路由与文档工作流
Git 版本化	已有提交历史	已使用版本管理
RAG 离线/在线链路	设计与教学示例	可实施设计，未证明上线
在线 API、索引、评测和监控	暂无运行证据	不得表述为已实现

11.2 真实仓库证据

项目定位与入口：根 README；
项目级规则：AGENTS.md；
唯一总索引：知识库总目录；
标准模板：知识主题模板、项目案例模板；
可复用工作流：AI 知识与面试 Skill；
RAG 项目入口：16 周学习计划中的项目主线。

11.3 关联知识主题

RAG 基础链路：离线摄取、在线查询、切块、Embedding、引用和拒答；
RAG 检索优化：BM25、Dense、RRF、Reranker、MMR 和查询改写；
RAG 评测与生产工程：分层评测、Trace、版本、发布门禁和回滚；
AI 应用系统设计：容量、可靠性、成本、安全和系统演进；
AI 面试教练项目：知识库作为题目证据和评分依据的下游应用。

基础公式、实现代码和一手参考资料由上述主题文档维护，本项目文档不重复复制。

11.4 实践任务

[ ] 为现有 Markdown 编写 Frontmatter、链接和标题结构检查器；
[ ] 实现标题感知切块，并输出可核验的 section path 与稳定 Chunk ID；
[ ] 建立 30～50 条不虚构结果的初始查询评测集，覆盖精确词、同义、多证据、无答案和版本冲突；
[ ] 比较 BM25、Dense 和混合检索，记录同一评测集上的分层结果；
[ ] 加入引用与拒答，并手工复核失败样本；
[ ] 注入文档删除、旧索引、Reranker 超时和越权缓存故障，完成一次复盘；
[ ] 用 30 秒和 3 分钟分别口述项目，并让面试官连续追问。

12. 简明总结

一句话记忆： AI 知识库先用可审查的内容治理建立可信知识源，再用可评测、可追踪、可回滚的 RAG 把知识转化为有证据的回答。

当前真实能力是结构化文档、总索引、模板、元信息、Skill 和 Git 工作流；
RAG 演进分为离线摄取与在线查询两条链路，源 Markdown 是事实源，索引和缓存是派生数据；
混合检索、重排、引用和拒答必须在版本、权限与 Token 预算内协同；
排障按语料、解析、索引、召回、上下文、生成和引用逐层定位；
面试表达必须区分已实现证据与待实现设计，所有指标以真实评测为准。

AI 知识库项目 ​

目录 ​

1. 项目摘要 ​

1.1 30 秒项目结论 ​

1.2 面试官为什么问 ​

1.3 小白版项目故事 ​

生活场景到技术机制的映射 ​

2. 背景、目标与边界 ​

2.1 业务背景 ​

2.2 功能目标 ​

2.3 成功标准 ​

2.4 输入、输出与主要数据 ​

2.5 明确边界 ​

3. 当前系统与演进架构 ​

3.1 当前组件职责 ​

图 1：当前知识生产与复习闭环 ​

3.2 技术栈、框架、库与组件清单 ​

3.3 横向选型对比 ​

3.4 RAG 演进架构 ​

3.5 技术调用流程 ​

3.6 离线摄取调用链 ​

3.7 在线查询调用链 ​

3.8 内容与索引状态 ​

4. 核心技术方案 ​

4.1 知识源治理 ​

4.2 解析与结构化切块 ​

4.3 混合检索、融合与重排 ​

4.4 上下文、引用与拒答 ​

4.5 版本、一致性与幂等 ​

4.6 核心数据模型 ​

4.7 最小查询伪代码 ​

5. 关键权衡 ​

5.1 性能与成本 ​

5.2 安全、权限与隐私 ​

5.3 可维护性与演进 ​

6. 实现难点与故障处理 ​

6.1 失败模式矩阵 ​

6.1.1 RAG 演进故障演练：半成品索引被提前切为可读 ​

6.2 推荐排查顺序 ​

6.3 超时、重试、降级和兜底 ​

6.4 典型故障复盘格式 ​

7. 评测、监控与验证 ​

7.1 离线评测集 ​

7.2 分层指标 ​

7.3 Trace、日志与告警 ​

7.4 测试策略 ​

7.5 最小验收清单 ​

8. 实施路线与复盘 ​

8.1 当前已验证能力 ​

8.2 第一阶段：结构化知识治理 ​

8.3 第二阶段：检索型 MVP ​

8.4 第三阶段：可引用 RAG ​

8.5 第四阶段：生产化 ​

8.6 当前未验证边界 ​

9. 面试表达 ​

9.1 30 秒项目介绍 ​

9.2 2～3 分钟完整表达 ​

9.3 个人贡献表达规则 ​

10. 递进追问 ​

10.1 问题 ​

10.2 回答要点 ​

11. 证据与关联文档 ​

11.1 当前证据状态 ​

11.2 真实仓库证据 ​

11.3 关联知识主题 ​

11.4 实践任务 ​

12. 简明总结 ​

AI 知识库项目

目录

1. 项目摘要

1.1 30 秒项目结论

1.2 面试官为什么问

1.3 小白版项目故事

生活场景到技术机制的映射

2. 背景、目标与边界

2.1 业务背景

2.2 功能目标

2.3 成功标准

2.4 输入、输出与主要数据

2.5 明确边界

3. 当前系统与演进架构

3.1 当前组件职责

图 1：当前知识生产与复习闭环

3.2 技术栈、框架、库与组件清单

3.3 横向选型对比

3.4 RAG 演进架构

3.5 技术调用流程

3.6 离线摄取调用链

3.7 在线查询调用链

3.8 内容与索引状态

4. 核心技术方案

4.1 知识源治理

4.2 解析与结构化切块

4.3 混合检索、融合与重排

4.4 上下文、引用与拒答

4.5 版本、一致性与幂等

4.6 核心数据模型

4.7 最小查询伪代码

5. 关键权衡

5.1 性能与成本

5.2 安全、权限与隐私

5.3 可维护性与演进

6. 实现难点与故障处理

6.1 失败模式矩阵

6.1.1 RAG 演进故障演练：半成品索引被提前切为可读

6.2 推荐排查顺序

6.3 超时、重试、降级和兜底

6.4 典型故障复盘格式

7. 评测、监控与验证

7.1 离线评测集

7.2 分层指标

7.3 Trace、日志与告警

7.4 测试策略

7.5 最小验收清单

8. 实施路线与复盘

8.1 当前已验证能力

8.2 第一阶段：结构化知识治理

8.3 第二阶段：检索型 MVP

8.4 第三阶段：可引用 RAG

8.5 第四阶段：生产化

8.6 当前未验证边界

9. 面试表达

9.1 30 秒项目介绍

9.2 2～3 分钟完整表达

9.3 个人贡献表达规则

10. 递进追问

10.1 问题

10.2 回答要点

11. 证据与关联文档

11.1 当前证据状态

11.2 真实仓库证据

11.3 关联知识主题

11.4 实践任务

12. 简明总结