AI 上下文涉及到的这些技术详解

约 5729 字大约 19 分钟

2026-07-02

AI 系统真正进入生产环境之后，一个绕不开的问题就是：怎么把"上下文"准备好交给模型。这个上下文可能来自当前会话、长期记忆、知识库，也可能来自外部工具。准备上下文的过程，本质上是一个检索与召回问题。

但"检索"并不是单一技术。团队最早接入向量检索时，往往以为 embedding 能解决一切；遇到专有名词搜不到，又开始补关键词；复杂问题需要跨文档关联时，又发现向量只能给出相似片段，却无法给出片段之间的关系。再到后来，查询改写、精排、去重、时间衰减、记忆画像压缩等技术都会陆续登场。

这篇文章把联犀在 AI 上下文链路中实际接触过、使用过的检索技术做一次系统梳理：全文索引、向量、图，以及围绕它们的关键词搜索、混合检索、RRF 融合、Cross-Encoder 精排、MMR、时间衰减、查询重写、稀疏向量、结构化检索、记忆画像压缩等。我们会依次讲清楚每种技术解决什么问题、适合什么场景、在联犀的代码实践里落在哪里，以及它们之间如何组合。

前置概念：AI 上下文链路里到底在检索什么

在进入具体技术之前，先对齐一个基本问题：AI 上下文链路里检索的对象并不一样。

会话历史：当前对话的最近轮次，通常是按时间顺序读取，检索压力最小。
长期记忆：用户的事实、偏好、事件，数量大、时间跨度长，需要语义相似 + 时效性 + 重要性综合排序。
知识库：产品文档、协议说明、操作手册，文档多、切片多，需要高召回 + 高准确。
记忆画像（Memory Profile）：把长期记忆压缩后的高频稳定画像，直接注入 prompt，作为快速通道。

不同对象决定了应该使用什么技术。接下来我们就按技术逐个展开。

1. 全文索引（Full-Text Index）

1.1 基本原理

全文索引的核心是倒排索引（Inverted Index）：把文档里的每个词映射到包含它的文档列表。查询时，根据查询词快速定位候选文档，再用 BM25、TF-IDF、Jaccard 等算法打分排序。

以 BM25 为例，它同时考虑三个因素：

词在文档中的出现频率（TF）
词在所有文档中的稀有程度（IDF）
文档长度（避免长文档占优）

Jaccard 则更简单，计算查询词集合与文档词集合的交集比例，适合短文本、关键词集合类召回。

1.2 能解决的问题

全文索引最擅长的是字面匹配：

精确查找专有名词、型号、错误码、协议名。
用户查询意图明确，关键词已经在问题里。
对延迟敏感，希望毫秒级返回。

1.3 联犀实践：语音链路里的记忆召回

在联犀的语音实时对话链路中，团队把长期记忆的同步注入从 embedding 向量召回 改为 全文索引文本检索（Jaccard + trust_score），曾经的 3 秒瓶颈被降到毫秒级。

这个改动的关键背景是：语音场景对延迟极度敏感，而记忆同步注入如果走 embedding 向量召回，每次都需要调用 embedding 接口把文本转成向量。调接口本身就会带来额外网络延迟，同时按调用量计费也会产生持续费用。改用全文索引后，系统直接基于本地关键词集合做 Jaccard 相似度计算，同时结合 trust_score 做质量过滤，召回速度快了几个数量级，也省去了 embedding 接口调用成本。

1.4 不适用的地方

全文索引对以下场景表现不佳：

用户用了同义词，但文档里没出现这个词。
用户问的是语义相关，但字面不同（"怎么上报温度" vs "设备数据上传格式"）。
跨语言查询。

这些正是向量检索的强项。

2. 向量检索（Vector / Embedding）

2.1 基本原理

向量检索先把文本（或图像、代码等）通过 embedding 模型编码成高维稠密向量，然后基于向量之间的相似度（通常是余弦相似度）找出最近邻。常用的近似最近邻算法包括 HNSW、IVF、PQ 等，它们用精度换速度，把高维空间的搜索成本控制在可接受范围。

向量检索的关键在于：

表示学习：embedding 模型能不能把语义相近的内容映射到相近的向量。
索引结构：向量库（pgvector、Milvus、Qdrant、Weaviate、Chroma 等）的索引策略决定召回速度和精度。
相似度度量：余弦相似度、点积、欧氏距离等。

2.2 能解决的问题

向量检索擅长的是语义相似：

同义词、近义词匹配。
跨语言表达。
模糊意图，用户说不清但语义接近。
长文档切片的语义召回。

2.3 联犀实践：知识库与长期记忆

