行业: 制造和移动性
产品: MongoDB Atlas、MongoDB Atlas Search、MongoDB Atlas Vector Search、混合搜索
合作伙伴: Google Cloud Platform
解决方案概述
航空航天、能源、汽车和制造业等资本密集型行业依赖于数十年的复杂技术知识。然而,这些技术知识保存在静态文档集合中,例如手册、维护指南和内部 wiki,它们存储为 PDF 或非结构化文件,可能难以访问权限。因此,一线工作人员无法实时检索精确信息。
这种差距给公司带来了以下挑战:
运营停机可能会给公司造成高达260,000 美元/小时的费用,而汽车等某些行业的成本高达 50,000 美元/分钟。除了这些成本之外,ABB 的可靠性价值调查还发现,超过三分之二的工业企业每月至少会经历一次计划外停电,典型成本为 125,000 美元/小时。
由于文档不完善,生产错误和返工影响了 97% 的制造专业人员。
为了解决这一差距,该解决方案提出了一个架构框架,使用上下文感知的 RAG 将惰性文档转换为动态知识库。标准 RAG 系统在将文档分割为多个数据段时会丢失关键上下文,而标准 RAG 系统则不同,上下文感知的 RAG 保留了技术文档中的层次结构和关系。然后,用户可以提出自然语言问题并从文档中获得准确答案,系统会自动查找并呈现最相关的信息,同时保留其原始技术背景。
通过在 RAG进程中维护文档结构,系统可确保安全警告与其程序保持联系,并确保技术规范保持其适当的范围。由此产生的系统使操作更安全,提高生产效率,并为下一代工业AI应用程序铺平道路。
参考架构
用于构建上下文感知 RAG 系统的架构由三个核心层组成:
摄取管道层
数据平台层
查询层
这些层协同工作,将静态技术文档转换为智能知识库。每一层都维护文档结构,并实现精确的关键字匹配和语义理解。本节讨论摄取层和查询层,而“数据模型方法”部分则更详细地介绍数据平台层。
下图说明了从 PDF 摄取到用户查询响应的数据流,显示了技术组件及其交互。它演示了每个层如何在保留上下文的同时处理、存储和检索技术文档。
图 1。用于技术文档架构的上下文感知 RAG
摄取管道层
摄取管道层将原始 PDF 转换为保留内容和上下文的结构化数据。这样可以确保技术关系、层次结构和上下文依赖在分块进程中保持不变,从而提高 RAG 系统的质量和可靠性,防止关键信息丢失。使用汽车手册数据摄取笔记本开发摄取管道层。此文件提供了有关如何实现该层的详细指南,并指导您完成以下进程。
1。将可移植文档转换为结构 DataFrame
要开发摄取管道层,请首先使用 google-cloud-documentai
Python库进程PDF 源。将API响应解析为结构化的 Pandas DataFrame。每行代表一个不同的文本区块,其中包含以下列:
边界框坐标
页码
文本内容
2。应用结构推断规则
然后,遍历 DataFrame 并应用基于规则的引擎来推断上下文,如下所示:
标题检测:全部大写或较大字体的文本块被识别为节标题。
列表和程序识别:水平边界框位置显示指示列表或程序步骤的缩进模式。
语义分块策略:文本被聚合为有意义的数据段,一直持续到遇到主标题,确保过程和表格保持不变。
3。丰富数据以实现高质量检索
创建一个名为 breadcrumb_trail
的字符串变量,以捕获每个数据块的层级路径。 将此字符串添加到数据段的文本之前,然后再将其发送到 Google Vertex AI textembedding-gecko
模型。 这种设计通过向量嵌入对数据段的文本及其在文档层次结构中的上下文位置进行编码,从而提高了语义搜索相关性。
4。使用替代方法
使用上下文化的数据块嵌入模型(例如 voyage-context-3)来简化进程。这些模型在生成嵌入时分析文档的全局上下文,并具有以下优点:
简化摄取:减少手动上下文扩充步骤,例如创建和添加
breadcrumb_trail
变量。该模型会在嵌入过程中自动处理上下文注入。更高的检索准确性:生成细致入微的嵌入,从而提高缺乏本地上下文的数据段的检索质量。
降低对分块的敏感度:实施对分块依赖程度较低的检索进程。该模型的全局感知能力弥补了次优分割的问题。
查询层
查询层实现了将精确匹配与语义搜索相结合的分层搜索方法。每个层级独立运行,并使用分数融合将其结果组合在一起,如下所示:
1 层提供高精度关键字匹配。
第 2 层将语义理解添加到最终排名分数中。
本部分演示如何构建平衡精度和召回率的查询层,同时保持分数透明度。生产系统使用分层的搜索相关性方法来衡量检索到的文档在满足用户查询的准确性。
第 1 层:复合文本搜索的精度
工业应用程序需要精确地查找错误代码或零件号等术语。您可以通过在Atlas Search的 compound
操作符内使用多层策略来实现此精度,如下所示:
{ "$search": { "index": "manual_text_search_index", "compound": { "should": [ // High-Precision: Exact phrase matching with highest boost { "phrase": { "query": "car won't start", "path": "breadcrumb_trail", "score": { "boost": { "value": 10 } } } }, // Balanced Relevance: Individual word matching with medium boost { "text": { "query": "car won't start", "path": "text", "score": { "boost": { "value": 4 } } } }, // High-Recall: Fuzzy matching to catch typos with low boost { "text": { "query": "car won't start", "path": "text", "fuzzy": {}, "score": { "boost": { "value": 1.5 } } } } ] } } }
此查询使用 should
子句,允许您构建复合搜索查询。生成的分数等于所有匹配子句的总和,如下所示:
精确短语匹配应用 10 的分数乘数,以确保包含精确短语的文档排名最高。
单个单词匹配会将分数乘数 4 应用于包含单个搜索词的文档。即使单词单独出现,此功能也会捕获相关内容。
模糊匹配应用的分数乘数为 1.5。此功能可捕获存在错别字或变体的文档,并防止其排名超过精确匹配项。
第 2 层:分解混合搜索以提高透明度
使用 $rankFusion
将 1 层的精确 compound
文本查询与 2 层的语义向量搜索相结合。该聚合操作符可提供关键字匹配精度和语义理解。您还可以细分最终分数,以准确显示文本和向量搜索对每个结果排名的贡献。这种透明度使开发者能够:
调试搜索相关性,以确定是文本搜索还是向量搜索驱动了排名结果。
通过清晰的分数明细,了解某些文档排名更高的原因。
使用不同的权重策略优化 A/B 测试场景。
使用search_new.py文件实施混合搜索。此文件包含执行以下操作的代码:
使用以下聚合管道通过
scoreDetails
执行$rankFusion
:{ $rankFusion: { input: { pipelines: { <myPipeline1>: <expression>, <myPipeline2>: <expression>, ... } }, combination: { weights: { <myPipeline1>: <numeric expression>, <myPipeline2>: <numeric expression>, ... } }, scoreDetails: <bool> } } 使用
$addFields
操作符提取元数据:{ $addFields: { scoreDetails: { $meta: "scoreDetails" } } } 使用
$filter
和$arrayElemAt
操作符解析scoreDetails
大量,从而隔离管道贡献。此方法为来自vectorPipeline
和fullTextPipeline
的特定排名和分数创建字段。使用 RRF 公式 乘以用户定义的权重,计算每种搜索方法的实际贡献。它将常量
k
设置为 60,以控制排名较低的结果影响力。为搜索排名提供透明的结果,如下所示:
SearchResult( score=0.0123, # Final combined RRF score vector_score=0.0086, # Vector pipeline contribution text_score=0.0037 # Text pipeline contribution )
数据模型方法
数据平台层是参考架构的核心组件。它作为摄取管道中所有丰富输出的持久存储,为查询层提供了统一的基础。在此解决方案中, MongoDB文档模型通过将文本、嵌入、分层上下文和元数据整合到单个结构中来为数据平台提供支持。
这种方法消除了对多个系统的需求,例如用于元数据、嵌入和全文搜索的单独数据库,从而降低了复杂性,同时保留了准确检索技术文档所需的丰富上下文。
传统的多系统设计带来了以下挑战:
数据孤岛:跨系统同步和复制信息会增加脆弱性并造成运营瓶颈。
运营开销:运行、扩展和保护单独的服务会增加基础架构成本。
开发者摩擦:集成和学习不同的 API 会减慢创新速度。
相比之下,文档模型简化了架构。 数据平台层通过存储内容及其上下文关系来原生支持上下文感知的 RAG,确保搜索和检索保留文档层次结构和含义。
以下是存储单个技术文档数据块文本及其丰富元元数据的文档模型示例:
{ "_id": { "$oid": "685011ade0cccc356ba545df" }, "text": "WARNING: Switching off the engine when your vehicle is still ...", "breadcrumb_trail": "ENGINE START STOP -- WHAT IS AUTOMATIC ENGINE STOP", "heading_level_1": null, "heading_level_2": "WHAT IS AUTOMATIC ENGINE STOP", "heading_level_3": "Starting and Stopping the Engine", "content_type": [ "procedure", "safety" ], "metadata": { "source_pages": "122-122", "chunk_length": 1459, "systems": [ "engine", "transmission" ] }, "id": "chunk_00174", "prev_chunk_id": "chunk_00173", "next_chunk_id": "chunk_00175", "embedding": [ -0.016625087708234787, ..., 0.005507152993232012, -0.022588932886719704 ] }
该文档包含以下相关字段:
text
:原始文本内容,由Atlas Search定位。breadcrumb_trail
:人类可读的字符串,保留完整的分层上下文。 此字段维护上下文感知 RAG 的文档导航结构。content_type
:为浏览用户界面中的多选筛选器提供支持的标签大量。该字段使用索引。metadata.source_pages
:一个整数范围,用于将数据数据块链接回其在源 PDF 中的原始页面。metadata.systems
:用于筛选并由关键字映射填充的标签大量。id
:确保可追溯性的数据块的唯一标识符。embedding
:数据段的上下文文本的 768 维向量表示。该字段使用Atlas Vector Search索引进行向量检索。
构建解决方案
要部署此解决方案,请按照此Github存储库中 README
的说明进行操作。此存储库将指导您完成以下步骤。
关键要点
建立技术知识的动态记录系统:通过在MongoDB中存储技术信息,将静态文档转换为结构化、可查询的知识库。MongoDB是组织运营的统一事实来源,确保所有AI应用程序访问权限一致且上下文丰富的信息。该系统为诊断聊天机器人和预测性维护系统等下游工具提供了坚实的基础。
设计混合搜索:使用
$rankFusion
将文本和向量搜索相结合,实现混合搜索。分解最终分数,实现调试和相关性调优的透明度。转换 RAG 系统:使用
voyage-context-3
等嵌入模型进程整个文档并维护数据段级详细信息。与标准方法相比,此实施的检索性能提高高达20 %。
作者
Mehar Grewal,MongoDB
Rami Pinto,MongoDB
了解详情
要学习;了解如何为 Gen AI构建数据平台,请阅读为 Gen AI构建统一数据平台博客。