医疗AI智能体长效记忆架构：向量数据库与上下文工程实践

1. 项目概述：为什么医疗AI智能体需要“长效记忆”？

最近在做一个医疗领域的AI智能体项目，核心目标不是让它回答一个孤立的问题，而是让它能像一个经验丰富的医生或健康顾问那样，与用户进行持续、连贯的多轮对话。想象一下这个场景：用户第一次咨询时提到自己有高血压病史，正在服用某种降压药。一周后，用户回来问：“我最近有点咳嗽，可以吃XX感冒药吗？”一个没有记忆的AI，会把这个当作一个全新的、孤立的用药咨询来处理。但一个有“记忆”的智能体，应该能立刻关联起用户的高血压病史和当前用药，并意识到某些感冒药（如含有伪麻黄碱成分的）可能会升高血压，与现有降压药产生相互作用，从而给出更安全、个性化的警告和建议。

这就是我们项目标题“构筑长效对话链路”的核心诉求。它不是一个简单的问答机器人，而是一个具备长期记忆和上下文完整处理能力的对话伙伴。在医疗这个容错率极低、信息关联性极强的领域，记忆的缺失或混乱可能导致建议无效，甚至存在安全隐患。用户不会每次都把病史、过敏史、用药清单从头到尾复述一遍，他们默认AI“记得”。因此，如何让智能体在多轮对话中，精准地记住关键信息，并在恰当的时机调用，同时避免记忆“污染”或“遗忘”，就成了技术实现上的核心挑战，也是本项目要解决的实践问题。

2. 核心需求解析：从“健忘”到“专业助理”的跨越

要理解我们需要构建什么，首先要看清现有方案的短板。很多基于大语言模型（LLM）的简单应用，其对话本质上是“无状态”的。常见的做法是：将用户当前的问题和模型上一次的回答（或许加上最近几轮对话）拼接起来，作为本次请求的上下文（Prompt）发送给模型。这种方式有几个致命缺陷：

1. 上下文长度限制：所有模型都有上下文窗口限制（如4K、8K、128K tokens）。随着对话轮次增加，把全部历史对话都塞进去很快会“爆窗”，导致最早的关键信息（如基础病史）被“挤出去”。
2. 信息噪音与稀释：即使上下文窗口足够大，把几十轮琐碎的闲聊、确认、寒暄都放进去，真正重要的医疗信息（诊断、用药、指标）反而被淹没在文本海洋里，模型难以精准捕捉。
3. 记忆“乱窜”与隔离缺失：这是我们在早期测试中踩过的大坑。假设智能体同时服务用户A和用户B（在异步或不同会话中）。如果记忆存储或检索机制设计不当，用户A的病史信息可能会在处理用户B的问题时被错误地关联或引用，造成严重的隐私泄露和逻辑混乱。这就是热词中提到的“记忆会‘乱窜’”问题。
4. 缺乏结构化记忆与推理：医疗信息是高度结构化的（疾病、药品、检查指标、时间线）。简单的文本历史记录无法支持复杂的查询，比如“用户过去三个月提到的所有肝功能相关指标有哪些变化趋势？”

因此，我们的核心需求可以分解为：

• 持久化：关键信息需要被提取并存储到对话之外的一个“记忆库”中，不受上下文窗口限制。
• 结构化：记忆不能是一团乱麻的文本，而应该被分类、打标（如标签：#过敏史、#长期用药、#诊断记录-2024-03），以便精确检索。
• 隔离性：记忆必须严格按会话或用户维度进行隔离，确保绝对的数据安全和对话逻辑独立。
• 相关性：在每一轮对话中，智能体应能根据当前问题，从海量记忆中自动检索出最相关的部分，动态地、精简地注入本次对话的上下文。
• 时效性与更新：记忆不是一成不变的。用户的用药方案可能会调整，新的检查结果会出现，智能体需要能更新或修正已有的记忆。

3. 架构设计：分层记忆系统与上下文处理流水线

基于上述需求，我们设计了一个分层级的记忆系统和与之配套的上下文处理流水线。这个架构是整个智能体的“大脑”工作模式。

3.1 记忆分层：短期、长期与工作记忆

我们借鉴了人类认知的一些概念，将记忆分为三层：

• 短期记忆（Short-term Memory）：等同于大模型的上下文窗口（Context Window）。它容量有限，但存取速度极快，存放的是当前对话轮次直接相关的信息。例如，用户当前这句话、智能体上一句回复、以及从长期记忆中检索出来的相关片段。它的内容是动态的、临时的，每次请求后即被清空或覆盖。

  注意：这里必须澄清一个关键点，也是热词中提到的误区：“function call的‘执行结果’必须放进短期上下文”。这是完全正确的。当智能体通过函数调用（Function Calling）查询了用户的电子病历档案后，这个查询结果必须作为系统或用户消息的一部分，追加到本次请求的上下文窗口中。否则，大模型在生成下一步回答时，就像没看过病历一样，会导致对话逻辑中断或“死机”。

