企业官网建设流程全解析

demo阶段跑通的RAG知识库，十个里有八个一上生产就露馅：昨天上传的合同今天就搜不到，PDF里的表格检索出来变成一团乱码，索引重建跑了一个小时，期间用户问什么都返回不了结果。你排查到最后往往会发现，问题根本不在Prompt，也不在大模型选得多强，十有八九出在知识库的“进料口”——文档上传与索引重建这两个环节。我一直认同一个说法：RAG系统的实际效果上限，早在文档进入知识库的那一刻就定了。这篇文章围绕RAG知识库的文档上传与索引重建，把我踩过的坑、验证过的方案、沉淀下来的工程做法完整写出来，适合正在搭建或调优RAG知识库的工程师，也适合那些已经跑通demo但生产环境效果不佳的团队。

1. 先把“进料口”拆明白：一条文档从上传到可检索的完整链路

1.1 为什么说RAG的瓶颈往往出在进料端

聊RAG瓶颈的人很多，但大部分讨论都集中在召回率、重排序、上下文压缩这些检索侧问题。实际做过的团队都有体会：检索质量的天花板，在文档进入系统的那一刻就已经被定死了。如果文档解析漏了内容、分块切碎了语义、元数据丢三落四，后面接再强的Embedding模型、再贵的重排序，也只能在残缺的地基上打转。

RAG的完整链路可以概括为三条：文档进料、索引检索、生成回答。第一条最不起眼，却决定了后两条的上限。我自己经历过一次印象很深的对比：同一批合同文本，什么都不改，只把分块策略从“固定500字硬切”换成“按条款编号切分”，再配合文档类型元数据过滤，检索命中的准确率从70%出头直接拉到90%以上。那之后我再没怀疑过进料端的价值。

1.2 进料口完整链路：从文件流到向量库

一条文档从上传到可被检索，至少要经历这么几个环节：

1. 文件上传：客户端把文件传给服务端，涉及大小限制、分片、断点续传。
2. 格式识别：根据扩展名和Magic Number判断是PDF、Word、Markdown还是扫描件。
3. 内容解析：把二进制文件转成纯文本或结构化文本，扫描件要过OCR。
4. 内容清洗：去掉页眉页脚、重复标题、乱码字符，保留表格和标题层级。
5. 文本拆解：把长文切成适合Embedding的块，这一步直接影响检索质量。
6. 向量化：用Embedding模型把每个块变成向量。
7. 索引写入：把向量和元数据送入向量库，同时更新文档登记表的状态。

可以把这个链条类比成图书馆的采编流程：收书只是第一步，还要拆封、编号、上书架、更新目录卡。目录卡没更新，书放在库里也查不到；书编错了号，查到了也是错的位置。RAG知识库里的“编目”环节，就是分块、向量化、元数据登记这三件事。

1.3 知识库的几种常见范式：RAG、结构化知识库与知识图谱的边界

做知识库选型时，很容易被“知识库的代表范式”这类问题绕晕。按我现在的经验，常见范式就三类，加一个混合体：

RAG适合“我不知道答案在哪，但我知道文档里一定有”的检索场景；结构知识库适合“字段明确、查询确定”的场景；知识图谱则适合“实体之间关系复杂、需要几跳推理”的场景。实际项目很少有单打一的，常见的是RAG做非结构化文档入口，命中后把结果再喂给KG做关系校验，或者反过来用KG里的实体表做检索过滤。Ontology增强的RAG就是在这个方向上做文章：用本体定义实体和关系，约束分块和检索的边界。

2. 文档上传层最容易翻车的细节：格式识别、图片附件与去重

2.1 文件落地之前，先设计一张文档登记表

很多人做文档上传，就是把文件存到OSS/MinIO，然后立刻扔给分块脚本，跑完就以为万事大吉。结果就是：文件到底有没有被处理？处理到哪一步了？失败了是哪一步失败的？全凭猜。生产环境不允许这种盲人摸象，我建议在没有写任何解析代码前，先建一张文档登记表。

这张表不需要很复杂，但字段要覆盖全生命周期的观测点：

有了这张表，你才能写出“查询为什么慢”“这个文档为什么搜不到”这类问题的第一个SQL。状态机里有一个容易漏的状态：failed。处理失败的文档必须留痕，否则用户上传后石沉大海，你还不知道问题出在PDF密码加密还是OCR服务挂了。

