专利检索工程化：检索式、批处理与AI初筛流水线

1. 三天和十分钟之间差的不是手速，是检索流程被拆成了几段

先还原一个特别典型的现场。某公司的硬件团队要做一轮竞品技术盘点，领导给的活儿很干脆：把相关领域的四百多份专利过一遍，三天后给结论。接下活的工程师当天就打开检索平台，一边敲关键词一边翻页，看到标题沾边的就点进去，读摘要、读权利要求、复制编号、粘贴到表格里，再标一句"相关/不相关"。第一天结束，表里躺了六十条，眼睛已经花了。第二天开始怀疑人生，因为发现前面用的关键词漏掉了一大类表述，得回头重搜。第三天勉强凑完，交付的东西自己都不敢打包票。

这个故事里最容易被误判的一点是：大家以为慢在"读"。其实读四百份摘要并不算特别恐怖的量，真正吃掉时间的是三件事——检索式反复推倒重来、同族和重复公开反复出现、每份专利都要从零开始判断相关性。这三件事有个共同特征：高度重复、规则可描述、不需要人的创造性判断。凡是符合这三条的环节，就是适合交给机器批处理的环节。

所以标题里那个"三天 vs 十分钟"的对比，我不太愿意把它理解成"AI 比人快三十倍"。更准确的理解是：人把检索当成了一个整体动作，而工程化的做法是把它切成若干段，只把其中真正需要人的那一段留给人。切完之后，机器跑批处理的十分钟和人做判断的两小时是可以并行叠在一起的，剩下的时间差主要来自"不用重复劳动"，而不是"算得更快"。

这篇内容面向的是需要亲手做专利检索的工程师、技术情报岗、做竞品分析的研发同学，也包括那些被临时抓去做"帮我查一下有没有人做过这个"的人。不需要你有算法背景，会写几十行脚本、会用命令行、能看懂权利要求书的结构，就足够把这套流程跑起来。我会把整条链路的每一段拆开讲：哪一段交给模型、哪一段必须自己上、每个参数为什么这么定、以及我在实操里被坑过的几个地方。

提示：本文讲的是技术情报性质的检索，用于研发参考和方向判断。涉及权利状态、侵权风险的正式结论，请交给有资质的专业流程处理，工具产出的结果只作为线索。

2. 把检索拆成五道工序，才知道哪一段该交给模型

2.1 工序拆解：从"查"到"交付"其实有五个独立动作

我习惯把整个活儿拆成五段：检索式构造、批量获取、去重与同族合并、相关性初筛、人工复核与固化。拆开之后你会发现，这五段的"人力敏感度"完全不同。

检索式构造是脑力活，但可以被大幅辅助。模型很擅长做一件事：你说"我要找的是某种散热结构"，它能给你吐出二十个同义表述、近义表述、上下游表述，包括行业口语和学术书面语两套。这一段的效率提升非常明显，因为人脑想同义词想到第八个就开始卡壳了。

批量获取是纯体力活，必须交给程序。翻页、导出、字段对齐，人做这个纯属浪费。去重与同族合并也是纯规则活，机器做比人做准，因为人会漏。相关性初筛是最容易被高估的一段：模型能帮你把四百份压到六十份，但它压不准最后那六十份里哪五份是真正的关键对比文件。人工复核与固化不可替代，这一段必须留足时间。

我把这五段的实际耗时分布做了个粗略记录，样本是我自己跑过的几轮任务，仅供参考：

看这张表要抓的重点不是总时长，而是"哪些格子几乎没变"。复核那一段基本没变，说明这套东西不是用来替代判断的，是用来把判断之前的所有铺垫压扁。谁要是跟你说 AI 能直接把检索报告生成出来，那基本可以判断他没真跑过完整流程。

2.2 模型真正擅长的三件事，和它明显不擅长的三件事

把能力边界说清楚，比堆工具清单有用得多。

模型擅长的第一件事是语言层面的发散。同一个技术特征，不同申请人会写成完全不同的说法。比如一个简单的"卡扣连接"，在有的文本里是"弹性扣合"，有的是"扣位配合"，有的是"凸起与凹槽的过盈嵌合"。人工想不全，模型想得全，这是它的强项。

