一、企业使用RAG的原因1.1、市面上关于企业为什么使用RAG常规说法是1、Knowledge Cutoff 知识截止日期2、Hallucination 幻觉问题3、Context Window 上下文窗口。1.2、其实在我看来企业使用RAG的根因是企业内部知识是保密的不可能提供给外部大模型厂商去训练所以大模型是不具备企业内部知识的。但是企业又想让大模型具备业务内部专业知识。于是基于大模型的ICL特性发明了外挂的RAG通过在发送请求时携带专业知识给大模型的方式让大模型短暂获取相关专业知识。1.3、真实稍微大一点的企业都不会使用闭源大模型的API接口。原因是闭源大模型的API接口可能会将企业的信息上传到大模型厂家导致企业信息泄露所以现状是稍大点的企业在企业内部部署开源大模型供企业相关业务使用。这里也顺带提下当前开源大模型的主力军是中国例如GLM、DeepSeek这都是非常了不起的1.4、这个时候企业如果想要大模型具备企业专有知识目前有三条路可走1、SFT对于企业内部的知识耗费人力进行打标为sft微调所需的问答形式再耗费大量硬件资源进行大模型微调训练。优势训练好后即可部署微调好的模型使用。使用阶段不需要额外资源损耗劣势sft训练时需要大量资源非一般企业能够训的起的训练后的知识无法实时更新微调模型可能会导致模型丢失原有的常识模型升级时需要重新训练现状所以当前企业除非逼不得已是不会选择这个方案的2、LoRA可以理解为是SFT的弱化版可视为外挂型微调优势训练时只需要额外训练专项知识。不改原有模型的参数劣势也是需要训练的训练后知识无法实时更新效果不如SFT3、RAG实际上可以理解为是在使用大模型的时候将问题相关知识从企业内部知识库中检索出来随问题一起喂给大模型让模型基于提供的知识组织答案。对大模型并无任何调整。优势不需要训练知识可实时更新劣势需要额外部署RAG相关的能力总结目前企业的主流做法是通过RAG达到企业专有知识扩充到大模型的效果1.5、个人感想IT界是所有行业中最热衷于分享的一个行业这也是当前的AI编程能够迅速普及的原因。当代如果还有人手敲代码那简直就像在电力时代还用牛拉车一样。如果世界是一个整体人类知识都共享那么一个大模型就够了。然而从人类简史来看这个的达成必然会经历大量痛苦时期才可能达成。就目前而言在我们的有生之年最好不要遇到。当前大模型的使用存在工作效率提升和企业经营利润提升不成正比的情况但是当大家都拥抱AI的时候谁不拥抱谁就注定会被淘汰。就像当初苹果的全屏手机的出现淘汰掉诺基亚一样。随着技术的发展肯定会涌现出使用AI更高效的创造出更高利润的企业于此同时技术肯定也是不断发展的更便宜的token的技术会不断出现就像近期的jev的爆火一样会给AI的广泛应用奠定基础AI的发展是势不可挡的然而世界的底层物质实际上是不变的我相信AI最终必然会让人类过的更轻松。就像现今的普通人过的日子和古代贵族差不多一样这个就是人类整体技术发展带来的效应。二、RAGLLM企业实战2.1、整体说明本文将会就RAG这项技术与LLM的结合在企业实际生产中的使用进行相关技术选型记录描述。接下来我将会从如下各个阶段的技术选型及实操结合ClaudeCode大模型的模式打通一个真正的企业级RAGLLM的应用样例索引Index把知识库切块向量化存入向量数据库备查检索Retrieve用户提问时找出最相关的top-K文档片段生成Generate将检索的内容塞入Prompt让LLM参考作答2.2、本地开发环境准备在Pycharm中安装Claude Code(beta)插件本地安装ClaudeCodeCli进行相关代码实现在Pycharm中安装ClaudeCode及对接国产大模型和IDEA中安装ClaudeCode对接国产大模型是一样的。详细配置步骤可参见我的另一个专栏文章IDEA搭建ClaudeCode本地环境对接国产大模型实操指导IDEAClaudeCodeccSwitchQwen2.2、索引2.2.1、数据特征说明企业内部的知识的载体有ppt、pdf、word、excel、csv、txt、.log、html、markdown、邮件、会议记录、json、图片、音频转录文本、知识问答文本、工单、反馈、历史对话记录 等这里我将使用 pdf html word markdown 文档为例进行功能实现示意2.2.2、Indexing Pipline流水线原始文档 -- 加载(Loader) -- 文本分块(Chunking) -- 向量化(Embedding) -- 向量数据库(Vector Store)技术选型加载Loader使用 langchain 中的加载相关能力。部分pdf文档中是扫描的图片这里选择 https://modelscope.cn/models/PaddlePaddle/PaddleOCR-VL-1.6 进行相关能力实现文本分块Chunking这里我们使用向量化模型BAAI/bge-m3的语义感知能力搭配langchain的切换能力一起做语义感知切块真实生产中我们还可以根据数据的特征情况就不同文档数据情况分不同模式进行更精细的分块语义感知切分、固定大小分块、递归字符分块依赖分隔符对表格无效向量化Embedding可选方案可分为两大类1、本地模型2、云端API这里我选择对中文召回率高且我本地电脑能够勉强运行的了的向量模型 BAAI/bge-m3。下载网址https://modelscope.cn/models/BAA*I/bge-m3冷门小知识RAG的向量化和大模型的prompt向量化使用的向量化能力是两套组件。因为大模型的向量化是面向生成目的的而RAG是面向检索目的的。向量数据库Vector Store这里选用Milvus。本地电脑安装一个Milvus Lite版本。这里注意下 Milvus Lite版本只支持Flat暴力检索文档量大了效率很低。生产要使用Milvus Standalone这个企业版才有 HNSW、IVF_SQ8 等向量索引在文档量大的时候检索性能大幅提升。pip install -U pymilvus -i https://pypi.tuna.tsinghua.edu.cn/simple安装完成后demo验证下2.3、检索hybrid_search (densesparse) RRF 进行融合排序再使用CrossEncoder进行Rerank提取top3。这里选择BAAI/bge-reranker-v2-m3 这个ranker大模型与前面向量化模型BGE-M3配套起来。下载地址https://modelscope.cn/models/BAAI/bge-reranker-v2-m32.4、生成如果是企业内部生产使用在生成前还可以执行一些预处理这里做成用户可选型到时我们对比下效果Multi-Query 多角度查询将用户输入让LLM生成3~5个改写版使用原始改写版去检索HyDEHyperthetical Document Embedding 假设文档嵌入先让LLM生成一个假设答案再用这个答案向量去向量库检索Parent-Child Chunk检索到小块返回父级大块提供更全面的上下文Self-Query 自动过滤LLM解析查询意图自动提取过滤条件时间、作者、类别。这种一般企业内的AI报表场景比较适合。构建PromptSystem Prompt:你是一个专业助手。请仅根据一下提供的上下文回答问题。如果上下文中没有相关信息请说【我不知道】不要编造答案。如果没有检索文档请回复【无相关知识】Context检索文档【文档1】检索到的内容【文档2】检索到的内容UserQuestion用户的原始问题RAG检索内容注入Prompt这里选择结构化注入为每个文档标注来源、相关性得分、序号让用户最终获取的答案可以看到知识来源达到可信的效果大模型选型DeepSeek的https://api.deepseek.com大模型选择deepseek-flash2.5 RAG质量评估根据 Milvus 向量库中的向量生产测试数据集进行检索质量评估使用大模型进行生成质量评估2.6 检索界面实现创建一个web界面供用户输入问题展示完整的RAG执行过程信息三、本地AI VibeCoding开发提示词请根据《RAGLLM_企业实战.md》文档的要求进行RAG能力建设并且创建一个网页供用户输入问题、展示检索/生成/RAG质量评估等各个过程信息。切换到plan mode模式进行设计方案输出。然后就等着AI干活就行了。所以以后我们面对客户需求最重要的是理解需求、掌握实现该需求的全栈技术然后让AI按照自己的要求进行代码实现。现在AI的编码能力很强依然采用的是先plan mode然后再是auto mode的模式。编码实现。整个过程耗时大概在2~3小时完工。四、生成代码执行效果记录4.1、原始数据准备这里技术方案演示我先随便找几个本地电脑上的文档作为原始数据4.2、索引流水线执行根据AI编码阶段生成的README.md中的操作步骤执行python -m indexing_pipline.build_index --no-skip-ocr通过观察过程发现paddle-ocr在我的本地cpu上运行非常慢我的电脑是4物理核8虚拟核内存是 16GB。一页pdf耗时大概在90300秒之间。cpu几乎全程在70%100%之间内存损耗在5G左右。整个过程非常耗时就我这几个文档跑了几天才真正跑完。感悟1、生产过程中肯定是要使用GPU运行这种加载分块的模型的2、技术选型上得评估看下是否有必要使用这么重的模型进行该加载分块的实现3、相同的文档在程序实现的时候应当增加适当的去重机制。4.3、生成流水线执行这里直接把web页面打开观察即可python -m uvicorn app.main:app --host 127.0.0.1 --port 8000执行效果如下所示使用感悟尝试检索:八部金刚功有哪几部每一部的功效分别是什么这种需要概括的场景下使用HyDE才会有个勉强可用的答案其他增强检索效果不佳尝试检索双手插顶利三焦 的具体动作是什么这种问题描述和文档中的原文描述不太一致的场景且需要一定的语言理解能力不论使用多少检索增强组合效果始终一般。毕竟RAG只是向量检索缺少大模型的强大的知识总结理解能力。尝试检索白发如何反黑这种在向量库中可以检索到对应文字片断的且知识库本身就是问答模式的检索结果的准确率相对就高很多不论用不用检索增强效果都很好。总结RAG的本质还是就文本做检索。跟传统的搜索引擎相比只是多了个向量检索仅此而已。其实本质与大模型无关。既然是检索那么检索质量最终还是与文本分块、问题匹配度相关。从我使用的感觉来看问答类的知识库的检索效果较佳不要奢望RAG能够对原始文档进行总结性的检索结果输出。映射到生产使用1、知识整理原始知识文档描述的合理性很重要。这里其实也不排除使用大模型对原始知识进行规范化的处理。2、分块的设计企业知识很多的时候可能会分为若干类知识不同类型的知识根据规范化情况不同采用不同的分块方法设计。3、向量化选择尽量贴合实际数据特点的向量化模型中文、英文等不同向量化模型的支持力度不同综合考虑运行成本及时间成本4、检索检索过程目前看走比较完整的 densesparserrfrerankerLLM整体耗时体感还是有点慢的起码我自己感觉有等待的感觉。这里从工程角度可以考虑界面先输出部分检索的rag内容再逐步吐内容的方式缓解用户感知最好的是根据实际业务实验情况进行部分能力的裁剪没必要把所有的技术都堆上去使用直觉RAG是文本检索支持同义词的检索。但是本质只是检索不具备推理能力。所以适用于固定信息的信息检索无法实现知识库的自动推理总结。企业的应用场景是否适合RAG应当对数据进行分析判断是否能够达到 小段内容 表达 完整信息 的效果。例如法律条文、中医经方、客服问答、企业规范等数据质量、数据规范很重要。必要时使用LLM先执行该操作达到归一化后再进行后续的向量化实现数据分块需要根据实际的数据规范情况进行精细化的分块实现设计不拘泥于固有的市面分块能力至于技术选型这个只要了解了整体的技术栈其实是相对容易的。必要的时候进行真实实验辅助选型确定检索增强根据实际的业务使用情况进行检索增强的尝试权衡取舍。工程能力上建议是允许用户自由组合配置性能用户使用的性能预期进行实现准确度和性能的权衡。以前我们更多的是安全和性能权衡现在大模型时代又多了个 准确性和性能的权衡。有意思一言以蔽之技术就是这些技术至于怎么组合使用得基于实际调查进行最终方案制定。这里祭出下我们伟大的毛爷爷的话没有调查就没有发言权、实事求是项目交付很多时候拼的并不是技术技术只是工具更多拼的是深入理解客户需求、解决客户痛点的能力