2.2 文件去重：光有SHA256还不够

文件去重是上传层最容易被低估的环节。最简单的做法是存文件时算一个SHA256，重复就拒绝。但实际使用中，大量场景是“同一个文档改了半句话又传了一遍”，这种文件SHA256完全不同，语义上却是高度重复。如果不去重，向量库里会出现同一篇文档的大量近似块，检索时它们会挤占召回名额，把真正不同的内容顶下去。

我的做法是两层去重：

• 文件级：SHA256完全相同，直接跳过。
• 内容级：解析出纯文本后，把所有空白字符、换行符统一归一化，再算一次哈希。两版文档如果归一化后的正文高度相似（比如相似度超过95%），就标记为“近似重复”，默认不重复入库，而是走“版本更新”逻辑：删除旧版本的向量，写入新版本。

这个策略在文档型知识库里非常有用，尤其是合同、方案、周报这类改来改去的文档。

2.3 PDF、Word、网页笔记：格式解析的正确打开方式

格式解析是“进料口”里最脏最累的活，但也是投入产出比最高的地方。我按文档类型说几个重点：

PDF。先判断是文字版还是扫描版。文字版用pypdfium2或PDFPlumber抽取文本，表格型内容建议开启表格提取模式，尽量转成Markdown表格结构而不是把单元格文字拍平成一串。扫描版走OCR，本地部署推荐PaddleOCR，识别中文印刷体效果很稳；OCR后的文本要保留大致版面关系，至少把同一段落合并，不要一行一个块。

Word。python-docx可以直接读取段落，但要注意三类隐藏内容：批注、修订记录、页眉页脚。默认情况下revised文本会混到正文里，解析前要明确“只取最终版正文”。老式.doc文件建议先用LibreOffice转成docx再处理，直接在Python里解析.binary格式会把自己坑死。

Markdown/HTML/网页笔记。这类格式最大的价值是保留了标题层级和链接，分块阶段可以按heading切，所以解析阶段一定不能把标题拍平。很多人把Markdown直接当纯文本读，等于把最值钱的结构信息扔了。网页收藏进知识库的场景也很多，比如把微信公众号文章保存进知识库：手机端直接复制全文会丢图片，最稳的路径是用“复制链接→在线转Markdown工具→导出Markdown文件”的方式，或者电脑端浏览器打开后另存为HTML再导入。不管哪种方式，图片最终都要单独走一轮处理，见下一节。

2.4 图片素材怎么办：OCR进文本还是走多模态

“RAG知识库能存储图片嘛”这个问题被问得很多。严格说，传统RAG索引的是文本，图片如果没有被转成文本或向量，它对检索就是不可见的。日常处理图片有三条路线：

我的建议是先判断“图片里有没有关键信息”。工业设备手册里的参数截图、合同里的签字盖章页，必须OCR；纯装饰性的配图，直接跳过，别浪费Embedding额度。做了OCR之后，一个隐藏收益是全文检索也能命中图片里的文字，比如搜索“报警阈值”能找到一张仪表盘截图。

3. 分块决定了检索质量的天花板——chunking策略与元数据设计

3.1 为什么“怎么切”比“用什么模型”更影响检索

分块是RAG里最反直觉的一环。很多人把大部分预算花在选Embedding模型上，却默认用了一个凑合的分块器。向量检索的本质是“在块和块之间找最相似的”，一个块就是一次匹配的最小单位。块太小，上下文残缺，命中一个句子也解释不了来龙去脉；块太大，噪音混进去，相似度被稀释，正确答案被埋在半页无关内容里。

最典型的中文灾难是硬切。有些工具默认按字符数硬切，比如每500字一刀，完全不看句号、换行、标题。一刀下去，可能把“违约方应赔偿守约方”和“守约方应赔偿违约方”切成两块，检索时语义完全相反的条款都可能被召回。这类问题不靠换模型能解决，只能靠分块策略本身。

3.2 三种主流分块策略与参数参考

我把分块策略按“投入产出比”排个序，方便不同阶段的团队对号入座：

策略一：固定大小+重叠滑动窗口。这是最便宜也最通用的方案，适合体量不大、文档结构不复杂的知识库。常用参数是chunk_size=400~800字符，overlap=10%~20%。重叠的作用是让边界信息不丢失，避免一句话从中间被拦腰切断。优点是快，缺点是它不感知语义结构。

