使用 Agentic AI和MongoDB实现文档智能

使用MongoDB Atlas Vector Search 和大型语言模型提高银行应用程序的交互性。

使用案例：Gen AI、智能搜索、内容管理
行业：金融服务
产品： MongoDB Atlas、 MongoDB Atlas Vector Search、Voyage AI
合作伙伴： Amazon Bedrock、LangChain

解决方案概述

在此解决方案中，您可以学习；了解如何使用由...提供支持MongoDB提供支持的代理AI来利用文档智能。这种方法可以从本地存储库、云容器和云存储等不同来源的结构化、半结构化和非结构化数据中释放见解。

金融机构和金融科技提供商托管多个来源的海量文档和碎片化数据。收集、搜索和分析此类信息等手动任务会降低操作速度并增加出错风险。

该解决方案使用多代理编排系统来应对这些挑战。它由...提供支持MongoDB 灵活的文档模型、 MongoDB Atlas Vector Search、VoyageAI 的 voyage-context-3 和 Agentic AI提供支持。

该解决方案探索了金融服务中的五个文档智能使用案例：

公司信用评级
付款处理中的异常处理
投资研究
客户端入门 (KYC)
贷款发放

下一节将介绍如何将静态文档转换为运营和战略见解的动态来源。

参考架构

该解决方案由三个主要模块化组件组成：

图 1。使用MongoDB的智能文档处理架构。

1。主管多代理编排

A 主管代理 负责协调专业代理团队。每个代理都有自己的提示和特定工具来执行特定任务：

扫描器代理会发现多个来源（本地文件、AWS S3、Google 云端硬盘）的可用文档并对其进行编录。
评估器代理根据行业和使用案例上下文评估文档相关性。
提取器代理使用 Vision AI (Claude 3.5Sonnet v2) 解释文本和视觉元素（如图表或表格）并将其转换为 Markdown。
处理器代理将内容分解为具有语义意义的数据块，使用 VoyageAI 生成嵌入，并将其存储在 MongoDB Atlas 集合中。

2 部分。代理 RAG 系统

摄取数据后，此 RAG 工作流程：

支持与文档助手代理进行实时交互。
使用查询生成、文档评分和查询重写循环来自动优化响应。
使用 voyage-context-3 嵌入，允许数据块保留更广泛的上下文，从而获得精确、有根据的回答。

注意

Agentic RAG 具有以下特点：

做出明智的决策：知道何时需要检索与直接响应
自我更正：如果检索到的文档不相关，则重写查询并重试
维护上下文：使用MongoDB检查点进行多轮对话
提供透明度：追踪工作流程步骤和评分决策

3 部分。报告和见解生成

该模块通过执行以下任务，使用有针对性的向量搜索和基于 LLM 的内容生成来自动生成定期报告：

处理信息以生成量身定制的报告。
汇编相关调查结果和上下文数据。
导出结构化输出，例如 PDF。
包括回退机制，即使在低上下文场景中也能确保可靠性。

数据模型方法

该解决方案的数据模型按功能对集合进行分组：

核心文档处理：

chunks：存储具有 voyage-context-3 向量的文本段。
documents：存储文档元数据，用于追踪处理状态和源信息。
assessments：包含相关性分数和处理决策等文档评估结果。
workflows：存储摄取工作流跟踪，用于监控多代理处理状态。

以下文档是 chunks集合中的一个示例：

{
   "_id": {
      "$oid": "68e7d4cd77c8fbfb9abdf878"
   },
   "document_id": "doc_ef5b1da6",
   "document_name": "Payment_Investigation_Ticket.pdf",
   "chunk_index": 2,
   "chunk_text": "Contacted cardholder to confirm receipt of temporary credit and advise on investigation timeline. Cardholder confirmed satisfaction with temporary resolution...",
   "embedding": [
      0.02789805270731449,
      0.0045435624197125435,
      -0.06760358065366745,
     ...
   ],
   "has_visual_references": false,
   "metadata": {
      "name": "Payment_Investigation_Ticket.pdf",
      "path": "@s3@.../document-intelligence/fsi/payment_processing_exception/Payment_Investigation_Ticket.pdf",
      "processed_at": {
         "$date": "2025-10-09T15:29:17.741Z"
      },
      "chunk_count": 3,
      "chunk_metadata": {
         "chunk_index": 2,
         "total_chunks": 3,
         "section_start": "Contacted cardholder",
         "section_end": "ion_ticket.html*\n4/5",
         "document_id": "doc_ef5b1da6",
         "document_name": "Payment_Investigation_Ticket.pdf",
         "contains_images": false
      }
   }
}

以下文档是 documents集合中的一个示例：

{
   "_id": {
      "$oid": "68e7d4cb5fc2bb6e17eaedb8"
   },
   "document_id": "doc_ef5b1da6",
   "document_name": "Payment_Investigation_Ticket.pdf",
   "document_path": "@s3.../document-intelligence/fsi/payment_processing_exception/Payment_Investigation_Ticket.pdf",
   "file_extension": "pdf",
   "file_size_mb": 0.3242454528808594,
   "source_type": "s3",
   "source_path": "@s3@fsi/payment_processing_exception",
   "page_count": 4,
   "created_at": {
      "$date": "2025-10-09T15:29:15.041Z"
   },
   "updated_at": {
      "$date": "2025-10-09T15:29:18.267Z"
   },
   "status": "completed",
   "chunk_count": 3,
   "has_visual_references": true,
   "metadata": {
      "markdown_length": 5592,
      "processing_timestamp": {
         "$date": "2025-10-09T15:29:15.041Z"
      }
   }
}

以下文档是 assessments集合中的一个示例：

