企业官网建设流程全解析

做这个《RAG进阶实战》专栏策划案，并不是临时起意。过去大半年里，我前后跟进了好几个RAG相关项目，从企业内部文档问答到个人知识库搭建，几乎每个项目都会撞上同一个怪现象：demo跑得很顺，一上真实数据就露馅。要么答非所问，要么引用的资料根本不是用户想要的，要么把两段毫不相关的内容拼在一起当答案。RAG最吸引人的地方是它把“大模型幻觉”关进了笼子，可真正落地时你会发现，笼子本身同样很难做。

所以我很早就想做一个专栏，不聊“什么是RAG”这种入门话题，而是把重心放在进阶实战上：知识库怎么切分才不丢信息，向量检索怎么调才能召回得准，重排模型什么时候该上，多模态内容能不能放进知识库，以及整个流程怎么在不花钱或者只花很小成本的前提下跑起来。这个专栏对标的不只是技术新人，还包括那些已经跑通过基础RAG、但始终觉得效果不够好、想系统排查优化的工程师和产品同学。下面这篇内容，就是我在筹划这个专栏时候的完整思考，也算是一份可以给同行参考的“专栏策划案”。

1. 专栏策划的来龙去脉：为什么这时做RAG进阶

1.1 RAG从爆火到落地的尴尬期

RAG这个词本身不算新，但大家真正把它当成一个工程问题去对待，也就是这两三年的事。从热门搜索词里能看得很清楚：“rag瓶颈”“rag框架”“rag实战”这些关键词的热度一直在涨，说明很多人已经过了“给大模型加个知识库”的新鲜阶段，进入了一个更务实的状态：关注效果、成本、稳定性。

当前不少团队用LangChain或者LlamaIndex搭一条标准链路，流程无非是load文档、文本切分、embedding、存入向量库、检索、拼Prompt，跑通很容易。可只要换到真实场景，问题就来了。比如同一个PDF，用固定长度切分和按Markdown结构切分，回答质量可以差出好几条街；再比如同一套流程换到垂直领域，通用embedding模型可能完全不顶用，检索出来一堆表面相似但语义不相关的内容。

我见过太多人把精力花在调Prompt上，结果发现调来调去都救不回来。这时候应该回头检查索引和检索链路，而不是继续在生成端较劲。RAG的效果上限，早在进入LLM生成之前就已经定了一半。检索端召不回准确、完整、相关的片段，后面生成端再强也是空转。所以专栏的第一部分，我不想急着教大家写代码，而是先把“为什么demo和实战差距这么大”这件事拆透。

1.2 专栏定位与目标读者

这个专栏的定位很明确：不是入门课，而是进阶实战。目标读者有三类。第一类是已经用LangChain或LlamaIndex跑通过简单RAG，但对效果不满意，想知道问题出在哪的人；第二类是手里有私有文档，想低成本搭建本地知识库，却不知道工具和参数怎么选的人；第三类是做产品方案的同学，需要在RAG、知识图谱、结构化知识库之间做技术选型。

这三类人关注的东西不一样，底层要解决的问题是同一套：如何用可控成本，把检索和生成质量做到真正可用。所以专栏会同时覆盖原理、选型和实操，不会只讲“怎么跑通”，更会讲明白“为什么这样选”“为什么这个方案能扛住真实数据”。

再提一个被问了无数次的关系：RAG和智能体（Agent）是什么关系？我的看法是，RAG是Agent工具箱里的重要工具，但它首先是一个独立的知识增强方案。专栏里会专门有一小节讲两者的边界与协作方式，避免大家把概念搅在一起。说到底，这一系列文章想训练的是拆解问题的能力，而不是带着大家把固定流程抄一遍。

2. 专栏内容规划：从查漏补缺到高阶实战

2.1 章节架构与每篇要解决的问题

我计划把专栏分成四个模块，整体篇目控制在十一篇左右。模块一聚焦概念与选型，解决“我的场景到底适不适合RAG”和“该选哪个框架”；模块二是知识库工程，解决“文档怎么准备、怎么切分、怎么存储”；模块三是检索与生成优化，解决“为什么召不回、为什么答不对”；模块四是部署与评估，解决“怎么上线、怎么度量效果”。

