做临床研究信息化这些年最常被问的一句话就是“这个方案里的入排标准能在我们的历史数据里直接跑出候选患者吗” 过去我一般只能回答“得人工筛选”因为系统里数据散在多个库里知识也散在一堆PDF和SOP里。直到我们把临床研究 AI Agent 平台的知识库与数据服务平台从设计草图一步步落到生产环境这个问题才开始真正有了答案。这篇内容就围绕这套平台来写它到底解决临床研究里的哪些实际问题、知识库和数据服务两条线怎么搭、Agent 怎么跟它们协同干活以及我们在过程中踩过哪些坑。适合正在做医疗信息化、临床研究数字化、或者想把大模型 Agent 引入专业垂直领域的技术团队参考也适合对临床研究与数据合规感兴趣的朋友理解整体逻辑。我不会去聊太多有光环的架构图重点讲落地时要面对的那些真实决策知识怎么清洗、分块怎么切、数据怎么标准化、权限怎么不越界、Agent 怎么调用工具还能不出错。把这些理顺了平台才不是一个 Demo而是能扛住稽查和审计的生产系统。1. 项目定位与整体设计思路1.1 临床研究场景到底缺什么先说业务背景。临床研究行业的信息化程度不算低但长期存在“系统孤岛”和“知识孤岛”两种并存的问题。数据孤岛好理解受试者的入组数据可能在 EDC 里检验结果在 LIS 里既往病史又散在电子病历或旧项目的历史表里想要做一次跨系统筛选得写一堆接口或者靠人手工导出再合并。知识孤岛则体现在方案、知情同意书模板、SOP、风险控制计划、国内外指南、监管要求统统以非结构化的文档形式躺在文件服务器或者内部 Wiki 里检索靠人工翻阅。如果只是做一个普通的全文搜索或者问答机器人其实解决不了真正的业务问题因为用户要的不是“找到一份文件”而是“基于某个问题给出结构化答案并给出证据来源”。举个例子研究者问“既往接受过两种及以上全身治疗方案的晚期实体瘤患者是否可以入组”系统得能理解方案文本里的语义同时可能还要结合历史数据中某位受试者的治疗记录来给判断依据。这样的需求决定了平台不能只是一个检索工具而必须是一个能调度知识、查询数据、组织推理链路的智能体平台。1.2 模块拆解知识库、数据服务与 Agent 引擎这套平台最终拆成三条主线知识库服务、数据服务平台、AI Agent 协调层。知识库服务负责把团队内部积累的方案、SOP、医学词典、历史项目资料转化成可持续检索、可追溯、带版本管理的知识资产。不要让“知识库”听起来很玄本质上就是一套针对医学文档做清洗、分块、向量化、混合检索和重排的流水线再加一层版本和溯源管理。数据服务平台负责打通多源临床数据统一接入、标准化字段映射、质量校验、隐私脱敏、权限隔离以及对外提供安全的查询接口。它的核心目标只有一个让上层应用能够用一套接口拿到可信的数据而不用关心底下的库是 Oracle、SQL Server 还是某个老旧的 CSV 导出。AI Agent 协调层是大脑。它可以调用知识库检索工具、数据查询工具、计算工具甚至未来可以接入自动化的表单填写工具。它要负责理解用户自然语言问句背后的真实意图规划调用哪些工具组装最终答案并在答案里附上知识来源和数据明细。1.3 为什么用 Agent 架构而不是单一问答接口一开始也考虑过最简单路线训练一个垂直领域问答模型或者在通用模型上做 fine-tuning把所有知识一股脑塞进去。但很快否掉了。原因有两个方面。第一是知识会频繁变化临床方案几乎每个月都有版本更新指南也会定期改版如果靠模型参数记住知识每次更新都要重新训练或者微调成本太高而且无法保证实时性。用知识库外挂的方式来提供事实依据模型只负责理解与生成知识更新只需要更新索引即可。第二是数据必须“查”出来。模型没有能力凭记忆算出“筛选期内有多少位受试者符合某条标准”必须有工具去数据库里执行查询。这也决定了 Agent 必须拥有工具调用能力而不是只做纯文本生成。1.4 私有化部署作为默认前提临床数据的保密等级非常高项目一开始就把私有化部署作为硬约束平台必须本地化运行服务全部部署在内网环境中推理和大模型服务只能使用本地或私有化的模型权重。这意味着很多“调云端 API 就完事”的方案全部不可行向量化模型、生成模型、重排模型都需要能在本地跑得起来同时还要兼顾效果与资源开销。这套平台的部署形态大致是一个算力节点跑推理服务两个普通应用节点跑知识库与数据接口再加一套对象存储和关系型数据库做元数据管理。总资源投入比很多人想象中要低关键在于推理模型的选型和向量化的批处理策略这部分在后面细说。2. 知识库工程实践让临床文档变得可检索、可推理2.1 知识源盘点与清洗加工知识库第一步不是向量化而是盘点和清洗。我见过不少团队一上来就闷头切文档结果检索效果一塌糊涂因为源文档里的版面噪声、重复和过期内容全被当成了金子。临床研究的知识源通常包括几类项目方案与修正案、知情同意书模板、SOP 文件、研究者手册、安全性参考信息、疾病领域指南、标准字典比如不良事件分级词典、历史项目的数据字典和注解 CRF。每一种文档都要先做格式统一。Word、PDF、扫描件混在一起有不少还需要 OCR 识别这一步不能外包给通用工具直接丢进向量库必须做版面分析把页眉页脚、目录、页码、水印全部清理干净。清洗时还要做一层“敏感信息识别”因为方案和 CRF 里偶尔会夹带受试者的姓名缩写或者医院名称。我们的做法是在清洗流水线里加入正则与命名实体识别识别到疑似个人信息就直接拦截交由人工确认后再发布进入知识库。我个人建议在清洗完成后保留一份“清洗后正文”原稿与最终向量化版本一一对应。做溯源查询或者争议复核时可以直接从数据库里拉出原稿片段而不是只能看到一段被切碎的向量块。2.2 分块策略不要用一把刀切所有文档经常有人问分块大小到底多少合适我的答案永远是一句话取决于文档结构和下游检索方式不存在全局最优。临床方案这种文档有非常清晰的层级结构通常是章节-小节-条款。如果直接按固定字符数硬切很容易出现“一条完整入排标准被截断到两块”的情况检索时只能召回其中一半非常影响效果。我们的策略是“结构优先语义兜底”优先用目录和标题层级去划分段落块每个块尽量在语义上自洽对于没有标题结构的表格和技术附录再按段落或表格单元格进行补充切分。块的长度我们控制在 600 到 1200 字之间对应到 token 大概是 400 到 800这个量级既能让向量表示足够聚焦又不会让上下文信息丢失过多。分块完成之后还要给每个块打上元数据标签所属文档ID、版本号、章节路径、文档类型、适用瘤种或适应症等。这些标签在后面的过滤排序里非常重要。2.3 混合检索与重排医学场景的必备动作纯向量检索在医学专业文档上往往会翻车因为医学术语的缩写、同义词和拼写变体太多。比如“NSCLC”“非小细胞肺癌”“non-small cell lung cancer”在向量空间里并不是总能靠语义贴近再比如方案里写“既往未接受过系统性抗肿瘤治疗”但用户问的是“初治患者”语义相近但字面完全不同。纯关键词检索对这组问答则完全无能为力。所以我们采用“BM25关键词召回 向量语义召回”的混合检索两路结果按权重合并后进入重排模型由重排模型确定最终返回的 Top K 块。重排不是可选项是必要项。跳过重排、直接在召回结果上做上下文拼接是很多 RAG 应用效果不佳的重要原因。实际操作上关键词路要做中文分词和医学同义词扩展向量路要选一个在医学语料上表现稳定的中文 Embedding 模型。我们内部对比过通用向量模型和经过医学语料微调的领域向量模型在临床方案的召回命中率上差距大概是 8 到 12 个百分点这个差距在后续问答中会造成肉眼可见的效果差异。2.4 版本管理与时效性知识库最容易被忽略的环节临床文档的时效性非常敏感。一个方案版本更新了旧版内容原则上不应该继续作为答案依据。SOP 和指南也一样不同版本可能给出完全不同的标准。知识库如果不做版本隔离就会出现 Agent 用 2021 年的指南回复 2024 年的问题这在稽查中属于比较严重的问题。我们的版本机制并不复杂每一份文档入库时就绑定统一的文档版本号已经向量化的向量数据也带上版本标识。检索时默认只查“当前有效版本”所有过期版本会被标记为“仅台账可查”不会被 Agent 作为答案来源。除非用户显式指定“查询历史版本”否则检索链路不会触碰已失效的版本。同步还建了一个“知识审核与发布”的流程任何新文档必须经过医学编辑或者资深研究者确认才能从“待审核”状态转为“已发布”状态。这个流程看似反效率实际在医疗领域非常必要。AI 可以加速检索和归纳但最终的发布权限必须由人把控这条原则建议所有想做临床知识库的人钉死。3. 数据服务平台落地细节标准化、质量与权限3.1 多源数据的接入与快照机制数据服务平台最耗时间的不是接口开发而是搞清楚每一个数据源的字段含义。EDC 系统的库表结构、电子病历导出的 CSV、外部实验室的 Excel 报告字段命名往往随心所欲有的叫“SUBJID”有的叫“Screening_No”还有的叫“受试者编号长整”。接入层的第一步永远是建“数据字典映射表”——把外部字段映射到平台内部的标准字段上。接入方式分三种对主流的关系型源头系统做定时增量同步对能提供 API 的系统做实时接口调用对文件型数据做上传批处理。我们全部配备了快照机制每天做一次全量快照配合增量日志这样即使某一轮 ETL 挂掉或者数据被误删也能从上一个快照恢复。实时接口调用看似最理想但在真实环境中最容易引起源端系统资源冲突。临床系统通常还要承载一线录入人员的操作查询压力太大会拖慢它们的响应所以我们对实时接口做了严格的限流和频率控制大多数场景宁可选择定时批量同步。3.2 临床数据标准化字段映射与衍生计算标准化是整个数据服务平台的灵魂。平台内部不直接使用源系统的原始字段名而是建立一套内部统一数据模型受试者表、访视表、不良事件表、检验检查表、合并用药表、病史表等。所有上游数据都必须完成字段映射和格式统一之后才能进入标准模型层。举个具体例子某个外部系统的“实验室值”字段传进来可能是字符串“3.5”而另一个系统可能是数值型“3.50”还带一个参考范围标志。标准化层会统一成数值单位参考范围异常标记的结构并且在入库时做质量校验数值能否解析、单位是否合法、日期是否符合逻辑。衍生指标也放在这一层计算。比如“既往治疗线数”不会存在于任何一张源表里但可以通过合并用药记录和病史记录按照既定算法计算出来。这些衍生指标直接面向 Agent 的查询接口Agent 不需要自己拼复杂逻辑只需要调用标准化层的“患者画像”服务即可。3.3 脱敏、权限隔离与审计追踪数据服务平台里最重要的一部分是“边界”。临床数据涉及受试者个体隐私和试验盲态数据边界做不好再强的功能都是定时炸弹。第一层是静态脱敏。姓名、身份证号、电话号码、详细地址在进入平台时立即处理姓名保留姓氏首字加脱敏符证件号做不可逆哈希替换自由文本中的敏感信息在 ETL 阶段用规则清洗。如果需要复原原始记录必须走脱离敏数据仓库的单独通道并在系统里留下完整操作日志。第二层是权限隔离。平台的用户分为研究者、数据管理员、医学监查员、稽查员等角色每个角色能看到的数据范围不一样。更细的还按项目隔离A 项目的权限默认看不到 B 项目的任何数据。所有数据查询都必须经过权限鉴权中间件不能只依赖数据库的账号权限因为 Agent 是统一入口如果放开数据库账号等于把钥匙直接交给系统。第三层是审计追踪。每一次数据查询、导出、删除操作都记录操作人、时间、查询条件、返回条数以及命中了哪些受试者标识。这一层在临床研究的稽查中是硬性要求从第一天设计就要想清楚后面补会非常痛苦。值得提醒的是权限控制不仅要做行级还要做列级。有些角色可以看到某受试者的检验结果但不能看到既往治疗明细有些角色只能看汇总统计不能下钻到个案。列级权限如果通过 SQL 拼接去控制日志会非常难维护我们最终是在标准化查询服务层做了统一拦截Agent 生成的查询语句会先经过字段白名单校验。3.4 接口层的两种查询形态SQL 与预聚合指标给 Agent 和上层应用提供数据查询接口时我们提供两种形态结构化查询接口和指标聚合接口。结构化查询接口供 Agent 生成精确查询语句使用但做了安全限制查询语句会被解析成 AST过滤掉危险操作并且加入强制性的项目权限条件。指标聚合接口则是提前算好一批常用指标筛选失败率、入组率、方案偏离率、SAE 发生率等Agent 只需要通过参数调用不用动态生成复杂 SQL。从实际使用频率看指标聚合接口调用量占七成以上结构化查询占三成。大量业务问题其实是重复的统计口径问题做成固化指标后准确率和大模型出错的概率都会大幅降低。这个调优思路值得借鉴不要把所有问题都丢给 Agent 现算把常用的、口径明确的问题固化成服务Agent 做路由就够了。4. Agent 与知识库、数据服务的协同实战4.1 工具注册与意图路由Agent 层采用工具调用型架构而不是“问答完事”。我的经验是第一步先做意图路由不是为了展示智能而是为了减少错误调用。比如用户问“我们中心现在入组了多少例”这个意图应该直接路由到数据指标查询工具用户问“方案里对既往治疗有什么要求”应该路由到知识检索工具如果用户两个问题混在一起问Agent 需要规划多次调用。我们给每个工具写了很详细的“工具说明书”包括适用场景、必填参数、可选参数、返回示例和常见错误。这里不要低估工具说明的作用实测中工具描述的丰富程度直接决定 Agent 选择工具的准确率。写工具说明的时候一定要用业务人员看得懂的口吻不要写成技术接口文档。路由判断本身可以有两种实现轻量级的可以用分类模型快速判断意图更推荐让主模型直接输出结构化的函数调用。我们最终选择的是后者因为模型输出的函数调用可以和自然语言问题在上下文里一起建模逻辑更自然。4.2 链路设计检索后组装与数据后处理知识问答链路相对简单用户问题 → 意图识别 → 知识库检索 → 召回块重排 → 组装 Prompt → 大模型生成答案 → 附上引用来源。这里容易做得不够好的点是“引用来源”不能只给一个文档标题必须定位到小节和原文片段。我们让 Prompt 强制要求模型输出引用角标同时在答案展示层把角标反向映射到原始文档片段点击即可查看原文。数据问答链路要复杂一些用户问题 → 意图识别 → 数据服务接口 → 前处理生成查询参数/查询语句→ 安全校验 → 数据服务执行 → 结果格式化 → 大模型撰写解读。这条链路里准确性风险不在模型而在于自然语言到数据查询语句的转换。建议不要追求让模型生成完全没有语法错误的 SQL而是尽量让模型生成“参数化的查询条件”和“聚合方式”再由平台内部的查询服务基于参数组合出规范 SQL。这样模型出错的空间会小得多。4.3 三个高频落地场景的复盘场景一方案撰写辅助。研究者写“入排标准”初稿时需要参考历史方案或者其他项目的同类标准。Agent 去知识库检索相似方案条款返回多个参考并标注出处研究者直接引用或修改。这个场景不需要跨数据服务也是上线最早、表现最稳定的功能。场景二受试者快速筛选。研究者给定一组筛选条件Agent 转换为受试者画像查询匹配的平台接口返回候选受试者及其临床特征列表再回链到方案入排标准逐条核对。这个场景要特别小心时间范围维度入排标准里“4周内未接受过某类药物”“筛选期内新出现的检查异常”都涉及时间窗口和用户产生歧义。我们的经验是必须在交互层让用户确认时间范围的默认口径不能由模型自行假设。场景三数据质询与差异分析。监查员发现某中心不良事件上报率异常偏低Agent 可以拉取该中心与其他中心的不良事件率和特征分布在解读里给出“某中心 AE 上报率低主要出现在某一类事件”的中性结论而不是直接给一个可能导致误读的单点数字。这个场景对“结论边界”的要求极高我们特意在 Prompt 里限制了判断性语言模型只允许描述事实与差异不做归因判断。4.4 提示词设计的医学化约束通用大模型在医学场景里很容易“嘴上没把门的”因此提示词里必须做几类约束。一是不允许模型凭记忆输出临床建议凡涉及医学判断的内容必须基于检索到的知识原文否则明确回答“未找到对应信息”。二是不允许模型在数据结果之外加戏数据查询结果显示“3 例”模型解读时只能解释统计口径不能扩展到“入组速度偏慢”这类推断。三是不允许模型告知“应该”如何诊断或治疗平台定位是信息整理和证据检索不是临床决策支持。这条约束不是一句简单的“请基于以下上下文回答”能实现的需要在多轮对话里反复强化。我们一开始只在系统提示里写了一次后来发现部分查询里模型还是会输出自主发挥的建议于是又在每个工具的返回前插入了统一的“回答边界”模板并且在测试集里专门加入“诱导性提问”来验证约束是否生效。4.5 效果评测机制平台不能只靠感觉调优任何做 Agent 平台的团队都必须建立评测集评测集不一定要多但必须贴合真实业务。我们内部维护了一套约两百条的问题集覆盖知识问答、数据查询、混合问题三类按季度做回归测试。评分维度有四块答案无幻觉、引用来源准确、数据口径正确、用户体验满意度。前两个维度由医学编辑人工打分数据口径可以自动化比对用户满意度用线上反馈抽样评测。这套评测机制上线后迭代速度明显加快因为你可以明确知道某一次模型替换、某个分块参数调整是变好了还是变差了而不是靠领导拍脑袋。评测集里一定要包含大量“边界问题”比如问题里漏了项目名称、问题里带模糊时间词“最近”、问题同时涉及数据和知识但用户没有说清楚。这些问题不是为了刁难模型而是为了逼平台把交互引导做得更好降低实际使用中的误解。5. 常见坑与排查实录5.1 检索结果相关度低错答连带出现现象用户问“入组标准”系统给出一堆与“排除标准”相关的内容。排查后发现分块时把“入选标准”和“排除标准”两个小节切到了同一个语义块里检索阶段无法区分。解决方式在分块元数据里增加“条款类型”标签并把它作为重排阶段的过滤条件同时在块级标题里强制保留原文档的小节标题。这个坑在方案类文档里非常典型因为入选标准和排除标准往往紧邻且同一个页面可能同时包含两类条款。任何做医疗文档切块的人都建议在分块策略里就考虑条款语义归属而不是等检索出错再去改。5.2 Agent 反复调用同一个数据接口导致慢查询现象用户问一个稍复杂的问题Agent 把它拆成多个子查询其中有三个子查询落到同一个大表上每次都要扫描数百万行最终接口超时报错。解决方式给数据服务加查询结果缓存同一项目下同一参数且数据版本不变时直接复用缓存同时给 Agent 加“合并重复调用”的规则在工具层面对相同参数做去重。这条其实属于 Agent 落地最常见的工程问题之一模型不会考虑数据库压力。如果不在中间层做限流、缓存和合并生产环境分分钟被打挂。5.3 权限边界被模糊查询绕过现象某角色只能看到汇总指标但通过构造“列出这些数字涉及的主要不良事件类型”这类问题模型会把明细字段拼进返回结果。排查后发现查询接口的列白名单只限制了 SQL 查询字段但没有限制模型的上下文模型拿到明细数据后在回答里做了转述。解决方式分两步数据服务返回结果时即使内部查到了明细字段对外输出也要按角色权限裁剪字段而不是把完整结果交给模型同时模型侧再做一次“输出边界校验”如果返回内容里出现了未授权字段名系统会在接口侧直接拦截并提示“该字段不在您的可见范围内”。不要低估模型的“翻兜能力”模型很擅长把接口里的关联字段通过自然语言带出。权限裁剪最好放在数据服务层就完成而不要在模型层做后置校验。5.4 知识时效性混乱导致新旧版本混答现象用户问“当前方案的入排标准”系统召回了两个版本的方案模型综合了新旧版本的内容。排查后发现元数据里的版本号在分块过程中丢失了只有文档级版本没有传递到块级。我们在向量化流水线里补上了“版本号全链路传递”每一步都校验块级元数据是否完整。另外还增加了“发布状态过滤”只允许查询“已发布”且“当前有效”的组合。版本问题在临床场景是红线问题宁可不出结果也不能给错版本的结果。建议每个检索结果都展示文档版本号和生效日期让用户一眼就能判断依据是否适用。5.5 模型幻觉数据明明查到了解读却跑偏现象数据查询返回“入组 17 例”模型在解读时写了一句“入组进展良好”。这就是幻觉平台没有业务依据判断“良好”与否。解决方式在生成提示词里加入“事实与解释分离”的结构事实部分由模型复述数据服务返回的字段解释部分只允许写统计口径、对比值和变化趋势禁止写评价性措辞。另外还加了一道人工抽查每个月随机抽取一定比例的问答记录医学编辑标记模型是否越界。出现越界时把样本加入评测集形成闭环修正。靠技术手段很难 100% 消除幻觉但用“约束抽查评测回归”三件套可以把发生率压到可控范围。做完整套平台我再多聊几句这套平台从前期的流程梳理到正式上线前后迭代了将近九个月。耗时最长的不是模型调优而是“业务知识的结构化”和“数据字典的统一”这两件事看起来不起眼却是决定平台上限的地基。回顾整个过程我个人有几点很真实的体会。先说知识库不要迷信越大的分块越好也不要迷信纯向量检索能搞定一切混合检索结构化元数据版本控制这三件套缺一不可。再说数据服务接入能力做得再花哨都不如把字段口径梳理清楚和把权限边界守住来得实在所谓数据中台本质上是数据字典和审计日志的中台。最后说 Agent模型的能力会快速迭代但工具调用链路和评测集才是长期资产。只要工具设计得足够清晰、评测集足够准未来换更强的模型系统效果自然水涨船高。如果在临床研究信息化或者医疗知识库方向你正在做类似的事情建议先从某一个具体场景切入不要一上来就画一个大而全的平台。选一个高频、边界清晰、效果能量化的场景比如方案条款检索辅助先把知识库这半边跑通再逐步叠加数据链路。跑通之后你会发现业务方对 Agent 的信任感是线性上升的后面的推广会顺很多。