面试题 · 检索
搜索「医疗」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
在构建具备记忆能力的智能体时，为何普遍采用向量数据库存储和检索历史信息？请说明embedding模型的选择原则、向量化表示的设计方法，以及高效的检索策略（如相似度匹配、重排序等）。
核心优势
对比传统方案：关系型数据库适合精确查询（如"查找3天内的订单"），但无法处理"找上次聊过的类似需求"；Redis等KV存储适合短期上下文，缺乏语义关联能力。
| 维度 | 考量要点 |
|---|
按学习路线查看教程、项目和面试题。
| 领域适配 | 通用场景用BGE-M3/E5，垂直领域（法律/医疗）需微调或专用模型 |
| 上下文长度 | Agent记忆可能很长，选择支持8K+的模型（如GTE-large） |
| 多语言 | 中文场景优先BGE、Piccolo；多语言选 multilingual E5 |
| 效率成本 | 端侧部署选轻量模型（BGE-small），云端可用大模型 |
| 指令理解 | 优先选用经过指令微调的模型（如instructor系列） |
文档切分策略
元信息增强
{
"content": "用户询问北京到上海的路线",
"metadata": {
"session_id": "xxx",
"timestamp": 1715000000,
"msg_type": "user_query",
"entities": ["北京", "上海"] # 用于预过滤
}
}多粒度表示：同时存储句子级（精细检索）和会话级（主题召回）向量
两阶段检索架构
粗排（向量相似度）：HNSW索引快速召回Top-K（K=50~100）
精排（重排序）：
关键优化
| 场景 | 策略 |
|---|---|
| 延迟敏感（<200ms） | 纯HNSW，放弃重排序；或本地部署小模型 |
| 精度优先 | 交叉编码器+多路召回（向量+关键词+图谱） |
| 长记忆（>10万条） | 分层存储：热数据内存向量库，冷数据磁盘索引 |
建议系统学习该知识点
场景切入
比如我们做一个订单客服助手，用户说“帮我查上次那个订单”，你得知道是哪个订单。如果只靠关键词匹配，“上次”根本对不上。你一般怎么让智能体记住这种历史信息？为啥非要用向量数据库？
层层追问
智能体要记住历史对话，你会怎么存？……如果用户问“上次说的那款产品还有吗”，怎么找到“上次”指的是啥？……那embedding怎么选？……怎么保证检索又快又准？
直球架构
设计一个带记忆的智能体，用向量数据库存储历史信息。说清楚为什么选向量数据库而不选关系型数据库；embedding模型怎么选、向量怎么设计；以及检索时粗排和精排具体怎么做。
这道题问的是[[Agent]]记忆为什么用[[向量数据库]]，其实本质是在问：怎么让智能体记住那些没法用精确条件表达的东西。比如用户说“上次我有个类似的退款问题”，你没法用SQL的where条件去匹配，因为关键词不一定对得上。所以向量数据库解决的是语义检索，不是精确查询。但真正落地的时候，它跟关键词检索不是二选一，而是互补的。我会用 [[Hybrid Search]]，把关键词和向量两条路结合起来，比如先用[[BM25]]粗筛，再用向量精排，这样既能处理同义改写，又能保证高频词不丢。
[[Embedding]]模型的选择，我主要看几个前提。先说领域适配，通用场景我用BGE或者E5就够了，但如果是医疗法律这种垂直领域，我会用领域数据微调过的模型，否则语义可能偏。接着说上下文长度，Agent的记忆可能很长，比如一个对话回合超过4K tokens，那模型窗口必须支持8K以上，不然切碎了语义就丢了。再补充效率成本，端侧部署我用轻量模型，云端可以用更大的。还有一点，我倾向于选经过[[指令微调]]的模型，比如instructor系列，这样检索时query和doc的表示更对齐。
向量化表示的设计，我重点做两件事。一个是元信息增强，不只是存文本向量，还会把session_id、时间戳、实体标签作为metadata。这样检索时可以先用实体过滤缩小范围，比如用户提到“北京”，我就只查metadata里包含“北京”的chunk，再算向量相似度，效率能高很多。另一个是多粒度表示，我会同时存句子级向量和会话级向量。句子级用来精细检索，比如找具体的一句话；会话级用来主题召回，比如找整个对话的脉络。切分策略上，我按语义切分，而不是固定长度，保留“用户问-Agent答”完整回合作为独立chunk，这样上下文不割裂。
检索策略我走两阶段。粗排用 [[HNSW]] 索引，快速召回Top-100，距离度量用余弦相似度，阈值低于0.7的直接丢掉。精排用 [[Cross-Encoder]] [[重排]]Top-20，精度高但慢，所以只对少量候选做。这里有个坑：如果延迟敏感，比如要求200ms以内，我会放弃重排序，纯用HNSW加向量相似度，或者用轻量的 [[ColBERT]] late interaction。另外，时间衰减很重要，我会在相似度分数上乘一个指数衰减因子，优先近期记忆，不然几周前的对话权重太高会误导。举个例子，客服退款场景，用户说“上次那个优惠券用不了”，系统通过向量检索找到上次对话，结合时间衰减，优先匹配最近的沟通记录，再根据实体过滤锁定具体订单，这样召回率能提高不少。
不过重排序这一步有个取舍：Cross-Encoder精度高但延迟高，尤其当候选集超过50条时，响应时间可能翻倍。我上线前会做压测，看延迟和精度的平衡点。如果业务对延迟更敏感，我会考虑用双编码器加[[蒸馏]]后的重排模型，或者干脆不做重排，只靠粗排加阈值过滤。
所以整体上，我更倾向于把向量数据库看成是Agent记忆的“语义索引”，跟关键词、时间过滤这些传统手段配合使用，而不是替代它们。前提是embedding模型要选对，元信息要设计好，检索流程要压测过。如果忽略这些，常见失败场景就是召回结果跟问题不相关，或者延迟超标，导致Agent反应慢半拍。