策略二：结构化感知分块。这是生产环境的首选。做法是利用Markdown标题、PDF的Heading、代码的函数定义、合同的条款编号作为切分边界，先按大标题分，再按小节分，保证每个块都有完整的语义边界。LangChain的RecursiveCharacterTextSplitter、LlamaIndex的SentenceSplitter都是这个思路，区别在于separator的优先级要按文档类型调整。中文场景，一定要把句号、换行符放在比逗号更高的优先级。

策略三：语义分块。先对句子做轻量Embedding，然后计算相邻句子之间的相似度，在相似度出现“谷底”的地方切块。LlamaIndex的SemanticSplitterNodeParser就是干这个的。适合高质量问答、论文、法律文书这类语义连贯且上下文依赖强的文本。代价是速度和成本都比前两者高，处理百万级文档时建议只在关键语料上用。

3.3 分块代码里最容易被忽略的细节：元数据

比切分策略更常被忽略的是块的元数据。每个chunk写入向量库时，都应该带上一份“坐标信息”，我最少会包含这些字段：

• doc_id：所属文档ID，后期删除/更新时靠它批量清理向量。
• title：文档标题，用于展示来源。
• heading_path：当前块所在的标题路径，比如“3.2 chunking策略 > 3.2.1 结构化感知分块”。
• page_num：页码，方便溯源跳转。
• chunk_index：块在文档内的序号。
• source_url：如果文档来自网页，保留原文链接。

元数据第一个作用是过滤。检索时加一个filter，比如“只看2024年的合同”“只看某个产品线的手册”，能瞬间缩小搜索空间，提升准确率。第二个作用是溯源，回答里引用“来自哪篇文档、第几页”，用户才敢信。第三个作用是维护，文档更新时，按doc_id删除旧块，比逐条比对文本高效得多。

一个进阶技巧：要不要把元数据拼进Embedding的输入文本里？我的经验是标题、heading这类结构化信息可以拼到正文前面，形式类似“标题: xxx；章节: xxx；内容: xxx”。这样能让向量带一点上下文，但tag、URL这类非语义字段不要拼进去，它们只会增加噪音。

3.4 本地RAG文本拆解工具怎么选

“有没有本地的rag文本拆解工具”是常被问的问题。本地部署的好处是数据不出域，适合私有化知识库。我常用的组合是：

• Unstructured：解析PDF、Word、PPT等格式很顺手，支持分区检测，能识别标题和正文。
• PaddleOCR：做中文OCR，本地跑GPU或CPU都可。
• LlamaIndex / LangChain：负责分块和组装Pipeline。
• RAGFlow：如果团队想开箱即用，它的DeepDoc组件会同时做版面分析、表格识别和OCR，省去自己拼装多个工具的精力。

选型上我的原则是：先用Unstructured跑通，发现版面复杂再上RAGFlow或LlamaParse。不要一上来就堆重武器，解析效果的差距只有生产数据才能暴露。

4. 索引重建不是“删了重跑一遍”：增量更新与全量重建的工程取舍

4.1 什么时候必须全量重建

索引重建是进料口的“收尾稳定器”。很多人以为重建就是把所有文档重新Embedding一遍，其实重建的触发条件远比“更新文档”要严格。我总结出四种必须全量重建的场景：

1. Embedding模型更换。这是最刚性的。换了模型，向量空间就变了，新旧向量在数学上不可比，混在一起检索就是灾难。
2. 分块策略大改。比如从固定切分改成结构化切分，旧块的边界全部失效，只重跑新文档会让同一篇文档的新旧块共存。
3. 向量库索引参数变化。比如HNSW的M和efConstruction调整，或者从Flat索引切到IVF，需要整体重新构建索引文件才生效。
4. 数据迁移，比如从FAISS迁到Milvus或Qdrant，索引格式完全不同。

看到这里你可能会问：那文档本身更新了怎么办？那叫增量更新，不要动全量。全量重建很贵，越是生产环境越要把“全量”视作一种带仪式感的动作，轻易不触发。

4.2 增量更新背后的三件套：版本号、任务队列、清理旧向量

增量更新的场景是常态：新文档来了要入库，老文档改了要替换，文档删了要把它的向量清出去。这三件事分别对应版本号、任务队列、旧向量清理。

