| Retrieval-Augmented Generation (RAG) | 检索增强生成 | 先从知识库检索相关片段拼进 prompt，再让模型生成回答 | 「库大塞不下」时的知识接入默认方案；成本随块数而非库大小线性 | 与 agentic search 混淆（后者模型自己决定查什么、何时查） |
| Embeddings | 嵌入向量 | 把文本映射成高维向量，意思相近的文本向量距离近 | 语义检索的上限由嵌入模型决定；官方推荐 Voyage AI（Gemini 嵌入测试中亦佳） | 与「词向量/词嵌入」混淆（那是词级的旧技术） |
| Vector Search / Semantic Search | 向量检索/语义检索 | 按余弦相似度等度量在向量库找查询的近邻 | 换说法查询的命中靠它；但精确 token（错误码/SKU）是它的系统性盲区 | 与「语义理解」混淆——它只比距离，不理解 |
| BM25 (Best Matching 25) | 词法排名函数 | TF-IDF 家族的排名函数：词频饱和 + 稀有词加权 + 文档长度归一 | 精确 token 查询（TS-999、法条编号、函数名）必须靠它；毫秒级倒排索引 | 与「关键词包含匹配」混淆（它有排名不是布尔过滤） |
| Lexical / Sparse Retrieval | 词法/稀疏检索 | 基于词表命中（BM25/TF-IDF）的检索范式 | Hybrid 的词法路；工业标准、可解释、零训练成本 | 与「过时技术」划等号——官方明确它补 embedding 盲区 |
| Hybrid Retrieval | 混合检索 | 语义 + 词法双路召回后融合去重 | 官方默认姿势：Embeddings+BM25 好于单独 embeddings | 与「多个向量模型 ensemble」混淆 |
| Rank Fusion / RRF (Reciprocal Rank Fusion) | 排名融合 | score = Σ 1/(k+rank)，k 常取 60，合并多路排名 | 双路分数量纲不可比，排名天然可比——融合的标准解 | 与「分数加权平均」混淆（需归一化且对分 calibrated 敏感） |
| Chunking | 分块 | 把文档切成检索与拼装的最小单元 | RAG 里性价比最高的调参点；块大小由「答案需要多少上下文自解释」决定 | 与「分页/分段展示」混淆（那是 UI 概念） |
| Chunk Overlap | 块重叠 | 相邻块共享 10–20% 文本，缓解边界信息丢失 | 代价是索引存储与重复内容膨胀；是缓解手段不是免费午餐 | 与「冗余=浪费」或「overlap 越大越好」两个极端混淆 |
| Semantic Chunking | 语义分块 | 在相邻句话题相似度骤降处切分 | 保句子完整、话题聚块；实现复杂、块长不均、有成本 | 与「用 embedding 模型做检索」混淆（这里是找切点不是找邻居） |
| Structural Chunking | 结构化分块 | 按标题/章节/函数/表格行切并保留层级元数据 | Markdown/代码/合同的正确切法；标题链天然缓解主语丢失 | 与「语义分块」混淆（按文档结构 vs 按话题相似度） |
| Context Loss | 上下文丢失 | 块被切出文档后失去归属（谁的？哪季？） | 传统 RAG 的系统性缺陷；"revenue grew 3%" 没有公司名就是废数据 | 与「块重叠能解决」混淆——重叠救边界，救不了主语 |
| Contextual Retrieval | 上下文检索 | 索引前用廉价 LLM 为每块生成 50–100 token 情境前缀再做嵌入与 BM25 | 官方数据：+上下文 BM25 降检索失败率 49%，+reranking 累计 67%；prompt caching 摊薄后 $1.02/M doc tokens | 与「结构化分块带标题」混淆（近似但机制不同：LLM 定制前缀 vs 复制标题） |
| Metadata Filtering | 元数据过滤 | 块入库时打结构化标签（tenant/acl/updated_at），查询时先过滤再检索 | 同时解决安全（租户隔离）、新鲜度（作废政策）、精度（候选更小）；pre-filter 优于 post-filter | 与「生成后检查」混淆——过滤必须发生在候选集形成前 |
| Pre-filter vs Post-filter | 检索前过滤 vs 检索后过滤 | 先缩小候选空间再检索 vs 检索完再筛结果 | pre-filter 更准更安全；post-filter 可能把 Top-K 滤空或被迫回填噪音 | 与「两者等价」混淆 |
| Top-K | 前K结果 | 最终拼进 prompt 的块数 | 上下文预算分配问题；官方实测 20>10>5 但收益递减；K×块长+提示+历史+输出 ≤ 窗口 | 与「召回 Top-N」混淆（N 是宽进的候选数，如 150） |
| Reranking | 重排序 | 用 cross-encoder 对 query-chunk 对精排，Top-N 收敛到 Top-K | 官方：更好回答+更低成本延迟（无关信息更少）；代价是运行期多一跳 | 与「重跑一遍向量检索」混淆 |
| Cross-encoder | 交叉编码器 | query 与 chunk 拼接后联合过模型打相关分 | 准但慢→只对 Top-N 做；精排阶段的模型形态 | 与 bi-encoder 混淆 |
| Bi-encoder | 双塔编码器 | query 与 chunk 分别独立编码再比距离 | 快而粗、可预计算——全库召回阶段的模型形态 | 与 cross-encoder 混淆（快粗 vs 慢准的分工） |
| Groundedness | 有据性/接地性 | 回答主张被检索证据支撑的比例 | 生成层防幻觉的核心指标；prompt 层 <quotes> 技巧、API 层 Citations、评估层独立评分 | 与 accuracy 混淆（可有据但不正确——原文过时；反之亦然） |
| Hallucination | 幻觉 | 输出无依据的虚构内容 | RAG 不自动消灭幻觉——检索到噪音块或无 groundedness 约束时照样编 | 与「检索错误」混淆（那是检索层问题，因果链上游） |
| Citations | 引用 | document 块上 citations.enabled=true，回答返回支撑每条主张的 cited_text 与出处 | 主张可审计；cited_text 不计输出 token；全开或全不开、仅文本 | 与「让模型自己写来源」混淆（自报来源可伪造，API 引用指向你给的文档） |
| Recall@k | 召回率 | 该找到的相关块找到了多少（\ | R∩Top-k\ | /\ | R\ | ） | RAG 优先指标——块没检索到生成再强也没用 | 单独看会被「加大 K」作弊（全库塞入=100%） |
| Precision@k | 精确率 | 找回的 Top-k 里有多少真的相关（\ | R∩Top-k\ | /k） | 上下文预算紧时的关键指标——噪音块挤占预算助长 context rot | 与 recall 的优先级之争：RAG 先 recall 后 precision |
| MRR (Mean Reciprocal Rank) | 平均倒数排名 | 首个相关结果排名倒数的平均 | 单正确答案问答场景的排序指标 | 与 nDCG 混淆（后者支持分级相关度） |
| nDCG | 折损累计增益 | 位置对数折损加权的相关度增益 | 分级相关度、列表排序质量；「好结果是否按重要度排好」 | 与 MRR 混淆 |
| Pass@k / Hit Rate | 命中率 | 金标块是否出现在前 k 个结果里 | 单金标块评测、实现最简；官方上下文检索 cookbook 的口径（248 条评测查询） | 与 Recall@k 混淆（多金标时两者才分化） |
| Golden Dataset | 金标数据集 | 人工标注的问题-答案/块对 | 无金标=盲调；换嵌入模型/调 chunk/加 reranker 都要有数字背书 | 与「线上日志」混淆（那是观测不是标注） |
| Context Rot | 上下文腐烂 | token 越多，准确率与召回率越退化（官方术语） | 「窗口够小就塞」的物理边界；策展上下文与窗口大小同样重要 | 与「超出窗口报错」混淆（那是硬限制，rot 是软退化） |
| Attention Budget | 注意力预算 | 模型处理长上下文的有限注意力，每个 token 都在消耗它 | 解释为什么 K 不能无限加、为什么 rerank 省上下文反而更好 | 与 max_tokens 混淆（那是输出上限） |
| Prompt Caching | 提示缓存 | 前缀缓存复用，降本提速 | 「塞库方案」与 Contextual Retrieval 索引期的经济学支柱（延迟 >2x、成本最高降 90%） | 与「客户端缓存」混淆（这是服务端前缀缓存） |
| Ingestion / Indexing | 摄取/索引 | 离线建库阶段：解析→分块→前缀→嵌入/倒排→入库 | 增量更新与失效机制在这里；「索引一建永不更新」是常见事故源 | 与「查询期」混淆（问题域完全不同） |
| Just-in-time Retrieval | 即时检索 | agent 运行期按需拉取，而非预先索引 | 规避陈旧索引、渐进式披露；代价是慢与不可预测（Claude Code 样板：预取+按需混合） | 与 RAG 对立起来——两者常组合 |