企业官网建设流程全解析

做企业知识库这几年，我前后换过好几套方案：有直接用向量数据库裸写的，有拿 LangChain 自己拼管线的，也有试过各类开源平台。最后让我真正愿意稳定跑下来、并且愿意推荐给团队的，是腾讯微信团队开源的 AI 知识库项目 WeKnora。它解决的痛点很实在：知识库要能私有化部署、要能处理乱七八糟的文档格式、要能把检索和问答衔接得足够好，而不是只给一个"能聊天的壳"。这篇文章我就把这段时间部署和使用 WeKnora 的完整经验整理出来，包括方案选型、本机部署、模型配置、文档解析、常见问题排查，以及从知识库到 Agent 的落地路径，给正在折腾知识库的朋友一个参照。

1. 为什么在众多知识库方案里挑了 WeKnora

1.1 WeKnora 到底是个什么东西

先把这个项目讲清楚。WeKnora 这个名字拆开看就有信息量：We 指微信团队，Knor 取 Knowledge 的词根，a 是常见 AI 产品后缀。简单说，它是一套完整的 RAG（检索增强生成）知识库引擎，核心链路是"知识采集 → 内容解析 → 文本切分 → 向量化 → 混合检索 → 大模型问答"。

和很多只做"问答玩具"的开源项目不同，WeKnora 把知识库这个完整闭环做了起来：它能扫描你指定的文件夹，自动解析 PDF、Word、Markdown、TXT、网页等多种格式；解析完会自动切分、清洗、生成向量索引；问答的时候不是直接把问题丢给大模型，而是先从知识库里检索出相关片段，再让大模型基于片段生成答案。这一点非常关键，知识库问答的准确率，很大程度上不取决于模型智商，而取决于"有没有把正确的内容检索出来"。

我自己的判断标准其实很朴素：一个知识库项目能不能用在生产环境，就看三件事——部署方不方便、解析能不能扛住真实文档、检索质量能不能调。WeKnora 在这三件事上都有完整答案，这也是它当时吸引我去试的核心原因。

1.2 和 Dify、RAGFlow、MaxKB 的横向对比

选型阶段，我把市面上主流的开源知识库 / RAG 项目都跑了一遍，包括 Dify、RAGFlow、MaxKB，还有 WeKnora。说说我的实际感受。

Dify 的强项是工作流编排和 Agent 生态，你可以拖拖拽拽搭一些自动化流程，它的定位更偏向"低代码 AI 应用开发平台"。但如果你只是想把一堆文档变成可检索、可问答的知识库，Dify 那套流程编排对普通用户来说有点重，而且它对知识库本身的检索细节打磨，说实话不如专门做检索的引擎。

RAGFlow 的文档解析能力非常强，尤其是复杂 PDF 版面还原，对表格、图片型 PDF 的处理是行业里数一数二的。代价是部署相对复杂、资源占用比较重，如果你不想折腾，直接上手 RAGFlow 可能会被它的架构绕晕。

MaxKB 是另一款很流行的开源知识库问答系统，界面做得好看，安装也快，开箱即用体验很好。但如果你后面需要做更细粒度的检索调优、需要深度定制 RAG 管线，MaxKB 就相对受限。

WeKnora 给我的感觉是站在了中间偏"检索极客"的位置：它本身不是一个重平台，而是把 RAG 引擎拱手给你，同时提供了一套完整 Web 界面做知识管理和问答测试。它特别在意检索质量，提供了混合检索、查询改写、上下文扩展这些深度功能，这些在别家通常要自己写代码实现。下面这张表是我的主观对比，供参考：

如果你已经有一个复杂的业务流程要编排，选 Dify 没错；如果你每天要解析大量扫描版 PDF，RAGFlow 会更省心；但如果你的核心诉求是"把手里的文档变成高质量的检索池，配合大模型做精准问答"，WeKnora 值得认真研究。

1.3 什么场景适合选它，什么场景不适合

先说适合的场景。我最推荐 WeKnora 的场景有三类：

第一，企业私有化知识库。文档涉及内部资料，不方便调用云端 API 做入库加工，必须在内网部署，WeKnora 对私有化部署支持得很干净，模型也可以接本地 Ollama 或者内网部署的模型服务。

第二，知识检索质量要求高的场景。比如研发团队想让 AI 基于内部技术文档回答问题，答案引用的内容必须准确，不允许大模型胡编。这种场景下，WeKnora 的混合检索机制能显著提升"答案是否有据可依"的概率。

