做企业知识库这几年我前后换过好几套方案有直接用向量数据库裸写的有拿 LangChain 自己拼管线的也有试过各类开源平台。最后让我真正愿意稳定跑下来、并且愿意推荐给团队的是腾讯微信团队开源的 AI 知识库项目 WeKnora。它解决的痛点很实在知识库要能私有化部署、要能处理乱七八糟的文档格式、要能把检索和问答衔接得足够好而不是只给一个能聊天的壳。这篇文章我就把这段时间部署和使用 WeKnora 的完整经验整理出来包括方案选型、本机部署、模型配置、文档解析、常见问题排查以及从知识库到 Agent 的落地路径给正在折腾知识库的朋友一个参照。1. 为什么在众多知识库方案里挑了 WeKnora1.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 界面做知识管理和问答测试。它特别在意检索质量提供了混合检索、查询改写、上下文扩展这些深度功能这些在别家通常要自己写代码实现。下面这张表是我的主观对比供参考对比项WeKnoraDifyRAGFlowMaxKB核心定位RAG 知识库引擎AI 应用开发平台深度文档解析 RAG知识库问答系统部署复杂度中等Docker Compose 一把梭较复杂较复杂简单文档解析能力强常见格式全覆盖中等极强中等检索调优能力强混合检索 多种参数可调一般较强一般平台化 / 工作流弱不是它的重点很强中等中等适合人群想深度做知识检索和 RAG 的团队需要完整 AI 应用平台的团队对复杂文档解析要求极高的团队快速搭建知识问答的个人或小团队如果你已经有一个复杂的业务流程要编排选 Dify 没错如果你每天要解析大量扫描版 PDFRAGFlow 会更省心但如果你的核心诉求是把手里的文档变成高质量的检索池配合大模型做精准问答WeKnora 值得认真研究。1.3 什么场景适合选它什么场景不适合先说适合的场景。我最推荐 WeKnora 的场景有三类第一企业私有化知识库。文档涉及内部资料不方便调用云端 API 做入库加工必须在内网部署WeKnora 对私有化部署支持得很干净模型也可以接本地 Ollama 或者内网部署的模型服务。第二知识检索质量要求高的场景。比如研发团队想让 AI 基于内部技术文档回答问题答案引用的内容必须准确不允许大模型胡编。这种场景下WeKnora 的混合检索机制能显著提升答案是否有据可依的概率。第三需要持续更新和扩充的知识库。WeKnora 在增量更新方面做得比较顺你可以随时往知识库目录里丢新文档重新扫描后新内容就能被检索到。不适合的场景我也要说实话。如果你需要的是一个完整的AI 应用工厂要把知识库、Agent、流程编排、外部工具调用全部整合到一个平台上WeKnora 不能满足你全部需求它更聚焦知识库与 RAG 本身复杂的工作流还是选择 Dify 这类平台更合适。另外如果你手里的文档全是扫描件、手写笔记、复杂版式 PDFWeKnora 的默认解析方案虽然能用但效果可能不如 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_LEVELinfo 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、国内 APIWeKnora 在模型接入方面做了一个很聪明的设计它没有绑死某一家厂商而是走统一的 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 文档或者有文档但解析全部失败是最常见的两个问题我把高频原因整理成了一张速查表现象常见原因解决办法扫描后 0 文档数据源路径配置错误容器里看不到该目录检查挂载卷路径是否对应先在容器内确认文件是否可见全部解析失败Docker 挂载目录权限不足容器内无读取权限宿主机关联目录执行 chmod或在 compose 里加 user 配置PDF 解析为空扫描件或图片型 PDF没有文本层先做 OCR 再导入或更换带 OCR 能力的解析组件Word 解析乱码文件编码问题多见于老式 doc先统一转成 docx 或 Markdown 再导入部分 Markdown 解析失败文件里有非常规语法或超长表格定位单文件测试简化异常内容大文件解析超时单文件过大或页数过多拆分文件后分批导入需要说明的是解析失败本身不可怕可怕的是你不知道失败在哪。我的做法是每次批量导入后第一时间在 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. 从知识库到 AgentWeKnora 在企业场景的落地路径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 会变成一个非常省心的知识底座。