企业官网建设流程全解析

1. 先拆解：这个平台到底解决什么问题

1.1 临床研究里的文档海洋与数据孤岛

我刚接触临床研究数字化那几年，最大的感受是：干这行的同事都在跟两样东西搏斗——文档和数据。

文档方面，一个三期项目从头到尾要经历方案撰写、病例报告表（CRF）设计、数据管理计划（DMP）、统计分析计划（SAP）、医学编码、SAE一致性核查。每一步都关联着几十份文件：研究方案、注释CRF、中心操作手册、监查计划、SOP、行业标准、监管问答，有些文件还有版本号，昨天刚更新了一版，今天又出了勘误。这些文件散落在共享盘、邮件、网盘、OA系统里，你问一个人“上次方案修订把主要疗效指标改成什么了”，他得翻半天。

数据方面更头疼。临床数据分布在电子数据采集系统（EDC）、中心实验室数据、安全性数据库、外部影像数据等多个来源。字段命名各不相同，单位有时不统一，同一受试者在这个库里叫SUBJID，在另一个库里叫PATIENT_ID。数据质量规则每个项目都有一套，清质疑靠人工一条条点，医学编码靠人工一个个查词典。这不是某一家的问题，是全行业长期存在的效率瓶颈。

所以当我们决定做临床研究AI Agent平台时，很清楚一件事：大模型不是这个平台的重点，真正决定成败的，是知识库和数据服务这两个底座。Agent再聪明，没有可靠的知识供给和数据通路，就是个空有口才但没有专业能力的实习生。

1.2 AI Agent在这里到底扮演什么角色

这套平台里的Agent，不是那种陪聊机器人。它是“数字临床研究助理”，能接收真实业务任务，然后自己拆解步骤、调用工具、检索知识、读数据、生成结果。典型的任务包括：

• 回答方案相关问题：“这个研究的主要终点是什么？次要终点有哪些？”
• 辅助生成质疑：“请筛查第12号受试者从第2个访视到第4个访视之间白细胞计数超过正常范围上限的记录”
• 协助医学编码：“根据标准术语词典，给这些不良事件文本给出编码建议”
• 一致性核查：“对比EDC里的原始记录与安全性数据库里的SAE描述，找出不一致的地方”

这些任务如果让通用大模型直接做，结果会很难看。它既没有准确的方案内容可依，也不了解数据字段的具体定义，更不能保证隐私合规地访问数据库。Agent要完成这些任务，必须有两个基础设施：一是知识库，给它提供准确的领域知识和项目背景；二是数据服务平台，给它在安全边界内取数、算数、验数的接口。

所以说白了，知识库和数据服务平台就是Agent的“大脑记忆”和“工作通路”。没有这两个，Agent再好的推理能力也只是空中楼阁。

1.3 为什么不能只靠通用大模型硬扛

可能有人会问：现在大模型不是挺能打的吗，直接喂给它几个Prompt不就行了？

这个念头我一开始也有过。但在临床研究这种场景里，通用大模型有几个硬伤绕不过去。

第一是幻觉。大模型没有确定性的知识边界，遇到没学过的内容就会“脑补”。我问它“某项目方案里规定血红蛋白低于多少算不良事件”，它很可能按常识编一个60g/L出来，而实际方案里写的是80g/L。这种错误在临床场景里是不可接受的。

第二是时效性。临床研究的方案、手册、法规要求是在不断更新的，大模型的训练数据永远滞后。今天刚出的方案修订版，大模型不可能知道。它必须实时从知识库里检索最新的、可溯源的文档片段。

第三是数据和隐私边界。让大模型直接访问数据库、直接查受试者的原始信息，风险极高。它可能不知道哪些字段能看、哪些字段需要脱敏，也不知道该用哪个数据标准去读表。数据服务层存在的意义，就是把这种直接暴露变成可控的接口调用，让Agent拿到的每一份数据都经过权限校验、脱敏处理和格式标准化。

我们曾经做过对比：让同一个Agent在“裸奔”状态下回答方案问题，正确率只有六成左右，而且答完还振振有词。挂上知识库后，正确率提升到九成以上，关键是每一次回答都能给出参考文献片段，业务人员能核实、能溯源。这就是知识库和数据服务平台价值最直观的体现。