{
   "_id": {
      "$oid": "68e7d2b35fc2bb6e17eaedb2"
   },
   "document_id": "doc_ef5b1da6",
   "document_name": "Payment_Investigation_Ticket.pdf",
   "document_path": "@s3.../document-intelligence/fsi/payment_processing_exception/Payment_Investigation_Ticket.pdf",
   "file_size_mb": 0.3242454528808594,
   "assessment": {
      "main_entity": "Payment Investigation Ticket",
      "document_category": "Banking Investigation Document",
      "key_topics": [
         "merchant chargeback investigation",
         "payment dispute resolution",
         "cardholder dispute handling"
      ],
      "relevance_score": 95,
      "reasoning": "This document is highly relevant to both the financial services industry and exception handling in payment processing. It is an official payment investigation ticket from First National Bank's Payment Investigation Department, specifically dealing with a cardholder dispute and merchant non-response case. The document contains formal banking investigation details, dispute resolution tracking, and payment processing exception handling elements.",
      "should_process": true
   },
   "assessed_at": {
      "$date": "2025-10-09T15:20:19.060Z"
   },
   "workflow_id": "fsi_payment_processing_exception_1760023126468"
}

以下文档是 workflows集合中的一个示例：

{
   "_id": {
      "$oid": "68e7d25d5fc2bb6e17eaedad"
   },
   "workflow_id": "fsi_payment_processing_exception_1760023126468",
   "endpoint": "/api/ingestion/start",
   "source_paths": [
      "@local@/docs/fsi/payment_processing_exception",
      "@s3@fsi/payment_processing_exception",
      "@gdrive@fsi/payment_processing_exception"
   ],
   "triggered_at": {
      "$date": "2025-10-09T15:18:53.563Z"
   }
}

除了核心文档处理集合外，该解决方案还包括其他功能及其相应的集合，例如：

提示交互和记忆：

gradings：包括文档相关性评分，例如来自问答检索评估的二进制分数。”
logs_qa：追踪代理 RAG 工作流程步骤和决策，包括提示交互会话日志。
agent_personas：定义每个行业的提示和功能，针对特定用例的AI配置量身定制。
checkpoint_writes_aio：处理会话状态的异步持久性，特别是针对 LangGraph 状态写入。
checkpoints_aio：托管基于线程的对话历史记录，充当对话内存。

报告：

scheduled_reports：追踪 PDF 位置和生成历史记录，包括生成的报告元数据。
report_templates：按使用案例定义部分和提示，作为报告结构模板。

这种数据模型方法创建了一种直观的设计，可简化开发，因为与特定任务相关的所有数据都位于 MongoDB 灵活的文档结构中。

构建解决方案

有关完整的实现和代码，请按照此 GitHub存储库中 README 中的说明进行操作。

该解决方案由三种主节点 (primary node in the replica set)架构模式构建。以下是每个组件的实施步骤：

实现主管多代理系统

这是协调多个专用AI代理的核心摄取管道。

定义专门的代理：首先，使用 LangGraph框架定义每个代理。
实现主管代理：然后实现用于管理整个工作流的 supervisor agent。这遵循 LangGraph 监控模式。

构建代理 RAG 系统

该系统提供自我纠正的 Agentic RAG 工作流程。它具有一个检索代理，可以智能地决定是从MongoDB Atlas Vector Search检索还是直接响应用户。

图 2。带有MongoDB （文档助手代理）的代理 RAG 架构。

创建向量搜索索引：在 chunks集合上创建向量搜索索引。这允许应用程序对文档嵌入执行快速语义搜索。
构建自修正 RAG 图表：使用 LangGraph 构建具有条件边的循环图表。该图表包括检索代理、文档分级器和查询重写器。查询重写器的目的是在结果不相关时进行重试。
启用会话持久性：实现MongoDB检查点系统以提供会话内存和多轮会话。这会自动保存和加载专用MongoDB集合中的对话状态，从而为代理提供内存持久性。

创建自动报告生成器

该模块可自动生成预定的 PDF 报告。

存储报告模板：利用 MongoDB 灵活的模式创建 report_templates集合。它存储每种报告类型（例如信用评级和投资研究报告）的结构、部分标题和特定语义搜索提示。
实现特定于部分的生成：创建循环遍历模板每个部分的脚本。此脚本运行单独的Atlas Vector Search查询。它使用该特定部分的提示，并累积内容。
计划并追踪报告输出：此脚本由计划程序运行。生成 PDF 后，该脚本会将其元数据（例如文件路径和生成日期）写入MongoDB中的 scheduled_reports集合以进行跟踪。

关键要点

使用 MongoDB Atlas 作为您的统一数据平台 来存储结构化元数据、非结构化文档、向量嵌入和操作状态。这消除了数据孤岛并降低了架构复杂性。
实现主管多代理编排模式以管理复杂的多步骤工作流程。这种模式允许您在专门的工作代理之间划分工具，以确保集中的专业知识。
部署具有自我更正机制的 Agentic RAG 以提高查询准确性。这使代理能够智能地决定何时检索上下文、重新制定查询并对文档相关性进行评分。
为持久代理内存实现 MongoDB 的检查点，以建立稳健的对话和工作流程跟踪。这确保了多轮交互的持久对话状态和对话历史记录。
使用 MongoDB Atlas Vector Search 执行语义搜索，生成有针对性的内容，例如自动报告。这允许查询通过含义（而不仅仅是关键字）检索内容，以获得更准确的输出。

作者

Peyman Parsi，MongoDB金融服务现场CTO
Ainhoa Mugica，MongoDB行业解决方案顾问
MongoDB行业解决方案高级专家 Julian Boronat
Andrea Alaman Calderon，行业解决方案高级专家，MongoDB

了解详情

后退

信用卡应用程序

来年

使用 Fireworks AI 优化 RAG 应用程序