版本号。文档登记表里的version字段，每次文档内容变化+1。向量库里的chunk也带version，检索时如果发现同一个doc_id有多个版本，只取version最大的那批。这是我处理“更新后仍搜到旧内容”的关键手段。

任务队列。索引重建和增量更新都不能放在上传请求的同步链路里跑。常见的坑是把Embedding放进HTTP请求内同步执行，结果一个10MB的PDF让接口直接阻塞几十秒，前端超时，用户反复重试，任务越积越多。正确做法是上传成功后立刻返回task_id，解析、分块、Embedding、入库全部丢到后台任务队列，Dify知识库里的“排队中”状态就是这么来的，这是正常且健康的现象，不是卡死了。

清理旧向量。这是很多人真正漏掉的一步。文档被删除时，只删了文件，向量库里对应的chunk还躺着，检索照样能搜出已删除的内容。正确顺序是先按doc_id执行向量库的delete操作，再更新登记表状态。更新后的文档同理，删除旧版本chunk和写入新版本chunk，最好放进同一个批处理流程，避免新旧版本同时在库。

4.3 重建过程中的一致性：双Buffer切换与幂等写入

全量重建最怕的是“重建到一半，线上检索挂了”。直接drop旧索引再跑新的，窗口期检索全部失败；跑完新的直接覆盖旧的，一旦新流程有问题就是全量回滚事故。我的习惯是双Buffer滚动重建：

1. 新建一个索引/Collection，命名带build_id，比如knowledge_v3_build_20250101。
2. 后台任务把所有文档解析并写入新索引。
3. 写入校验通过后，把读流量切到新索引。
4. 观察一段时间，如果有问题，把流量切回旧索引；没问题，才drop旧索引。

这么做的前提是写入要幂等。向量库的写入键最好用doc_id + chunk_index拼一个唯一id，同一批任务重跑几次，不会产生重复向量。这个设计在“重建跑到一半失败，重新拉起任务”时特别有用。

4.4 平台上的索引重建实践：以Dify流水线为例

如果你用的是Dify这类开源平台，知识库的流水线是可视化的，但底层逻辑一样。Dify文档处理流程一般包含“上传→等待（排队中）→解析→分段→索引→完成”几个阶段。它内部也会区分“全量索引”和“更新索引”任务。“排队中”不代表系统坏了，通常只是任务队列里积压了太多文档，后台Worker处理不过来。

在这种平台下，我建议把批处理分成两档：小批量文档（几十份）可以直接等待任务完成；大批量文档（上千份）最好错峰操作，比如夜间批量导入，避免和白天高频查询抢资源。平台默认的chunk_size参数往往偏大，比如500~1000字符，中文场景建议调低到300~600并开启重叠，效果会更稳。

5. 手把手搭一条可控的文档进料管线：代码与配置

5.1 技术栈选择与理由

我在真实项目里的组合是：LlamaIndex做Pipeline编排，Qdrant做向量库，PostgreSQL存文档登记表，本地部署bge-m3做Embedding。选这套组合的原因很简单：

• LlamaIndex的IngestionPipeline天然支持“加载→分块→Embedding→写入”的有状态流程，中途失败可以从断点重放。
• Qdrant支持按Payload过滤和按doc_id批量删除，正好满足元数据过滤和旧向量清理两个硬需求。
• bge-m3是中文场景性价比很高的本地Embedding，不依赖外部API，私有化部署友好。

代码示例基于Python 3.10、LlamaIndex 0.10及以上版本。如果你是LangChain重度用户，思路完全一致，把Pipeline概念换成LCEL即可。

5.2 核心代码：解析、分块、Embedding、入库

先看主体Pipeline：

from llama_index.core.ingestion import IngestionPipeline from llama_index.core.node_parser import SentenceSplitter from llama_index.embeddings.bge import BGEM3Embedding from llama_index.vector_stores.qdrant import QdrantVectorStore from llama_index.core.schema import Document # 1. 分块器：中文场景优先按句号和换行切 splitter = SentenceSplitter( chunk_size=512, chunk_overlap=64, separator="。\n", ) # 2. Embedding：本地bge-m3，保持全流程同一个模型 embed_model = BGEM3Embedding( model_name="BAAI/bge-m3", use_fp16=True, ) # 3. 向量库：Qdrant，collection按build_id命名 vector_store = QdrantVectorStore( collection_name="knowledge_v3_build_20250101", path="./qdrant_data", ) pipeline = IngestionPipeline( transformations=[splitter, embed_model], vector_store=vector_store, ) # 4. 喂入Document，doc_id由登记表生成 documents = [ Document( text="...解析出的正文文本...", metadata={ "doc_id": "doc_0001", "title": "设备运维手册", "heading_path": "3.2 故障处理", "page_num": 18, "chunk_index": 0, "version": 3, }, ) ] pipeline.run(documents=documents)