第二件是结构化抽取。给它一段权利要求，让它按"独立权利要求/从属权利要求""必要技术特征/附加技术特征"拆成条目，准确率在实践中是可以接受的，尤其是你给了明确的输出格式约束之后。

第三件是粗粒度分类。四百份里判断"这份跟我的主题沾不沾边"，模型的表现相当稳。注意是"沾不沾边"，不是"是不是关键对比文件"。这两件事的难度差着一个量级。

它不擅长的也很明确。第一，数值和符号。文本里的参数范围、化学式、附图标记，模型经常记串或者编造，必须回原文核对。第二，权利要求的保护范围解读。一句"所述连接件设置于所述壳体内"，到底涵盖哪些等效形态，这是需要专业训练的判断题。第三，时效性。模型的知识有截止点，而专利的公开、权利状态天天在变，所有状态字段必须从数据源现取，不能问模型。

2.3 为什么不能一步到位让模型直接出结论

有个很自然的想法：把四百份专利全文丢给模型，让它直接告诉我哪几份最重要。这个做法我试过，效果不稳定，原因有三个。

一是上下文长度和注意力衰减。四百份专利全文加起来是几十万字的量级，硬塞进去，模型对中后段内容的注意力会明显下降，排在前面的几份会不成比例地获得更高权重。这不是模型"不认真"，是机制决定的。

二是缺少可比基准。让模型自由发挥打"重要程度"，它每份都用不同的尺子。第一份它可能按技术接近度打分，第十份它可能开始按标题相似度打分。没有固定评分卡，结果没法排序。

三是不可追溯。它给你一句"第 73 份比较关键"，你没法知道它是根据哪一句判断的。而检索报告的价值恰恰在于可追溯——每个结论都要能指回原文的某一段。

所以正确的做法不是"一步到位"，而是把大任务切成小任务，每个小任务给死格式，让结果可校验。下一节讲具体怎么切。

3. 检索式怎么搭：关键词发散、分类号兜底、引证挖窝

3.1 关键词的颗粒度：太细查不全，太粗淹死人

检索式构造这一步，新手最常犯的错是关键词太"工程师"。什么叫太工程师？就是直接把自己方案里的技术名词原样敲进去。你写的是"多级梯度微流道散热基板"，检索平台返回三条结果，你还以为这个方向没人做。实际上别人写的是"分段式流道结构""阶梯流道""变截面通道"，一个词都没撞上。

我自己的做法是分三层铺关键词。第一层是核心功能词，描述"解决什么问题"，比如"散热""均温""热流密度"。第二层是结构实现词，描述"用什么手段"，比如"流道""微通道""翅片""嵌件"。第三层是场景限定词，把领域框住，比如"功率模块""电池包""服务器主板"。

这三层用逻辑运算符组合的时候，别一上来就把三层全用 AND 串起来。正确顺序是：先用第一层 AND 第二层跑一遍，看结果量级；如果量级在几百到一两千，再把第三层加上做收窄；如果量级只有个位数，说明你的第二层词太窄，回去补同义词。这个"先看量级再收紧"的习惯，能省掉大量无效翻页。

同义词表的生成可以这么操作：把核心词丢给模型，让它按"学术表述 / 行业口语 / 上游材料视角 / 下游应用视角 / 英文对应词"五个维度各出五到八个候选，然后你自己删。删的时候注意两个原则：明显跨领域的词删掉（会引入大量噪声），过于宽泛的词也删掉（比如"装置""结构"这种，加了等于没加）。我给个实际用过的提示结构，思路可以直接搬：

text复制我所在的领域是[填领域]，核心技术问题是[填问题]。
请围绕这个技术问题，从以下五个角度各给出 6 个中文检索候选词：
1) 学术论文中的规范表述
2) 工程现场的口语表述
3) 从上游材料/器件角度的表述
4) 从下游整机/应用角度的表述
5) 对应的英文表述
要求：不要给单个字的词；不要给"装置""方法"这类无区分度的词；
每个词后面用一句话说明它为什么可能出现在专利文本里。

