4. 检索需求分析与查询意图拆解

药物研发中的数据检索，很少以“给我一些资料”这种形式出现。真实场景往往是一句高度压缩的业务诉求，例如“帮我查一下这个靶点有没有已上市的小分子抑制剂，最好有中国专利风险提示”。这句话里同时包含了靶点实体、分子类型、研发阶段、地域范围、法律风险等多个维度，如果直接把它丢进检索框，返回结果大概率是噪声。检索需求分析要做的第一件事，就是把业务语言翻译成可检索的信息需求结构。

从研发场景识别信息需求

研发场景决定了信息需求的边界。同一个化合物，在立项阶段关心的是“有没有人做过、竞争格局如何”，在临床前阶段关心的是“毒理数据、给药方案、对照药选择”，在专利阶段关心的是“权利要求范围、同族专利、法律状态”。因此识别信息需求时，建议先定位场景，再追问四个问题：要解决什么决策、需要哪类证据、证据的时效与地域范围、可接受的召回与精度。这四个问题分别对应检索目标、数据源类型、过滤条件和评价标准。

以“评估某激酶抑制剂是否值得立项”为例，决策是“是否投入早期研发”，需要的证据包括：该靶点已有化合物的活性数据、进入临床的分子数量与阶段、核心专利的到期时间、以及是否存在难以绕开的化合物专利。时效上要求近五年为主，地域上重点关注中国、美国、欧洲。召回与精度上，专利检索宁可多召回再人工筛，活性数据检索则要求高精度，避免把不同靶点的数据混入。

任务分解：把大问题拆成可独立检索的子任务

信息需求明确后，下一步是任务分解。分解的原则是：每个子任务应当能对应到明确的数据源和检索字段，并且可以独立判断“查到了没有”。继续上面的例子，可以拆成四个子任务：

• T1 靶点与适应症确认：确认靶点基因名、蛋白名、别名、相关适应症，解决实体歧义。
• T2 化合物与活性检索：在 ChEMBL、PubChem 等数据库中检索该靶点的生物活性数据，提取 IC50、Ki 等参数。
• T3 临床与竞争格局检索：在 ClinicalTrials.gov、CDE 等平台检索进入临床的分子、阶段、申办方。
• T4 专利与法律状态检索：在专利数据库中检索化合物专利、同族、法律状态与到期时间。

分解之后，每个子任务都有清晰的输入和输出。T1 的输出是标准化的靶点标识（如 UniProt ID 或基因符号），它会作为 T2、T3、T4 的检索入口。这种“先归一实体，再分发检索”的顺序，能显著降低后续任务中的歧义。

实体识别与关系抽取

实体识别要回答“这句话里有哪些可检索对象”。在药物研发语境中，常见实体类型包括：靶点（基因、蛋白、通路）、化合物（名称、编号、结构）、适应症、研究阶段、数据指标（IC50、EC50、AUC）、专利号、申请人、临床登记号。识别时要注意同义词和缩写，例如 EGFR 与 ERBB1、Her1 指同一靶点；化合物常同时存在研发代号、通用名和 CAS 号。

关系抽取则回答“这些实体之间是什么关系”。典型关系有：化合物—靶点（抑制/激动）、化合物—适应症（用于治疗）、化合物—专利（被权利要求覆盖）、临床登记号—申办方。关系抽取的价值在于，它能把零散的实体连接成可推理的网络。例如，当检索到“化合物 A 抑制靶点 B”且“化合物 A 被专利 P 覆盖”时，就能进一步判断“靶点 B 的化合物专利风险来自 P”。

实际操作中，可以先用规则和词典做初步实体识别，再用关系模板或轻量模型抽取关系。对于教学示例，假设我们从一段摘要中识别出实体：化合物 X、EGFR、非小细胞肺癌、IC50 = 12 nM、专利 CN1234567，并抽取出关系：X 抑制 EGFR、X 用于非小细胞肺癌、X 被 CN1234567 覆盖。这些结构化结果可以直接作为后续检索的过滤条件。

查询改写与检索策略设计

查询改写的目标是把自然语言诉求转成数据库能理解的查询表达式。改写通常包括：同义词扩展、字段限定、逻辑组合、以及必要的截词或通配。例如，原始需求“EGFR 抑制剂专利”可以改写为：(EGFR OR ERBB1 OR Her1) AND (inhibitor OR antagonist) AND patent，并在专利数据库中限定 CN、US、EP 等国家代码。

检索策略设计则要决定“先宽后窄”还是“先窄后宽”。对于探索性任务，建议先宽后窄：先用宽泛的同义词组合获得较大召回，再通过阶段、时间、地域等过滤器逐步收敛。对于验证性任务，例如确认某专利是否到期，则适合先窄后宽：先用精确的专利号或申请号定位，再扩展到同族和法律状态。

下面这张图展示了一个从研发场景到检索执行的意图拆解链路。它把“业务诉求”作为起点，经过场景定位、信息需求四问、任务分解、实体与关系抽取，最终落到查询表达式和检索策略。图中同时标出了每个环节的关键输出，便于对照检查。

图中最左侧是业务诉求，它经过场景定位后，被拆成四个可独立执行的任务；中间下方展示实体识别与关系抽取的结果，这些结构化结果会作为查询改写的输入；右侧则是改写后的查询表达式和两种检索策略。整条链路的核心思想是：先理解需求，再拆解任务，然后归一实体、抽取关系，最后才写查询。跳过前面任何一步，检索都会变成碰运气。

一个可复用的检索需求分析表

为了让上述过程可操作，可以设计一张检索需求分析表。它不追求字段多，而是要求每个字段都能直接影响检索行为。以下是一个针对“EGFR 抑制剂专利风险”的示例，字段和取值均为教学假设，用于说明填写方式。

填写这张表的过程，本身就是一次需求澄清。很多检索失败，不是因为数据库不会用，而是因为需求没有被拆到可执行的粒度。把“查一下”变成“查什么、从哪查、怎么查、查到什么算够”，检索才真正开始服务于研发决策。

最后需要强调，查询意图拆解不是一次性动作。检索过程中如果发现召回结果偏离预期，应当回到“信息需求四问”重新检查：是决策目标理解偏了，还是证据类型选错了，或者是同义词扩展不足。把检索当作一个可迭代的分析过程，而不是一次性的输入输出，才能让数据检索真正嵌入药物研发的决策链条。