如果你想用LangChain的等价实现，核心是这三个组件的组合：RecursiveCharacterTextSplitter（注意separators次序）、OpenAIEmbeddings或HuggingFaceEmbeddings、QdrantVectorStore的add_texts。

5.3 支持全量/增量两种模式的索引重建脚本

生产里的重建脚本不能每次手改，我用命令行参数区分模式：

import argparse def run_full_rebuild(): # 1. 新建collection，命名带上build_id # 2. 从数据源扫描所有文档（数据库/对象存储） # 3. 批量写入新collection # 4. 写入完成后切换collection别名 # 5. 校验通过后drop旧collection pass def run_incremental(): # 1. 查登记表，找status != ready的文档 # 2. 对每个文档：先delete by doc_id，再跑pipeline # 3. 成功后更新登记表status和version pass if __name__ == "__main__": parser = argparse.ArgumentParser() parser.add_argument("--mode", choices=["full", "incremental"], required=True) args = parser.parse_args() if args.mode == "full": run_full_rebuild() else: run_incremental()

脚本里最核心的纪律是：任何一次写入，向量库里的chunk都必须带着doc_id、version、build_id这三个字段，缺一个都别放行。

5.4 入库表结构与文件存储约定

文档登记表我前面已经给过字段，再补两张辅助表的建表语句，供你直接抄：

-- 文档登记表 CREATE TABLE documents ( doc_id VARCHAR(64) PRIMARY KEY, file_name TEXT NOT NULL, file_type VARCHAR(128), file_size BIGINT, sha256 VARCHAR(64), status VARCHAR(32) DEFAULT 'uploaded', version INT DEFAULT 1, source_type VARCHAR(32), error_msg TEXT, created_at TIMESTAMPTZ DEFAULT now(), updated_at TIMESTAMPTZ DEFAULT now() ); -- 索引构建批次表 CREATE TABLE index_builds ( build_id VARCHAR(64) PRIMARY KEY, collection_name VARCHAR(128) NOT NULL, embed_model VARCHAR(128) NOT NULL, total_docs INT DEFAULT 0, success_docs INT DEFAULT 0, status VARCHAR(16) DEFAULT 'running', created_at TIMESTAMPTZ DEFAULT now(), finished_at TIMESTAMPTZ );

文件本身我建议统一存到对象存储的raw目录下，路径规则为raw/{source_type}/{YYYYMMDD}/{doc_id}.{ext}，解析出的纯文本缓存到clean/{doc_id}.txt。这样重跑Pipeline时可以直接读取clean文本，省去重复解析PDF的时间。对象存储路径里的doc_id，就是和登记表关联的钥匙。

5.5 效果验证：怎么知道这次重建“真的变好了”

重建完成不等于工作完成，必须验证。最实用的方法是准备一组“金标问题集”：挑20~30个业务中真实会被问到的问题，每个问题标注“期望召回哪几篇文档”。重建后跑一遍这组问题，统计期望文档是否出现在Top-K里。

golden_queries = [ {"query": "设备报警阈值是多少", "expected_docs": ["doc_0012", "doc_0013"]}, {"query": "合同违约赔偿计算方式", "expected_docs": ["doc_0033"]}, ] def validate_index(retriever): hit_count = 0 for item in golden_queries: nodes = retriever.retrieve(item["query"]) hit_docs = {node.metadata["doc_id"] for node in nodes} if set(item["expected_docs"]).issubset(hit_docs): hit_count += 1 print(f"Golden Query Hit Rate: {hit_count / len(golden_queries):.2%}")

每次改动分块参数、Embedding模型、元数据过滤规则后，都用同一组golden queries对比，防止“修好一个坑，踩了另一个坑”。

6. 生产环境下的进料坑与排查链路：从“查不到”到“旧答案”

