行业: 制造
产品: MongoDB Atlas Search、MongoDB Atlas Vector Search、MongoDB Atlas 中的混合搜索
解决方案概述
CMVR 是根据印度机动车辆法案发布的规则。他们制定了车辆在该国家制造、销售或注册之前必须满足的技术和安全要求。该 AI 包括由 ARAI 开发和维护的技术标准。它们规定了车辆或零件必须如何进行测试,以表明其符合某一 CMVR 要求。为印度市场制造汽车的 OEM 使用以下文档:CMVR 规定了车辆必须满足的安全要求,相关的 AIS 则规定了如何测试和认证车辆满足这些要求。
监管和标准内容仅在人们能在合适的时间找到正确的要求时才有价值。考虑一位在零部件供应商处工作的工程师,他正在为一家印度原始设备制造商 (OEM) 完成头灯组装。在零件送交 ARAI 进行认证之前,工程师需要确认 AI-xyz 的当前版本,并检查 CMVR 的“规则 abc” 自上次提交以来是否已经修订。搜索公报通知和标准的 PDF 文件夹以查找该条款需要数小时,引用过时的修订版本意味着认证被拒绝和发布延迟。
本解决方案将详细介绍一个用于搜索 CMVR 和 AIS 内容的 MongoDB 实现,其中:
获取 CMVR 规则文本、AI 标准及其修订通知等源材料。
将此材料转换为可搜索的记录。
检索用户查询的相关文档或部分。
返回结果上下文:标题、章节或规则编号、来源以及文档版本。
该应用程序使用 MongoDB Search 将查询与规则和章节文本进行匹配,并返回匹配的段落及其来源定位器。
制造商在多个市场销售产品时,同样的问题无论在哪里都会出现。向欧洲发货的供应商检查 UNECE 法规,向美国发货的供应商检查 FMVSS,向中国发货的供应商检查 GB 标准。每个监管机构都有自己的修订周期、自己的编号规则以及自己的生效日期。此解决方案中的模式,即在保留可搜索文本的同时,也保留部分、版本和源定位符,应用于这些监管机构。
此解决方案可帮助用户定位和验证可能回答特定领域问题的源材料。总体而言,该解决方案使用以下工作流程:
摄取:阅读 CMVR 规则文本、AI 标准以及修订这些规则文本和标准的公报通知或 ARAI 通告。
准备:将每个来源标准化为一条记录,其中包含追溯段落来源所需的文档、章节或规则编号、修订编号、生效日期和定位器元数据。
检索: 应用 MongoDB Search 路径、过滤器和排名逻辑,尊重当前生效的修正或更改。
当前:返回匹配的内容及其规则编号、标准标识符、版本和源上下文,以便合规工程师确认他们正在阅读的是当前文本。
应用程序处理的代表性查询包括标准标识符(例如 AIS-xyz)、CMVR 规则编号或缩写、自然语言要求(例如“乘用车的后排安全带要求是什么”),以及按类别或修订日期限制的查询。这些查询使搜索词汇具体化,并为评估工作提供了一个起点。
为什么法规和标准查询很困难
CMVR 规则通过在官方公报上发布的 G.S.R. 通知进行修改,单一规则可以在原有文本的基础上叠加多项修改。AIS 标准有自己的修订周期,由 ARAI 通过修订字母(如 AIS-xyz Rev B)进行追踪。合规工程师通过关键字搜索,无法可靠地判断所找到的段落是当前版本还是后续版本。依据已失效的条款提交申请材料可能 trigger 被拒绝的同意认证申请,并将汽车发布时间推迟数周。这会增加第二轮认证的费用。
专业术语又增加了一层困难。工程师、供应商和监管机构经常会用不同的词语来指代同一个要求:供应商可能会搜索 "前灯光束模式",而标准本身则使用 "近光的光度要求"。仅构建于精确关键字匹配的搜索会错过这些连接。词法搜索匹配单词、前缀或标识符。语义搜索通过向量嵌入(文本的数值表示)来匹配含义。通过结合使用这些搜索方法,一个 RAG 管道可以给 LLM 提供正确的上下文。
在汽车行业以外,同样的困难也存在。查看汽车保险索赔的承保人必须检查汽车制造时适用的碰撞测试标准,因为汽车行业标准的修订可能会改变保单覆盖范围。同时向欧洲、美国和中国销售的 OEM 需要同时追踪 UNECE、FMVSS 和 GB 的修订,每个都有自己的修订历史和生效日期。在每种情况下,根本的要求都是相同的:保留部分、版本和源定位符,以及可搜索文本。这种模式告诉用户要求的内容和它的应用条件。
参考架构
该解决方案可以帮助工程、认证和合规团队查找权威的 CMVR 和 AI 内容,而不会丧失验证结果所需的修订和源上下文。它使用一种混合检索模式:词汇搜索支持对 CMVR 规则编号或 AI 标准等标识符的高精度查询,而向量搜索则在用户以普通语言描述要求时显示相关段落。
每个进入的文档都会经历摄取过程,该过程会将文本解析为更加细粒单位,例如特定规则、部分或单个数据块。在转换过程中,会附加衍生和有效性元数据,包括来源 ID、具体的部分或条款定位符、类别、文档版本/修订版、生效日期和当前生命周期状态。MongoDB 然后存储并索引用于关键字搜索的文本数据和用于语义搜索的向量嵌入。最后,系统将词汇和语义查询候选合并,以生成并呈现基于源材料的排序后可验证的结果。
图 1。端到端参考架构图
诸如 AIS-[standard identifier]、CMVR 规则编号或“乘用车后排安全带要求”之类的查询遵循相同的顶级路径:
该应用程序会识别适用的搜索术语和可选过滤器,例如类别、修订版、生效日期或活动状态。
MongoDB Search 检索源文本中精确标识符、缩写和术语的词汇匹配项。
MongoDB 向量搜索可以检索语义相似的段落,以满足自然语言要求和术语变体。
该应用程序合并并排名候选集,应用生命周期过滤器,并投影验证所需的来源字段。
结果视图展示匹配的段落及其源上下文。
图 2。混合检索序列图
数据模型方法
可搜索的记录应包含检索到的文本以及使该文本可验证的上下文。对于监管语料库,应用程序应保留文档标识、章节或规则层级、已索引的修订版本,以及指向原始材料的稳定定位器。
图 3。文档到记录的转换可视化
以下仅为说明性模式。
{ _id: '<documentId>:rule:<ruleNumber>', AIS: { 'AIS-XXX': 'Summary of what this standard requires.', 'AIS-YYY': 'Summary of another referenced standard.' }, canonicalKey: '<documentId>:rule:<ruleNumber>', canonicalTitle: '<Short descriptive title of the rule>', chapterId: '<documentId>:chapter:<chapterNumber>', createdAt: ISODate('<YYYY-MM-DDTHH:mm:ss.sssZ>'), documentId: '<documentId>', ruleNumber: '<ruleNumber>', ruleText: '<Full rule text, including sub-rules, provisos, tables and footnotes>', source: { documentName: '<Official title of the source document>', pdfFile: '<source-file>.pdf', pages: [], chunkCount: NumberInt('<numberOfChunksExtracted>'), extractionModel: '<extraction-model-name>' }, status: 'active', updatedAt: ISODate('<YYYY-MM-DDTHH:mm:ss.sssZ>'), ruleTextEmbedding: [/* float[<dimensions>] */] }
ruleText 字段包含主要监管段落,而 canonicalTitle 和 ruleNumber 则支持快速验证该要求。结构元数据(包括 documentId 和 chapterId)维护特定记录与其父章节层级之间的关系。source 对象提供可追溯至原始 PDF、页码和提取模型所需的来源信息。对于特定标准的上下文,AI 对象会捕获交叉引用和相关要求的摘要。记录生命周期通过 status、createdAt 和 updatedAt 进行跟踪。最后,ruleTextEmbedding 和相关的元数据字段存储支持语义检索的数值向量表示和模型详细信息。
构建解决方案
本节介绍了混合搜索实现的构建流程。访问 Github 存储库中的完整源代码 。
创建混合搜索索引
创建一个用于精确标识符和文本匹配的 MongoDB Search 索引,和一个用于嵌入字段的 MongoDB 向量搜索索引。从经过验证的实现中定义映射、分析器、过滤器、向量维度和相似性指标。
搜索索引
{ mappings: { dynamic: false, fields: { canonicalTitle: { type: "string", analyzer: "lucene.english" }, ruleText: { type: "string", analyzer: "lucene.english" }, documentId: { type: "token" } } } }
向量搜索索引
{ fields: [ { type: "vector", path: "ruleTextEmbedding", numDimensions: 1024, similarity: "cosine" }, { type: "filter", path: "documentId" } ] }
关键要点
专业的监管搜索不仅需要文本匹配: 将词汇检索和语义检索相结合,可以为准确的标准标识符和用户对同一要求应用的各种语言提供服务。
来源是产品需求:每个检索到的段落都应保留稳定的来源标识符、定位器、文档修订版本和生命周期状态,以便用户可以验证根本的材料。
文档修订是相关性的一部分:相关但已取代的条款不应作为当前要求呈现。
混合搜索应根据代表性用户查询进行评估:候选计数、结果限制、融合权重和延迟目标必须从实际工作负载中选择,而不是直接复制为默认。
基于源的搜索体验加快验证: 这种改进的体验可以帮助用户更快地查找和验证材料;它本身并不做出合规判定。
作者
Utsav Talwar,解决方案架构师,MongoDB
Humza Akhtar,制造行业现场 CTO,MongoDB