第三，需要持续更新和扩充的知识库。WeKnora 在增量更新方面做得比较顺，你可以随时往知识库目录里丢新文档，重新扫描后新内容就能被检索到。

不适合的场景我也要说实话。如果你需要的是一个完整的"AI 应用工厂"，要把知识库、Agent、流程编排、外部工具调用全部整合到一个平台上，WeKnora 不能满足你全部需求，它更聚焦知识库与 RAG 本身，复杂的工作流还是选择 Dify 这类平台更合适。另外，如果你手里的文档全是扫描件、手写笔记、复杂版式 PDF，WeKnora 的默认解析方案虽然能用，但效果可能不如 RAGFlow 的深度解析来得暴力，这种情况建议先用 RAGFlow 这类解析方案做前端处理。

2. 本机部署 WeKnora 的完整踩坑记录

2.1 部署前需要准备哪些东西

先聊一个很多人忽略的问题：部署知识库不是"装个软件"那么简单，它是一个系统工程，核心依赖除了 WeKnora 本身，还有三样东西——Docker 环境、一个大模型服务、一个 Embedding 模型。

硬件方面，我的建议是 CPU 至少 8 核、内存 16GB 起步，如果你想在本地同时跑 Embedding 模型和大模型做全离线验证，内存最好到 32GB 甚至更高。我自己第一次部署用的是 4 核 8G 的旧笔记本，系统起来了，但一旦执行文档向量化和问答请求，CPU 直接打满，体验很糟糕。说实话，如果只是测试，16G 内存算是个比较舒服的起步线。

软件环境，我只推荐 Docker 方式部署，这是最不容易出错的路径。Linux 服务器直接装 Docker 和 Docker Compose 就行；Windows 11 用户建议先装 WSL2 加 Docker Desktop，然后把整个部署目录放在 Linux 子系统里，文件路径相关的坑会少很多。我个人在 Windows 上踩过最典型的坑是：项目目录放在 Windows 文件系统，Docker 卷挂载的时候路径分隔符和权限出了问题，导致知识库目录一直扫描不到文件。后来把项目挪进 WSL2 的文件系统里，问题立刻消失。

模型准备这块要提前想清楚。你至少需要一个 Chat 模型用于最终生成答案，以及一个 Embedding 模型用于把文本变成向量。前者可以临时用云端 API，后者也同理。但如果你要做全离线私有化部署，我建议本地先把 Ollama 装好，后面模型的对接都走 Ollama 的 OpenAI 兼容接口，省很多事。

2.2 用 Docker Compose 一键拉起

WeKnora 的官方仓库里提供了 docker-compose 配置文件，我部署的时候大体是下面这个结构，你可以按自己的需求改端口和数据目录：

version: "3.8" services: weknora: image: weknora/weknora:latest container_name: weknora restart: unless-stopped ports: - "8080:8080" volumes: - ./data:/app/data - ./knowledge:/app/knowledge environment: - PERSIST_DIR=/app/data - LOG_LEVEL=info extra_hosts: - "host.docker.internal:host-gateway"

这里有几个细节我解释一下。./knowledge目录挂载出来，是为了让你可以直接往宿主机里丢文档，容器内部的扫描器就能读到；./data目录是 WeKnora 的持久化目录，向量索引、配置、日志都存在这里，所以一定要挂出来，不然容器一删，你的索引全部归零。host.docker.internal这个配置是为了在容器内访问宿主机的服务，比如你本地 Ollama 跑了 11434 端口，这个配置就能让 WeKnora 容器通过http://host.docker.internal:11434访问到它。

启动命令很简单：

docker compose up -d

启动后访问http://localhost:8080，就会看到 WeKnora 的 Web 管理界面。第一次启动会拉起数据库、索引服务等依赖组件，我实测下来首次启动需要等一两分钟，页面能打开之前别急着刷新，容易把初始化流程打断。如果页面一直打不开，先用docker compose logs -f看日志，90% 的原因都在挂载路径或者端口冲突上。

2.3 首次启动后的系统初始化

这里有一个最容易让新手懵掉的点：WeKnora 的 Web 界面跟那些"登录进去就能直接上传文件"的网盘型知识库不一样，它把知识库设计成了"先配置数据源、再扫描入库"的模式。第一次登录后，你要做的几件事是：

先到系统设置里把模型配好。你需要配置两个模型：一个是对话模型，负责最终生成回答；一个是 Embedding 模型，负责把文档切片转成向量。这两个模型配置好之前，扫描文档可以执行，但向量化那一步会卡住或报错。