2. 知识库层：Agent的“专业大脑”怎么搭

2.1 知识来源盘点与分类治理

建知识库的第一步，永远不是选数据库，而是搞清楚你要吃进去哪些文档、这些文档长什么样。

我们在实际项目中把知识源分成四类：

• 结构化标准类：行业标准术语集、标准数据集模型、编码词典。这类内容条理性强、字段固定，适合直接解析成结构化表或JSON。
• 半结构化流程类：SOP、工作指引、核查清单。这类内容有章节、有标题、有编号，适合按文档结构切片后做段落级索引。
• 非结构化项目文档类：研究方案、注释CRF、数据管理计划、统计分析计划。这是Agent最常检索的内容，也是价值最高的知识来源，但格式千差万别，PDF转出后经常出现表格错位、页眉页脚干扰。
• 问答积累类：历史项目的常见质疑、监管问答、内部FAQ。这类内容最贴近真实使用场景，直接切成问答对存效果反而比存原文好。

分类治理的意义在于：不同类型内容更适合的切分策略完全不同。如果你把一份方案PDF当成一个纯文本块直接丢进去，出来的知识库检索效果基本等于没有。我们踩过这个坑，后面细说。

处理流程上，我们走的是这么一条流水线：文档收集 → 格式转换 → 清洗去噪 → 元数据打标 → 结构解析 → 切分 → 嵌入 → 索引 → 人工抽检。这里面最容易被忽略的是元数据打标。每一个知识切片都带着项目代号、文档类型、版本号、生效日期、所属模块这些标签，后面做权限过滤和时效控制全靠它们。

2.2 切分、嵌入与混合检索的关键参数

知识库切片这件事，听起来简单，做起来全靠细节。我们试过固定长度切分，比如一刀切512个字符，结果就是方案里的一个表格被拦腰截断，上下文完全丢失，检索时明明相关但就是匹配不上。

后来改用结构感知切分：先按文档的标题层级做递归拆分，遇到表格按行重组成逻辑块，遇到列表保持列表完整。每个切片的长度控制在500到800字符之间，相邻切片保留100到200字符的重叠区间。重叠区间的意义在于避免“切点正好落在关键句中间”导致信息断裂。这样切完，一个两百页的研究方案大概会产生两三千个知识切片，每一条都带着来源页码和所属章节。

切完之后就是嵌入。嵌入模型的选择直接影响检索效果，我们对比过几个常见的开源文本嵌入模型，最终选了在医学术语上表现较好的一个。需要提醒的是，嵌入向量的维度不是越大越好，维度越高存储和检索成本越高，而且在数据量不够大的场景下提升有限。

检索方面，我们用了混合检索，不再是单纯向量检索。原因很简单：向量检索擅长语义召回，但临床文档里充满了大量缩写、编号、药品名，这些东西的精确匹配能力反而不如传统的关键词检索。比如检索“ALT”这个词，向量检索可能把“丙氨酸氨基转移酶”的片段带出来，但如果你要的是“ALT”这个字段在CRF里的位置，BM25式的关键词检索会更精准。我们线上的配置是向量检索和关键词检索并行召回，各自取Top 50，合并去重后用重排序模型精排，最后取Top 5作为上下文窗口喂给大模型。效果非常明显，后面我会放对比数据。

2.3 版本管理、权限与知识溯源

知识库做得再大，如果没有版本管理和溯源机制，就等于没有。这是我做这个项目最深刻的体会。

版本管理的核心是“每一份知识切片都要有生命状态”。我们的知识切片里有三个关键字段：生效时间、失效时间、状态。状态可以是草稿、已生效、已归档。检索的时候必须过滤掉已归档和未生效的内容。不然就会出现这种情况：方案第3版已经删掉了某个次要疗效指标，但Agent还在按第2版的旧知识回答问题。一开始我们没加这个过滤，上线第一天就翻车了，业务同事直接甩截图过来：这答案是上个月的方案，早改了好吗。

