tmpjx33ds0q

AI辅助受试者招募：纳排标准匹配为什么比广撒网更重要

受试者招募系统最容易踩坑的地方，不是“找不到人”，而是给研究协调员推送了太多无效名单：纳入条件没核对完整、排除条件被漏掉、病历字段含义不一致，最后还是要人工反复回看。本文只讨论技术架构和工程流程示例，不提供诊断、治疗、分诊或用药建议；文中阈值和规则均为示例，真实项目必须由研究团队、医疗专业人员和机构规范确认。

问题背景：名单多不等于招募效率高

在一个受试者招募后端里，常见输入有两类：试验方案中的纳排标准，以及候选患者的结构化或半结构化记录。早期系统如果只按关键词检索，例如把“年龄”“既往用药”“实验室检查”拆成几个查询词，很快会得到一个看似很大的候选池。

问题出在初筛环节。协调员打开列表后，经常发现候选人只是命中了某个宽泛词，但关键条件没有满足；或者某条排除标准藏在自由文本备注里，系统没有识别。技术上看，这不是检索召回不足，而是匹配链路缺少“规则优先、语义补充、证据可追溯”的设计。

一个更可控的目标是：系统输出的不是“可能相关的人”，而是“每条纳排标准的匹配状态、证据位置、置信度和待人工确认点”。

技术目标与边界

本文实现一条简化后端链路，技术栈为 Python、FastAPI、Elasticsearch、PostgreSQL 和 LLM API。核心目标包括：

• 将纳排标准解析成可执行条件
• 对结构化字段先做规则匹配
• 对自由文本做语义匹配和证据抽取
• 将结果写入 PostgreSQL，供人工复核
• 暴露 FastAPI 接口，方便前端或任务系统调用

需要强调边界：自动匹配只服务于人工初筛，不能替代研究团队对入组资格的判断。系统也不应把示例规则包装成医学结论，所有配置都应经过项目方确认。

方案概览：规则引擎在前，语义匹配在后

推荐链路如下：

规则引擎适合处理年龄、性别、日期范围、明确数值、已确认状态等字段。语义匹配适合处理自由文本中的描述，例如“曾参加过类似研究”“近期接受过某类干预”等，但这类结果必须给出原文证据和人工确认标记。

Elasticsearch 用来做候选记录检索和文本证据召回，PostgreSQL 保存试验配置、候选人索引、匹配结果、人工复核状态。LLM API 只参与标准解析辅助和证据抽取，不直接决定最终入排。

数据模型设计：别只存一个分数

很多初筛系统只给候选人一个总分，后续解释成本很高。更稳妥的做法是按标准逐条保存匹配状态。

建议 PostgreSQL 至少保留这些实体：

• trial_criteria：标准原文、标准类型、结构化表达式、版本号
• candidate_profile：候选人脱敏标识、结构化字段、更新时间
• match_result：候选人、标准、状态、证据、置信度、是否需复核
• review_task：复核人、复核结论、备注、时间戳

状态可以设计为matched、not_matched、unknown、need_review。其中unknown很重要，它表示数据不足，而不是不符合。

核心实现：一个可运行的匹配骨架

下面示例只演示工程结构，不代表任何真实试验规则。年龄范围、时间窗口、风险标记等都应按机构规则配置。

fromenumimportEnumfromtypingimportAny,Dict,List,OptionalfromfastapiimportFastAPIfrompydanticimportBaseModel app=FastAPI(title="Trial Recruitment Matcher Demo")classMatchStatus(str,Enum):matched="matched"not_matched="not_matched"unknown="unknown"need_review="need_review"classCriterion(BaseModel):id:strtype:strfield:Optional[str]=Noneoperator:Optional[str]=Nonevalue:Optional[Any]=Nonetext:strclassCandidate(BaseModel):id:strfields:Dict[str,Any]notes:List[str]=[]classCriterionResult(BaseModel):criterion_id:strstatus:MatchStatus evidence:strconfidence:floatdefeval_rule(criterion:Criterion,candidate:Candidate)->CriterionResult:ifnotcriterion.field:returnCriterionResult(criterion_id=criterion.id,status=MatchStatus.need_review,evidence="无结构化字段，进入文本证据核对",confidence=0.3)actual=candidate.fields.get(criterion.field)ifactualisNone:returnCriterionResult(criterion_id=criterion.id,status=MatchStatus.unknown,evidence=f"字段{criterion.field}缺失",confidence=0.0)ok=Falseifcriterion.operator=="between":low,high=criterion.value ok=low<=actual<=highelifcriterion.operator=="eq":ok=actual==criterion.valueelifcriterion.operator=="gte":ok=actual>=criterion.valueelifcriterion.operator=="lte":ok=actual<=criterion.valuereturnCriterionResult(criterion_id=criterion.id,status=MatchStatus.matchedifokelseMatchStatus.not_matched,evidence=f"{criterion.field}={actual}, rule={criterion.operator}{criterion.value}",confidence=0.95)defsemantic_check(criterion:Criterion,candidate:Candidate)->CriterionResult:joined_notes="\n".join(candidate.notes)ifnotjoined_notes:returnCriterionResult(criterion_id=criterion.id,status=MatchStatus.unknown,evidence="无可检索文本记录",confidence=0.0)# 生产环境可替换为 Elasticsearch 召回 + LLM API 抽取证据hit=any(tokeninjoined_notesfortokenincriterion.text.split()[:3])returnCriterionResult(criterion_id=criterion.id,status=MatchStatus.need_reviewifhitelseMatchStatus.unknown,evidence=joined_notes[:200],confidence=0.55ifhitelse0.2)@app.post("/match")defmatch_candidate(criteria:List[Criterion],candidate:Candidate):results=[]forcincriteria:ifc.type=="structured":results.append(eval_rule(c,candidate))else:results.append(semantic_check(c,candidate))include_ok=all(r.statusin[MatchStatus.matched,MatchStatus.need_review]forrinresults)has_review=any(r.status==MatchStatus.need_reviewforrinresults)return{"candidate_id":candidate.id,"pre_screen_status":"review_required"ifhas_reviewelse("potential_match"ifinclude_okelse"not_match"),"results":results}