接着创建知识库。WeKnora 里的知识库可以理解成一个独立的命名空间，每个知识库有自己的配置、自己的检索参数。创建的时候会让你选择解析方式、切分参数这些，初次使用保持默认就行，后面再根据文档实际情况慢慢调。

最后添加数据源。数据源指向你挂载的目录，把目录路径填进去，然后触发扫描。扫描完成后，你会看到一个"文档列表"，每条文档后面有解析状态，绿色代表成功，红色代表失败，失败的可以点进去看具体报错原因。到这里，一个基础的知识库就算跑通了。

3. 核心配置：模型对接与 Embedding 选择

3.1 大模型怎么接：OpenAI 兼容接口、Ollama、国内 API

WeKnora 在模型接入方面做了一个很聪明的设计：它没有绑死某一家厂商，而是走统一的 OpenAI 兼容接口。这意味着只要是兼容 OpenAI API 格式的服务，都能直接填进去用。我实测可用的有三类：

第一类，云端商用 API，直接在配置里填base_url和api_key就行。这类模型效果好、速度快，但数据要出内网，私有化场景慎用。

第二类，Ollama 本地模型。把 Ollama 跑在宿主机上，base_url填http://host.docker.internal:11434/v1，模型名填你在 Ollama 里拉取的模型名，比如qwen2.5:14b。这里有个经验：配置里填的模型名必须和ollama list显示的名字完全一致，大小写、冒号都不能差，不然会报 model not found。我一开始填qwen2.5而不是qwen2.5:14b，折腾了很久才反应过来。

第三类，本地部署的 vLLM、Xinference 等服务，只要是 OpenAI 兼容协议都能接。这类适合正式的生产环境，吞吐量和并发控制都比 Ollama 更稳。

模型选多大、选什么架构，直接影响使用体验。我的经验是：8B 量级的模型在常识性问答上表现尚可，但涉及企业内部专业术语、长文档推理时，效果明显不足，幻觉也更多；有条件就上 14B 以上的模型。如果资源有限，宁可把精力花在检索质量上——检索足够准，小模型也能给出不错的效果。这正好回应了网上那个讨论"卡帕西的知识库可以用小模型做吗"：检索增强本身就是小模型对抗幻觉最有效的手段。

3.2 Embedding 模型怎么选：匹配度的半条命

我可以直接说：在 RAG 系统里，Embedding 模型对最终效果的影响，有时候比对话模型还要大。对话模型不行可以换，Embedding 选错了，整个检索池的"语义结构"就是歪的，后面无论怎么调参都别扭。

聊参数之前先理解一个概念：Embedding 模型的作用是把一段文本变成一个高维向量，语义相近的文本在向量空间里离得近。所以 Embedding 模型的"语文水平"直接决定了你对文档的语义理解能力。这个能力用什么衡量？有一个主流方案是 MTEB 中文榜单，它就是专门评测 Embedding 模型效果的排行榜，选模型前先去看一眼，比自己瞎猜强得多。

2025 年这个时间点，我个人觉得值得优先考虑的几个方向包括：BGE 系列，尤其是针对中文优化的版本，在通用领域和检索任务上非常均衡；M3E 系列，对中文支持很好，在小规模私有数据上表现不赖；BCE 系列里专门做中文 embedding 的版本，检索效果也很能打。另外一些新的开源中文向量模型也持续在榜单上表现突出，我自己的习惯是拿真实语料做一个 mini 测试集，跑一次对比再决定。

无论选哪个，记住一个原则：Embedding 模型一旦确定并完成向量化，后面如果更换，必须对全部文档重新做向量化，否则会出现"新旧向量不兼容"的问题，检索结果会非常奇怪。这也是为什么我强烈建议在正式建库前就定好 Embedding 模型，而不是先随便填一个后面再换。

3.3 混合检索比例和相似度阈值怎么调

WeKnora 一个非常有价值的点，是内置了混合检索（Hybrid Search）机制，把"向量语义检索"和"关键词检索"（类似 BM25）结合起来。为什么要混合？因为两者有很强的互补性：向量检索擅长理解语义，能处理"换个说法但意思一样"的查询；关键词检索擅长精确匹配，能保证"提到了某个型号、某个代码"的文档绝对不会被漏掉。