每个模块都按照“问题→方法→案例”的结构来写，不写空泛理论。每篇末尾会附一个“实践检查表”，把当篇提到的关键参数、命令、注意事项浓缩成清单，方便读者直接对照干活。比如在知识库工程篇里，检查表会包含“是否保留了文档标题层级”“是否处理了表格”“切分块之间是否有重叠”这几项。读者照着打勾，就能避免很多低级错误。

框架选型也是一个必须讲透的话题。目前主流选择有LangChain、LlamaIndex、langchain4j easy rag等。LangChain功能最全，但抽象层级多，新人容易迷失；LlamaIndex对文档处理和索引的支持更细致；langchain4j easy rag则适合Java技术栈，轻量、开箱即用，不引入太多概念负担。对于零基础用户，我更推荐先用Ollama这类本地推理工具把链路跑起来，再逐步引入框架，这样理解底层的成本最低。

2.2 重点专题：从热词里提炼出来的实战主题

我平时会留意技术社区里的真实搜索需求，这次看到RAG相关热词时，发现大家在进阶路上最关心的问题高度集中。

第一个高频问题是“RAG能不能存图片”。很多人在做知识库的时候，手上的资料是PDF截图、流程图、产品照片，传统文本RAG确实处理不了。专栏准备用一篇专门讲多模态RAG：先走OCR把文字提取出来，再用视觉模型生成图片描述，最后把描述文本向量化；更进一步也可以直接使用多模态embedding模型给图文统一编码，但这个门槛高一些，会放在进阶篇部分。

第二个高频问题是“RAG的瓶颈在哪”。这类问题往往不是单一原因，而是多个环节同时出问题。我会安排一篇独立的排错专题，从索引、召回、重排、生成四个环节逐个拆解，并给出一个可以复用的排查顺序表。

第三个高频问题是“本地工具怎么选”，比如“有没有本地的RAG文本拆解工具”。这个点很多人不重视，其实是RAG工程里最容易拉开差距的地方。专栏会推荐unstructured、MarkItDown、PyMuPDF、Pandoc等本地可用工具，并给出实际对比。还有底下这些需求，比如“怎么在Mac上搭建RAG知识库”“ollama加简易本地RAG知识库怎么复现”，都会落到专门的操作篇里，保证读者能真正复现。

2.3 专栏更新节奏与内容交付

内容交付形式同样重要。我计划每周更新一篇，整个专栏周期控制在两个月。每篇文章都配一个可以在本地低成本复现的示例项目，示例代码统一放在同一个仓库里，避免大家把时间浪费在环境配置上。这里说的低成本不是随便讲讲，而是真的用一台普通电脑就能跑起来，CPU环境也能接受，不需要昂贵的GPU服务器。

更新节奏上，我不打算追求“一次性写完再发布”。更符合RAG这种快速演进主题的做法，是以问题驱动内容迭代。每篇开头写一个真实用户场景，结尾给一个可以直接套用的方案。如果某个主题发酵出新的问题，比如“在Mac上内存不够怎么办”，我会在对应篇目后面追加一个小节，而不是另起炉灶重新写一篇，这样对读者来说信息最集中。

3. 几个绕不开的技术难点拆解

3.1 多模态内容怎么进RAG：图片存储与检索的三种路径

“RAG知识库能存储图片嘛”这个问题，我先给一个明确结论：普通RAG知识库本质上只能存文本，想把图片纳入进来，必须做一层“翻译”。

第一种路径是OCR后入库。适合扫描件、截图、拍照文档，把图片里的文字变成可检索文本。流程最简单，也是我在实际项目里最推荐的做法。第二种路径是“图生文”。用视觉语言模型把图片内容生成一段描述，把描述文本和原图路径一起存入知识库。这样用户搜“季度营收趋势”，系统能找到那张描述里包含“营收趋势”的图表图片。第三种路径是使用多模态embedding模型，把图片和文本映射到同一个向量空间，实现真正意义上的图文联合检索。但这类模型本地部署成本偏高，对硬件有要求，一般先用前两种就够了。

实际操作中，我强烈建议先想清楚一个问题：你要检索的是图片里的文字、图片的语义，还是图片本身。如果是票据、合同扫描件，OCR就够；如果是流程图、架构图，需要视觉语言模型生成描述；如果是用户希望“按图搜图”，那才需要走到多模态向量模型这一步。想清楚需求边界再去选路径，事半功倍。

3.2 RAG的瓶颈在哪里，如何用工程手段突破