• 长期记忆（Long-term Memory）：这是我们构建的核心，一个外部的、持久化的存储系统。它用于存放从历史对话中提炼出的结构化关键事实。我们选择使用向量数据库（Vector Database）作为主要存储引擎，原因在于它能基于语义进行相似度检索，非常适合从用户模糊、自然的表述中找回相关记忆。

  • 存储内容：不是存储原始对话，而是存储经过“记忆提取”环节处理后的记忆片段（Memory Snippets）。每个片段包含：核心事实文本、对应的结构化元数据（如：用户ID、会话ID、实体类型【疾病、药品、检查项】、发生时间、置信度）、以及该文本的向量嵌入（Embedding）。
  • 隔离机制：这是解决“乱窜”问题的关键。所有记忆片段的元数据中都必须包含唯一的user_id和session_id。在进行检索时，检索条件必须严格带上user_id（和可选的session_id）。这意味着，即使用户A和用户B问了语义一模一样的问题“我头疼怎么办？”，系统也只会从用户A自己的记忆库中检索相关病史，绝不会触达用户B的数据。这实现了数据层面的硬隔离。

• 工作记忆（Working Memory）：这是一个逻辑概念，指在单轮对话处理周期内，被激活和使用的记忆集合。它 =动态检索到的相关长期记忆+当前短期记忆（上下文）。工作记忆是智能体进行本轮推理和决策的直接依据。

3.2 上下文处理流水线：从用户输入到智能体输出

单轮对话的处理，遵循一个清晰的流水线，我称之为“感知-记忆-思考-行动”循环：

1. 输入感知与会话路由：

   • 接收用户输入。
   • 通过user_id和session_id确定当前对话的“身份”和“场景”。这通常由上层应用（如App、网站）在请求中携带。

2. 记忆检索（Remember）：

   • 将用户当前查询进行向量化，得到一个查询向量。
   • 向向量数据库发起查询，条件是：user_id= 当前用户，并计算查询向量与存储向量之间的相似度，返回Top-K个最相关的记忆片段。
   • 这里有个实践技巧：单纯靠语义相似度可能不够。例如，用户问“降压药”，历史中既有“我吃硝苯地平”，也有“我停用了氯沙坦”。两者都相关，但后者是过去式。因此，检索时最好能结合元数据中的时间戳进行加权，让更近期的记忆有更高权重，或者允许在检索后根据时间进行过滤。

3. 上下文组装（Context Assembly）：

   • 这是上下文工程（Context Engineering）的核心环节。我们需要将不同的信息模块，按照一个精心设计的模板，组装成本轮对话最终提交给大模型的Prompt。
   • 一个基础的组装模板如下：

     # 系统指令（固定） 你是一名专业的医疗健康助手。请根据用户的健康状况历史和个人信息，提供安全、准确的建议。 用户的关键健康信息如下： <此处插入检索到的、格式化后的长期记忆片段> # 对话历史（最近N轮，用于保持对话流畅性） <此处插入最近的几轮原始对话，作为短期记忆> # 当前查询 用户：{用户当前输入} # 助手：

   • 关键点：长期记忆片段的插入需要格式化，例如用“- 病史：高血压（2023年确诊）”这样的列表形式，清晰易读。同时，要严格控制注入的记忆总量，避免挤占对话历史和分析思考所需的空间。

4. 模型推理与函数调用（Reason & Act）：

   • 将组装好的上下文发送给大语言模型（如GPT-4、Claude、或国内主流模型）。
   • 模型根据上下文生成回复。如果模型认为需要获取更多外部信息（如查询最新的药品说明书数据库），它会触发预设的函数调用（Function Calling）。
   • 关键实践：函数调用的结果必须被追加到上下文中，并让模型基于新信息进行“二次思考”，生成最终回复给用户。这个过程可能循环多次。

5. 记忆更新（Update Memory）：

   • 本轮对话结束后，系统需要判断是否有新的关键信息需要存入长期记忆。
   • 这可以通过一个独立的“记忆提取”LLM调用来实现：将本轮有信息增量的对话部分（例如用户陈述了新症状，或助手确认了一个诊断）发送给一个专门优化的模型，指令其提取结构化事实。
   • 例如，用户说：“医生今天给我换了药，把阿司匹林换成了氯吡格雷。” 记忆提取模型应输出类似：{“action”: “update”, “entity”: “medication”, “name”: “阿司匹林”, “status”: “stopped”, “new_name”: “氯吡格雷”, “time”: “2024-10-27”}的结构化数据，然后将其向量化并存入该用户的长期记忆库，同时可能需要对旧的“阿司匹林”记忆标记为失效。

