企业官网建设流程全解析

微信开源了一个神级知识库项目——说实话，我第一次看到这个标题的时候，第一反应是“又蹭微信热度的标题党”。但点进仓库之后发现，这次是腾讯微信AI团队认真把东西放出来了，项目叫 WeKnora，是一个面向 RAG（检索增强生成）场景的知识库问答平台。更让我意外的是，它不是那种只给你一堆算法代码的“半成品”，而是直接把文档解析、索引、检索、LLM 问答、可视化控制台、API 接口这条链路全部做完了。

这篇东西我写的时候，尽量按一个真正部署和使用过它的人的视角来聊：先讲清楚它解决的到底是什么问题，再拆几个我认为值得关注的设计点，然后是我本地从零部署到跑通问答的完整过程，最后说说进阶用法和我在实测中真正踩到的坑。如果你最近正在选型知识库项目，或者用 Dify、RAGFlow、Obsidian 这类工具搭过知识库但总觉得哪里不对劲，这篇应该对你有用。

1. 微信团队开源的这个仓库，究竟解决的是哪类问题

1.1 知识库问答的老大难：文档进了库，答案还是出不来

过去两年，我见过太多团队在做“知识库问答”了。大家的标准动作几乎一模一样：先把文档解析成文本，切片，做 embedding，存进向量数据库，然后接一个大模型接口，用户提问时把向量检索结果拼进 prompt 里让大模型回答。

听起来顺畅，实际用起来问题一堆。

第一个坑是文档解析。真实场景里的文档，谁也不会给你规规矩矩的 txt。合同是 PDF 扫描件，产品手册做成 PPT，还有密密麻麻的 Excel 表格、带多层标题的 Word 文档。普通脚本解析 PDF 只能按页把文字抽出来，标题顺序乱了、表格挤成一坨、多栏排版的内容串行，这些都是家常便饭。我见过有人拿 pdfplumber 解析一份 100 页的手册，结果检索的时候前十页的内容全是页眉页脚。

第二个坑是召回质量。向量检索擅长处理“语义相似”，但在知识库场景里，大量提问是带专有名词的，比如“LPR 浮动利率定价的加点数值怎么计算”这种句子，你把它切碎了做 embedding，专有名词的精确匹配能力反而不如简单的 BM25 关键词检索。很多团队被迫把召回改成向量加关键词混合，但自己拼这个混合逻辑，又要处理权重、阈值、重排序一大堆问题。

第三个坑是中文效果。通用 embedding 模型在中文长文档上的表现，跟英文完全不是一个量级。段落切大了，召回一堆不相关的内容；切小了，上下文被截断，大模型拿到的信息不完整。

WeKnora 这个项目，基本就是冲着这些问题来的。

1.2 和 Dify、RAGFlow、Obsidian 知识库方案放在一起看

我不是说 WeKnora 是唯一的选择，但你可以把它放进现有的工具生态里对比着看。

Dify 的核心定位是 LLM 应用编排平台，知识库只是其中一个功能模块。你用 Dify 搭 Agent、搭工作流、做对话应用，体验确实顺。但 Dify 的文档解析能力，至少在默认配置下，还没有达到能应付复杂 PDF 和表格的程度。你负责解决“应用怎么做”，它不太愿意回答“文档怎么吃得干净”。

RAGFlow 走的是“深度文档理解”路线，对版面分析、表格还原下了很重的功夫。如果你有一堆排版复杂的文档，RAGFlow 的解析效果确实能打。但它的部署和运维门槛也高，对硬件资源更挑剔，小团队自己跑起来没那么轻松。

Obsidian 这一类是给个人笔记用的。它的知识库本质上是本地 Markdown 文件加插件，适合你自己写的东西，不适合处理几十份外部合同和产品资料，更不是一个服务化、有 API 的“知识库后端”。

WeKnora 的路线是：把“文档解析 + 索引 + 检索”做深做重，做成一个可以被 Dify 这类编排平台调用的基础设施。它自带一个控制台，方便你单独用；同时也提供了接口，方便你接进更大的系统。这和我上面提到的那几个工具比，定位是有差异的——你可以把它理解为知识库问答的“专业底座”。

1.3 仓库拿到手之后，你实际上会得到什么

我把它跑起来之后，感觉最值钱的是下面这几块，你 clone 仓库之后基本都能拿到：