模型给的东西一定有噪声，但它的价值在于"打开思路"，不在于"直接可用"。我一般的采纳率是三成左右，这三成往往就是我自己想不到的那部分。

3.2 分类号是查全率的地板，关键词是查准率的天花板

只靠关键词检索，查全率是没底的，因为语言表达是无穷的。分类号（国际专利分类体系里的 IPC、以及部分体系使用的 CPC）是审查员人工标注的，它描述的是"这份专利在技术体系里属于哪个位置"，跟它用什么词写无关。这就意味着，分类号能捞到大量关键词捞不到的文献。

实操上怎么找分类号？两条路。第一条是从你已经确认高度相关的那几份专利里，看它们的分类号，通常主分类号就能直接复用。第二条是用平台的分类号查询工具，从技术主题词反查对应的分类位置，再往下钻两三层。找到之后，把分类号作为一个独立的检索分支，跟关键词检索并行跑，最后合并去重。

这里有个度的把握问题。分类号给得太上位（比如只到大类），会拉进来几万份完全无关的东西；给得太下位，又会漏。我的经验是给到小类或大组这一级比较合适，然后再用关键词在里面筛。打个比方，分类号像是把图书馆的一个书架指给你，关键词是在书架上挑书。只给书架不挑书，一架子书你得全翻；只挑书不给书架，你可能压根没走到那个书架前面。

顺便说一句，分类号还有个隐藏用法：做漏检自检。你跑完关键词检索，拿到结果集之后，统计一下这些结果的分类号分布。如果发现某个分类号下集中了二三十份，而你的检索式里完全没覆盖它，那基本可以确定这里有个漏检区，得回去补检。

3.3 引证关系：从一篇好专利顺藤摸瓜挖出一窝

找到一篇特别对味的专利之后，别急着往下翻列表。看一眼它的引证文献（它引用了谁）和被引证文献（谁引用了它）。这两个方向的信息密度远高于关键词列表。

引证它的文献，通常是沿着同一条技术路线往下做的改进，技术语境高度相似。它引用的文献，往往是这条路线上的奠基性工作。我做过一次对比：同一个主题，纯关键词检索拿到 380 份，加引证扩展之后多出 90 多份，其中大概有十几份是关键词完全检索不到的——因为那些文献用的术语体系属于另一个年代，早年的表述跟现在差得很远。

引证扩展也有代价：会引入大量"形式上引证、实质上无关"的噪声，尤其是审查员引证里那种程式化的对比文件。所以引证扩展的结果不能直接进最终集，得单独打个标记，进初筛环节一起过。

3.4 检索式要留版本，别嫌麻烦

这一条听起来很琐碎，但吃过亏的人都懂。检索式一定要编号存档，每次修改都留一版，记下修改原因和结果量级变化。原因很实在：你跑到第三天突然想回到"第二天上午那个思路"，如果没有版本记录，就得凭记忆重建，而人的记忆在这种细节上极不可靠。

我自己的记录格式很简单，一张表就够：

这张表最后是要跟报告一起交出去的。一方面别人能复核你的检索逻辑，另一方面下次做类似主题，可以直接从这张表起步，省掉一半时间。

4. 四百份的批处理流水线：限速、落库、断点续跑

4.1 抓取层：先把"慢"和"稳"设计进去

批量获取这一段，很多人栽在"写得太快"。第一天兴致勃勃写个循环，几百个请求一秒钟打出去，跑到第一百多条被限流，或者直接拿不到数据。这不是平台的错，任何公共接口都有访问频率约束，这是常态。

所以抓取层的第一条设计原则是主动限速。具体做法是给每个请求之间加固定间隔，间隔取多少？我的经验值是每秒不超过一个请求，遇到大批量任务再降到每两秒一个。这个速度听起来慢，但算一下：四百份，每两秒一个，也就十几分钟。而如果因为限速被封，重来的成本远高于这十几分钟。

第二条原则是失败要能分辨。请求失败分好几种：网络超时、返回空、返回了错误结构、返回了但内容不完整。这几种必须分开计数、分开重试。混在一起只记一个"失败数"，排查的时候你会疯掉。我的做法是给每次请求记录一个状态码加一个自定义的状态标签，落在日志里，事后按标签统计。