聊“RAG瓶颈”这个话题，不能把锅都甩给大模型。我的经验是，大部分RAG效果差都差在三个环节上。

第一是切分不科学。语义完整的一段话被拦腰截断，检索时片段缺少上下文，模型看到的只是半句话，自然答不准。第二是召回数量太保守。很多人习惯只取TopK=3或5，真正的答案可能排在第七第八位，根本进不了候选集。第三是没有重排机制。向量相似度排在前面的，往往是字面长度碰巧接近的片段，而不是语义上真正匹配的段落。

突破手段其实很具体。切分策略优先考虑结构优先，标题、段落、表格尽量不拆开；召回阶段可以稍微放大TopK，比如取10到20个候选，再用交叉编码器做精细重排。还有一个容易被忽略的优化是query改写：用户问题先经过一次LLM改写，生成几个更利于检索的关键词或子问题，再进入向量检索。这些方法单独看不难，但把它们放到同一条链路上统一调整，效果提升非常明显。这也是我专栏里“性能优化”模块的核心内容。

3.3 RAG与知识图谱、结构化知识库：不是替代关系，是配合关系

在热词里“rag知识库和结构知识库区分”“ontology rag”“kg知识库”这些出现得很频繁，说明大家在选型时确实困惑。我用一个生活化的比喻来讲：RAG像开卷考试时带了一堆参考书，边查边答；知识图谱像一张关系网，适合回答“谁和谁是什么关系”这类需要精确推理的问题；结构化知识库更像一本账本，每个数字都是确定性的，不能含糊。

实际项目里怎么选？如果业务数据是强规则、强关系的，比如员工档案、组织架构、供应链上下游关联，优先用知识图谱或结构化查询，不要硬套RAG。反过来，资料是大量非结构化文本，比如合同、报告、FAQ，用RAG更合理。最理想的做法是两者结合，先用KG或本体做实体识别和关系过滤，把候选集范围缩到很小，再让RAG在候选文档里做阅读理解。也就是说，“ontological RAG”这类实践不是推翻RAG，而是给RAG加了一副眼镜，让它看得更准。

为了让大家快速看懂区别，我在这份策划案里放了一张对照表：

这张表我会直接用在专栏里，帮助读者对号入座。

4. 实操环节：搭建一个可复用的本地RAG项目

4.1 工具选型：Ollama加向量库的零基础可复制方案

很多朋友在搜“ollama + 简易本地 rag 知识库【零基础可复制教程】”，这个需求非常真实。所以专栏实操篇的第一课，就是带大家搭一套最简但可扩展的本地RAG。

选型思路是这样：大模型用Ollama托管，省去自己写CUDA推理代码的麻烦；Embedding模型选bge-m3这类中文友好的模型；向量库选Chroma或Qdrant，两者都能通过Docker一键起服务，也可以直接嵌入到Python进程里。在Mac上搭建时，要额外注意Apple Silicon的内存占用和模型量化级别，这些细节都会单独立一个小节来写。

核心命令其实不多：

# 安装Ollama并拉取一个适合本地推理的模型 curl -fsSL https://ollama.com/install.sh | sh ollama pull qwen2.5:7b # 拉取embedding模型 ollama pull bge-m3 # 使用Docker启动Qdrant向量库 docker run -p 6333:6333 -v qdrant_storage:/qdrant/storage qdrant/qdrant

这几个命令跑完之后，本地推理模型、向量模型、向量数据库就都齐了。接下来需要做的就是用Python脚本读取文档、切分、向量化、写入集合。专栏里会把这段脚本完整拆开讲，并且解释每一行代码背后的设计意图，而不是丢一个“复制就能用”的黑盒。

4.2 本地文本拆解工具与切分策略

“有没有本地的RAG文本拆解工具”这个问题，答案非常肯定：有，而且选择不少。文档拆解不是简单地把txt按字数切块，而是要处理PDF、DOCX、Markdown、HTML等格式，还要尽量保留文档本身的逻辑结构。

本地可用的工具，我推荐三类。第一类是通用解析库，比如unstructured，能识别标题层级、表格和列表结构，输出带结构信息的分块；第二类是轻量转换工具，比如MarkItDown，能把各种格式转成Markdown，方便后续处理；第三类是专用库，比如PyMuPDF适合高效处理PDF，Pandoc适合在几十种文档格式之间互相转换。