• 可视化控制台：网页界面可以管理知识库、上传文档、看解析结果、直接问答，不用自己写前端。
• 文档解析引擎：对 PDF、Word、PPT、Excel、Markdown 等格式做结构化抽取，能识别标题层级和表格结构，这是常规 PDF 转文本工具做不到的。
• 多个知识库检索引擎：默认的 KNN+BM25 混合召回方案，以及面向医学、长文档等特定场景的专用引擎，后面我会详细拆。
• 面向 RAG 的 API：知识库的创建、文档上传、检索、问答这些操作都有接口暴露，方便接入到其他系统里。
• Dify 集成能力：官方文档提供了把它接进 Dify 的方式。你可以让 Dify 专心做应用编排，让 WeKnora 专心负责文档解析和检索。

而且整个项目用 Docker Compose 就能拉起来，对内存的要求没有想象中那么夸张。我没有 GPU，纯 CPU 环境跑默认配置，一样能完成整个问答流程。

2. 真正让我觉得“能打”的几个能力细节

2.1 DeepDoc 解析引擎：PDF、Word、表格从“能读”到“读得懂”

如果你只看懂了一个组件，那一定是 DeepDoc。这是 WeKnora 里负责文档解析的核心引擎，也是我认为这个项目区别于其他知识库方案的最大亮点。

普通的文档解析工具，做的事情是把文字抽出来。DeepDoc 做的事情，是把文档的版面和语义结构拆出来。它能识别一块版面上哪个区域是标题、哪个区域是正文、哪个区域是表格、哪个区域是图片注释，然后把它们按照原本的层级关系组织起来。

你可以简单类比一下：普通工具给你一堆散落的词句，相当于把一座图书馆的书全拆成纸片堆在地上；DeepDoc 会先把书架、楼层、分类标签拍下来，再把文字放回原位。知识库问答里，“上下文结构”对回答质量的影响，远比大多数人想象的大。比如一份带多层标题的技术规范，“3.2.1 节”的内容为什么属于“3.2 节”，这个问题普通解析是回答不了的，但 DeepDoc 的结构化抽取可以尽量保留这种关系。

表格更是痛点中的痛点。一份价格明细表，检索结果如果只是把表格里的所有格子拼成一段话，那这条信息基本废了。DeepDoc 会让表格保持行列结构，落到知识库里之后，你问“A 型号和 B 型号的差价是多少”这种问题，模型能拿到真正能读取的表格数据。我在实测里用带合并单元格的复杂表格试过，确实比我之前自己写的解析脚本靠谱太多。

另外需要注意，扫描版文档不是 DeepDoc 的魔法范围，它本身带 OCR 相关能力，但扫描件质量参差不齐，如果你知识库里全是图片型 PDF，建议先单独评估效果。正常的电子版文档，它处理起来基本不需要额外干预。

2.2 从 KNN+BM25 到医学专用引擎：多路召回不是噱头

知识库问答的检索环节，普遍存在的矛盾是：向量检索理解语义，但会漏掉专有名词；关键词检索精确匹配，但不懂同义表达。单靠哪一路都不可靠，所以 WeKnora 的默认方案是做一个混合检索：一条路走向量召回（KNN，即最近邻搜索），一条路走关键词召回（BM25），两条路的结果再做合并和排序。

这个设计我特别认同。中文知识库里，专有名词的问题非常突出。比如“止回阀 H41X-16C”这种型号，embedding 之后，它和“逆止阀”“单向阀”在实际语义上有相关性，但用户在提问时更经常直接敲型号，这时候 BM25 的精确匹配是救命的。反过来，用户如果问“管道介质倒流怎么防止”，没有关键词“止回阀”，向量召回又能发挥作用。混合召回的价值就在这里。

另外项目里还提供了分场景的引擎选择。比如面向医学场景，有专门用医学语料调整过的排序模型，做问答时会用医学问答的相关性重新给召回结果打分。再比如长文档排序相关的能力，适合说明书、规范类文档这种动辄几十上百页的资料。我的态度比较务实：如果你手头就是普通的企业文档，默认的 KNN+BM25 引擎已经够用；如果你有医学术语密集或者长文段比例极高的场景，再去研究特定引擎切换，收益会更明显。

这一步设计上的成熟还体现在：它把检索与生成分开了。检索只管召回，生成交给大模型。换不同的大模型，不需要动知识库索引。以后模型升级、换供应商，知识库照旧工作。长期维护的角度看，这个边界划分非常值得赞赏。