联犀知识库的第一版就是基于向量检索：用户提问后，系统先做一轮向量搜索，把命中的切片塞进 prompt 交给模型回答。这个方案在小知识库里跑得很快，但规模变大后暴露出召回不准、专有名词匹配差的问题。

在长期记忆中，联犀同样使用 embedding 向量作为一路召回源。长期记忆不是简单的一段文本，而是带有 keywords、importance、access_count、向量索引 key 等字段的结构化记录，embedding 负责从中找出语义相关的内容。

2.4 不适用的地方

向量检索的短板也很明显：

对专有名词、型号、ID、错误码等精确匹配不稳定。
需要 embedding 模型和向量存储，部署成本高于纯文本索引。
召回结果可解释性较差，很难直接回答"为什么这次没搜到"。

这些短板让联犀在知识库和记忆召回中都引入了其他技术做补充。

3. 图与关系网络（Graph / Chunk Relations）

3.1 基本原理

图检索把数据组织成节点 + 边的结构。节点可以是文档、切片、实体、记忆；边表示它们之间的关系，比如"同一章节"、"互相引用"、"语义相关"、"时间先后"等。

在 RAG 领域，图增强检索（GraphRAG）的典型做法是：

抽取文档中的实体和关系，构建知识图谱。
查询时先定位相关实体，再沿关系扩展邻居节点。
把扩展后的子图上下文交给模型，支持多跳推理。

3.2 能解决的问题

图检索擅长的是关系推理和上下文扩展：

一个问题需要跨多个文档才能回答。
需要理解"这个切片和那个切片为什么相关"。
复杂问题需要多步推导，比如"A 影响 B，B 影响 C，所以 A 和 C 有什么关系"。

3.3 联犀实践：切片关系扩展

联犀知识库在 skills/ur-ai 中暴露了一个工具接口：

POST /api/v1/ai/knowledge/tool/get-chunk-relations

它接收 artifactID、relationTypes、minScore、limit 等参数，返回当前切片与其他切片的关系，关系字段包括：

relationType：关系类型
cosineScore：向量余弦相似度
lexicalOverlap：词重叠度
llmConfidence：LLM 判断的关系置信度
score：综合得分

这个设计说明联犀并没有把"图"当成一个独立的图数据库来用，而是把 chunk 之间的关系作为知识库检索链路的扩展层。当首轮搜索只命中了局部切片，而问题需要更多上下文时，系统可以调用这个关系工具，按需扩展关联切片。

联犀把这三个能力定义为知识库工具：

knowledge_search
knowledge_get_document_content
knowledge_get_chunk_relations

knowledge_get_chunk_relations 承担的就是"图"的角色：它不是默认执行，而是按需触发，用来解决复杂问题的上下文补全。

3.4 不适用的地方

构建和维护关系有成本，不是所有查询都需要。
如果关系质量不高，扩展出来的上下文可能是噪音。
对简单问题来说，图检索是过度设计。

4. 关键词搜索与倒排索引

4.1 与全文索引的关系

关键词搜索和全文索引都依赖倒排索引，但侧重点不同：

关键词搜索：通常指精确匹配或简单包含查询，比如 SQL 里的 LIKE 或 WHERE keywords IN (...)。
全文索引：在倒排索引基础上做分词、词干提取、停用词过滤、相关性打分，更像一个完整的搜索系统。

在工程实现中，关键词搜索往往是全文索引的一个子集或前置过滤。

4.2 能解决的问题

关键词搜索适合：

快速过滤：先按关键词缩小候选集。
结构化字段查询：比如按 keywords 字段直接匹配。
与向量搜索并行作为一路召回源。

4.3 联犀实践

在联犀知识库的混合搜索中，关键词搜索是并行于向量搜索的另外一路召回。它的价值在于：当用户问题中包含专有名词、型号、协议名时，关键词能稳定命中，而向量可能因为这些词在训练语料中出现频率低而失效。

在长期记忆中，联犀的记忆记录本身带有 keywords 字段，这意味着关键词过滤是记忆召回链路的一部分。

5. 混合检索与 RRF 融合

5.1 基本原理

混合检索（Hybrid Search）通常指向量搜索 + 关键词搜索并行执行，然后用某种融合算法把两套结果合并成一套最终排序。

Reciprocal Rank Fusion（RRF）是最常用的融合公式之一：

RRFScore(d) = Σ 1 / (k + rank_i(d))

其中 rank_i(d) 是文档 d 在第 i 路召回中的排名，k 是常数（通常取 60）。一个文档只要在任意一路中排名靠前，RRF 分数就会比较高。

5.2 能解决的问题

混合检索解决了单一检索技术的盲区：

向量擅长语义，关键词擅长精确。
融合后，同一文档如果在关键词侧排第一、向量侧排第十，仍可能进入前列。
避免人工维护大量 boost 规则。