在实际使用中，我拿内部技术文档做过测试：纯向量检索时，涉及精确型号的查询，正确文档经常排在第五名以后，导致回答引不到正确内容；纯关键词检索时，换一种说法提问就完全检索不到。混合检索把两者结合后，精确查询能被关键词捞上来，同义表述能被语义检索兜住，命中率提升了非常明显。

WeKnora 里可控的几个关键参数：

• 检索方式权重。调整语义检索和关键词检索的贡献比例，比如"七分语义、三分关键词"。我建议如果文档里专业术语多、代码片段多，关键词检索的权重应该调高一些。
• Top-K 值。控制召回多少条候选片段送给大模型。K 太小容易漏，K 太大容易把无关内容塞给模型造成干扰。我建议默认从 5 开始试，根据回答效果上下微调。
• 相似度阈值。低于这个阈值的片断不会被召回。阈值设太高会漏召回，设太低会混入大量噪音。我见过很多新手直接把阈值拉到 0.8，然后抱怨"什么也查不到"，实际上阈值应该根据你 Embedding 模型的分数分布来定。

我的调参步骤很简单：先用一组有代表性的真实问题做测试集，记录每一轮的检索命中情况，然后每次只改一个参数，对比前后效果。调参是一场实验，不是靠感觉。

4. 知识库构建：文档解析、切分与资源迁移

4.1 文档解析和切分策略怎么定才合理

知识库的原料是文档，文档进系统后要经历"解析 → 清洗 → 切分 → 向量化"这条流水线。解析阶段，WeKnora 支持 PDF、Word、Markdown、TXT、网页等主流格式，内部会把它们统一转成 Markdown 处理，这个设计很聪明——Markdown 是结构化的，保留了标题层级、表格、列表这些信息，后续按需切分就有依据。

切分是整个流程里最容易被低估的一步。切分是指把一篇长文档拆成若干文本块，每块单独向量化。切得好不好，直接影响两条：一是检索时能不能把"包含答案的那块"完整召回，二是喂给大模型时会不会把不相干的东西揉在一起。

切分参数里最关键的是 chunk size（块大小）和 overlap（重叠长度）。块太小，一个完整知识点被拆得七零八落，检索到一块也说不清来龙去脉；块太大，单个块里塞了太多噪音，向量表达变得模糊，还容易超出模型的上下文窗口。我的一般经验是：技术文档、操作手册这类结构清晰的，chunk size 设在 300 到 600 个字比较稳；overlap 设在 50 到 100 个字，保证相邻块的上下文不丢。

这里有个真实的负面案例。我一开始偷懒用默认的超大块去切一份产品需求文档，结果问答的时候，模型经常把两个不同的功能点揉在一起回答，看起来说得头头是道，实际上张冠李戴。把切分参数调小、overlap 调合理之后，这种情况立刻缓解。所以我对切分建议只有一句话：宁可多切几刀，不要把一整块硬吞下去。

4.2 从 Obsidian 或本地 Markdown 库迁移知识

很多人手里已经有一个 Obsidian 笔记库，里面沉淀了大量 Markdown 文档，想直接拿来做 AI 知识库。这个思路非常好，但直接拷贝整个 Obsidian 库文件夹进去扫描，大概率发现效果不理想。原因在于 Obsidian 的 Markdown 文件有很多"知识库特有元素"：双链[[笔记]]、标签、Callout 块、内嵌附件等，这些内容对普通文本解析器来说就是一堆噪音符号。

我的迁移建议是分三步走。第一步，把 Obsidian 库里的纯笔记文件复制一份出来，不需要保留所有双链语法，你可以用 Obsidian 插件先把链接格式化掉，或者写个简单的脚本把[[目标笔记]]替换成纯文本标题。第二步，按主题或目录分批导入，不要一次性倒一个几千篇的大库，批次导入方便你定位解析问题。第三步，导入后在 WeKnora 里跑一遍测试问题，看看哪些内容检索不到，再针对性调整切分策略。

还遇到过一个很实际的问题：Obsidian 里可能同时存在 Markdown 文件和大量图片、附件，WeKnora 扫描时会把这些附件也纳入索引流程。如果不需要对图片做处理，建议单独建一个数据源目录，只把纯净的文本类文件放进去，附件和源库文件分开管理，既保持 Obsidian 原库的完整性，又不影响 AI 知识库的整洁度。

4.3 索引不到、解析失败的高频原因

这段时间用下来，"知识库文件夹在那，但扫描之后显示 0 文档"或者"有文档但解析全部失败"是最常见的两个问题，我把高频原因整理成了一张速查表：