2.3 REST API 与外部知识库接入：它不只是一个带页面的 Demo

很多开源项目所谓的“知识库”，其实是先做一个聊天气泡，再把知识库藏在后端。用户看着能用，但你想拿它构建自己的产品，就发现完全使不上劲。

WeKnora 没有犯这个毛病。它的知识库操作都有对应的 API 能力：创建知识库、上传文档、发起检索、发起问答，这些都能通过 REST 接口调用。我自己在测试阶段，是用 Postman 和脚本分别调的，确认过接口本身是独立的，页面只是套在接口外面的一个壳。

这对开发者的意义是：你可以把这个项目当成“文档解析与检索服务”来用，不一定要用它的聊天页面。你有自己的一套 Agent 编排逻辑，完全可以在自己的系统里调用 WeKnora 的接口拿回检索结果，再喂给你自己的大模型。这种“可嵌入”的设计，比那种什么都做好但不让你碰的方案实用得多。

它和 Dify 的集成，走的也是外部知识库的路子。Dify 负责管理对话流、Agent 和工具调用，把 WeKnora 配成外部知识库来源；用户在 Dify 里提问时，Dify 会触发对 WeKnora 的检索请求，把内容拿回来拼进上下文。这样一来，Dify 用户不需要再在 Dify 里重新上传一遍文档，文档统一由 WeKnora 维护。两个系统各管一段，边界非常清楚。

3. Docker Compose 部署完整过程：从拉代码到第一次问答

3.1 先准备这些环境和配置项

我这次部署用的是纯 CPU 环境，配置大概是 8 核 16GB 内存的云服务器，系统是 Ubuntu 22.04。如果你是在自己电脑上跑，建议内存至少 8GB，否则多个容器一起起会明显吃力。GPU 不是必须的，没有 GPU 也能完成全流程，只是文档解析和向量化的速度会慢一些。

需要提前准备的东西：

• Docker 和 Docker Compose 插件，这是最基本的。
• 一个大模型 API 的 key，OpenAI 兼容格式的都可以，我用的是 DeepSeek 的通义兼容接口做测试。WeKnora 本身支持配置这类 OpenAI-compatible 接口，所以你有国内厂商的 key 也能直接用，不一定非要 OpenAI 官方。
• 一个网络稳定的环境。项目第一次启动要拉不少镜像，镜像比较大，建议找一个网络条件好的时间段操作。
• Postman 或者 curl，后面测试 API 用得到。

我习惯先把项目 clone 到服务器上的 /opt 目录，方便后续管理。官方 README 里对硬件和软件的要求写得比较清楚，动作之前先扫一眼，能免掉不少后面“为什么跑不起来”的困惑。

3.2 核心配置文件怎么看，参数怎么填

项目目录下会有 docker-compose.yml 和对应的环境变量配置文件。我们不需要一上来就懂所有服务，但有几个关键配置必须理解，因为填错会导致模型调用直接失败。

第一个是大模型配置。核心字段是 API 地址、API key、模型名称。我用的是 OpenAI 兼容格式，所以只需要把 base_url 指到对应厂商的接口地址，把 key 填进去，再指定一个模型名。注意，不同模型厂商兼容程度不同，有的需要加 /v1 后缀，有的不用，这个要以你模型的官方文档为准。我在测试时就因为 base_url 少写了一个路径段，结果日志里反复报 404，后来发现是地址没写对。

第二个是 embedding 配置。知识库召回依赖 embedding，因此这里也要配一个可用的模型服务。项目里默认会有一套方案，但如果你的网络或模型不通，向量化就会失败。embedding 模型我也选了一个 OpenAI 兼容的接口来配，跑下来没遇到问题。如果你的整个环境是隔离内网，打算全换成本地部署的模型，那我建议你重点看 4.4 节，那块会专门聊本地模型的接法。

第三个是你希望暴露给 Web 界面的访问配置。默认情况下，服务启动后会监听某个端口，如果服务器有防火墙，记得把这个端口放行。我一开始只放行了 Web 端口，没有放行后端服务端口，导致页面能打开但后端请求一直失败。这种小细节，排查起来特别费时间。