第三条是重试要退避。失败之后立刻重试，大概率还是失败。正确的做法是等一段时间再试，而且等待时间逐次递增。连续失败超过阈值就停下来，别硬刚，先去看看是不是检索式本身有问题或者接口参数写错了。

python复制# 伪代码，只表达结构，具体客户端按你用的库替换
import time

MAX_RETRY = 3
BASE_WAIT = 2.0

def fetch_one(doc_id):
    for attempt in range(MAX_RETRY):
        try:
            resp = client.get(doc_id, timeout=15)
            if resp.ok and resp.has_payload:
                return {"id": doc_id, "status": "ok", "data": resp.data}
            # 明确区分"空结果"和"异常"
            return {"id": doc_id, "status": "empty", "data": None}
        except TimeoutError:
            time.sleep(BASE_WAIT * (2 ** attempt))   # 指数退避
        except Exception as e:
            log(doc_id, "error", str(e))
            time.sleep(BASE_WAIT * (2 ** attempt))
    return {"id": doc_id, "status": "failed", "data": None}

for doc_id in doc_ids:
    result = fetch_one(doc_id)
    save(result)
    time.sleep(1.0)   # 主动限速，别省这一行

4.2 落库字段：现在多留一个字段，将来少返工一次

字段设计这件事，属于典型的"事前十分钟，事后三小时"。我最开始只存了编号、标题、摘要，做到一半发现需要按公开时间排序筛选，又得重新抓一遍。

下面这套字段是我踩过几轮之后稳定下来的，按重要程度排：

有一点要特别强调：申请日、公开日、优先权日这三个日期不能混用。做时间线分析的时候用哪个，取决于你问的是什么问题。问"这个技术方案最早什么时候出现的"，看优先权日；问"这个方案什么时候向公众公开的"，看公开日；问"申请行为发生在什么时候"，看申请日。这三个数在一份文献里可能相差一年半以上，混用会得出完全错误的结论。这一点我在第 6 节还会展开讲。

4.3 断点续跑和幂等：跑长任务的基本素养

四百份是个不大的量，但如果你做的是几千份的盘点，中途断掉是必然会发生的事。所以从第一版脚本开始就要按"随时可以中断、重启后不重复"来设计。

幂等的实现很朴素：以文献编号为主键写库，写之前先查存不存在，存在就跳过。这样重跑一遍的成本只是多查几次库，不会产生重复记录，也不会重复消耗接口配额。配合上面那个失败状态表，续跑的时候只挑"failed"和"没跑过"的，效率最高。

另外提醒一个容易忽略的点：把原始返回也存一份。解析逻辑总会有 bug，或者你后来想多抽一个字段出来。如果原始数据没留，就得重新抓；留了的话，改解析脚本重跑一遍本地就行，几分钟的事。我现在的习惯是原始响应按编号存成单个文件，解析结果进数据库，两者分离。

5. 让模型读专利：切分、打分卡和幻觉的三道防线

5.1 切分策略：权利要求书和说明书要分开喂

一份专利文本里，各部分的信息密度差别很大。权利要求书是法律边界的表述，措辞精确但极度浓缩，一句话可能包含五六个技术特征。说明书是展开描述，信息量大但冗余多，背景技术部分经常有一半是套话。摘要信息最少，只适合做初筛。

我的切分方式是：初筛阶段只喂标题加摘要，控制单次输入长度，追求吞吐；进入细读阶段再喂权利要求书，逐条拆技术特征；只有在需要理解具体实现的时候，才去翻说明书里对应的段落。

为什么不一开始就喂全文？两个原因。一是成本，全文的长度是摘要的几十倍，四百份全喂全文，费用和时间都上去了。二是精度，长文本里噪声多，模型容易被背景技术部分的表述带偏，把"现有技术的缺陷"误读成"本方案的特征"。这个错误在实测中出现频率不低，尤其是在背景技术写得很详细的文献里。

5.2 打分卡：把"相关"这个模糊词拆成可打分的维度