需要说明的是，解析失败本身不可怕，可怕的是你不知道失败在哪。我的做法是：每次批量导入后，第一时间在 Web 界面看解析状态列表，红色失败的单独点进去看日志；如果失败率超过百分之十，停下来查共性原因，而不是继续加量。批量导入加逐条排错，是知识库运维的基本功。

5. 问答过程中的常见问题排查

5.1 回答不准确、检索不到正确内容的三板斧

知识库部署好之后，第一个实际考验永远是："我丢进去几篇文档，问它里面的内容，它答得对不对？"如果答得不对，你八成会怀疑模型不够聪明，但大多数情况下，问题出在检索这一层。

排查顺序我建议固定为三个步骤。第一，先确认文档确实被正确向量化了——去知识库的文档列表里看状态，有没有大量失败的，有没有内容为空。第二，直接在知识库的检索测试功能里输入问题，看召回的前几条是不是真的包含答案；如果不包含，说明问题在切分或 Embedding 上，而不在模型上。第三，如果召回内容包含答案但回答仍然错误，才去检查对话模型的提示词设置、上下文处理逻辑。

实际案例很能说明问题。有一次我问一个内部系统的配置细节，AI 回答得模棱两可，检索日志显示命中的文件是对的，但命中的文本块停留在文档开头，压根没覆盖到答案所在的中段。这就是典型的切分不当——把 chunk size 调小、overlap 调大之后，答案所在的文本块被完整召回，回答立刻精准。所以遇到"答不准"，先不要把锅甩给模型。

5.2 解析失败的原因定位与针对性解决

WeKnora 的解析流程虽然做得完整，但遇到现实文档依然有翻车概率。我碰到最典型的是三种：

一种是被加密或加了水印的 PDF。这类文件表面上是 PDF，但内容流是加密的，解析器读不出文本。解决方式是先解密或用 PDF 工具去掉保护再入库。

另一种是"扫描件冒充 PDF"。很多人用扫描仪直接生成 PDF，里面全是图片，根本没有文本层。WeKnora 默认解析器对这种文件无能为力，需要走 OCR。技术方案有两个：一是先对 PDF 做文字识别，把识别结果转成带文本层的 PDF 或 Markdown 再导入；二是在知识库里接入 OCR 能力，在解析阶段自动处理图片内容。我个人前期用先转后导的方式，效果好、可控性强。

还有一种是超大表格。文档里嵌一张几十列、上千行的巨型 Excel 或 Word 表格，解析后变成了难以切分的超长文本块，向量化效果很差。遇到这种情况，建议先对原表格做结构拆分，拆成多个小表或用摘要描述每个部分，再进知识库。知识库不是数据库，它不适合存那种需要精确计算的原始数据表。

5.3 中文查询效果差怎么办

中文检索有一个所有 RAG 系统都逃不掉的课题：分词与语义对齐。中文不像英文天然有空格分词，一个词可能以不同的切分方式落在文本里，这给关键词检索带来很大挑战。我测试过同一个问题，用英文文档和中文文档分别做检索，中文的命中率下限要低得多，原因并不是二者难度差异，而是中文文本没有做好预处理。

提升中文检索效果，我有几个亲测有效的手段。第一，开混合检索且关键词分支权重适当提高，让精确的词面匹配把正确文档拉回来。第二，在文档切分前做统一预处理：全角符号转半角、清理多余空行和特殊符号、规范标题层级，这些看似是小事，但对向量化和关键词匹配都有实在帮助。第三，对查询词做同义扩展，比如用户问"怎么退款"，但文档里写的是"退费流程"，靠向量语义能关联一部分，但如果把查询词自动改写再检索，命中会更稳。WeKnora 的查询改写能力在这种场景下非常实用，强烈建议开启。

6. 从知识库到 Agent：WeKnora 在企业场景的落地路径

6.1 私有化部署在企业落地的关键要求

聊完个人部署，说点企业级的干货。我们在团队内部落地 WeKnora 时，遇到的不只是技术问题，还有部署环境和工程化要求，几个关键点我单独列出来。

第一个是网络隔离。企业私有化部署经常要求完全内网运行，这就意味着 Embedding 模型、对话模型都必须内网可达，不能有任何云端调用。我们的做法是用 Ollama 或 vLLM 在内网服务器上跑模型，所有模型调用都走内网地址，数据全程不出内网。这一点想明白之后，整个架构就清晰了。

