基于 GraphRAG 的汽车售后知识检索方案
内容提要
本文提出基于AWS托管服务的GraphRAG汽车售后知识助手方案，融合知识图谱与向量检索，解决维修手册多语言、多模态、难关联查询等痛点。方案涵盖文档解析、实体抽取、混合检索与可溯源问答，可缩短手册启用周期、降低技师依赖，并可推广至其他知识密集型领域。
延伸解读
GraphRAG 如何补足传统 RAG 的关系盲区
文章指出，经典 RAG 依赖向量相似度，只能找到“看起来相似”的段落，无法理解零部件、故障与维修步骤之间的关联。GraphRAG 在向量检索之外引入知识图谱，用实体和关系网络回答跨概念的复杂问题，例如传感器故障会连带影响哪些零部件、对应拆装步骤是什么。这种互补设计让检索从“语义匹配”升级为“关系感知”，更贴合维修场景的因果与结构查询。
可溯源引用对维修场景的实际价值
方案要求每个答案携带引用标记，映射回原始 chunk 及其边界框，前端在文档查看器中高亮显示确切源位置。对一线技师而言，这不仅是体验优化，更直接关系到信任与误诊风险：维修手册中的参数、步骤和电路图一旦被错误引用，可能导致操作失误。可溯源机制让技师能快速核对原文，减少对答案的盲目采信，也便于在争议时回溯依据。
多语言多模态解析是落地的前置条件
汽车维修文档以 PDF、Word、Excel、PowerPoint 为主，文字、拆装图、参数表和电路图混杂，且需分发到不同语言区域。方案用 Docling 配置 OCR、表格结构解析和图片提取，支持中英文混合识别，并保留每个元素的页面坐标。这意味着系统必须先解决文档解析的完整性和定位精度，后续的实体抽取、图谱构建和引用溯源才有可靠基础，否则关系检索会因输入残缺而失真。
托管服务选型与多租户隔离的工程考量
方案将 LightRAG 的存储后端替换为 AWS 托管服务：Neptune 存图、OpenSearch Serverless 存向量、DynamoDB 存元数据与 KV，并用 Step Functions 编排摄入流程、ECS Fargate 运行容器。通过 workspace（context_id）实现多租户数据隔离，配合 Secrets Manager 管理 Bedrock API Key，避免硬编码。这种组合降低了运维负担，但读者需注意，多租户隔离依赖 workspace 参数的正确传递，配置疏漏可能导致数
Q&A
GraphRAG 汽车售后知识检索方案主要解决哪些业务痛点？
该方案主要解决四类痛点：语言障碍显著，维修手册翻译需2-4周且术语不统一；诊断高度依赖经验，新技师需6-12个月才能独立处理复杂故障；知识同步困难，新知识从总部到海外服务站需4-8周且版本管理混乱；跨区域协调缓慢，沟通渠道单一且时差导致延迟。
这个方案用到了哪些 AWS 托管服务？
方案使用的核心 AWS 服务包括：Amazon Neptune（图数据库）、Amazon OpenSearch Serverless（向量数据库）、Amazon DynamoDB（元数据存储）、Amazon S3（文件存储）、AWS Step Functions（编排文档处理管道）、Amazon ECS Fargate（运行容器）、Application Load Balancer（负载均衡）、Amazon Cognito/OIDC（用户认证）、AWS Secrets Manager（密钥管理）以及 Amazon Bedrock（提供 LLM 与 Embedding 模型能力）。
GraphRAG 的文档摄入流程是怎样的？
用户上传文档至 S3 触发 Step Functions 工作流。首先从 DynamoDB 读取配置，然后在 ECS Fargate 中运行文档解析：OCR 识别文本、表格转 Markdown、提取图片并保留页面坐标（bbox）。若启用图像描述，并行调用视觉模型生成图片描述。解析后语义分块，每个 chunk 保留 bbox 并标注标签，再调用 LLM 抽取实体和关系，相同实体描述自动合并摘要。最终实体和关系写入 Neptune，文本 embedding 写入 OpenSearch，元数据和 bbox 映射写入 DynamoDB。
用户查询时系统是如何进行检索和生成回答的？
查询分四步：首先 LLM 从问题中提取高级关键词（抽象概念）和低级关键词（具体实体）；然后多路并行检索——用低级关键词在 Neptune 图谱中查找匹配实体及其邻居关系（local 检索），用高级关键词查找相关关系网络（global 检索），同时用原始问题在 OpenSearch 中做向量相似度搜索（naive 检索）；接着根据权重或向量相似度从关联的 chunk 中选取最相关文本片段，与实体描述、关系描述一起组装为上下文；最后将上下文和问题发送给 LLM 生成回答。回答中包含引用标记（chunk_id + bbox_id），前端据此在 PDF 查看器中高亮显示原文出处。
方案如何实现答案的可溯源？
每个答案都携带引用标记（chunk_id + bbox_id），这些标记可映射回原始 chunk 及其边界框（bbox）。前端根据这些信息在文档查看器中高亮显示确切的源位置，让用户能够一键回溯到手册原文的确切位置，从而确信答案基于权威内容。
这个方案相比传统 RAG 有哪些优势？
相比传统 RAG，该方案具备四个关键优势：更准确，图谱提供关系感知检索，向量提供语义相似性检索，两者互补，能回答跨多个相关概念的复杂问题；可溯源，每个答案都能回溯到维修手册原文的确切位置，提升信任度并降低误诊风险；多语言、多模态，支持中英文混合文档，解析 PDF/DOCX/XLSX/PPTX 中的文字、表格与图片；托管与 Serverless，基于 Neptune、OpenSearch Serverless、DynamoDB 等托管服务，弹性伸缩且运维负担低。
该方案可以推广到汽车行业以外的领域吗？
可以。该参考架构并不局限于汽车行业，其他装备制造、金融、医疗、法律等知识密集型场景，只要需要从复杂文档中快速、准确、可溯源地获取知识，都能复用同一套架构。