5.3 联犀实践

联犀知识库引入混合搜索的原因很直接：纯向量搜索擅长语义相似，但不擅长精确匹配专有名词和型号编号。为了互补，系统把向量搜索和关键词搜索并行执行，然后用 Reciprocal Rank Fusion（RRF）融合两套结果。

这是联犀知识库从"单一向量"走向"多路召回"的关键一步。

6. Cross-Encoder 精排（Rerank）

6.1 基本原理

Cross-Encoder 把 query 和 document 拼接成一对输入，一次性编码后输出一个相关性分数。相比双塔向量模型（分别编码 query 和 document），Cross-Encoder 能直接建模 query 和 document 之间的交叉语义，因此排序更准确。

代价是计算成本高：需要对每一对 query-document 单独推理，所以只能用在候选集较小的时候（比如 TopK 的两倍）。

6.2 能解决的问题

精排解决的是"候选集已经召回，但内部排序还不够准"的问题：

向量相似度和 RRF 分数都是粗排，对 query-document 交叉语义理解有限。
Cross-Encoder 能在漏斗出口做最后一轮质量筛选。

6.3 联犀实践

联犀知识库在第三阶段引入 Cross-Encoder 做精排：取 RRF 融合后的 TopK 的两倍作为候选，用 BAAI/bge-reranker-v2-m3 模型逐对计算 query-document 的相关性得分，再按精排分数取最终 TopK。Cross-Encoder 把查询和文档拼接后一次性编码，比双塔向量模型的语义对齐能力更强。

为了不增加部署负担，这一阶段被设计为可选配置（默认关闭），ONNX Runtime 本地推理，模型文件约 2.2 GB。

7. MMR 与时间衰减

7.1 MMR（最大边际相关性）

MMR 的公式可以概括为：

MMR = λ * Sim(q, d_i) - (1 - λ) * max Sim(d_i, d_j)

它同时优化两个目标：

与查询的相关性高。
与已选结果之间的相似性低（即保证多样性）。

在记忆召回中，如果连续多轮都召回同一类记忆，模型看到的上下文会高度同质化。MMR 能让结果覆盖更多不同方面。

7.2 时间衰减

时间衰减解决的是"记忆是否仍然有效"的问题。一条很久以前的记忆可能仍然相关，也可能已经过时。常见的做法是给记忆加上时间衰减因子：

final_score = base_score * decay_factor^(elapsed_time)

同时可以结合 access_count 做加权：经常被访问的记忆衰减更慢。

7.3 联犀实践

联犀的长期记忆召回链路并不是简单向量检索，而是 embedding、关键词、MMR、时间衰减等多步组合。

这说明长期记忆召回是一个综合打分过程，不是单一技术能解决的。记忆记录带有 importance、access_count 等字段，这些都是时间衰减和重要性打分的输入。

8. 查询重写（Query Rewriting）

8.1 基本原理

查询重写在检索链路的最前端，负责把用户的原始问题转换成更适合下游检索的查询。常见操作包括：

移除停用词和疑问后缀（"怎么"、"应该"、"吗"）。
扩展同义词或相关概念。
把多跳问题拆成多个子查询。
修正错别字、规范化专有名词。

8.2 能解决的问题

用户的原始问题往往不是最优的检索输入。查询重写能让：

embedding 模型的输入更干净，向量方向更准确。
关键词搜索命中更稳定的词。
复杂问题被拆解成多个可检索的子问题。

8.3 联犀实践

联犀知识库查询重写的一个典型例子是：查询"设备物模型属性上报应该怎么填写"被净化为"设备物模型属性上报"，embedding 方向立刻清晰很多。

具体优化策略是：

完全移除 n-gram 生成逻辑，保留原始查询的完整语义。
做字符级停用词过滤（中文无空格分词，必须以字符级处理），去掉"怎么"、"应该"、"填写"等疑问后缀和无关动作词。

这个改动的效果非常显著：之前因为 n-gram 把查询拆成"备物"、"物模"等无意义片段，embedding 方向被污染；重写后相关文档的排名明显提升。

9. 稀疏向量与 BM25 编码

9.1 基本原理

稀疏向量试图结合全文索引的可解释性和向量检索的语义能力。它把文档表示成一个高维稀疏向量，维度对应词汇表中的词，权重由 learned sparse retrieval 模型（如 SPLADE）学习得到，而不是简单的 TF-IDF。

相比稠密向量：

稀疏向量保留了词级别的可解释性。
对专有名词、罕见词的匹配更稳定。
可以用相同的向量检索基础设施（ANN）进行搜索。

9.2 与全文索引、稠密向量的关系