4. 关键技术选型与实现细节

4.1 向量数据库选型：为什么是Pgvector？

市面上向量数据库很多（Milvus, Qdrant, Weaviate等）。我们最终选择了Pgvector，一个PostgreSQL的扩展。理由如下：

• 运维简单：团队对PostgreSQL非常熟悉，无需引入新的基础设施和运维复杂度。Pgvector无缝集成，直接用SQL操作，管理备份都一套流程。
• 数据一致性：记忆的元数据（用户ID、时间、标签）和向量本身可以放在同一张表、同一个事务中操作，保证了“记忆片段”作为一个整体的一致性。这是很多独立向量数据库需要额外通过外部关联来处理的痛点。
• 成熟稳定：PostgreSQL的ACID特性和可靠性，对于存储用户敏感的医疗数据至关重要。
• 性能足够：对于我们的场景——单用户记忆检索（即每次查询都带user_id过滤），数据量在百万级以下，Pgvector的性能完全满足要求，延迟在几十毫秒内。

表结构设计示例：

CREATE TABLE user_memories ( id BIGSERIAL PRIMARY KEY, user_id VARCHAR(128) NOT NULL, session_id VARCHAR(256), memory_text TEXT NOT NULL, -- 记忆文本 metadata JSONB, -- 结构化信息，如 {"entity_type": "medication", "drug_name": "硝苯地平", "status": "active"} embedding vector(1536), -- OpenAI text-embedding-3-small 维度 created_at TIMESTAMPTZ DEFAULT NOW(), is_active BOOLEAN DEFAULT TRUE -- 软删除标记 ); CREATE INDEX ON user_memories USING hnsw (embedding vector_cosine_ops); CREATE INDEX ON user_memories (user_id, is_active, created_at); -- 加速过滤查询

实操心得：在metadata字段里，我们不仅存放实体信息，还会存一个source_dialogue_id，指向原始对话记录的ID。这样当后续发现某条记忆有误时，可以快速溯源到具体的对话上下文，便于人工审核和修正。

4.2 嵌入模型选择与“词义统一”问题

我们使用文本嵌入模型将记忆文本和用户查询转换为向量。选择的是text-embedding-3-small，在效果和成本间取得了良好平衡。

这里就遇到了热词中的一个经典问题：“我的向量数据库包含试卷的解析内容，意思相近的词需要完全统一吗？比如 ‘上下文理解’ 和 ‘语境推测’ 这两个词？”

答案是：在医疗领域，强烈建议进行术语标准化，但并非简单粗暴的统一。

• 为什么需要标准化？用户和医生描述同一事物用语千差万别：“心慌”、“心悸”、“心脏砰砰跳”；“二甲双胍”、“格华止”（商品名）。如果不对这些术语进行归一化，那么当用户用“心慌”查询时，可能无法有效检索到记录为“心悸”的历史记忆。
• 如何做？我们引入了一个医疗实体标准化模块。在记忆入库和查询前，文本会先经过这个模块处理，识别并替换其中的医疗实体为标准化术语（通常采用医学标准词典如SNOMED CT、ICD-10中的编码或标准名称）。例如，将“格华止”替换为“二甲双胍”，并可能在元数据中保留原始表述。
• “上下文理解”vs“语境推测”：在通用领域，这两个短语语义高度相关，嵌入模型本身可能就能处理好它们的相似性。但在严谨的医疗场景，如果它们指代的是我们系统中两个不同的具体功能模块，那么就应该被视为不同的概念，不应强行统一。核心原则是：标准化的是客观实体（疾病、药品、检查），而不是主观描述或功能概念。

4.3 大模型上下文管理与压缩策略

即使我们通过记忆检索注入了最相关的信息，上下文窗口依然可能因为复杂的思考过程、函数调用结果而变得臃肿。我们采用了以下策略进行管理：

• 对话历史摘要：我们不保存所有原始对话历史。每经过一定轮次（如10轮），或当对话主题明显切换时，我们会触发一个“摘要”函数调用。让大模型用一段简洁的文字总结之前对话的核心健康事实和决策，然后用这个摘要替换掉之前冗长的原始历史。这个摘要本身也会被向量化存入长期记忆。
• 分层上下文（Context Layering）：受热词“claude code上下文分层”启发，我们在Prompt设计上采用了分层结构。最核心的“系统指令”和“用户关键健康信息”放在最前面且固定不变。中间的“对话历史”是动态滑动窗口。函数调用结果作为“最新情报”插入在查询之前。这种结构让模型能优先关注最重要的信息。
• 选择性遗忘：对于长期记忆，我们设置了记忆的“衰减”机制。例如，一条“感冒症状”的记忆，如果在存入后90天内没有被再次检索或关联，其is_active标志可能被自动设为FALSE（归档），或在检索时权重降低。而对于“青霉素过敏”这类终身关键信息，则设置为永久有效。