配置方式基本都是写环境变量，改完保存后，执行 docker compose up -d 启动。首次启动会拉镜像、初始化数据库，这个过程通常需要一点时间，不要看到容器没起来就急着反复重启。可以用 docker compose logs -f 跟着日志看进度。

3.3 跑起来后按这个顺序做第一次知识库问答

服务起来之后，我第一次操作的时候还是犯了顺序上的迷糊。总结经验，最稳妥的流程是下面这几步：

1. 浏览器访问 Web 控制台，用默认账号登录。
2. 在控制台里找到“创建知识库”的入口，给它起个名字。
3. 知识库创建时，会让你选知识库引擎类型。如果你不清楚自己属于什么领域，选默认的 KNN+BM25 混合引擎就好。
4. 创建完成后，进入这个知识库，上传文档。我建议第一次先传一份格式规范的 PDF，比如一本产品手册的电子版，这样解析效果容易验证，不会一开始就撞上复杂版式的坑。
5. 上传完成后，等系统完成解析和向量化。这个过程在文档列表里能看到状态变化，解析中、已完成这类标识都会显示。
6. 状态显示完成后，回到问答界面，选刚才的知识库，提问。

第一次最好问一个文档里明确写了答案的问题。比如手册里写了工作温度范围，你就直接问“工作温度范围是多少”。如果回答内容和文档一致，说明从解析到检索到生成，整条链路已经通了。

我当时第一次问答就成功了，回答内容准确，还给出了引用来源的提示。这一步跑通之后，整个项目的信任感一下子就建立起来了。

3.4 第一次问答背后的处理链路拆解

你看到的是一次问答操作，后台其实做了好几件事。我觉得把这个链路理解清楚，比记住任何配置都重要。

第一步，文档解析。上传的 PDF 会先交给 DeepDoc，它把版面结构、标题层级、表格内容抽取出来，整理成有结构的知识片段。这一步决定了后面所有环节的起点质量。解析失败的段落，后面检索永远不可能命中的你想要的信息。

第二步，索引。解析出来的文本会被切分成长度合适的切片，然后做向量化并和关键词索引一起存储。切片的大小很关键，太大会稀释上下文，太小会丢失联系，系统默认设置是对大多数文档比较稳妥的取值。

第三步，召回。你提问之后，系统把问题转换成向量走一遍 KNN 检索，同时走一遍关键词 BM25 检索，再把两路结果合并排序。这个阶段返回的不是最终答案，而是一批相关文档片段。

第四步，生成。召回的结果拼进 prompt，连同你的问题一起发给大模型，大模型基于这些片段生成答案。

理解这个链路，对排查问题特别有帮助。比如答错了，你可以先去确认是“没检索到”还是“检索到了但模型回答错了”。这两类问题的解决办法完全不同。我在第 5 节会展开讲这个定位思路。

4. 进阶玩法：把它接进 Dify 工作流，让 Agent 用上文档解析能力

4.1 为什么要拆成“Dify 做编排，WeKnora 做解析和检索”

先说说我自己接 Dify 的真实感受。单独用 WeKnora，你用到的只是它的聊天界面，相当于 Knowledge Base 的“单机增强版”。但在我自己的业务里，用户入口不只是一个简单的问答框，我需要把知识库能力挂接到 Agent 工作流里，让大模型根据意图决定要不要查知识库、查完以后要做什么。这些逻辑放在 Dify 里编排，确实比自己在代码里实现一遍要快得多。

所以一个比较务实的分工是：Dify 负责对话管理、用户输入分类、工具调用、多轮对话上下文维护；WeKnora 负责文档解析、索引和检索，回答问题时，由 Dify 的工作流触发一次对 WeKnora 的检索，把结果注入到大模型的上下文里。这样一来，你不需要在 Dify 里重复上传文档，也不会被 Dify 默认的文档解析能力限制住。两边各干各的，替换和维护都方便。

4.2 对接步骤：在 Dify 里挂一个外部知识库

Dify 提供了外部知识库（External Knowledge Base）的接入方式。具体操作路径大致是：先在 Dify 的后台配置一个外部知识库 API，填上 WeKnora 的服务地址和访问凭证，然后建立一个外部知识库条目，绑定你希望在问答中检索的数据集。