第二个是资源规划。别小看 RAG 系统的资源消耗。对话模型、Embedding 模型、WeKnora 服务、向量索引，每一块都要占到资源。我们内部给的参考值是：如果文档总量在几十万级，Embedding 模型推理需要独立分配 GPU，对话模型如果并发量不大，CPU 推理勉强能跑，但响应速度会慢。一个实际的经验教训是：先小规模跑通，再根据并发压力逐步加资源，比一上来就按最大的买要省得多。

第三个是权限与审计。知识库里的内容通常是公司核心资产，账号体系、访问控制、操作审计都要提前规划。WeKnora 本身定位在 RAG 引擎，更重度的企业权限能力需要结合你已有的认证体系或网关来补。我建议把知识库服务部署在公司统一网关后面，由网关统一做认证和授权，这样管理和安全都能兼顾。

6.2 用 WeKnora 支撑 Agent 问答和外部知识补充

很多团队做知识库不只是为了问答，而是想把它接入 AI Agent，让 Agent 回答问题时能实时引用内部知识。WeKnora 走 OpenAI 兼容接口这个设计，在这一点上给了我们很大的便利：Agent 框架可以通过标准接口把查询发过来，检索结果以标准化结构返回，Agent 再结合大模型生成最终回复。

我们实际落地的一个流程是：Agent 收到用户问题后，先从 WeKnora 检索相关内容，如果检索到的置信度不够，再触发一次网页搜索作为补充，把搜索结果和知识库结果一起给到大模型处理。这么做的好处是"内外部知识两不误"：对于内部制度、产品文档这类问题，知识库给出准确答案；对于突发的、外部的新信息，网页搜索兜底。WeKnora 本身也内置了网页搜索增强相关的设计，这个方向它早就考虑到了。

另外，别忘了 RAG 的经典问题：知识库更新。企业里的文档库永远在变，新版本替代旧版本，旧文档下线。我们的建议是给知识库建立定期重建机制。信息变动频繁的业务线，每天增量扫描一次；变动少的团队，每周全量重建一次。索引文件和原始文档分开存储，重建时才能做到不影响线上服务。

6.3 更近一步：农业知识库、专利辅助等垂直场景怎么用

最后聊两个我在跟朋友交流时经常被问到的垂直场景，其实都是从同一个方法论展开的。

一个是农业知识库。农业领域的知识来源特别杂：有地方标准、种植手册、气象数据、病虫害图谱、专家问答记录，格式五花八门。用 WeKnora 建农业知识库的要点在于：先把结构化程度高的政策文件、技术规程做精细解析入库，再把专家问答记录、田间案例这类非结构化文本单独建一个知识库，两个库分开管理、按需检索。另外农业场景里方言和俗称非常多，比如同一个病害在不同地区叫法完全不同，这个问题靠 Embedding 语义关联能解决一部分，配合关键词检索和查询改写能兜住更多，混合检索在这个场景下价值尤其明显。

另一个是专利相关辅助。专利领域的检索特点是专有名词极多、权利要求表述极其精确，一个字符差异可能就导致完全不同的技术方案。这类场景我强烈建议把关键词检索权重拉高，并且在入库前对专利文本做结构化预处理：把标题、摘要、权利要求、说明书拆成单独字段分别入库分类。不要把所有内容混在一个大文本块里，否则检索精度会损失很多。把精准匹配机制用足，专利辅助才能做到靠谱。

最后分享一点我的实际体会

做知识库这件事，和很多人想的不一样，真正难的不是部署，而是"让检索结果配得上大模型的生成能力"。WeKnora 这个项目给我最大的启发是：一个好的 RAG 引擎不是把文档一股脑交给模型，而是通过解析、切分、混合检索、查询改写这一整套流程，把正确的信息准确捞出来，让模型站在可靠的信息上进行生成。

我在实际操作中的一个体会是：不要急着追求"所有知识一个库解决"。不同来源、不同结构的内容，拆成多个知识库、分配合适的解析和检索参数，结果永远比堆在同一个库里更稳定。遇到效果不理想，先从检索日志和召回结果里找原因，再回头调切分和检索参数，这条路径比盲目换模型、乱调 prompt 靠谱得多。

如果你正准备把本地笔记或者企业内部文档变成 AI 知识库，我的建议是：先把最小闭环跑通，用一两篇真实文档测试整个链路，再做批量导入和参数调优。这个流程走顺了，WeKnora 会变成一个非常省心的知识底座。