1. 项目概述为什么医疗AI智能体需要“长效记忆”最近在做一个医疗领域的AI智能体项目核心目标不是让它回答一个孤立的问题而是让它能像一个经验丰富的医生或健康顾问那样与用户进行持续、连贯的多轮对话。想象一下这个场景用户第一次咨询时提到自己有高血压病史正在服用某种降压药。一周后用户回来问“我最近有点咳嗽可以吃XX感冒药吗”一个没有记忆的AI会把这个当作一个全新的、孤立的用药咨询来处理。但一个有“记忆”的智能体应该能立刻关联起用户的高血压病史和当前用药并意识到某些感冒药如含有伪麻黄碱成分的可能会升高血压与现有降压药产生相互作用从而给出更安全、个性化的警告和建议。这就是我们项目标题“构筑长效对话链路”的核心诉求。它不是一个简单的问答机器人而是一个具备长期记忆和上下文完整处理能力的对话伙伴。在医疗这个容错率极低、信息关联性极强的领域记忆的缺失或混乱可能导致建议无效甚至存在安全隐患。用户不会每次都把病史、过敏史、用药清单从头到尾复述一遍他们默认AI“记得”。因此如何让智能体在多轮对话中精准地记住关键信息并在恰当的时机调用同时避免记忆“污染”或“遗忘”就成了技术实现上的核心挑战也是本项目要解决的实践问题。2. 核心需求解析从“健忘”到“专业助理”的跨越要理解我们需要构建什么首先要看清现有方案的短板。很多基于大语言模型LLM的简单应用其对话本质上是“无状态”的。常见的做法是将用户当前的问题和模型上一次的回答或许加上最近几轮对话拼接起来作为本次请求的上下文Prompt发送给模型。这种方式有几个致命缺陷上下文长度限制所有模型都有上下文窗口限制如4K、8K、128K tokens。随着对话轮次增加把全部历史对话都塞进去很快会“爆窗”导致最早的关键信息如基础病史被“挤出去”。信息噪音与稀释即使上下文窗口足够大把几十轮琐碎的闲聊、确认、寒暄都放进去真正重要的医疗信息诊断、用药、指标反而被淹没在文本海洋里模型难以精准捕捉。记忆“乱窜”与隔离缺失这是我们在早期测试中踩过的大坑。假设智能体同时服务用户A和用户B在异步或不同会话中。如果记忆存储或检索机制设计不当用户A的病史信息可能会在处理用户B的问题时被错误地关联或引用造成严重的隐私泄露和逻辑混乱。这就是热词中提到的“记忆会‘乱窜’”问题。缺乏结构化记忆与推理医疗信息是高度结构化的疾病、药品、检查指标、时间线。简单的文本历史记录无法支持复杂的查询比如“用户过去三个月提到的所有肝功能相关指标有哪些变化趋势”因此我们的核心需求可以分解为持久化关键信息需要被提取并存储到对话之外的一个“记忆库”中不受上下文窗口限制。结构化记忆不能是一团乱麻的文本而应该被分类、打标如标签#过敏史、#长期用药、#诊断记录-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 上下文处理流水线从用户输入到智能体输出单轮对话的处理遵循一个清晰的流水线我称之为“感知-记忆-思考-行动”循环输入感知与会话路由接收用户输入。通过user_id和session_id确定当前对话的“身份”和“场景”。这通常由上层应用如App、网站在请求中携带。记忆检索Remember将用户当前查询进行向量化得到一个查询向量。向向量数据库发起查询条件是user_id 当前用户并计算查询向量与存储向量之间的相似度返回Top-K个最相关的记忆片段。这里有个实践技巧单纯靠语义相似度可能不够。例如用户问“降压药”历史中既有“我吃硝苯地平”也有“我停用了氯沙坦”。两者都相关但后者是过去式。因此检索时最好能结合元数据中的时间戳进行加权让更近期的记忆有更高权重或者允许在检索后根据时间进行过滤。上下文组装Context Assembly这是上下文工程Context Engineering的核心环节。我们需要将不同的信息模块按照一个精心设计的模板组装成本轮对话最终提交给大模型的Prompt。一个基础的组装模板如下# 系统指令固定 你是一名专业的医疗健康助手。请根据用户的健康状况历史和个人信息提供安全、准确的建议。 用户的关键健康信息如下 此处插入检索到的、格式化后的长期记忆片段 # 对话历史最近N轮用于保持对话流畅性 此处插入最近的几轮原始对话作为短期记忆 # 当前查询 用户{用户当前输入} # 助手关键点长期记忆片段的插入需要格式化例如用“- 病史高血压2023年确诊”这样的列表形式清晰易读。同时要严格控制注入的记忆总量避免挤占对话历史和分析思考所需的空间。模型推理与函数调用Reason Act将组装好的上下文发送给大语言模型如GPT-4、Claude、或国内主流模型。模型根据上下文生成回复。如果模型认为需要获取更多外部信息如查询最新的药品说明书数据库它会触发预设的函数调用Function Calling。关键实践函数调用的结果必须被追加到上下文中并让模型基于新信息进行“二次思考”生成最终回复给用户。这个过程可能循环多次。记忆更新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 问题记忆检索“不准”或“不全”现象用户问及“我之前的肝脏检查怎么样”但系统没有检索出三个月前用户提到的“转氨酶偏高”记录。排查检查嵌入模型用于“肝脏检查”和“转氨酶偏高”的向量相似度是否足够高可能领域特异性不够。解决方案尝试在医疗文本上进一步微调嵌入模型或换用领域更强的模型。检查标准化用户历史说的是“肝功不太好转氨酶有点高”但入库时可能只被标准化为“肝功能异常”而“转氨酶”这个关键实体没有被单独提取和标准化。解决方案强化实体识别和标准化流程确保关键指标被单独抽离存储。检查检索策略是否只检索了is_activeTrue的记忆那条记录是否被错误归档了检索的Top-K数量是否太小解决方案调整检索参数并对“否定陈述”如“转氨酶已恢复正常”这类记忆进行特殊元数据标记避免在正向查询时被排除。5.2 问题多轮对话中的指代消解混乱现象用户第一轮说“我胃疼”第二轮问“该吃什么药”。智能体可能无法理解“该”指的是“胃疼”该吃什么药。解决方案这需要结合短期上下文上一轮对话和长期记忆。在我们的流水线中“对话历史”部分包含了上一轮问答因此大模型本身具备一定的指代消解能力。但对于更复杂的指代如“我上次说的那个药”我们会在记忆检索环节不仅用当前查询也结合最近一两轮对话的上下文共同生成检索向量提高召回相关记忆的几率。5.3 问题智能体“幻觉”与记忆冲突现象用户历史明确说过“对青霉素不过敏”但智能体在建议用药时仍警告“请注意青霉素过敏风险”。排查与解决检查记忆检索结果是否“青霉素不过敏”这条记忆没有被成功检索到可能是检索相似度阈值设得太高或者这条记忆的向量表征不清晰。检查Prompt指令在系统指令中必须强约束“严格依据提供的关键健康信息进行回答如果信息中没有提及不得自行假设。” 同时可以将检索到的关键记忆以更醒目的方式呈现例如用户关键健康信息 【重要】药物过敏史无青霉素过敏史记录于2024-09-01。 其他病史...设置验证步骤对于关键建议如用药可以设计一个额外的“验证”函数调用专门核查建议内容是否与已知的禁忌症从长期记忆中检索冲突。5.4 性能与成本优化记忆检索异步化记忆检索和向量化是比较耗时的操作几十到几百毫秒。我们将其与对话响应的其他准备操作并行执行缩短整体响应时间。缓存热点记忆对于每个用户其最核心的几条记忆如活跃的慢性病诊断、当前用药、已知严重过敏史可以在应用层缓存避免每次对话都进行向量检索。分级存储将记忆分为“核心记忆”高频、关键和“边缘记忆”低频、细节。核心记忆使用更快更贵的存储/索引边缘记忆则使用成本更低的方案。6. 效果评估与迭代方向上线后我们通过人工评测和自动化指标相结合的方式评估效果核心指标记忆召回率在需要历史信息的对话轮次中系统成功提供相关记忆的比例。信息一致性智能体在不同轮次中对同一用户事实的表述是否一致。对话连贯性评分人工评估多轮对话是否自然、流畅有无突兀的重复提问或信息断层。发现与迭代初期记忆提取的精度是瓶颈。我们通过标注一批医疗对话数据专门微调了一个小模型用于“记忆提取”任务显著提升了结构化信息抽取的准确率。用户有时会提供相互矛盾的信息如两次描述过敏史不同。我们增加了记忆置信度和冲突检测机制。当新提取的记忆与旧记忆冲突时会触发一个澄清流程主动询问用户以确认并将确认后的结果作为最终记忆。构筑这样一个具备长效对话能力的医疗AI智能体绝非一蹴而就。它不是一个简单的“聊天接口”而是一个融合了信息检索、自然语言理解、知识管理和对话管理的复杂系统。每一处设计无论是分层的记忆结构、严格的隔离机制还是精细的上下文工程都直接关系到最终用户体验的可靠性与专业性。