这里有几个容易踩的细节。第一，WeKnora 的接口地址必须能被 Dify 所在环境访问到，如果 Dify 和 WeKnora 部署在不同的网络环境，要先把连通性测通。第二，外部知识库的配置项里，数据集 ID 这些东西要对得上，如果你在 WeKnora 里建了多个知识库，一定要在 Dify 里配置正确的那个，否则检索时返回的是另一个知识库的内容。第三，对接完成后先用最简单的“单知识库对话”测一遍，确认检索能被触发，再往上加 Agent 和复杂工作流。直接一上来就搭完整 Agent，出了问题你根本分不清是 Dify 编排的问题还是 WeKnora 返回的问题。

4.3 通过 API 调用 WeKnora 时最常用的几个请求

如果你不打算用 Dify，或者你就是想在自己的后端里直接调用 WeKnora，那你要经常用到一些类似下面的操作：

创建知识库：向对应接口发送一个 POST 请求，请求体里带上知识库名称。返回结果里会有知识库 ID，后续的文档上传和查询都要用到。

上传文档：通过文件上传方式请求接口，把文档文件和知识库 ID 一起传过去，系统解析完成后，文档状态会变成可用。

检索知识库：向检索接口 POST 一个携带 query 的请求，可以调整返回条数相关的参数。这一步返回的是召回片段，不是答案。如果你自己的系统已经有 RAG 流程，拿到这些片段拼 prompt 就足够了。

问答请求：带 query 直接请求问答接口，系统会帮你完成检索、拼接和调用大模型，返回最终答案。适合不想自己拼 RAG 流程的场景。

如果你用的是 Postman，项目文档里通常会提供已有的接口集合，可以直接导入，省得手写每个请求头。需要注意，不同部署版本的接口路径可能会有差异，我建议以你部署版本的接口文档为准，不要直接照搬网上截图里的路径。

4.4 完全内网环境：用本地模型替掉云端 API

很多企业客户找我问的第一句话就是：这个能不能完全内网部署，不连外面的模型服务？

回答是能，但你要把几个点准备好。如果你希望大模型、embedding 都在本地跑，常见方案是搭配本地模型推理框架，比如 Ollama。原理很简单：WeKnora 支持 OpenAI 兼容接口，而本地推理服务本身也会启动一个兼容接口，你把 WeKnora 的模型 API 地址指向本地推理服务的地址就可以。

这样做的好处是数据不出内网，适合有合规要求的场景。需要留意的是资源消耗。本地跑 7B 规模的模型，16GB 内存勉强能带动，但回答速度不会快；如果你想跑更大参数规模的模型，或者文档量比较大，强烈建议加一张 GPU。embedding 模型也一样，本地小模型对长文档的处理能力会弱一些。所以我通常建议：先明确知识库的规模和回答速度要求，再决定本地模型方案是不是真的适合你。

这套方案对国内的私有化 Agent 部署场景尤其有意义。你可以用 WeKnora 管理企业内部文档，用本地模型完成推理，让整套服务完全跑在自己的机房环境里。省去了文档内容外传的顾虑，代价就是硬件投入和日常调优需要自己负责。

5. 我实测踩过的坑，和一套可复用的排查思路

5.1 服务启动失败时，先按这个顺序排查

我第一次部署的时候，docker compose up -d 之后马上查看容器状态，发现有的容器没起来。那种心情相信你也经历过。但这次我没有像以前一样盲目重启，而是按顺序做了排查。

第一步看日志。docker compose logs 之后发现一个服务启动失败的直接原因是端口被占用。我的服务器上已经有一个服务占了默认端口，改成其他端口之后问题解决。这类问题，日志里通常有明确提示。

第二步检查镜像是否完全拉取成功。如果你的网络条件不理想，某个镜像一个 pull 拉到一半断了，依赖它的服务就会起不来。这种情况最好的办法不是反复重试，而是找一个网络稳定的时间重新执行拉取操作。项目首次启动的镜像数量不少，建议耐心等，不要中途强制断开。

第三步检查依赖服务是否就绪。有些服务依赖数据库等组件，如果数据库还没初始化完成，应用服务起来也会退出。如果你的机器性能一般，启动时间会明显变长，日志里出现“等待数据库就绪”这类字样是正常的，等一会儿再看即可。

5.2 中文 PDF 解析乱掉，问题大概率不是解析引擎

很多人刚上手，第一反应是拿一份中文 PDF 去测。如果这份 PDF 是扫描件，或者是用某些特殊排版软件生成的，解析结果会很难看。这时候最常犯的错，是直接给项目判死刑：“中文支持不行”。