让模型判断"这份专利相不相关"，得到的答案没法用。正确做法是把相关性拆成几个正交的维度，每个维度给明确的评分标准和分值范围，最后加权求和。

我常用的一套四维打分卡：

加权的时候，手段维度的权重给最高，因为专利检索的核心是找"技术方案"，不是找"技术问题"。同一个问题有几十种解法，只有手段接近的才是真正需要精读的对比文件。

这套卡子的好处是可解释。模型给出"手段 3 分"的时候，你能要求它指出是哪一句权利要求支撑这个判断，然后你回原文核对那一句。核对通过，这个分数就可信；核对不上，说明模型在这一条上出了问题，整份的可信度都要打折。

提示：打分卡一旦定下来，整批任务里就不要改。中途改标准，前后的分数就没法放在一起排序，等于白跑。

5.3 幻觉的三副面孔，和对应的三道防线

专利场景下模型的幻觉有几副特别典型的面孔，必须提前防。

第一副面孔是编造数值和范围。 原文写的是"温度 60 到 120 摄氏度"，模型可能给你复述成"80 到 150 摄氏度"。这种错误最危险，因为它看起来完全合理，不核对原文根本发现不了。防线很简单也很笨：所有数值必须回原文做字符串比对。写个小函数，把模型输出里的数字全部抽出来，去原文里找，找不到就标红。

第二副面孔是张冠李戴。 处理长文本的时候，模型有时会把 A 文献的技术特征安到 B 文献头上，尤其是在批量处理、上下文没隔干净的情况下。防线是每条结论强制带文献编号，输出格式里把编号作为必填字段，缺了就丢弃这条结果重跑。

第三副面孔是"合理化"缺失信息。 你问它某个特征的实现方式，原文里其实没写，它不会说"没写"，而是根据常识给你补一个看似合理的。防线是在提示里明确写死：原文未提及的内容，必须输出"未提及"三个字，不得推测。这句话必须放在提示的显眼位置，而且要配一个正例一个反例，模型的遵守率会明显提升。

这三道防线都不是什么高深技术，本质就是"别信模型的自述，去原文里验"。我现在的流程里，凡是模型输出的关键结论，都要过一遍自动比对，比对不上的进人工队列。这一步会多花十几分钟，但省掉的是后面被人当场指出错误的尴尬。

6. 踩过的坑：日期、状态、同族和"看起来很像"

6.1 三个日期混用，结论能偏出去一年半

前面提过一句，这里展开说。我做过一次技术演进时间线，一开始图省事，直接用了数据里默认返回的那个日期字段。图做出来之后发现有个技术分支在时间上完全说不通——某个改进方案的出现时间比它的基础方案还早。查了半天才发现，默认返回的是公开日，而基础方案是走优先权路径的，它的优先权日比公开日早了将近两年。

这件事的教训是：任何时间维度的分析，先把三个日期的定义写清楚，再动手。我的做法是在数据表里明确加三列，做分析的时候在脚本里写死用哪一列，绝不依赖"默认排序"。如果是做"某技术最早出现时间"的判断，用优先权日；如果是做"公众何时可知"的判断，用公开日。这两个问题在实践中经常被混为一谈，但实际上回答的是完全不同的事。

6.2 权利状态是会变的，缓存下来的状态等于没有

第二类坑跟时效有关。专利的权利状态不是静态的：审查中可能授权，授权后可能因各种原因终止，也可能在有效期内。你把数据抓下来存进表格，过两个月再看，那个状态字段就已经不能代表现实了。

我的处理原则是状态字段不进缓存，每次用之前现取。如果数量大、现取成本高，至少要标注清楚"该状态取自某年某月某日"，并且在使用的时候明确说明这是快照而非现状。凡是需要就"当前是否有效"下判断的场合，一律回源头核对，不用二手数据。

顺带说一句，做竞品分析的时候，很多人只盯着"有效"的专利看，把失效的全都过滤掉。这个做法有时候是亏的：失效专利里藏着大量可以直接借鉴的技术细节，因为不再有权利约束，参考价值反而更直接。我一般的做法是有效性作为筛选的一个维度，而不是一刀切的过滤器。