6.1 上传大文件直接超时：同步转异步的改造

第一次把几十MB的PPT扔进知识库时，接口直接卡死，网关超时，用户那边看到的只有一片空白。原因不用猜：请求里同步做了文件解析和Embedding。改造方案分三步：

1. 上传接口立刻落盘并返回task_id。
2. 解析、分块、Embedding、入库全部进异步Worker队列。
3. 前端轮询task状态，实时展示“解析中”“生成索引中”“完成”。

如果原系统是单体服务，可以用Redis + RQ或Celery；如果是K8s环境，直接用Sidekiq风格的任务队列。核心就一句话：上传只做上传，重活全部异步化。

6.2 更新文档后检索仍是旧答案：整条排查链路

这是生产环境里投诉最多的问题，排查链路的顺序很重要，我按概率排好了：

1. 查登记表：select status, version from documents where doc_id = ...，如果status不是ready，说明任务根本没跑完。
2. 查向量库：按doc_id查是否还有旧版本chunk，比如select count(*) from collection where payload.doc_id = ... and payload.version < 3，有就执行“旧版本删除”。
3. 查检索代码：确认查询时有没有filter限定collection或build_id，如果filter写死成了旧的build_id，新数据永远搜不到。
4. 查Embedding模型一致性：入库和查询用的是不是同一个模型，换模型后混用会出现“索引正常但匹配混乱”。
5. 查缓存：有些团队给检索结果加了Redis缓存，更新索引后缓存没失效，用户看到的永远是旧回答。

按这个顺序排查，基本十分钟内能定位问题。大多数情况是第2和第3步二选一，根本不涉及模型。

6.3 中文分块切碎语义：观察、定位、重切

症状是用户问“设备维修周期是多少”，返回的内容是一条碎得看不清的句子片断。定位方法是检查检索命中的chunk原文，打印出来看边界落在哪里。如果边界落在“设备维修周期应严格……但特殊情况下可以延长”中间，那就是典型的硬切问题。

修复方案是换分块器：用SentenceSplitter并设置separator包含“。”、“！？”、换行符，或者更激进一点，对合同类文档先用正则按“第X条”切分，再对每一条内部按段落切分。切完之后重新跑一次golden queries，对比前后命中率变化。这套“观察→定位→重切→验证”的循环，比我见过的任何调参技巧都管用。

6.4 并发写入索引与查询互相拖慢的问题

大批量重建时，向量库的写入会吃掉大量CPU和IO，线上查询跟着变慢。我的应对思路是资源隔离和降级：

• 批量写入时把batch_size调小一点，比如Qdrant一次写入64条而不是512条，降低单次压力。
• 有条件的话，写入和查询走不同的副本/节点。
• 实在没有独立资源，就把全量重建安排在低峰期，比如凌晨2点。
• 向量索引的sync参数要合理设置：查询时开sync会影响写入性能，写入时开sync会影响查询延迟，二选一，别两头都要。

这里多说一句：我在Qdrant里习惯把写入端设置成异步模式，等待后台flush；查询端保持同步。配合幂等键，即使异步写入失败也能重跑，不会丢数据也不会重复。

6.5 一个小而美的补充：网页文章快速入库存通道

微信文章、公众号文章入库存，我前面提过转Markdown的方法，这里补一个工程化细节：如果你的知识库经常要吞网页内容，可以在进料口加一个“URL导入”入口，用阅读器类组件把网页正文抽出来，连同标题、作者、发布时间一起存入登记表，source_type记成web_clip。图片继续按2.4节的规则处理：文中关键截图走OCR，纯装饰图忽略。这个入口加上去之后，团队收集资料的效率会明显提升，因为它把“复制粘贴再排版”变成了“贴个链接就能入库”。

处理文档上传和索引重建这件事，不同团队会走不同的技术路线，但我越来越觉得，真正决定知识库好用不好用的，往往不是大模型品牌，而是这些“进料口”里的细节有没有做到位。文档登记表建没建，分块边界有没有感知语义，重建时有没有清理旧向量，每一个看似琐碎的环节，最后都会变成检索质量的差距。我自己在这条路上踩过的坑不算少，写下来最大的愿望就是你不需要再踩一遍。如果再有人问我RAG知识库最重要的是什么，我还是那句话：先把进料口打磨好，后面的路就顺了。