5. 实践中的挑战与解决方案实录

在开发和上线过程中，我们遇到了不少具体问题，以下是部分实录：

5.1 问题：记忆检索“不准”或“不全”

• 现象：用户问及“我之前的肝脏检查怎么样？”，但系统没有检索出三个月前用户提到的“转氨酶偏高”记录。
• 排查：
  1. 检查嵌入模型：用于“肝脏检查”和“转氨酶偏高”的向量相似度是否足够高？可能领域特异性不够。解决方案：尝试在医疗文本上进一步微调嵌入模型，或换用领域更强的模型。
  2. 检查标准化：用户历史说的是“肝功不太好，转氨酶有点高”，但入库时可能只被标准化为“肝功能异常”，而“转氨酶”这个关键实体没有被单独提取和标准化。解决方案：强化实体识别和标准化流程，确保关键指标被单独抽离存储。
  3. 检查检索策略：是否只检索了is_active=True的记忆？那条记录是否被错误归档了？检索的Top-K数量是否太小？解决方案：调整检索参数，并对“否定陈述”（如“转氨酶已恢复正常”）这类记忆进行特殊元数据标记，避免在正向查询时被排除。

5.2 问题：多轮对话中的指代消解混乱

• 现象：用户第一轮说“我胃疼”，第二轮问“该吃什么药？”。智能体可能无法理解“该”指的是“胃疼”该吃什么药。
• 解决方案：这需要结合短期上下文（上一轮对话）和长期记忆。在我们的流水线中，“对话历史”部分包含了上一轮问答，因此大模型本身具备一定的指代消解能力。但对于更复杂的指代（如“我上次说的那个药”），我们会在记忆检索环节，不仅用当前查询，也结合最近一两轮对话的上下文共同生成检索向量，提高召回相关记忆的几率。

5.3 问题：智能体“幻觉”与记忆冲突

• 现象：用户历史明确说过“对青霉素不过敏”，但智能体在建议用药时仍警告“请注意青霉素过敏风险”。
• 排查与解决：
  1. 检查记忆检索结果：是否“青霉素不过敏”这条记忆没有被成功检索到？可能是检索相似度阈值设得太高，或者这条记忆的向量表征不清晰。
  2. 检查Prompt指令：在系统指令中，必须强约束：“严格依据提供的关键健康信息进行回答，如果信息中没有提及，不得自行假设。” 同时，可以将检索到的关键记忆以更醒目的方式呈现，例如：

     用户关键健康信息： 【重要】药物过敏史：无青霉素过敏史（记录于2024-09-01）。 其他病史：...

  3. 设置验证步骤：对于关键建议（如用药），可以设计一个额外的“验证”函数调用，专门核查建议内容是否与已知的禁忌症（从长期记忆中检索）冲突。

5.4 性能与成本优化

• 记忆检索异步化：记忆检索和向量化是比较耗时的操作（几十到几百毫秒）。我们将其与对话响应的其他准备操作并行执行，缩短整体响应时间。
• 缓存热点记忆：对于每个用户，其最核心的几条记忆（如活跃的慢性病诊断、当前用药、已知严重过敏史）可以在应用层缓存，避免每次对话都进行向量检索。
• 分级存储：将记忆分为“核心记忆”（高频、关键）和“边缘记忆”（低频、细节）。核心记忆使用更快更贵的存储/索引，边缘记忆则使用成本更低的方案。

6. 效果评估与迭代方向

上线后，我们通过人工评测和自动化指标相结合的方式评估效果：

• 核心指标：
  • 记忆召回率：在需要历史信息的对话轮次中，系统成功提供相关记忆的比例。
  • 信息一致性：智能体在不同轮次中对同一用户事实的表述是否一致。
  • 对话连贯性评分：人工评估多轮对话是否自然、流畅，有无突兀的重复提问或信息断层。
• 发现与迭代：
  • 初期，记忆提取的精度是瓶颈。我们通过标注一批医疗对话数据，专门微调了一个小模型用于“记忆提取”任务，显著提升了结构化信息抽取的准确率。
  • 用户有时会提供相互矛盾的信息（如两次描述过敏史不同）。我们增加了记忆置信度和冲突检测机制。当新提取的记忆与旧记忆冲突时，会触发一个澄清流程，主动询问用户以确认，并将确认后的结果作为最终记忆。

构筑这样一个具备长效对话能力的医疗AI智能体，绝非一蹴而就。它不是一个简单的“聊天接口”，而是一个融合了信息检索、自然语言理解、知识管理和对话管理的复杂系统。每一处设计，无论是分层的记忆结构、严格的隔离机制，还是精细的上下文工程，都直接关系到最终用户体验的可靠性与专业性。