开篇先聊点实在的。今年做AI应用，如果只让我推荐一个最值得投入的技术组合，我会毫不犹豫选“RAG + Wiki”。这八个字几乎覆盖了目前企业级知识问答、个人知识库、文档助手的最优解：RAG负责“精准找答案”，Wiki负责“体系化长知识”。前者解决大模型幻觉和私有知识缺失的问题，后者解决知识从哪来、怎么持续维护的问题。两个词拼在一起，就是一个能落地、能迭代、效果可评估的完整系统。
我前后折腾过几个知识库项目，从早期拿PDF硬喂给大模型，到后来用LangChain搭RAG流程，再到把Wiki文档作为唯一知识源跑通Agentic RAG，中间踩过的坑不算少。这篇就把我对“RAG找答案，Wiki长知识”这套组合的完整理解写出来，包含方案选型的思路、关键环节的实现细节、我在实际项目里遇到的问题和排查过程。如果你是刚接触RAG的新手，或者已经在用LangChain但效果不理想的同学，这篇会很对胃口。
1. 先想清楚：RAG和Wiki到底怎么配合
1.1 RAG的本质是“检索 + 生成”，不是魔法
很多人第一次听到RAG（Retrieval-Augmented Generation，检索增强生成）时，总觉得这是一个高深莫测的模型架构。实际上它的核心逻辑特别朴素：让大模型回答问题时，先“翻书”再“说话”。
传统的大模型问答是纯靠参数记忆生成答案，你问什么它直接吐什么。这在通用知识上表现不错，但放到企业内部场景就露馅了——公司内部的流程规范、产品文档、历史项目记录，这些私有知识根本不在模型的训练数据里。你问“咱们公司的报销单需要几个层级审批”，模型只能靠猜，猜出来的结果谁也不敢拿去执行。
RAG的做法是把问题拆成两步：先从知识库里检索出相关的文档片段，再把“问题 + 检索到的片段”一起交给大模型，让模型基于这些片段生成答案。这样答案就有了出处，有据可查，模型不容易一本正经地胡说八道。整个过程不用重新训练模型，成本低，知识更新快，这几乎是目前落地AI问答最务实的一条路。
1.2 Wiki是知识库的理想形态，不只是一个网站
聊到Wiki，很多人第一反应是维基百科，或者某些游戏攻略站（比如热搜词里那个“英灵神殿Wiki”）。但站在知识库建设的角度，Wiki代表的是一种“多人协作、持续更新、相互链接的知识组织方式”。
我特别推崇Wiki作为RAG知识源的原因有三个：
第一，Wiki天然有结构。一个成熟的Wiki不是零散的txt文件，它有目录、有分类、有页面之间的跳转关系。这些结构信息本身就是很好的元数据，在做文本拆解和检索时可以大幅提升精度。
第二，Wiki有版本管理能力。知识库最怕的不是内容少，而是内容过时。Wiki保留了每次修改的历史记录，团队可以追踪知识的演进，RAG检索的内容永远可以对齐到最新版本。
第三，Wiki的“页面”粒度恰好适合RAG的检索粒度。RAG需要把长文档切成小块再向量化，而Wiki一页一个主题的形态，天然就是主题粒度清晰的知识单元。
1.3 这套组合适合谁，不适合谁
适合的人，我总结成三类：
- 企业内部做知识问答系统，希望员工可以用自然语言直接问出制度、流程、文档里的答案。
- 个人或小团队维护一个长期增长的知识库，想用大模型盘活这些沉淀内容。
- 做垂直领域工具型产品（例如法律助手、设备维修助手、教学助手）的开发者，需要让AI真正理解领域语料。
不适合的场景也要说清楚：如果你的知识是高度动态的（比如实时行情、股价的数据表），RAG的检索时延和数据更新链路可能跟不上；如果你的问题全部是简单的事实型问答（比如“现在几点”），直接用模型能力就够了，没必要上RAG；如果知识库里的内容质量本身就很差——到处都是复制粘贴的马赛克文本，RAG跑得再稳也白搭。
2. 准备工作和方案选型，先把地基打牢
2.1 技术栈怎么选：我的一贯原则是“本地优先”
现在做RAG的框架选择非常多。最知名的是LangChain，如今已经演进到LangChain4j这类Java版；Spring AI也在往RAG方向发力；还有Agentscope 2.0提出了“RAG as a Service”的封装思路。框架层面的繁荣说明一件事：RAG的标准化程度已经很高了，真正拉开差距的是工程细节和知识源质量。
我的选型原则一直都是“能本地跑就不要先上云”。好处是零成本试错、数据不出内网、调试方便。具体技术栈我给一个我跑通过的组合：
- LLM推理引擎：Ollama，本地跑开源模型，零基础也能照着命令装好。
- 文本向量化模型：BAAI/bge系列，做中文检索效果稳。
- 向量数据库：先本地sqlite-vss或ChromaDB起步，数据量大再换Milvus、Qdrant。
- 编排框架：LangChain或者LlamaIndex，按需取用。
有人会纠结“LangChain太重了，要不要直接自己写RAG流程”。我的建议是，如果你从来没写过RAG，建议先用LangChain或LlamaIndex这类框架把流程跑通，不要一上来就手搓。等你真正理解了每个环节在干什么，再决定要不要剥掉框架。
2.2 环境搭建的几个关键动作
以我常用的本地方案为例，环境准备需要这几步：
第一步，保证机器显卡至少6GB以上显存，纯CPU推理不是不行，但回答一个问题的等待时间会让人崩溃。我用的是NVIDIA显卡就配CUDA环境，Apple Silicon的机器则直接用Metal加速。
第二步，安装Ollama并拉取模型。选模型有几个考量维度：中文能力、上下文长度、硬件开销。我实测下来，7B到14B参数量的量化模型（比如Qwen2.5 7B）在普通消费级显卡上跑RAG是比较舒服的区间，既能保证一定的推理质量，又不至于把整台机器拖垮。
第三步，把Wiki的导出内容准备好。绝大多数Wiki系统（包括Confluence、MediaWiki、语雀、飞书文档里的Wiki）都支持导出Markdown或HTML，要构造RAG知识库就优先导出为Markdown格式。Markdown干净、可读、结构信息保留完整，后续做文本拆解时比PDF好处理太多。
这里有个特别容易踩的坑：很多人把PDF直接丢进向量库，结果检索效果差到怀疑人生。PDF的文本提取过程中常见乱码、错位、表格错乱，这些噪声会直接拉低embedding的质量。所以我的原则是——能拿到Markdown就不要用PDF，知识库建设的第一质量关卡就是源文件格式。
2.3 数据准备：Wiki的结构化信息是金矿
拿到Wiki导出的Markdown之后，别急着一股脑切块向量化。先做一轮简单的清洗和结构识别：
第一步，把Wiki里的导航页、编辑模板、系统自动生成的索引从知识数据里剔除，这些不是知识，是“页面的脚手架”。
第二步，把页面标题、标签、目录层级这些元数据提取出来。标题和目录不是没有用的信息，它们应该作为每个文本块的“上下文标识”存储起来，检索时刻意让模型参考这些上下文，效果会明显提升。
第三步，处理Wiki里的链接和引用。Wiki页面之间互相链接是常态，如果把这些链接忽略掉，等于丢掉了知识之间的关联关系。高级一点的做法是构建知识图谱做GraphRAG，基础的做法是把链接锚文本替换成对应的实体名，这样检索时“报销审批”这个锚文本就不会被机械地丢掉。
3. 核心实现细节，逐层拆开讲
3.1 文本拆解：决定了检索精度的“第一道闸门”
这里我要先明确一个概念：跟“RAG文本拆解工具”相关的热搜词会比较多，有人问“有没有本地的RAG文本拆解工具”，其实拆解不一定要靠专用工具，框架内置的Splitter就够用，关键是你得理解拆解的逻辑。
RAG检索的最小单位是“文本块”（chunk），文本块怎么切，直接决定了后续向量检索的命中质量。切得太大，一个块里塞了太多主题，向量化后语义模糊，检索出来“好像相关但找不到具体答案”；切得太小，语义不完整，检索出来“细节对但缺乏上下文”。
我在实践中最常用的是递归字符切分（Recursive Character Splitter），它不是按固定长度硬切，而是按照段落、句子、标点符号的优先级逐级递归切分。实际操作中，我把块大小设置在500到800个token之间，重叠量设置在100到150个token之间。
这组参数不是拍脑袋定的。我做过对比实验，块太小（200 token以下）时，检索返回的段落经常是“一句话的碎片”，大模型很难从里面找到完整的因果逻辑；块太大（1200 token以上）时，跨主题的噪声明显增加，命中率反而下降。500到800这个区间在我处理的技术文档、制度文档、操作手册时表现最稳。
当然，切分策略还要根据Wiki页面的实际结构微调。如果页面本身就有清晰的二级标题结构，更推荐的做法是“按标题切块”，每个标题下的一整段内容作为一个块，同时把标题本身作为块的摘要标签。这样检索的时候，即使正文没命中，标题命中也能把候选捞回来。
3.2 向量化与索引：embedding模型的选型决定了“语义理解”的上限
文本拆好之后，下一步就是把每个块变成向量。这个环节里，embedding模型的选择是最值得投入精力的。
目前社区常用的embedding方案可以分为几类：
- 通用英文向量模型：OpenAI的text-embedding-3-small、Cohere的embed模型等，英文效果好，但直接处理中文会打折扣。
- 中文优化的向量模型：BAAI/bge-large-zh、m3e-base中文版，中文文档的语义匹配效果明显更好。
- 多语言模型：multilingual-e5-base、bge-m3，适合中英混杂的文档。
我做中文知识库的经验是，别偷懒直接套英文模型，而是用bge系列的中文向量模型。特别是在技术文档里，中文表达习惯跟英文差异很大，比如“报销单需要三个层级的审批”这种话，英文模型理解起来就比较容易飘。
索引构建时还有个常被忽略的细节：要不要加元数据过滤器。比如你的Wiki里有“产品文档”和“运维手册”两个大类，检索时可以先按类别过滤，再走向量召回，这与“先粗筛再精排”的思路一致。具体实现是在向量库的record里存一个metadata字段，查询时把它作为filter条件即可。
我在一些项目里会把“关键词倒排索引”和“向量索引”做组合，先用BM25做关键词精确匹配，再用向量做语义召回，最后合并结果去重。这种混合检索（Hybrid Search）在技术文档场景下比纯向量检索稳不少，因为很多专业术语（比如“鉴权”“幂等”“回滚”）用明文关键词搜更靠谱，语义向量反而会把它“翻译”得变形。
3.3 检索策略：从Naive RAG到Agentic RAG的升级路径
单独的向量检索只能在这个流程中扮演“召回器”的角色，整个RAG系统的体验高度依赖于检索策略的设计。
初阶形态是Naive RAG：问题进来，embedding化，到向量库检索TopK个块，拼进Prompt，交给LLM生成答案。这个流程很简单，但问题也不少：
第一，问题本身可能很复杂，比如“这个接口在什么情况下会返回超时错误，我应该怎么排查”？它包含了条件、场景、对象好几个子问题，直接拿整句去检索往往抓不到最匹配的块。
第二，知识的分散性很强，答案可能散落在Wiki的多个页面上，单次TopK检索覆盖不够。
升级走向是Agentic RAG：让LLM作为“路由”和“规划器”，先去理解用户问题，拆解出多个检索需求，然后逐一去检索、汇总、冲突消解，最后再组织答案。
我实际跑过一层“不够就再搜”的自适应检索流程：第一轮用Top5向量检索，把结果交给LLM判断是否足以回答问题；如果LLM认为信息不足，就触发第二轮查询，更换关键词再检索；最多循环两轮。实测下来，这个策略能把涉及多页面的复杂问题解决得比较好。
如果想要更进一步，就是GraphRAG和Ontology RAG，它们把知识之间的实体关系显式建模成图，再结合图遍历做检索。这个方向非常适合Wiki这种“页面之间天然有链接”的知识库。但它的实现复杂度也比较高，需要在Wiki页面里提取实体关系，并维护一个知识图谱结构，我建议等基础RAG跑通了再考虑要不要升级。
3.4 生成环节：让大模型可靠地“照着资料说话”
检索做完，最后一步是生成。别小看这一步，同样的检索结果，Prompt写得好不好，答案质量能差出一截。
我给生成阶段设计的Prompt结构至少包含四个部分：
- 角色约束：明确告诉模型“你是企业内部知识助手，只基于提供的资料段落回答”，这是抑制幻觉的第一道防线。
- 检索到的文档块：一律按编号提供，并保留来源标题，方便回答中引用。
- 问题本身。
- 输出格式要求：比如“如果资料中找不到答案，请直接说不知道，不要编造”。
实际操作中，我会要求模型在回答末尾列出引用的文档标题。这样做有两个好处：一是倒逼模型忠实使用检索结果，二是一旦答案出问题，使用者可以快速回溯到原始文档核对。
有一点点实现里比较关键的细节：大模型有所谓的“上下文注意力偏移”现象——放在Prompt中间的信息容易被忽略，放在开头和结尾的信息利用率最高。所以构造Prompt的时候，我会尽量把检索到的核心段落放在开头或紧邻问题输出处，避免把一堆不相关的块堆在中间。
4. 实操演示：从零搭一套“Wiki知识库+RAG问答”，含完整可复现步骤
4.1 第一步：准备好你的Wiki内容和Ollama模型
我在测试环境里拿了公司内部一个操作手册Wiki的Markdown导出目录作为样本，目录结构大概长这样：
- wiki/快速开始.md
- wiki/账务处理/普通报销.md
- wiki/账务处理/差旅费报销.md
- wiki/权限管理/审批角色.md
- wiki/故障排查/接口超时.md
然后拉取模型。我常跑的模型是qwen2.5:7b和bge-m3，前者做生成，后者做向量化。Ollama的命令很简单：
ollama pull qwen2.5:7b ollama pull bge-m3如果你准备在NVIDIA显卡上跑，记得先确认驱动和CUDA版本，不然模型推理会非常慢。
4.2 第二步：做一个可复用的RAG流程脚本
我不打算贴一整个生产级项目代码，因为每个团队的工程环境差异太大。我更建议用Python写一个最小可运行、可魔改的脚本，重点是理解流程反而更重要。
核心流程拆解如下：
# 1. 加载Wiki导出的Markdown # 2. 对每个文件做文本拆解（使用递归字符切分，chunk_size=600，overlap=120） # 3. 调用embedding模型对每个chunk生成向量 # 4. 把向量 + 文本 + 元数据（来源文件路径）存入向量数据库 # 5. 检索：问题向量化 -> TopK召回 # 6. 生成：构造Prompt + 调用LLM这里的代码量其实很少，难的是数据清洗和参数调优。
我建议把知识库的构建脚本和问答服务拆成两个独立模块。构建脚本负责“文档进 -> 向量出”，问答服务负责“问题进 -> 答案出”。这样每次知识库更新只管跑构建脚本，问答服务不用重启，数据一致性也更好控制。
4.3 第三步：搜索“RAG找答案”的真实效果对比
搭好之后，我拿几个典型问题测试了一遍效果：
问题一：“差旅费报销的审批流程是什么？”这个问题的关键词在Wiki标题里就命中，检索阶段非常顺利，返回的两个块都包含审批节点。生成的回答准确，且能列出“申请—部门主管—财务复核”等具体节点，符合文档原文。
问题二：“接口超时应该怎么排查？”这个问题难度上升了，因为“接口超时”在文档中可能分散在多个页面，单靠向量检索可能只抓到一段分析，不够完整。这时候我的自适应检索循环就起作用了——第一轮检索返回的内容被模型判定信息不足，触发第二轮以“超时 + 排查步骤”为关键词的检索，补充了日志分析的步骤，最后答案质量明显提升。
问题三：“员工入职当天需要准备哪些材料？”这个问题属于知识库没有明确对应页面的场景。我设计的Prompt让模型在找不到答案时直接说“知识库中暂无相关内容”，模型果然没有硬编，而是如实反馈。这在知识问答场景中是正确行为，比胡编乱造强太多。
4.4 评估环节：别只看回答“像不像”，要看“命中率”和“忠实度”
RAG项目上线前的评估是很多人忽略的环节。很多人只是拿几个问题人工看一下回答，觉得“看起来还行”就上了，最后往往在真实使用中被吐槽得体无完肤。
我用的评估指标主要有两个：
第一个是检索命中率（Hit Rate），把每个测试问题对应的正确答案所在的文档块标记为ground truth，然后看TopK检索结果里是否包含正确答案。这个指标衡量的是“知识有没有被找到”，如果命中率太低，后面的生成再怎么调都白搭。
第二个是答案忠实度（Faithfulness），检查模型生成的回答是否严格基于检索到的文档内容，有没有虚构额外的信息。我常用的做法是把“回答”和“检索到的文档块”一起再喂给一个评测模型，让它逐一判断回答里的每个事实点是否能在文档中找到依据。
一组有参考意义的实测数据：直接跑Naive RAG，Hit Rate大概在65%左右；优化文本拆解参数和加入标题元数据之后，提到78%左右；再加上混合检索和自适应循环之后，能接近88%。生成端的忠实度从87%提到了93%左右。说实话，想要接近满分，单纯靠调参是不够的，更多还是要回到知识库本身的覆盖度和内容质量上去补。
4.5 迭代维护：Wiki内容更新之后，知识库怎么保持同步
Wiki的实际特点是“每天都在变”。今天有人改了差旅费的报销上限，明天有人新增了一个权限角色，如果知识库不及时同步，RAG就变成了“带病运行”。
我的同步策略非常简单但有效：增量构建。先给每个Wiki页面记录一个来源路径和文件哈希值，每次构建脚本扫描文件时，只对哈希变化的页面重新拆解、重新向量化，并在向量库里替换对应的旧记录。这样即使全库有几百个页面，每次更新只需要处理几个变动页面，全量构建的时间和算力成本都降了下来。
如果你用的Wiki系统本身支持API，还可以把同步做成定时任务，每天凌晨自动拉取新增和修改的页面。这个方案我跑过几个月，稳定性和及时性都很不错。
5. 常见问题与排查技巧，都是我自己踩过的坑
5.1 RAG“找不到答案”的常见原因与排查思路
最典型的问题是：问了一个明显在文档里有答案的问题，但RAG回答“不知道”。这时候不要先去调生成Prompt，而是先怀疑检索。
排查步骤我一般这么走：
第一，确认问题本身有没有被embedding模型理解好。可以单独打印出问题的向量，和候选文档的向量做一次余弦相似度对比，看看分数是不是全都很低。如果相似度普遍过低，可能是问题表述和文档表述差异太大（比如用户说“打车钱怎么报销”，文档里写的是“交通费报销”），这种情况下要用混合检索或者改写查询词。
第二，确认TopK取值是否过小。如果你只返回Top3，而相关文档排在第四名，那就被硬生生截掉了。初期调试可以先把TopK放到10，看清楚召回效果再决定缩不缩。
第三，确认切块是否把答案切散了。比如一个完整的流程被切成两半，并且两块之间又没有重叠，检索时很可能只召回半段。检查一下Ground Truth落在哪个块里，是不是正好被切断，就可以判断。
另外一个很隐蔽的问题是多个文档块内容重复。比如Wiki里有两个页面都粘贴了同一段内容，检索时重复内容占掉了多个TopK名额，反而把真正相关但内容不重复的块挤出了候选。解决办法是在构建知识库时做一个去重操作，比如基于MinHash对高相似度的块做过滤。
5.2 检索命中率（Hit Rate）上不去的深层原因
如果Hit Rate长期停滞在70%以下，通常不是某一环节的配置问题，而是“检索目标”和“文档形式”之间存在根本错配的问题。
我在数次失败里总结出的三种情况：
第一类，文档是非叙述性的：表格、列表、步骤序列。表格的语义信息在向量化时特别容易丢失，因为“行”和“列”的交叉关系在embedding的向量空间里没有太好的表征方式。后来我把Wiki里的表格转成Markdown原文，并且按行和按表分别生成两个块：按表的块保留全表给模型推理，按行的块作为一个检索入口。效果好了不少。
第二类，问题描述很口语化，文档却是高度术语化。这时候光靠“检索一遍”很难一次命中，我的做法是引入“查询改写”环节：LLM把口语化问题改写为更接近文档风格的检索式表述。例如“打车钱怎么报销”改写成“交通费用报销标准”。
第三类，知识分散且隐含。比如“入职流程”涉及系统权限开通、门禁卡发放、导师分配等多个页面，没有一页能直接回答全部流程。这种问题想要用RAG直接一次回答到完美，本质上不太可能靠Naive RAG完成，必须引入Agentic RAG的多轮检索。
5.3 本地模型部署的坑：显存、性能与配置
如果你用Ollama做本地部署、跑7B模型，常规配置下可能遇到两个适得其反的问题：
第一个是显存不足导致模型运行在部分CPU模式，推理速度骤降。解决思路是把模型量化版本换低一点（比如Q4_K_M），或者换一个更小的模型（3B/4B）。别嫌模型小，做问答不是写长文，7B在RAG场景下已经能给出相当不错的答案。
第二个是内存溢出。Ollama默认会把模型的一部分加载到内存做缓存，如果同时跑embedding模型和生成模型，内存占用很容易冲高。我的建议是拆成两个服务分别跑，或者共用一台机器时把embedding模型固定在进程常驻的模型容器里，不让它反复加载卸载。
第三个是生成速度的体感优化。RAG场景里用户能接受的响应时间上限是10秒左右，超过这个阈值，体验断崖式下降。除了靠硬件性能，还可以在“检索耗时”上做优化——向量维度不要太夸张（1024够用了），索引文件尽量完全加载到内存而非磁盘读取。我用ChromaDB时有过一次磁盘IO卡顿的教训，后来把索引文件换到SSD并在启动时预热加载，检索延迟从300毫秒降到50毫秒以下。
5.4 关于Agentic RAG和Ontology RAG的实践选择
不少朋友问我“要不要直接上Agentic RAG”或者“要不要一步到位做GraphRAG”。我的回答是：先看你手里的知识库形态。
如果你的Wiki只有几百页纯文本描述，不需要图谱就能检索得很好，GraphRAG属于过度设计——它需要构建实体识别、关系抽取、图存储，维护成本不低，但收益增量却未必大。
如果知识库已经是强关联形态，比如产品文档之间大量互相引用、故障案例和解决方案相互交叉，那可以考虑在基础RAG稳定之后，从中抽取出“实体-关系”结构升级为GraphRAG。不过在动手之前，我仍然建议先跑一遍基础RAG，把命中率评估结果拿到手，再判断是否值得用图结构提升这一层。否则连对比的基准都没有，升级了也看不出好坏，这跟做性能优化时先建立baseline的思路一模一样。
6. 一点更具体的工程建议
6.1 必做的三件“小事”
我想把三个看起来小事、实际影响很大的细节再强调一遍：
第一个，把来源列在回答里。别嫌丑，会显著提升用户对系统的信任度。我们内部落地的时候，最初版本回答里没有来源，同事看到答案总是带着怀疑来追问“你确定吗”；加了来源之后，质疑声少了大半，大家还会主动点开原文核对。
第二个，记录每次问答的日志。至少把“问题、检索到的块、模型输出、用户反馈”存下来，这是一份天然的金矿。知识库有哪些内容空缺、哪些文档写得让大家看不懂，都会在日志里暴露出来。我靠日志做了一轮文档补写，把问题反馈率压低了接近六成。
第三个，做一个简单的“拒答”策略。当所有检索结果的分数都低于阈值时，直接告诉用户“没找到相关内容”，而不是硬拉着低置信度的文档生成答案。这个阈值怎么设？用一批已知无关问题跑一遍，观察它们的相似度分数分布，取一个分值上限即可。我做过一批一百个无关问题的测试，检索相似度分数通常在0.45以下，而相关问题的分数普遍在0.6以上，中间这个间隙就适合做拒答阈值。
6.2 知识库的质量比模型质量更重要
最后说一个我在实践中体会最深、也是最有价值的一点：在RAG系统里，知识库的数据质量决定了下限，模型只是锦上添花。
一个糟糕的Wiki，哪怕用上最强的LLM和最好的embedding模型，检索回来的都是残缺、过时、互相矛盾的内容，再聪明的模型也变不出正确答案。反过来，一个组织良好、内容精炼的Wiki，哪怕只用7B的本地模型，跑出来的效果也足以满足日常问答需求。
所以我整理的RAG实践路径其实是这样的：先把Wiki整理好，再跑通基础RAG，评估Hit Rate和忠实度，最后根据评估结果决定要不要加Agent、要不要上图谱。这套路径我走了三遍，每一遍都验证了“数据第一，模型第二”的判断。
拿“Wiki长知识”这个说法来总结：Wiki本身不是用来“存储”的，而是用来“生长”知识的。每个页面、每个链接、每次修订都是知识的增量。RAG则是给这些增量配了一把高效的“取用钥匙”。两者搭在一起，才算真正把沉淀的知识变成了随时能调用的资产。
如果你正准备在自己的项目里搭一套RAG，我的建议是，不要急着追热点框架、不要迷信SOTA模型，先把自己手头的资料整理成一份规范清晰的Wiki，然后跑通最朴素的那条RAG流水线，看看效果，再一点点调。这套路不会出大错，而且每一步的提升你都能看得见。
