十年匠心定制 · 商业建站与技术教学双线并行 咨询热线:400-886-1026 service@lmnt.cn
ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

检索增强生成(RAG)的架构设计及其应用

检索增强生成(RAG)的架构设计及其应用 一、项目概述与个人职责2025年至2026年间我作为核心技术负责人主导设计并开发了某大型企业的智能知识问答系统。该项目背景源于企业数字化转型过程中面临的现实痛点企业内部积累了数万份产品文档、技术方案、售后案例和规章制度等非结构化知识资产但传统关键词搜索无法精准定位用户所需信息技术团队在历史问题排查中效率低下。与此同时大语言模型虽有强大的语义理解与生成能力却无法直接接入企业私有数据且存在知识滞后和内容幻觉等固有问题。基于上述背景我们决定构建一套基于检索增强生成RAG架构的企业级智能问答系统。我在该项目中承担了整体架构设计工作包括离线索引管道的设计、在线检索生成流程的编排、向量数据库选型与集群部署方案、多轮对话上下文管理机制的设计以及系统性能与安全合规方案的制定。二、RAG典型架构组成与整体设计2.1 RAG典型架构概述RAG是一种融合“信息检索技术”与“AI内容生成技术”的混合架构。典型RAG系统的工作流程可分为离线索引和在线检索生成两大阶段。离线索引阶段的核心流程为原始文档 → 文档解析与清洗 → 文本分块Chunking→ 向量化Embedding→ 构建索引 → 存入向量数据库。在线检索生成阶段的核心流程为用户输入问题 → 问题分析与拆解 → 向量检索召回 → 重排序Rerank→ 上下文注入 → LLM生成 → 引用溯源与输出。2.2 各核心组件作用1文档解析与预处理模块负责从PDF、Word、Excel、Markdown等多种格式中提取文本内容。该模块需处理表格、代码块、页眉页脚等复杂结构。2文本分块Chunking模块将长文档切分为语义完整的片段。分块策略直接影响检索质量——文本块太长语义模糊太短则丢失上下文。业界推荐采用基于语义边界的递归分块块大小控制在300-800字保留10%-20%的重叠率。3向量化Embedding模块使用Embedding模型将文本片段转换为高维向量语义相似的文本在向量空间中距离更近。4向量数据库存储向量并支持高效的近似最近邻ANN检索需在百万甚至亿级向量中实现毫秒级相似度检索。5检索与重排序模块执行向量相似度检索召回再通过重排序模型对候选结果进行精排提升Top结果的准确率。6上下文组装与生成模块将检索到的相关片段与用户问题拼装成Prompt交由LLM生成最终答案。2.3 项目整体架构设计基于上述组件我为本项目设计了四层模块化架构数据层构建统一的数据接入管道支持多源异构文档的自动化采集、清洗和版本管理。针对企业文档特点采用按章节/语义边界的动态分块策略块大小设定为500-800字重叠率15%。索引层选用Milvus作为向量数据库部署三节点集群保障高可用。向量化模型选用BGE-large-zh该模型在中文语义理解场景下表现优异。同时构建倒排索引支持关键词检索形成“稠密向量稀疏关键词”的混合检索能力。检索层采用“多路召回→融合排序→重排精排”的三级检索流水线。多路召回并行执行向量检索和BM25关键词检索通过RRF倒数排名融合算法合并结果再经由Cross-Encoder重排序模型精排Top-20。生成层基于检索结果动态组装Prompt调用企业私有化部署的大语言模型生成答案并附加引用来源确保可追溯性。三、架构难点与解决方案3.1 召回率优化难点描述项目初期系统召回率Recall10仅为72%左右大量本应被检索到的相关文档未能进入候选集。分析发现三大根因一是部分文档切分策略不当导致语义被割裂二是用户口语化提问与企业文档的陈述性表述存在“语义鸿沟”三是纯向量检索对专业术语和缩写词不敏感。解决方案1优化分块策略从固定大小切分512字符升级为基于语义边界的递归切分并依据文档类型动态调整——技术文档按章节边界切分FAQ类按问答对切分。语义分块相比固定大小分块可提升最高9%的召回率。2引入HyDE与多路查询借鉴“问题与问题匹配”的思路引入HyDE假设性文档嵌入机制——让LLM先根据用户问题生成一段“假想答案”再用假想答案去向量库检索弥合查询与文档的语义鸿沟。同时对复杂问题进行多路查询扩展生成3-5个不同视角的相似问题并行检索。3混合检索将稠密向量检索与BM25稀疏关键词检索相结合通过RRF融合排序。混合检索被证明可显著提升召回率尤其对专业术语和缩写词的检索效果更好。实施效果经过上述优化召回率Recall10从72%提升至91%Top-3准确率提升28%。混合检索上线后专业术语查询的命中率提升了近40%。3.2 向量数据库选型难点描述项目面临10万级文档规模实际入库的chunk数量达50万至300万级别。选型需综合考量性能毫秒级检索延迟、可扩展性支持水平扩展、成本开源vs商业和运维复杂度等多维因素。解决方案经过对Milvus、Qdrant、Weaviate、pgvector等多款方案的对比评估最终选择Milvus作为核心向量数据库理由如下性能卓越支持HNSW、IVF等多种索引类型实测HNSW相比Flat索引查询速度提升15倍可稳定支撑百万级向量的毫秒级检索。水平扩展能力支持分片Sharding和分区Partitioning机制可按业务线或时间维度进行数据隔离便于未来扩展。生态成熟与LangChain、LlamaIndex等主流RAG框架原生集成开发效率高。开源可控避免厂商锁定同时社区活跃度高问题响应及时。部署上采用三节点集群按业务领域划分Collection集合每个Collection内按文档更新时间分区既保障了检索性能也便于增量更新。实施效果系统上线后P99检索延迟稳定在120ms以内日均承载超5万次问答请求未出现性能瓶颈。后期数据量增长至200万chunk时通过增加节点和调整索引参数平滑扩展。3.3 多轮对话上下文管理难点描述在多轮对话场景中用户后续问题往往依赖前文语境如指代消解、省略补全直接将每轮问题独立检索会导致上下文断裂。同时多轮对话累积的上下文可能超出LLM的窗口限制。解决方案1对话状态维护设计对话会话Session管理机制为每个用户会话维护独立的对话历史。每轮对话将历史上下文压缩后与当前问题拼接形成完整的检索Query。2历史上下文压缩当对话轮次超过阈值时采用关键信息提取策略——使用LLM对历史对话进行摘要压缩保留核心实体和意图丢弃冗余信息避免上下文膨胀。3动态窗口调整根据查询复杂度动态调整注入LLM的上下文窗口大小。简单查询使用基础窗口1024 tokens复杂查询扩展至2048-3072 tokens在保证信息完整性的同时控制推理成本。4上下文感知检索在检索阶段不仅使用当前问题还融合历史上下文中的关键实体和意图生成增强后的检索Query确保后续问题能命中与上下文相关的文档片段。实施效果多轮对话功能上线后用户连续追问场景下的回答准确率从58%提升至84%。对话历史压缩机制将平均上下文token数控制在1500以内有效规避了窗口溢出问题。四、总结本项目通过构建端到端的RAG架构成功将企业私有知识资产与大语言模型相结合实现了从“关键词搜索”到“智能问答”的能力跃迁。在架构设计上我们坚持模块化、可扩展、可观测的原则将系统划分为数据层、索引层、检索层和生成层四个独立模块在关键技术选型上通过充分的对比评估选择了Milvus向量数据库和BGE嵌入模型在难点攻关上通过分块策略优化、混合检索、HyDE查询增强和多轮对话管理等一系列手段系统性解决了召回率低、检索性能和多轮对话等核心挑战。系统上线以来日均处理问答请求超5万次平均响应时间控制在2.5秒以内用户满意度达92%。该项目验证了RAG架构在企业级知识管理场景中的可行性与高价值也为后续在多模态RAG和Agentic RAG方向的演进奠定了坚实基础。
返回列表