企业官网建设流程全解析

一、企业使用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的弱化版，可视为外挂型微调
  • 优势：训练时，只需要额外训练专项知识。不改原有模型的参数
  • 劣势：也是需要训练的，训练后知识无法实时更新；效果不如SFT
• 3、RAG：实际上可以理解为是在使用大模型的时候，将问题相关知识从企业内部知识库中检索出来，随问题一起喂给大模型，让模型基于提供的知识，组织答案。对大模型并无任何调整。
  • 优势：不需要训练；知识可实时更新
  • 劣势：需要额外部署RAG相关的能力
• 总结：目前企业的主流做法是通过RAG，达到企业专有知识扩充到大模型的效果

1.5、个人感想

• IT界是所有行业中，最热衷于分享的一个行业，这也是当前的AI编程能够迅速普及的原因。当代如果还有人手敲代码，那简直就像在电力时代还用牛拉车一样。
• 如果世界是一个整体，人类知识都共享，那么一个大模型就够了。然而从人类简史来看，这个的达成必然会经历大量痛苦时期才可能达成。就目前而言，在我们的有生之年，最好不要遇到。
• 当前大模型的使用，存在工作效率提升和企业经营利润提升不成正比的情况，但是当大家都拥抱AI的时候，谁不拥抱，谁就注定会被淘汰。就像当初苹果的全屏手机的出现，淘汰掉诺基亚一样。
• 随着技术的发展，肯定会涌现出使用AI更高效的创造出更高利润的企业，于此同时，技术肯定也是不断发展的，更便宜的token的技术会不断出现，就像近期的jev的爆火一样，会给AI的广泛应用奠定基础
• AI的发展是势不可挡的，然而世界的底层物质实际上是不变的，我相信AI最终必然会让人类过的更轻松。就像现今的普通人过的日子和古代贵族差不多一样，这个就是人类整体技术发展带来的效应。

二、RAG+LLM企业实战

2.1、整体说明

本文将会就RAG这项技术与LLM的结合，在企业实际生产中的使用，进行相关技术选型记录描述。
接下来，我将会从如下各个阶段的技术选型及实操，结合ClaudeCode+大模型的模式，打通一个真正的企业级RAG+LLM的应用样例

• 索引（Index）：
  • 把知识库切块，向量化，存入向量数据库备查
• 检索（Retrieve）：
  • 用户提问时，找出最相关的top-K文档片段
• 生成（Generate）：
  • 将检索的内容塞入Prompt，让LLM参考作答

2.2、本地开发环境准备

• 在Pycharm中，安装Claude Code(beta)插件，本地安装ClaudeCodeCli，进行相关代码实现
• 在Pycharm中安装ClaudeCode及对接国产大模型，和IDEA中安装ClaudeCode对接国产大模型是一样的。
• 详细配置步骤，可参见我的另一个专栏文章：IDEA搭建ClaudeCode本地环境，对接国产大模型实操指导（IDEA+ClaudeCode+ccSwitch+Qwen）

2.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 (dense+sparse) + RRF 进行融合排序
• 再使用CrossEncoder进行Rerank，提取top3。这里选择：BAAI/bge-reranker-v2-m3 这个ranker大模型，与前面向量化模型BGE-M3配套起来。
  • 下载地址：https://modelscope.cn/models/BAAI/bge-reranker-v2-m3

2.4、生成

• 如果是企业内部生产使用，在生成前，还可以执行一些预处理：这里做成用户可选型，到时我们对比下效果
  • Multi-Query 多角度查询：将用户输入，让LLM生成3~5个改写版，使用原始+改写版，去检索
  • HyDE（Hyperthetical Document Embedding） 假设文档嵌入：先让LLM生成一个假设答案，再用这个答案向量去向量库检索
  • Parent-Child Chunk：检索到小块，返回父级大块，提供更全面的上下文
  • Self-Query 自动过滤：LLM解析查询意图，自动提取过滤条件（时间、作者、类别）。这种一般企业内的AI报表场景比较适合。
• 构建Prompt
  • System Prompt:
    • 你是一个专业助手。请仅根据一下提供的上下文回答问题。如果上下文中没有相关信息，请说【我不知道】，不要编造答案。如果没有检索文档，请回复【无相关知识】
  • Context（检索文档）
    • 【文档1】检索到的内容
    • 【文档2】检索到的内容
  • UserQuestion
    • 用户的原始问题
• RAG检索内容注入Prompt：
  • 这里选择结构化注入，为每个文档标注来源、相关性得分、序号，让用户最终获取的答案可以看到知识来源，达到可信的效果
• 大模型选型：
  • DeepSeek的：https://api.deepseek.com
  • 大模型选择：deepseek-flash

2.5 RAG质量评估

• 根据 Milvus 向量库中的向量，生产测试数据集，进行检索质量评估
• 使用大模型，进行生成质量评估

2.6 检索界面实现

• 创建一个web界面，供用户输入问题，展示完整的RAG执行过程信息

三、本地AI VibeCoding开发

• 提示词：请根据《RAG+LLM_企业实战.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耗时大概在90_{300秒之间。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、检索：检索过程，目前看，走比较完整的 dense+sparse+rrf+reranker+LLM，整体耗时体感还是有点慢的，起码我自己感觉有等待的感觉。
        • 这里从工程角度，可以考虑界面先输出部分检索的rag内容，再逐步吐内容的方式，缓解用户感知
        • 最好的是根据实际业务实验情况，进行部分能力的裁剪，没必要把所有的技术都堆上去
    • 使用直觉：
      • RAG是文本检索，支持同义词的检索。但是本质只是检索，不具备推理能力。所以适用于固定信息的信息检索，无法实现知识库的自动推理总结。
      • 企业的应用场景，是否适合RAG，应当对数据进行分析，判断是否能够达到 小段内容 表达 完整信息 的效果。例如：法律条文、中医经方、客服问答、企业规范等
      • 数据质量、数据规范很重要。必要时使用LLM先执行该操作，达到归一化后，再进行后续的向量化实现
      • 数据分块，需要根据实际的数据规范情况，进行精细化的分块实现设计，不拘泥于固有的市面分块能力
      • 至于技术选型，这个只要了解了整体的技术栈，其实是相对容易的。必要的时候，进行真实实验，辅助选型确定
      • 检索增强：根据实际的业务使用情况，进行检索增强的尝试，权衡取舍。工程能力上，建议是允许用户自由组合配置
      • 性能：用户使用的性能预期，进行实现准确度和性能的权衡。以前我们更多的是安全和性能权衡；现在大模型时代，又多了个 准确性和性能的权衡。有意思
    • 一言以蔽之：
      • 技术就是这些技术，至于怎么组合使用，得基于实际调查，进行最终方案制定。这里祭出下我们伟大的毛爷爷的话：没有调查就没有发言权、实事求是
      • 项目交付，很多时候拼的并不是技术，技术只是工具，更多拼的是深入理解客户需求、解决客户痛点的能力！