可以把三者放在同一个光谱上：

全文索引 / BM25：基于词频和逆文档频率，无学习过程，可解释性强。
稀疏向量（如 SPLADE）：在 BM25 基础上加入学习，权重由神经网络学习。
稠密向量（Embedding）：完全学习得到的低维表示，语义能力强但可解释性弱。

9.3 适用场景

希望保留关键词匹配能力，又想享受向量检索的部署一致性。
专有名词多、对可解释性有要求。
作为稠密向量的补充，构成三路混合检索。

稀疏向量目前在联犀知识库和记忆召回中尚未使用，但它是值得关注的扩展方向，特别是在已经使用混合检索的体系里，可以作为第三路召回进一步提升稳定性。

10. 结构化检索与记忆画像压缩

10.1 结构化检索

结构化检索不是搜索引擎技术，而是利用数据库字段做过滤和排序。在长期记忆中，联犀的记忆记录包含多个可被检索/排序的字段：

keywords：关键词列表
importance：重要性
access_count：访问次数
created_time / updated_time：时间
记忆类型：fact、preference、event、summary
向量索引 key

这些字段让记忆召回可以先做结构化过滤（比如只查 fact 类型、只查最近 30 天、只查高重要性），再进入向量或全文检索。这种分层能显著降低检索成本。

10.2 记忆画像压缩（Memory Profile）

记忆画像是把长期记忆压缩成一段精炼文本，直接注入 prompt。它不是检索技术，但深刻影响上下文成本。

联犀的记忆画像合并策略经历了三个阶段：

简单拼接：画像无限增长，prompt 膨胀至 218KB。
LLM 压缩合并：限制输出 500 字符，但引入额外 LLM 调用。
进一步压缩：控制 prompt 长度，优先保留姓名、偏好、重要约定等关键事实。

memory profile 就像回忆链路里的快速通道：它不是替代长期记忆，而是在很多常见问题上提前给出一个更轻的语义入口。

10.3 为什么放在一起讲

结构化检索和记忆画像压缩都指向同一个工程目标：不要让每次请求都走最重的完整召回链。先用结构化字段和画像把大量请求挡住，只有必要时才进入向量/全文/图的深层召回。

11. 技术选择：场景决策矩阵

到这里，我们已经讲了十几种技术。实际工程中不可能全部堆上去，关键是按场景选择。下面给出一个简化的决策矩阵：

场景	推荐技术	联犀对应实践
精确匹配专有名词、型号、错误码	全文索引 / 关键词搜索	语音链路记忆召回用 Jaccard + trust_score
语义相似、同义词、跨语言	向量检索	知识库首轮召回、长期记忆 embedding 召回
跨文档/跨切片上下文扩展	图 / Chunk Relations	`knowledge_get_chunk_relations` 工具
既要语义又要精确	混合检索 + RRF	知识库三阶段检索第二阶段
候选集已召回但排序不准	Cross-Encoder 精排	知识库第三阶段（可选）
记忆召回要考虑多样性	MMR	长期记忆多步组合
记忆召回要考虑时效性	时间衰减 + access_count	长期记忆多步组合
用户问题表述不清	查询重写	知识库查询净化
已经知道用户稳定画像	记忆画像压缩	`ai_memory_profiles.profile_text`
需要先缩小候选范围	结构化检索	记忆记录的 keywords/importance/access_count

真实系统往往不是"选一个"，而是把这些技术按成本从轻到重组织成一条链路：

查询重写 → 结构化过滤 → 多路召回（全文/关键词/向量/稀疏向量）
  → RRF 融合 → Cross-Encoder 精排 → 按需图/关系扩展 → 上下文压缩

12. 联犀实践总结

回顾联犀在 AI 上下文链路上的演进，可以概括为从"单一向量"走向"分层组合"：

知识库：从"固定前置向量检索"变成工具化调用，支持 knowledge_search、knowledge_get_document_content、knowledge_get_chunk_relations 三种动作按需组合。准确度治理上采用查询重写 → 混合搜索 + RRF → Cross-Encoder 精排的三阶段架构。
长期记忆：不是简单向量检索，而是 embedding、关键词、MMR、时间衰减、importance、access_count 等多步组合。同时用 memory profile 做高频画像的快速通道。
语音链路：对延迟极度敏感的场景里，把记忆同步注入从 embedding 改为全文索引（Jaccard + trust_score），用精度换速度。
关系扩展：通过 chunk relations 把"图"的能力作为知识库检索的可选扩展层，而不是默认全量执行。

这些实践的共同点是：不让所有问题都走最重的链路。简单问题用轻量技术，复杂问题才进入多层组合。上下文准备的成本，应该与问题的复杂度匹配。