我的经验是，先确认文件类型。把 PDF 的一页截图放大，看看文字是不是真的可以选中。如果文字是图片里的像素，DeepDoc 的常规解析流程肯定吃不到文本，这时候要确认是否开启了 OCR 能力。如果文字本身可以选中，但解析出来的段落顺序不对，那大概率是版式的问题，可以试试调整解析时的页面方向或分栏识别。如果是那种带复杂页眉页脚、多栏混排的科技论文，解析结果比你想象的“好捞一点”是正常的，知识库构建本来就需要针对文档特点做调整。

判断标准很简单：同一个文件，你用 Adobe 打开能选中文字，解析出来却乱码，那才叫解析引擎的问题；如果 Adobe 打开也选不中文字，这就是扫描件，得走 OCR 路线再评估。

5.3 问答答非所问：从“查没查到”开始定位

我测试阶段最诡异的一个 bug 是：文档里明明写了“最低工作温度为零下 20 摄氏度”，但问“最低工作温度是多少”时，系统回答了一个完全不同的值。一开始我以为是大模型出了问题，后来冷静下来，发现答案不对的情况必须先区分“没查到”和“查到但答错了”。

排查顺序是这样：

先看检索。在 WeKnora 的控制台里，问答结果通常会展示引用来源。你可以直接看这次回答到底引用了哪些片段。如果引用的片段里根本没有包含“零下 20 摄氏度”这句话，那问题出在检索环节，说明相关切片没被召回到。

接着调整检索参数。你可以放宽 topK，让系统多召回几条；或者检查切片大小，如果切片太大导致每段都混入大量无关内容，相关性排序压低了正确答案的位置，那就该考虑是否调小切片长度。如果检索出来了相关片段，但你问模型的时候它还是答错，那才是生成环节的问题，这时候可以考虑更换大模型、或者调整回答提示词。

再补充一个我自己总结的小技巧：别一上来就调 embedding，先从 topK 和切片长度下手。这两个参数对召回结果的影响最直接，改动成本低，反馈也快。改 embedding 模型要重新向量化整个知识库，成本高，留到最后再说。

5.4 小内存机器也想跑：资源占用优化清单

如果你的机器只有 8GB 内存，跑默认完整套件会有点勉强。我不是说跑不了，但你要做一些取舍。

第一，优先确保核心服务正常，非核心的服务可以按需关闭。文档解析完成之后，相关组件如果吃内存很厉害，可以考虑在处理完大量文档之后再启动，平时保持关闭状态。第二，严格控制同时向知识库提交的文档数量，一次性塞几百个文件，解析任务排队会导致内存瞬间吃满，我试过一次，直接把机器弄到卡死。第三，如果你的目标是生产环境，我还是建议升到 16GB 以上。知识库的内存需求不是固定的，它会随着文档数量和检索并发量增长，小内存跑出来的效果只能算“能用”，离“放心”还有距离。

另外提醒一下，部署完成后如果长期不用，注意定期清理日志和临时文件，容器日志长期不清理会占掉不少磁盘。小机器上，磁盘资源同样紧张。

写在最后

我把这套东西从拉代码到接入 Dify 完整跑过一遍之后，最大的体会是：WeKnora 不是一个“聊两句就完”的玩具知识库，而是一个适合接进真实业务系统的知识库后端。它把文档解析、索引、检索、问答、API 这条链路整理得相当完整，尤其是 DeepDoc 的结构化解析能力，解决了知识库项目里最脏最累的那块活儿。如果你现在遇到的是“文档太多、格式太杂、检索总是不准”这类问题，它确实值得你花一个下午拉起来试试。

我个人实际使用中的建议是：不要因为它带了聊天界面就把它当聊天工具用，尽量从 API 的角度去理解它——你的知识库内容由它统一管理，检索结果由它统一提供，至于答案怎么组织，让外面的大模型和 Agent 工作流去决定。这样系统边界清晰，后续扩展的时候你会感谢自己当初没贪图那个内置问答页面省事儿。

最后分享一个实测时发现的细节。中文知识库的问答质量，很多时候不是模型不行，而是切片方式不够细。如果你发现回答经常答非所问，先去调整切片参数，把块大小调小一档，再开启重排序，很多人反映这样调整后回答质量提升非常明显。这个小参数，算是我折腾几轮之后最想让你先试的东西。