6.3 同族合并做过头，把不同的技术方案合成了一份

同族合并是必须做的，因为同一件发明在不同地区申请，会产出多份文献，内容高度重复。四百份里不做合并，实际可能是两百多个独立方案，阅读量虚高了一倍。

但合并这件事有个坑：同族里的不同成员，内容并不总是完全一致。有的成员在进入不同地区时，权利要求范围做了调整，有的补充了实施方式，有的删减了部分内容。如果你粗暴地"一个同族只留一份"，而且留的那份恰好是内容最简的版本，就会丢掉关键信息。

我的做法是合并但保留全部成员编号，代表文献选内容最全的那个（通常看权利要求条数和说明书篇幅），同时在表里记下这个同族还有哪几个成员。这样初筛的时候按同族算一份，需要细读的时候能顺着编号把其他成员调出来。这个细节听起来微不足道，但真到了要精确比对权利要求范围的时候，就是它能救你。

6.4 "看起来很像"是初筛最大的敌人

最后一类坑最难量化，但影响最大：标题和摘要很像，实质方案完全不同。

举个抽象的例子。两份文献标题都带"散热结构"和"均温"，摘要都提到了"提高温度均匀性"。乍看是同类方案，但一份讲的是通过流道布局改变流体分布，另一份讲的是通过相变材料吸热。这两者在技术手段上毫无关系，只有问题层面重合。如果你按"问题匹配"来筛，两份都会进来；如果按"手段匹配"来筛，只有一份该进来。

这就是为什么打分卡里"手段"的权重必须高于"问题"。也是为什么初筛的结果只能用来排序，不能用来定论。模型把四百份压到六十份，这六十份的排序是有意义的，但"排在第六十位的那份一定不重要"这个判断是不成立的。排在后段的文献里，经常藏着用词完全不同但思路非常接近的方案。

我自己的习惯是：初筛之后，除了精读排名前二十的，还会随机抽十份排名靠后的看一眼摘要。这个动作花不了几分钟，但抓到过好几次"被埋掉的关键文献"。抽样不是为了统计意义，是为了给自己一个"排序可能不准"的提醒。

7. 交付物长什么样：字段、口径和留痕

做到最后一步，交付的东西不是"四百份的表格"，而是"一份能被人直接拿去用的判断依据"。这两者的差别在于三个东西：字段是否完整、口径是否一致、过程是否留痕。

字段完整指的是每一行都能回答"这是什么、讲什么、跟我什么关系、我为什么这么判断"。我常用的交付表结构是这样的：

"技术手段摘要"那一列我坚持自己写，不用模型的输出直接填。原因很实在：这一列是整张表的信息密度所在，写这一列的过程就是你自己把方案重新理解一遍的过程。模型写的摘要语法通顺但没有重点，读的人还是得回去看原文。你自己写的一句话，能让人一眼判断"要不要看"。

口径一致指的是全表的判断标准统一。同一批任务里，打分卡不能改，术语不能换，同一个技术特征的叫法要统一。这个要求听起来基础，但多人协作的时候特别容易破功——两个人对"手段匹配 2 分"的理解可能就不一样。解决办法是在表头附近放一小段评分说明，把每一档的判定标准写清楚，谁填表谁先读一遍。

留痕指的是检索式版本、抓取时间、数据快照日期、模型版本、人工复核记录，这些都要在报告末尾附上。这不是形式主义。过两个月有人问"当时为什么没查到某某文献"，你能不能答上来，全看这些记录在不在。有过一次被问住的经历之后，我现在的报告末尾必带这一块，哪怕只有五行字。

最后分享一个我自己一直在用的习惯：每做完一轮检索，把检索式、踩到的坑、下次要改的地方记在一个单独的文件里。这个文件不交付，只给自己看。做了几轮之后你会发现，同一个领域的检索式有大量可以复用的部分，坑也高度重复。第二轮做同类主题的时候，从这份笔记起步，前面那三段最耗时的工序能省掉一大半。工具会换、模型会升级，但"这个领域的文献习惯用什么词、分类号集中在哪几个位置、哪些申请人的表述风格容易误导"这类东西，是攒出来的，不是搜出来的。