权限控制也不能马虎。临床研究里的文档是有保密等级的，方案、未披露的分组信息只有特定角色能看。我们在知识检索服务里做了角色级的权限过滤，不同角色调用同一个检索接口，返回的内容范围不一样。比如数据管理员可以检索到数据清理SOP和质疑指南，但看不到统计师的盲态审核报告。权限过滤在切片的元数据层级就完成了，而不是在用户界面层做隐藏，这样更安全。

溯源是Agent回答可信度的最后一道防线。我们的Agent每次引用知识库内容，都要在回答里附上来源片段、文档编号、版本和页码。业务人员点击就能看到原文对应位置。这样做还有一个额外好处：当Agent答错时，通过溯源可以快速定位是知识库内容本身错了、检索排到错误内容了，还是大模型推理偏离了，排查效率高很多。

3. 数据服务层：让Agent安全地拿数据

3.1 数据来源与统一视图

知识库解决了“懂不懂”的问题，数据服务层要解决的是“拿得到”和“拿得对”的问题。

临床研究的数据源远比外人想象的复杂。核心数据在EDC里，按访视录入；实验室数据由中心实验室回传，格式是固定的电子文件；安全性数据在药物警戒系统里；还有外部的影像评估数据、生物样本检测数据。这些数据源之间的字段命名、日期格式、单位体系完全不同。

我们做了一个统一数据视图层，相当于在原始数据源和Agent之间加了一个中间层。这个视图层做的事情是：从各数据源抽取原始数据，清洗后映射成一套统一的标准字段，包括受试者编号、实际年龄、性别、访视名称、计划日期、实际日期、检测项编码、检测值、单位、正常值范围、异常标记、原始记录ID。这样Agent通过接口拿到的数据永远是结构一致、语义清晰的，而不是某个数据库里没人看得懂的原始表。

做统一视图层最花时间的不是技术，而是字段映射规则的确认。我们光是定义“检测项编码”这一个字段的映射规则，就开了三场跨部门评审会。因为不同数据源里同一检测项可能有不同代码，比如“血红蛋白”在EDC里叫HGB，在实验室数据里叫Hb，单位还不一样。这些映射规则如果错了，后面Agent拿到的所有数据都是错的，属于地基性错误。

3.2 API优先，而不是让Agent直连数据库

关于Agent怎么取数这件事，团队内部有过激烈争论。有人说，让Agent直接写SQL访问数据仓库不就行了，现在大模型生成SQL能力很强。我坚决反对。原因有三个。

第一是安全审计问题。Agent直连数据库，你没法控制它查什么字段。它可能为了回答一个简单问题，顺手把整个受试者表拖出来，这在合规上完全不可接受。我们要求每一次数据访问都要有审计日志可追溯：谁调用的、通过哪个接口、查了哪个受试者、用到哪些字段。直连SQL做不到这种粒度。

第二是数据语义问题。业务人员问Agent“最近一次访视的受试者有多少”，这句话如果让Agent自己写SQL，它得先理解“最近一次访视”在数据表里是怎么定义的：是计划日期还是实际日期？只有最近完成的访视才叫这次？这些在接口层封装成明确逻辑后，Agent根本不用纠结，一个参数传进去就行。

第三是稳定性问题。生产数据库的查询超时、并发控制、结果集大小限制，如果让Agent生成的SQL来管理，早晚出事。有一次测试时Agent生成了个笛卡尔积的查询，直接把开发库搞到卡死。从那以后我们就定了规矩：Agent只能调用我们定义好的数据服务API，不允许直接接触数据库连接。

平台上一共封装了十几个核心接口，比如按受试者查询访视时间表、查询检测结果、查询不良事件记录、按条件筛查疑点数据、统计入组进度、生成数据质量报告。每个接口都带参数校验、权限校验和返回行数限制。Agent从接口拿到JSON数据后，再根据任务需要做整合和推理，这样整个链路干净又可控。

3.3 数据质量规则引擎与派生逻辑

数据服务层不只是取数，它还要承担数据质量判断和派生指标计算的职责。这些逻辑放在数据服务层而不是让Agent自己做，能保证一致性和可复用性。

规则引擎这块，我们把常见的数据核查规则做成了可配置的规则集。比如缺失值检查、超出正常值范围检查、访视窗口超窗检查、逻辑矛盾检查（男性受试者不可能有妊娠相关记录）、单位换算一致性检查。Agent要生成质疑时，调用这些规则接口就能拿到结构化的疑点列表，再结合知识库里的质疑编写规范生成质疑文本。