运行时可以先用uvicorn main:app --reload启动，再通过接口提交标准和候选记录。真实项目中，接口层不应直接访问明文敏感数据，候选人标识、日志和导出结果都要按机构安全策略处理。

Elasticsearch 负责召回，不负责最终判断

自由文本证据可以先写入 Elasticsearch，例如按候选人 ID、记录类型、时间、文本内容建索引。查询时不要只用一个宽泛 query，建议把每条标准拆成独立检索任务。

一个常见做法是：

• inclusion 标准优先查找支持证据
• exclusion 标准优先查找风险证据
• 每条命中都保留文档 ID、字段名、时间和片段
• LLM 只基于召回片段输出“是否相关”和“证据句”

这样可以避免模型凭空判断，也方便复核人员回到原始记录。对于排除条件，系统宁可输出need_review，也不要在证据不足时给出确定性结论。

人工复核队列怎么设计

自动匹配的价值主要体现在排序和减负。候选人进入复核队列时，前端不应只展示一个总分，而应按纳排标准展开：

• 哪些标准已由结构化字段命中
• 哪些标准缺少数据
• 哪些标准来自文本证据
• 哪些标准需要研究团队确认
• 哪条证据导致候选人被暂时排除

复核结论还应回写系统，用于修正规则配置、字段映射和提示词模板。例如某类文本总被误判为相关，可以在 Elasticsearch 查询词或 LLM 抽取提示中增加排除条件。

踩坑记录：比模型更麻烦的是数据口径

第一类问题是字段口径不一致。同一个概念可能来自不同系统字段，单位、时间点、更新频率都不同。解决方式不是让 LLM 猜，而是建立字段映射表和单位转换层。

第二类问题是纳排标准版本变化。试验方案修订后，旧结果必须能追溯到旧版本标准，否则复核记录会失去审计价值。trial_criteria表建议保存版本号和生效时间。

第三类问题是“未记录”被误当成“不符合”。工程上必须区分unknown和not_matched，否则会把数据缺失包装成排除理由。

性能与扩展建议

在小规模试点中，可以同步调用规则引擎和文本检索；候选人规模扩大后，建议改成任务队列。结构化规则匹配通常很快，瓶颈多在 Elasticsearch 查询、LLM API 延迟和人工复核页面加载。

可优先做三件事：

• 对稳定标准生成缓存键，避免重复解析
• 对候选人记录按更新时间做增量匹配
• 对 LLM 抽取结果保存证据哈希，文本未变化时不重复调用

如果需要灰度上线，可以先只启用“纳入标准结构化匹配 + 排除标准人工提示”，再逐步加入文本证据抽取。这样风险更可控，也更容易被研究团队接受。

总结

AI辅助受试者招募的关键，不是把候选名单尽量做大，而是把纳排标准逐条核对清楚，并把证据、状态和不确定性留给人工复核。规则引擎适合承担确定性判断，Elasticsearch 适合做证据召回，LLM 适合辅助解析和片段抽取，但最终资格判断不能越权交给系统。

下一步可以从一个试验、十几条标准、少量脱敏候选记录开始验证，先跑通标准版本管理、匹配结果解释和复核闭环。等流程稳定后，再考虑批量任务、缓存、监控和权限审计。

本文文献检索、文献挖掘以及文献翻译采用的是【超能文献| AI文献检索|AI文档翻译】。