ClauseBase 一瞥

ClauseBase 由三位前律师创立，他们对冗长的合同起草过程感到厌烦。他们意识到，法律团队和律师事务所在起草合同时往往需要重新创建合同，这增加了法律服务的成本。通常，起草的起点是一个旧文件——清理后删除旧名称，然后是一个漫长的过程，添加、编辑和重新排列条款。从旧合同中复制粘贴条款浪费了很多时间，尤其是因为相关的条款往往分散在旧文件和电子邮件链中。

为了解决这个问题，ClauseBase 创建了 Clause9 ，一个自动化整个法律文件的工具。律师们现在只需点击几下就可以生成复杂的文档，而无需花费数小时进行手动起草。 ClauseBuddy 是他们的第二个产品，允许用户构建“条款库”以收集和重复使用有用的合同元素。最初，这些条款需要手动上传。但最近，ClauseBase 添加了一个功能，可以从旧合同中自动提取条款——将它们组织到一个存储在Manticore Search中的库中。

法律条款的向量搜索

ClauseBase 想要一种方法，让律师能够轻松找到合同条款的替代版本，无论是用于起草还是在谈判期间。对于任何给定的条款，都有无数的变体：不同的长度、不同的语气（中性、强硬或行业特定），等等。律师需要一种快速浏览这些变体的方法，以避免重新发明轮子并找到灵感。

虽然拥有一个手动编目并带有详细元数据的条款库是理想的，但创建一个需要时间。许多律师刚开始使用技术，正在寻找一种更容易找到相似条款的方法。向量搜索提供了这种解决方案，通过在Manticore中为每个条款存储一个文本向量，允许律师快速搜索具有相似意义的条款——无需手动标记。这是拥有完美注释条款的下一个最佳选择。

为什么选择Manticore搜索？

最初，ClauseBase 将提取的条款存储在PostgreSQL中。虽然PostgreSQL在一定程度上是可行的，但在全文搜索方面存在显著限制。诸如自动补全、分面搜索和短语邻近搜索等功能难以实现。PostgreSQL还缺乏BM25等高级排名功能，这对于法律文本至关重要，因为诸如“义务”、“当事人”和“责任”等常见词需要适当加权以提高搜索结果。

除此之外，性能问题开始出现。ClauseBuddy 提供用户提取自己文档的能力，并提供一个包含数百万条款的公共样本数据库，这些条款来自美国EDGAR图书馆。PostgreSQL和Pgvector组合在这种数据量下变得明显缓慢，返回结果需要几秒钟。正是在这种情况下，ClauseBase 决定转向Manticore Search。

在之前使用Manticore搜索整个法律文件时，ClauseBase 已经知道它既快又功能丰富。因此，他们将条款库迁移到Manticore，结果证明非常成功——用户现在可以无缝跳转到条款及其原始文档。

合作实现向量搜索

当ClauseBase 决定需要向量搜索时，Manticore尚未提供该功能。他们联系了Manticore团队，双方合作实现了向量搜索功能。仅仅几周后，ClauseBase 就能够开始使用Manticore的新向量搜索功能进行实验。后来，当ClauseBase 遇到问题时，Manticore团队迅速解决了这些问题，确保了平稳的体验。

向量搜索的影响

向量搜索在ClauseBase中的集成已经持续了一年多，结果非常令人鼓舞。ClauseBase的目标是找到一种解决方案，避免依赖商业向量服务，这些服务通常响应速度较慢。经过广泛的实验，他们选择了平衡质量和性能的模型，特别针对他们的用例进行了定制。

除了在 Manticore Search 中使用向量搜索外，ClauseBase 引入了一种重新排序的过程，以进一步优化搜索结果。重新排序器处理来自初始向量搜索的最佳匹配，有效地“更深入地思考”一小部分潜在答案。这种方法显著提高了搜索结果的相关性，为用户提供了不仅快速而且上下文准确且非常有用的结果。