我举一个实际例子：某项目里，受试者使用某降糖药物，方案规定每三个月测一次糖化血红蛋白，结果第5号受试者在第3访视时漏录了，系统当天没有提醒，过了两周数据录入员也没注意到。规则引擎会定时扫描，发现漏录后生成一条记录：“第5号受试者第3访视糖化血红蛋白缺失，超出预计检查日期15天”。Agent接到的任务是“生成质疑”，于是它从知识库里找到该项目的质疑模板，结合漏录记录生成一条措辞规范、有据可依的质疑文本，再由数据管理人员审核后发出。

派生逻辑也放在数据服务层。比如肾小球滤过率估算值，不同方案用的计算公式不一样，有的用标准公式，有的用中国人群修正公式。我们把这些规则做成服务，Agent需要的时候直接调用，而不是自己根据某一次Prompt的内容临时计算。这样能避免同一个指标在不同任务里被Agent用不同公式算出来结果不一致的尴尬。

数据脱敏是最后一道闸门。所有覆盖受试者隐私的字段，在接口返回给Agent之前都做了处理。姓名、住址、电话号码这些字段默认不返回，只有授权角色在特定场景下才能看到假名化之后的数据。Agent拿到的受试者编号是统一重编码后的标识，即使回答内容被截屏流出，也无法直接对应到真实患者身份。

4. 实操记录：选型、配置与效果

4.1 技术栈选择与部署形态

平台的技术栈，我按“模型层、知识层、服务层、编排层”四层来说明。

模型层用的是通用大模型做对话推理和任务规划，再搭配一个专业的小模型做重排序。为什么不用一个模型跑到底？因为重排序这种任务对语义精细度要求高，但不需要那么大参数量，专门的重排序模型又快又准。对话主模型放在私有化环境里，数据不出域，这是满足临床数据合规要求的前提。

知识层我们选了主流的向量数据库，选型时核心比较的是三个能力：数据量扩展性、元数据过滤性能、权限集成便利性。我们需要能支撑几十万级知识切片，并且能够在检索时根据角色权限做标签过滤，很多向量库在过滤条件复杂时检索性能会明显下降，这个要实测，不能只看宣传参数。

数据服务层用了独立的服务节点，和业务系统的数据库分开部署。接口统一走内部服务总线，所有调用都有日志。Agent的编排框架我们自己搭了一套轻量级的工具调用链，核心功能是：任务拆解、工具注册、上下文管理、用户确认节点、审计日志。说白了就是让Agent可以按规划好的步骤去调用知识库和API，而不是自由发挥横冲直撞。

4.2 知识库检索效果的关键配置实测

直接上数据。我们在同一个测试集上对比了三种检索策略，测试集包含80个基于某降糖药物三期方案整理的问答对，全部由资深数据管理员审核过标准答案。

这个结果很有说服力。混合检索带来的提升主要靠关键词兜底，尤其是处理方案里的编号、缩写、具体数值这类精确信息；重排序则解决了“召回的内容相关但不够精确”的问题，把最关键的知识片段推到最前面。

其他几个关键参数也分享出来：检索召回数设为Top 20，重排序后保留4到5个切片作为上下文。相关性阈值设为0.45，低于这个分数的知识片段宁可不用也不硬塞给Agent。上下文窗口里知识切片的总长度控制在1500字以内，超出部分Agent就有点迷失了，容易答非所问。

4.3 数据服务接口与Agent任务实测效果

我们再看看Agent结合数据服务后的实际任务效果。选了三个任务：方案信息查询、质疑生成、SAE一致性核查。

方案信息查询的测试方式是随机抽了30个方案相关问题，包括主要终点、入选排除标准、给药方案调整规则。传统做法是人工翻PDF，平均每题耗时6到8分钟；Agent挂了知识库后，平均检索加回答时间为15秒，准确率92%。虽然人工答案更高一点，但效率差距实在太明显。

