<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Bert on Judy的Blog</title>
    <link>https://my-blog-5ay.pages.dev/tags/bert/</link>
    <description>Recent content in Bert on Judy的Blog</description>
    <generator>Hugo</generator>
    <language>zh-cn</language>
    <lastBuildDate>Wed, 08 Apr 2026 20:00:00 +0900</lastBuildDate>
    <atom:link href="https://my-blog-5ay.pages.dev/tags/bert/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>基于Bert&#43;LMST&#43;MLP专利相关性筛选项目实践</title>
      <link>https://my-blog-5ay.pages.dev/posts/patent_small_sample_project_summary_blog_style/</link>
      <pubDate>Wed, 08 Apr 2026 20:00:00 +0900</pubDate>
      <guid>https://my-blog-5ay.pages.dev/posts/patent_small_sample_project_summary_blog_style/</guid>
      <description>&lt;h1 id=&#34;小样本专利相关性筛选一个从-100-条不到的标注数据起步的项目实践&#34;&gt;小样本专利相关性筛选：一个从 100 条不到的标注数据起步的项目实践&lt;/h1&gt;
&lt;p&gt;很多文本分类项目一开始都会默认一个前提：&lt;strong&gt;先有一批像样的标注数据，再谈模型效果&lt;/strong&gt;。&lt;br&gt;
但真实项目里，经常不是这样。&lt;/p&gt;
&lt;p&gt;这次做的是一个专利相关性筛选任务。目标并不复杂：从一批专利中找出与目标技术方向更相关、值得进一步研究的候选专利。真正复杂的是现实条件：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;已标注样本不到 100 条&lt;/li&gt;
&lt;li&gt;正样本更少&lt;/li&gt;
&lt;li&gt;未标注样本有上千条&lt;/li&gt;
&lt;li&gt;专利文本很长，表达也不统一&lt;/li&gt;
&lt;li&gt;结果还需要能回写到原始表格，方便人工复核&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;在这种条件下，项目的重点其实不是“堆一个多复杂的模型”，而是先找到一条&lt;strong&gt;能跑通、能迭代、能扩充数据&lt;/strong&gt;的路线。&lt;/p&gt;
&lt;p&gt;这篇文章就总结一下这个项目的思路、取舍和踩坑。&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id=&#34;1-项目到底在做什么&#34;&gt;1. 项目到底在做什么&lt;/h2&gt;
&lt;p&gt;从任务定义上看，这其实是一个很标准的二分类问题：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;code&gt;relevant&lt;/code&gt;：相关专利&lt;/li&gt;
&lt;li&gt;&lt;code&gt;irrelevant&lt;/code&gt;：不相关专利&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;但从业务视角看，它更像一个&lt;strong&gt;筛选系统&lt;/strong&gt;，而不是一个追求绝对准确率的学术分类器。&lt;/p&gt;
&lt;p&gt;我真正想解决的问题不是：&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;“模型能不能把每一条专利都 100% 判对？”&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;而是：&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;“能不能先把最值得看的相关候选排到前面，减少人工筛选成本？”&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;这个目标的变化非常重要。&lt;br&gt;
因为在小样本阶段，模型更适合作为：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;概率打分器&lt;/li&gt;
&lt;li&gt;候选发现器&lt;/li&gt;
&lt;li&gt;人工筛选辅助工具&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;而不是最终裁决者。&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id=&#34;2-数据长什么样&#34;&gt;2. 数据长什么样&lt;/h2&gt;
&lt;p&gt;项目里每条专利大致包含这些字段：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;code&gt;Publication Number&lt;/code&gt;：公开号&lt;/li&gt;
&lt;li&gt;&lt;code&gt;Claims&lt;/code&gt;：权利要求相关文本&lt;/li&gt;
&lt;li&gt;&lt;code&gt;Description&lt;/code&gt;：描述文本&lt;/li&gt;
&lt;li&gt;&lt;code&gt;IPC&lt;/code&gt;：国际专利分类号&lt;/li&gt;
&lt;li&gt;&lt;code&gt;label&lt;/code&gt;：人工标注结果，仅训练阶段有&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;这里有一个容易被忽略但很关键的点：&lt;/p&gt;
&lt;h3 id=&#34;publication-number-要保留但不要喂给模型&#34;&gt;&lt;code&gt;Publication Number&lt;/code&gt; 要保留，但不要喂给模型&lt;/h3&gt;
&lt;p&gt;它的作用是：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;标识这条样本是谁&lt;/li&gt;
&lt;li&gt;后续和原始 Excel 对齐&lt;/li&gt;
&lt;li&gt;预测结果回写&lt;/li&gt;
&lt;li&gt;人工复核定位&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;但它本身不是语义特征，不应该参与模型学习。&lt;br&gt;
如果把它拼进输入文本里，模型学不到什么有用信息，反而可能引入噪声。&lt;/p&gt;
&lt;p&gt;所以在整个流程里，我一直保留 &lt;code&gt;Publication Number&lt;/code&gt;，但只把它当作&lt;strong&gt;样本主键&lt;/strong&gt;。&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id=&#34;3-为什么没有一上来就重度微调-bert&#34;&gt;3. 为什么没有一上来就重度微调 BERT&lt;/h2&gt;
&lt;p&gt;这个问题其实很关键。&lt;/p&gt;
&lt;p&gt;一开始最自然的想法是：&lt;br&gt;
既然是文本分类，那就直接用 BERT 微调不就好了？&lt;/p&gt;
&lt;p&gt;理论上可以，但在这个项目里不太合适，原因很现实：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;已标注样本太少&lt;/li&gt;
&lt;li&gt;正负样本不平衡&lt;/li&gt;
&lt;li&gt;文本很长&lt;/li&gt;
&lt;li&gt;输入字段比较多&lt;/li&gt;
&lt;li&gt;直接全参数微调很容易过拟合&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;简单说就是：&lt;strong&gt;模型复杂度和数据规模不匹配&lt;/strong&gt;。&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