切分策略方面，很多朋友习惯无脑用固定窗口，比如512字符一切，这是很多场景下效果差的直接原因。正确思路应该是先按文档结构切出一个“语义块”，标题、章节、段落尽量保持完整；如果这个语义块仍然太长，再在块内做小窗重叠切分。简单说就是“结构优先、重叠兜底”。专栏里会给出一套可以直接套用的切分模板，同时提醒大家注意：表格、代码块、引用这些特殊元素要单独处理，否则信息最容易在这里丢失。

4.3 检索增强与问答联调的关键步骤

搭建完成之后，重头戏是调通“检索增强”这条链路。标准流程是：用户问题先做归一化，再向量化，然后在向量库中召回TopK个候选块，经过可选的重排后，把候选块拼进Prompt，最后让Ollama里的本地模型生成答案。

这里有一个很多教程不会重点讲的细节：Prompt里的上下文不要一股脑全塞进去，而是按相关度排序，并显式告诉模型“优先基于提供的资料回答，资料里没有的信息如实说不知道”。这个简单的约束能显著减少幻觉。

联调过程中，我建议先在检索环节做单点验证。具体做法是直接打印召回的文本片段，人工看一下这些片段是不是用户问题真正需要的。如果检索结果本身就不准，就别急着调整生成Prompt；如果检索结果准了，回答还是不对，再去检查Prompt和模型能力。这个排查顺序能节省大量时间。

5. 真实踩坑记录与排查思路

5.1 检索结果质量差，先别怪大模型

说一个真实项目里的排错案例。某个项目要回答“某某流程的审批时限是多少”，系统反复答错，一开始大家以为是模型理解能力不够。可我直接查看召回结果后发现，系统召回的全是流程总则的内容，而真正包含审批时限的表格根本没有进入知识库。原因是PDF里的表格在解析时被当成了图片丢弃，连文本层都没留下。

后来用MarkItDown把PDF转成Markdown，保留了表格结构，再重新切分入库，问题立刻解决。这个案例给我最大的提醒是：RAG里的大部分错误，发生在“文档进得不够好”的环节，而不是大模型本身。所以排查的第一条原则永远是：从输入端开始查，而不是从输出端猜。

其实这个排查思路在所有RAG项目里都适用。先确认数据源有没有被正确解析，再看切分有没有破坏语义，然后看召回结果是否命中，最后才轮到生成端。每一步都可以用一个很小的测试集来验证，而不是直接拿一个模糊的“效果不好”来反复试Prompt。

5.2 资源占用与部署问题

本地部署最现实的坑，是内存和模型大小。很多朋友一上来就拉一个14B甚至更大的模型，结果检索和推理一起跑，普通笔记本风扇直接起飞，响应速度降到十几秒，体验非常差。

我的做法是：推理模型用7B级别的量化版本，Embedding模型单独用一个小模型，两个模型分开跑；向量库放在Docker里但限制内存上限；如果文档量不大，甚至可以用SQLite加向量扩展这种更轻的方案。这些细节在专栏里都会做成一个“资源规划表”，让读者根据自己的机器配置对号入座，而不是盲目追求大模型。

另外，检索和生成尽量拆成两个独立服务，避免互相抢占资源。可以先调用检索接口看反馈速度，再调用生成接口，一步步定位响应瓶颈到底在哪。很多本地RAG跑得慢，不是单点性能不行，而是两个服务放在同一个进程里互相拖累。

5.3 专栏内容迭代：用问题驱动保持生命力

到这一步，我想顺带说说做这个专栏的真实体会。RAG技术变化太快，四个月前觉得最优的方案，下个月可能就被新模型或新框架取代。所以我不会把这个专栏当成一套“写完就定稿”的丛书，而是把它当成一个持续迭代的实战项目。

每一篇发布之后，我会根据读者提问和新的技术动态补充“更新记录”。比如“langchain4j easy rag”这种轻量Java方案出现后，要在框架对比篇补上一段；多模态embedding模型成熟之后，图片存储专题也要随之升级。这种维护方式确实会增加工作量，但专栏的生命力也会更强。

我个人觉得，做技术内容最怕的是“自说自话”。把每个章节都拿去真实项目里验证一遍，把每个示例项目的依赖都精简到最少，甚至把已经写好的代码再推倒重来一次，这些投入都是值得的。如果你也在做自己的技术专栏，我的建议只有一条：每一个案例都请自己在本地跑通后再发布。那不是浪费时间，反而是最有效的备课方式。