质疑生成是更考验综合能力的任务。传统方式是数据管理员逐个筛选疑点数据，再手工编写质疑措辞，平均每条质疑需要8分钟左右，而且不同人的措辞风格不一致。我们让Agent先通过规则引擎接口筛出疑点，再结合质疑SOP的知识片段生成质疑初稿，人工审核后发出。实测下来，一条质疑从发现到生成初稿压缩到90秒以内，措辞统一度也明显提升。这里必须强调，质疑生成不是全自动，必须有审核节点，临床场景里不能允许AI直接对外沟通。

SAE一致性核查这个任务最有代表性。传统做法是数据管理员把EDC里的原始记录和药物警戒系统的SAE报告打开两个屏幕，逐字段比对，一个项目几十个SAE通常要忙两天。我们通过数据服务层把两边的数据标准化后统一输出，让Agent自动比对方案编号、不良事件名称、开始日期、结束日期、严重程度、因果关系这些关键字段，生成差异清单。第一批测试的47个SAE，Agent跑完用时不到20分钟，识别出5个字段不一致，人工复核后确认其中4个是真差异、1个是日期格式不同导致的误报。这个效率差距让很多原本犹豫的同事都开始主动使用平台了。

5. 上线踩坑实录与排查速查表

5.1 三个被翻来覆去问到的坑

我们平台上线后，内部支持群里问得最多的问题来来回回就集中在几个坑上，我觉得非常有代表性，专门拿出来说。

第一个坑是PDF表格被切碎导致检索失效。这个坑我们前面提到过。某次有人在知识库里搜“某方案的实验室正常值范围”，Agent的回答里引用的表格数据断行少列，数值完全对不上。排查结果发现，那段知识切片是从PDF转换后按固定字符数硬切的，原表格被拦腰切断，换行符被当成了普通字符。后来我们把所有方案类文档的解析流程改成“先还原表格结构，再按表格块切分”，同时保留表头作为切片的元数据。修完之后再检索，正常值范围的召回效果立刻正常了。

第二个坑是Agent生成的数据查询请求绕过权限。我们的Agent有自然语言转接口调用的能力，一开始工具注册时参数太宽松，用户问一句“看看某受试者最近的情况”，Agent可能会试图调取那个受试者的全部历史记录接口，返回的数据量远超正常需要。虽然脱敏后不涉及身份信息，但这种行为一旦成为日常，迟早出问题。我们后续加了两个限制：接口的默认返回字段不能超过任务合理需要，最多返回200行记录；涉及超出权限范围的查询时必须向用户确认，并记录审计日志。改完之后这套行为规范多了。

第三个坑是知识库版本跟花里胡哨的元数据策略打架。同步新版方案时，文档编号变了，但文件里的内容结构和上一版几乎一样。如果只按文档编号过滤，新版知识切片生效后，旧版切片并没有被彻底停用，Agent会同时检索到新旧两版的内容，回答时前面引用新版、后面又漏出旧版的语句，非常混乱。解决办法是在切分阶段就把版本信息固化到每条切片里，并在检索时强制过滤当前生效版本。这个过滤逻辑一定要在服务端做，不能依赖提示词约束。我们一开始想偷懒，想用Prompt告诉Agent“只使用有效版本”，结果它偶尔还是会用错，后来老老实实改成服务端过滤，问题才真正消失。

5.2 知识库与数据服务的常见问题速查表

我把平时支持中遇到的高频问题整理成了一张排查表，给团队内部用着挺顺手。有类似环境的同行可以直接参考。

这八条基本覆盖了平台上线后最常见的求助场景。很多时候问题不在大模型本身，而在它背后的数据和知识管道。

做这套知识库与数据服务平台，我最大的体会是：所谓的AI Agent平台，表面上是模型能力的竞赛，实际上拼的是工程和治理能力。一个Agent能不能在临床研究这种高严肃场景里被信任，取决于它能不能说清楚每个结论是从哪份文档哪条数据里来的，取决于它能不能在权限和合规的边界内行动。这两件事，靠提示词写不出来的，必须靠体系化的知识管理和数据服务来保证。

如果你正在规划类似的平台，我的建议很直接：别急着让Agent去回答问题，先在知识切分、版本控制、数据接口封装这些“不起眼”的地方多花时间。地基打得稳，Agent才能跑得远。