本文介绍了RAG检索增强生成技术旨在解决大模型知识局限导致的“幻觉”问题。通过检索企业内部文档结合大模型生成答案显著提升AI应用效果。文章以群晖技术支援团队将响应时间压缩20倍的案例为例阐述了RAG的基本架构、演进阶段及企业落地策略。同时提供了使用LangChain搭建简单RAG系统的代码示例并探讨了生产环境需注意的数据质量、检索精度、上下文管理、性能优化等问题。最后总结RAG的优势与局限建议从简单开始重视数据质量持续监控结合人工辅助以实现最佳效果。先说个真实的故事。群晖Synology的技术支援团队之前处理一个客户问题平均需要 22 小时。这不是因为他们效率低而是因为技术支援需要查阅大量历史案例、文档、FAQ还要找到相关的解决方案。2024 年他们上了 RAG 系统把响应时间压缩到了 0.5 小时。整整快了 20 倍。群晖分享原文博客可以搜索到 https://blog.synology.com/cht/这背后不是什么黑魔法就是一个叫 RAG检索增强生成的技术。今天就来聊聊RAG 是什么怎么用以及在企业里怎么落地。01 大模型的幻觉问题用过大模型的应该都遇到过你问个公司内部的问题它要么一本正经地胡说八道要么回答得很笼泛完全没有参考你公司的实际情况。为什么因为大模型的知识是训练数据里的它不知道你公司的文档、产品、流程这些内部知识。RAG 就是解决这个问题的一个思路先检索相关文档再让大模型基于这些文档生成答案。听起来简单但实际落地有一堆坑。02 RAG 的基本架构先说说最基础的 RAG 长什么样。用户提问题 → 检索相关文档 → 把问题和文档拼在一起 → 丢给大模型生成答案就这么简单。但问题来了这个简单的流程在实际使用中会有各种问题问题 1检索到的文档不相关大模型很聪明但检索器可能很笨。比如用户问怎么重置路由器检索器可能找来了路由器故障排除的文档但里面没有重置的方法。问题 2检索到的文档太多上下文窗口是有限的检索太多文档大模型可能处理不过来检索太少可能漏掉关键信息。问题 3文档质量参差不齐有些文档可能过时了有些文档写得不清楚这些都会影响最终答案的质量。03 RAG 的演进从简单到复杂RAG 技术这几年发展很快大概经历了三个阶段第一阶段基础 RAG2020-2022就是刚才说的简单流程检索 → 拼接 → 生成。能用但效果一般。第二阶段增强 RAG2023-2024开始加入各种优化•查询改写用大模型优化用户的查询•混合检索向量检索关键词检索BM25•重排序检索后用轻量级模型重新排序•迭代检索根据生成结果再检索这个阶段的 RAG 效果明显提升开源框架也成熟了LlamaIndex、LangChain。第三阶段前沿 RAG2024-2025开始往更复杂的方向发展•图增强 RAG引入知识图谱处理复杂推理•自适应 RAG系统自己判断什么时候该检索•多模态 RAG不仅检索文本还能检索图片、视频•端到端训练检索器和生成器一起训练04 Synology 是怎么做的回到群晖的案例他们是怎么把 RAG 用在实际业务里的他们的 RAG 系统包含四个关键步骤1. 数据预处理历史支援案例需要先处理• 去识别化保护隐私• 分段处理不能整个文档直接丢进去• 质量过滤过时的、无用的要筛掉2. 客户意图分析用户的问题可能表述不清楚需要解析意图、提取关键实体、生成优化后的检索查询。3. 数据库检索这里他们用了混合检索向量相似度关键词匹配。为什么只用向量检索不够因为有些专业术语、产品型号这些精确匹配向量检索效果不好。4. 生成回应LLM 基于检索到的文档生成答案但还有一个 Guardrail 机制避免生成不当内容比如敏感信息、不当言论。他们的部署策略很有意思•第一阶段只作为内部参考工具客服还是要自己确认答案•第二阶段对简单问题直接自动回复•最终目标覆盖绝大多数非复杂案件结果• 人工介入率从 100%降到了不到 20%• 用户满意度提升 35%05 搭建一个简单的 RAG 系统说了这么多怎么自己搭一个 RAG 系统用 LangChain 可以快速搭个 demofrom langchain_community.chat_models import ChatDeepSeekfrom langchain.chains import ConversationalRetrievalChainfrom langchain.vectorstores import Chromafrom langchain_community.embeddings import DeepSeekEmbeddingsfrom langchain.document_loaders import DirectoryLoaderfrom langchain.text_splitter import CharacterTextSplitter# 加载并分割文档loader DirectoryLoader(faq_documents, glob**/*.txt)documents loader.load()text_splitter CharacterTextSplitter(chunk_size1000, chunk_overlap0)texts text_splitter.split_documents(documents)# 创建向量数据库embeddings DeepSeekEmbeddings()vectordb Chroma.from_documents(texts, embeddingembeddings)# 初始化LLM和QA链llm ChatDeepSeek(modeldeepseek-chat)qa ConversationalRetrievalChain.from_llm(llm, vectordb.as_retriever())# 开始对话chat_history []question 我如何更改我的账户密码result qa({question: question, chat_history: chat_history})print(result[answer])这个 demo 能用但距离生产环境还差得很远。06 生产环境要考虑的问题真正要把 RAG 用在生产环境有一堆坑要填1. 数据质量垃圾进垃圾出。文档要清洗、去重、去噪过时的要更新。2. 检索精度单纯的向量检索不够要考虑混合检索、重排序、查询改写。3. 上下文管理怎么选择最相关的文档怎么控制上下文长度怎么处理检索不到结果的情况4. 性能优化向量数据库的选择、索引策略、缓存设计这些都影响响应速度。5. 监控和评估怎么知道 RAG 系统工作得好不好需要监控检索指标、生成指标、业务指标。6. 安全和合规敏感数据怎么处理访问权限怎么控制审计日志怎么记录07 RAG 不是万能的RAG 确实能解决大模型的幻觉问题但它不是万能的。它擅长• 知识问答基于文档的事实性问题• 文档检索和分析• 企业知识管理• 客服自动化它不擅长• 需要创造性回答的问题• 需要推理的复杂问题• 文档里没有答案的问题• 需要实时信息的问题所以实际应用中往往是RAG人工的结合简单问题 RAG 处理复杂问题转人工。08 一些实战建议如果你打算在项目里用 RAG这里有几点建议1. 从简单开始不要一开始就上各种复杂的技术。先搭个简单的 RAG 系统验证核心价值再逐步优化。2. 重视数据质量好的数据比复杂的架构更重要。花时间清洗、整理你的文档。3. 持续监控RAG 系统不是一劳永逸的要持续监控性能及时调整。4. 考虑成本向量数据库、大模型 API、存储这些都有成本。要评估投入产出比。5. 关注新技术RAG 技术发展很快但要评估新技术是否适合你的场景不要盲目追新。09 写在最后RAG 不是一个新技术了但它在企业应用中的价值才刚刚开始被认识。像群晖这样的成功案例证明了用好了 RAG能显著提升效率、降低成本。但 RAG 不是银弹它需要和其他技术、流程、人配合才能真正发挥作用。对于技术人员来说理解 RAG 的原理知道它的优缺点知道什么时候用、怎么用比盲目追新技术更重要。01什么是AI大模型应用开发工程师如果说AI大模型是蕴藏着巨大能量的“后台超级能力”那么AI大模型应用开发工程师就是将这种能量转化为实用工具的执行者。AI大模型应用开发工程师是基于AI大模型设计开发落地业务的应用工程师。这个职业的核心价值在于打破技术与用户之间的壁垒把普通人难以理解的算法逻辑、模型参数转化为人人都能轻松操作的产品形态。无论是日常写作时用到的AI文案生成器、修图软件里的智能美化功能还是办公场景中的自动记账工具、会议记录用的语音转文字APP这些看似简单的应用背后都是应用开发工程师在默默搭建技术与需求之间的桥梁。他们不追求创造全新的大模型而是专注于让已有的大模型“听懂”业务需求“学会”解决具体问题最终形成可落地、可使用的产品。CSDN粉丝独家福利给大家整理了一份AI大模型全套学习资料这份完整版的 AI 大模型学习资料已经上传CSDN朋友们如果需要可以扫描下方二维码点击下方CSDN官方认证链接免费领取【保证100%免费】02AI大模型应用开发工程师的核心职责需求分析与拆解是工作的起点也是确保开发不偏离方向的关键。应用开发工程师需要直接对接业务方深入理解其核心诉求——不仅要明确“要做什么”更要厘清“为什么要做”以及“做到什么程度算合格”。在此基础上他们会将模糊的业务需求拆解为具体的技术任务明确每个环节的执行标准并评估技术实现的可行性同时定义清晰的核心指标为后续开发、测试提供依据。这一步就像建筑前的图纸设计若出现偏差后续所有工作都可能白费。技术选型与适配是衔接需求与开发的核心环节。工程师需要根据业务场景的特点选择合适的基础大模型、开发框架和工具——不同的业务对模型的响应速度、精度、成本要求不同选型的合理性直接影响最终产品的表现。同时他们还要对行业相关数据进行预处理通过提示词工程优化模型输出或在必要时进行轻量化微调让基础模型更好地适配具体业务。此外设计合理的上下文管理规则确保模型理解连贯需求建立敏感信息过滤机制保障数据安全也是这一环节的重要内容。应用开发与对接则是将方案转化为产品的实操阶段。工程师会利用选定的开发框架构建应用的核心功能同时联动各类外部系统——比如将AI模型与企业现有的客户管理系统、数据存储系统打通确保数据流转顺畅。在这一过程中他们还需要配合设计团队打磨前端交互界面让技术功能以简洁易懂的方式呈现给用户实现从技术方案到产品形态的转化。测试与优化是保障产品质量的关键步骤。工程师会开展全面的功能测试找出并修复开发过程中出现的漏洞同时针对模型的响应速度、稳定性等性能指标进行优化。安全合规性也是测试的重点需要确保应用符合数据保护、隐私安全等相关规定。此外他们还会收集用户反馈通过调整模型参数、优化提示词等方式持续提升产品体验让应用更贴合用户实际使用需求。部署运维与迭代则贯穿产品的整个生命周期。工程师会通过云服务器或私有服务器将应用部署上线并实时监控运行状态及时处理突发故障确保应用稳定运行。随着业务需求的变化他们还需要对应用功能进行迭代更新同时编写完善的开发文档和使用手册为后续的维护和交接提供支持。03薪资情况与职业价值市场对这一职业的高度认可直接体现在薪资待遇上。据猎聘最新在招岗位数据显示AI大模型应用开发工程师的月薪最高可达60k。在AI技术加速落地的当下这种“技术业务”的复合型能力尤为稀缺让该职业成为当下极具吸引力的就业选择。AI大模型应用开发工程师是AI技术落地的关键桥梁。他们用专业能力将抽象的技术转化为具体的产品让大模型的价值真正渗透到各行各业。随着AI场景化应用的不断深化这一职业的重要性将更加凸显也必将吸引更多人才投身其中推动AI技术更好地服务于社会发展。CSDN粉丝独家福利给大家整理了一份AI大模型全套学习资料这份完整版的 AI 大模型学习资料已经上传CSDN朋友们如果需要可以扫描下方二维码点击下方CSDN官方认证链接免费领取【保证100%免费】
RAG技术：让AI从“幻觉”变“靠谱”，群晖案例证明效率提升20倍！
本文介绍了RAG检索增强生成技术旨在解决大模型知识局限导致的“幻觉”问题。通过检索企业内部文档结合大模型生成答案显著提升AI应用效果。文章以群晖技术支援团队将响应时间压缩20倍的案例为例阐述了RAG的基本架构、演进阶段及企业落地策略。同时提供了使用LangChain搭建简单RAG系统的代码示例并探讨了生产环境需注意的数据质量、检索精度、上下文管理、性能优化等问题。最后总结RAG的优势与局限建议从简单开始重视数据质量持续监控结合人工辅助以实现最佳效果。先说个真实的故事。群晖Synology的技术支援团队之前处理一个客户问题平均需要 22 小时。这不是因为他们效率低而是因为技术支援需要查阅大量历史案例、文档、FAQ还要找到相关的解决方案。2024 年他们上了 RAG 系统把响应时间压缩到了 0.5 小时。整整快了 20 倍。群晖分享原文博客可以搜索到 https://blog.synology.com/cht/这背后不是什么黑魔法就是一个叫 RAG检索增强生成的技术。今天就来聊聊RAG 是什么怎么用以及在企业里怎么落地。01 大模型的幻觉问题用过大模型的应该都遇到过你问个公司内部的问题它要么一本正经地胡说八道要么回答得很笼泛完全没有参考你公司的实际情况。为什么因为大模型的知识是训练数据里的它不知道你公司的文档、产品、流程这些内部知识。RAG 就是解决这个问题的一个思路先检索相关文档再让大模型基于这些文档生成答案。听起来简单但实际落地有一堆坑。02 RAG 的基本架构先说说最基础的 RAG 长什么样。用户提问题 → 检索相关文档 → 把问题和文档拼在一起 → 丢给大模型生成答案就这么简单。但问题来了这个简单的流程在实际使用中会有各种问题问题 1检索到的文档不相关大模型很聪明但检索器可能很笨。比如用户问怎么重置路由器检索器可能找来了路由器故障排除的文档但里面没有重置的方法。问题 2检索到的文档太多上下文窗口是有限的检索太多文档大模型可能处理不过来检索太少可能漏掉关键信息。问题 3文档质量参差不齐有些文档可能过时了有些文档写得不清楚这些都会影响最终答案的质量。03 RAG 的演进从简单到复杂RAG 技术这几年发展很快大概经历了三个阶段第一阶段基础 RAG2020-2022就是刚才说的简单流程检索 → 拼接 → 生成。能用但效果一般。第二阶段增强 RAG2023-2024开始加入各种优化•查询改写用大模型优化用户的查询•混合检索向量检索关键词检索BM25•重排序检索后用轻量级模型重新排序•迭代检索根据生成结果再检索这个阶段的 RAG 效果明显提升开源框架也成熟了LlamaIndex、LangChain。第三阶段前沿 RAG2024-2025开始往更复杂的方向发展•图增强 RAG引入知识图谱处理复杂推理•自适应 RAG系统自己判断什么时候该检索•多模态 RAG不仅检索文本还能检索图片、视频•端到端训练检索器和生成器一起训练04 Synology 是怎么做的回到群晖的案例他们是怎么把 RAG 用在实际业务里的他们的 RAG 系统包含四个关键步骤1. 数据预处理历史支援案例需要先处理• 去识别化保护隐私• 分段处理不能整个文档直接丢进去• 质量过滤过时的、无用的要筛掉2. 客户意图分析用户的问题可能表述不清楚需要解析意图、提取关键实体、生成优化后的检索查询。3. 数据库检索这里他们用了混合检索向量相似度关键词匹配。为什么只用向量检索不够因为有些专业术语、产品型号这些精确匹配向量检索效果不好。4. 生成回应LLM 基于检索到的文档生成答案但还有一个 Guardrail 机制避免生成不当内容比如敏感信息、不当言论。他们的部署策略很有意思•第一阶段只作为内部参考工具客服还是要自己确认答案•第二阶段对简单问题直接自动回复•最终目标覆盖绝大多数非复杂案件结果• 人工介入率从 100%降到了不到 20%• 用户满意度提升 35%05 搭建一个简单的 RAG 系统说了这么多怎么自己搭一个 RAG 系统用 LangChain 可以快速搭个 demofrom langchain_community.chat_models import ChatDeepSeekfrom langchain.chains import ConversationalRetrievalChainfrom langchain.vectorstores import Chromafrom langchain_community.embeddings import DeepSeekEmbeddingsfrom langchain.document_loaders import DirectoryLoaderfrom langchain.text_splitter import CharacterTextSplitter# 加载并分割文档loader DirectoryLoader(faq_documents, glob**/*.txt)documents loader.load()text_splitter CharacterTextSplitter(chunk_size1000, chunk_overlap0)texts text_splitter.split_documents(documents)# 创建向量数据库embeddings DeepSeekEmbeddings()vectordb Chroma.from_documents(texts, embeddingembeddings)# 初始化LLM和QA链llm ChatDeepSeek(modeldeepseek-chat)qa ConversationalRetrievalChain.from_llm(llm, vectordb.as_retriever())# 开始对话chat_history []question 我如何更改我的账户密码result qa({question: question, chat_history: chat_history})print(result[answer])这个 demo 能用但距离生产环境还差得很远。06 生产环境要考虑的问题真正要把 RAG 用在生产环境有一堆坑要填1. 数据质量垃圾进垃圾出。文档要清洗、去重、去噪过时的要更新。2. 检索精度单纯的向量检索不够要考虑混合检索、重排序、查询改写。3. 上下文管理怎么选择最相关的文档怎么控制上下文长度怎么处理检索不到结果的情况4. 性能优化向量数据库的选择、索引策略、缓存设计这些都影响响应速度。5. 监控和评估怎么知道 RAG 系统工作得好不好需要监控检索指标、生成指标、业务指标。6. 安全和合规敏感数据怎么处理访问权限怎么控制审计日志怎么记录07 RAG 不是万能的RAG 确实能解决大模型的幻觉问题但它不是万能的。它擅长• 知识问答基于文档的事实性问题• 文档检索和分析• 企业知识管理• 客服自动化它不擅长• 需要创造性回答的问题• 需要推理的复杂问题• 文档里没有答案的问题• 需要实时信息的问题所以实际应用中往往是RAG人工的结合简单问题 RAG 处理复杂问题转人工。08 一些实战建议如果你打算在项目里用 RAG这里有几点建议1. 从简单开始不要一开始就上各种复杂的技术。先搭个简单的 RAG 系统验证核心价值再逐步优化。2. 重视数据质量好的数据比复杂的架构更重要。花时间清洗、整理你的文档。3. 持续监控RAG 系统不是一劳永逸的要持续监控性能及时调整。4. 考虑成本向量数据库、大模型 API、存储这些都有成本。要评估投入产出比。5. 关注新技术RAG 技术发展很快但要评估新技术是否适合你的场景不要盲目追新。09 写在最后RAG 不是一个新技术了但它在企业应用中的价值才刚刚开始被认识。像群晖这样的成功案例证明了用好了 RAG能显著提升效率、降低成本。但 RAG 不是银弹它需要和其他技术、流程、人配合才能真正发挥作用。对于技术人员来说理解 RAG 的原理知道它的优缺点知道什么时候用、怎么用比盲目追新技术更重要。01什么是AI大模型应用开发工程师如果说AI大模型是蕴藏着巨大能量的“后台超级能力”那么AI大模型应用开发工程师就是将这种能量转化为实用工具的执行者。AI大模型应用开发工程师是基于AI大模型设计开发落地业务的应用工程师。这个职业的核心价值在于打破技术与用户之间的壁垒把普通人难以理解的算法逻辑、模型参数转化为人人都能轻松操作的产品形态。无论是日常写作时用到的AI文案生成器、修图软件里的智能美化功能还是办公场景中的自动记账工具、会议记录用的语音转文字APP这些看似简单的应用背后都是应用开发工程师在默默搭建技术与需求之间的桥梁。他们不追求创造全新的大模型而是专注于让已有的大模型“听懂”业务需求“学会”解决具体问题最终形成可落地、可使用的产品。CSDN粉丝独家福利给大家整理了一份AI大模型全套学习资料这份完整版的 AI 大模型学习资料已经上传CSDN朋友们如果需要可以扫描下方二维码点击下方CSDN官方认证链接免费领取【保证100%免费】02AI大模型应用开发工程师的核心职责需求分析与拆解是工作的起点也是确保开发不偏离方向的关键。应用开发工程师需要直接对接业务方深入理解其核心诉求——不仅要明确“要做什么”更要厘清“为什么要做”以及“做到什么程度算合格”。在此基础上他们会将模糊的业务需求拆解为具体的技术任务明确每个环节的执行标准并评估技术实现的可行性同时定义清晰的核心指标为后续开发、测试提供依据。这一步就像建筑前的图纸设计若出现偏差后续所有工作都可能白费。技术选型与适配是衔接需求与开发的核心环节。工程师需要根据业务场景的特点选择合适的基础大模型、开发框架和工具——不同的业务对模型的响应速度、精度、成本要求不同选型的合理性直接影响最终产品的表现。同时他们还要对行业相关数据进行预处理通过提示词工程优化模型输出或在必要时进行轻量化微调让基础模型更好地适配具体业务。此外设计合理的上下文管理规则确保模型理解连贯需求建立敏感信息过滤机制保障数据安全也是这一环节的重要内容。应用开发与对接则是将方案转化为产品的实操阶段。工程师会利用选定的开发框架构建应用的核心功能同时联动各类外部系统——比如将AI模型与企业现有的客户管理系统、数据存储系统打通确保数据流转顺畅。在这一过程中他们还需要配合设计团队打磨前端交互界面让技术功能以简洁易懂的方式呈现给用户实现从技术方案到产品形态的转化。测试与优化是保障产品质量的关键步骤。工程师会开展全面的功能测试找出并修复开发过程中出现的漏洞同时针对模型的响应速度、稳定性等性能指标进行优化。安全合规性也是测试的重点需要确保应用符合数据保护、隐私安全等相关规定。此外他们还会收集用户反馈通过调整模型参数、优化提示词等方式持续提升产品体验让应用更贴合用户实际使用需求。部署运维与迭代则贯穿产品的整个生命周期。工程师会通过云服务器或私有服务器将应用部署上线并实时监控运行状态及时处理突发故障确保应用稳定运行。随着业务需求的变化他们还需要对应用功能进行迭代更新同时编写完善的开发文档和使用手册为后续的维护和交接提供支持。03薪资情况与职业价值市场对这一职业的高度认可直接体现在薪资待遇上。据猎聘最新在招岗位数据显示AI大模型应用开发工程师的月薪最高可达60k。在AI技术加速落地的当下这种“技术业务”的复合型能力尤为稀缺让该职业成为当下极具吸引力的就业选择。AI大模型应用开发工程师是AI技术落地的关键桥梁。他们用专业能力将抽象的技术转化为具体的产品让大模型的价值真正渗透到各行各业。随着AI场景化应用的不断深化这一职业的重要性将更加凸显也必将吸引更多人才投身其中推动AI技术更好地服务于社会发展。CSDN粉丝独家福利给大家整理了一份AI大模型全套学习资料这份完整版的 AI 大模型学习资料已经上传CSDN朋友们如果需要可以扫描下方二维码点击下方CSDN官方认证链接免费领取【保证100%免费】
