几千条问题里找重复问法，Sentence Transformers 能先帮你配成对

“怎么修改密码”和“忘记密码以后怎么办”，看起来接近，却未必该放进同一个答案。整理FAQ最费力的部分，往往是先从几千条不同写法里找出这些可比较的问题。Sentence Transformers提供的相似句挖掘功能，可以先把候选配成对，给编辑一个更小的检查范围。

它不只比较字面是否相同，而是借助选定模型的句子表示寻找意义接近的表达。最后是否合并，仍然可以由内容维护者决定。

不用先问一句话，也能从整批材料里找

一般搜索有一条查询和一批资料。相似句挖掘则接收一组句子，在这组材料内部寻找彼此接近的条目。官方示例把猫、吉他、电影等不同主题的短句放在一起，其中包含两句措辞不同但都在夸一部新电影的话。

调用 paraphrase_mining 后，结果以三个值组织：相似度、第一条句子的位置、第二条句子的位置。位置可以回到原始列表，因此你能同时展示两条原文，而不必只保存一个难以复查的合并结论。

对FAQ工作台，这种结果很适合做成“待比较”队列：左边原问题，右边相近问题，旁边保留各自已有答案。上面的密码例子只是编辑情境，不是官方中文测评；它说明为什么候选相似还需要判断问题是否真的要求同一种处理。

官方文档特别提醒，A最相似的句子是B，并不意味着B最相似的也一定是A。结果还可能包含A与B、B与C这样的关系。这些配对说明局部接近，不能直接当成一个语义完全一致的分类。

例如，两条问题都提到退款，一条问申请条件，另一条问到账时间。它们可能值得放在同一个主题下，却仍需要不同答案。如果只按高分自动删掉一条，就可能把用户真正需要的内容丢掉。

因此，更合适的交接物是带原始ID的候选对及编辑决定。哪两条合并、哪两条只关联、哪两条其实不同，都能继续积累成下一次整理的依据。

把每条句子和所有其他句子一次性组成大矩阵，内存开销会随数量快速增长。官方函数用分块方式比较，提供查询块、语料块、每句保留候选数和最多返回配对数等参数。它们让整理过程可以分步观察，也需要结合材料规模选择。

框架仓库采用Apache 2.0许可，提供多种嵌入模型入口；框架支持多语言，不代表任意默认模型都适合中文问答。选模型时应查看具体语言范围、长度限制和许可，再拿自己能判断的一批问题核对候选质量。

这类工具最容易带来的改善，是减少人工翻找近似问法的时间。让机器先找出值得并排阅读的两条，再由编辑判断答案该如何组织，往往比一次性要求系统替你清空所有重复问题更有用。