★ FEATURED ARTICLE 如果公司最近想搞一个“私有知识库问答”系统又不想从零开始写一套RAG流水线WeKnora 这个名字值得多看两眼。它是腾讯微信团队开源的知识库产品定位非常明确把文档解析、知识切片、混合检索、重排、大模型生成以及 Agent 能力打包成一整套可部署的方案。我最近一个月把它的部署、知识库搭建、参数调优、解析失败排查全跑了一遍踩了不少坑也摸索出一些处理经验这篇就围绕“WeKnora 能解决什么问题、核心链路怎么设计的、本机和服务器的部署流程、知识库调优与排错技巧”展开尽量给一份可以直接照做的实操记录。先说适用范围如果你要给团队搭私有文档问答或者想把 Obsidian 笔记变成一个可搜索的“第二大脑”又或者你在对比 Dify、RAGFlow、MaxKB 和 WeKnora 这类开源知识库方案这篇内容会比较对路。下面从项目定位开始逐步拆解。1. WeKnora 是什么先看清它解决的是一类什么问题1.1 它属于哪一层产品大部分人最开始接触大模型应用时脑子里想的是“我找一个 ChatGLM / Qwen / Llama 模型把文档丢给它它就能回答”。实际做起来会发现根本不是这么回事。模型不会自动记得你私有文档里的内容它只知道训练阶段看到的数据。要让模型回答公司内部的制度手册、产品文档、售后 FAQ必须走一条“先把文档变成可检索的索引再带着检索结果去问模型”的链路。这条链路就是 RAGRetrieval-Augmented Generation检索增强生成。WeKnora 属于“RAG 知识库”这一层产品它把链路里的组件都集成好了。你部署好之后既可以把它理解成知识库管理系统也可以理解成一个带有检索增强能力的问答服务。它内部包含了文本向量化、知识库管理、关键词检索、向量检索、重排、大模型接入这几个核心模块。更关键的是它还带了 Agent 能力不只做简单的一问一答还能在某些场景下做多轮意图判断和任务路由。我把它和“自己拼装”的方案对比过。自己拼装需要处理的问题非常多文本抽取用哪个解析器、文档要怎么切片、向量库选 MySQL 里的 Vector 插件还是 Elasticsearch、要不要用 Milvus、重排模型怎么单独部署、前端问答界面怎么实现。这些问题每一个单独拿出来都是一个小项目全部串起来调试以周为单位的工期就没了。WeKnora 的思路是直接把这一套东西做成开箱即用的产品形态部署完有界面有 API也有管理后台我只要关注“文档准备得好不好”和“参数调得对不对”而不是从零去搭每一块组件。1.2 和 Dify、RAGFlow、MaxKB 横向对比差异在哪我见过很多人在选型时候纠结Dify、RAGFlow、MaxKB、WeKnora 到底选哪个根据我这段时间的对比使用它们虽然都属于大模型应用/知识库赛道但侧重点差别很大。项目定位侧重上手门槛知识库能力额外亮点适合场景DifyLLM 应用开发平台中等知识库是模块之一支持基础的检索与召回工作流编排、Agent、API 发布想从问答延伸到完整 AI 应用开发RAGFlow深度文档理解较高强调对 PDF、表格、版面等多模文档的解析切分DeepDoc 文档智能解析文档格式复杂、版式繁多的企业资料MaxKB轻量知识库问答低基础检索问答简洁直接安装简单聚焦快速落地对“快速跑通问答”有强需求的小团队WeKnora知识库 RAG Agent中等混合检索、重排、切片管理、知识库管理完整Agent 机制、多模型源支持、可视化需要私有化知识库、同时需要任务型问答的企业我个人的选型建议是如果你的诉求非常纯粹就是把一堆 PDF 变成可问答的知识库那 WeKnora 和 RAGFlow 是主要候选。RAGFlow 在文档版面理解上更激进适合表格多、扫描版样式多的复杂文档WeKnora 则在 Agent 能力和整体产品完整度上更均衡尤其适合不仅要问答还想定义一些“知识库自动处理任务”的场景。如果你本来就更需要工作流编排那 Dify 更合适它的强项是应用开发框架。MaxKB 适合做轻量验证先把项目跑起来看看效果再决定要不要换更重的方案。2. 核心链路拆解为什么知识库的核心在检索而不在生成2.1 RAG 完整工作流程从文档上传到回答生成要真正用明白 WeKnora必须先理解它内部的工作流。RAG 这条链路我们可以拆成四个阶段索引构建、检索召回、重排精排、生成回答。索引构建阶段发生在“你上传文档”的时候。WeKnora 会先把 PDF、DOCX、Markdown、TXT 里的文本抽取出来按设定好的切片规则把长文本切成若干块然后对每一块做向量化生成对应的向量索引同时建立关键词索引。简单说就是把一本厚书拆成很多张带编号的小卡片每张卡片上写着内容还有一个可以按语义查位置的编号。检索召回阶段发生在“用户提问”的时候。问句会被同时拿去匹配两种索引关键词匹配和向量匹配。关键词匹配像搜索引擎那样找字面命中向量匹配是理解语义后找意思相近的内容。两个检索结果会被合并到一起形成一个候选集合。这个阶段追求的不是精确而是“不要漏掉可能相关的片段”。重排精排阶段解决的是“召回太粗糙”的问题。一次检索可能召回几十个片段但真正和用户问题强相关的也许只有三五个。WeKnora 会用一个更精细的重排模型把候选片段按相关性重新打分排序只留下最靠前的几个片段。生成回答阶段就是把保留下的片段当成参考资料和用户问题一起组成提示词交给大模型进行回答。模型的回答会被要求“只依据参考资料中的内容生成”这样就能从机制上减少模型瞎编的概率。如果你发现回答质量不好先不要急着怪大模型大概率是前面某个环节出了问题。我调试的时候最深的体会是检索不准后面模型再强也救不回来。2.2 为什么需要混合检索和多路召回很多人在初学 RAG 时有个误解觉得向量检索是万能的关键词检索是过时的技术。实际用下来根本不是这样。向量检索处理“语义相同但表述不同”的查询效果很好比如用户问“公司的年假政策”文档里写的是“休假管理规定”两者字面上没重合向量检索能通过语义关联找到。但向量检索在精确匹配上有明显短板比如产品编号、合同号、工单号这种需要完全匹配的信息关键词检索的效率反而更高。字面检索能直接命中唯一编号向量检索却可能因为语义相近给你返回一堆相似但不相干的结果。WeKnora 采用的就是混合检索方案。刚才提到的多路召回本质上就是把两类检索的长处都利用起来一路用 BM25 之类的关键词算法做字面匹配另一路用向量模型做语义匹配最后通过 RRFReciprocal Rank Fusion倒数排名融合之类的方法把两个结果列表合并排序。这个设计是从搜索引擎里继承来的成熟方案稳定性非常高。我做过一个比较直观的测试文档里全是 SOP 类操作手册里面大量出现参数名称和固定编号。只开向量检索时常见的现象是“意思接近但编号对不上”只开关键词检索时又容易漏掉用户用同义表达提问的情况。混合检索之后两类状况都明显减少。所以部署完 WeKnora我个人建议保持默认的混合检索模式不要轻易关掉某一端。2.3 Rerank 重排花很小代价换很大的准确率提升重排是容易被忽略、但效果收益非常大的模块。第一次跑通 WeKnora 之后我给知识库传了一份约 200 页的产品维护手册然后提问“设备运行时报温度过高如何处理”。初版回答内容其实已经提到了排查步骤但引用内容的顺序是乱的甚至把不相关的巡检流程也带进来了。原因是检索阶段召回的片段相关性排序不够细大模型按原顺序把信息拼进去逻辑自然就显得混乱。打开重排之后效果有了非常明显的提升。原因在于召回阶段用的是对性能要求高、速度快的轻量模型这类模型的排序精度有限可以把它理解成“快速海选”而重排阶段用的是专门的 reranker 模型它会对每个候选片段和用户问题做更精细的语义相关性打分然后重新排序。海选负责不漏掉精排负责排好序。在实际配置中最好给重排模块单独预留一点资源。如果和向量模型、大模型挤在同一块 GPU 上有可能导致整体延迟上升。重排结果里通常会给出一个相关性分数我建议在前期调优时把这个分数打开观察一下同一问题的得分数值范围后面设置阈值时心里更有数。2.4 Agent 能力知识库从“问答”迈向“任务处理”只是做一个“能回答问题”的知识库系统其实很多开源方案都能实现。WeKnora 比较有区分度的一点是它内置了 Agent 机制。我自己的理解是Agent 在知识库场景里解决的是“如何在多轮对话中判断该做什么”的问题。普通问答模式下用户每说一句话系统就去知识库里检索一次然后生成答案。但真实场景里用户说话不会那么规整。用户可能先问一句“今年公司的调休规则是什么”然后又来一句“和去年有什么区别”如果每次都独立检索第二句很可能检索不到有效内容因为“去年”需要结合第一轮提到的背景才能定位。Agent 机制会把对话历史纳入判断流程识别有没有上下文依赖决定是重新检索还是基于上一轮结果直接回答。另外Agent 还支持把知识库当工具来调用。比如“帮我总结一遍售后话术再按客户类型分个组”这种指令已经超出了“检索一段文本然后复读”的边界需要系统理解任务意图、拆解步骤、调用知识库或模型能力去执行。当然Agent 的复杂度也会带来调试难度提升如果你只需要简单的文档问答可以先关掉它等基础链路稳定之后再逐步启用。3. 部署实操Windows 本机和 Linux 服务器的完整记录3.1 Windows 11 下的 Docker 快速启动不少人在 Windows 上折腾开源项目时会遇到环境依赖问题WeKnora 在 Windows 11 下最稳妥的启动方式是用 Docker。我先把本机安装过程完整说一遍。首先是前置准备安装并启动 Docker Desktop。启动之后建议在 Settings 里把资源内存调到 8GB 以上因为知识库服务往往包含向量模型、重排模型和多个后端组件内存太小容易启动到一半直接 OOM。我用的是 16GB 内存的笔记本给 Docker 分配了 8GB运行起来还算从容。然后从 WeKnora 的 GitHub 仓库拿到 docker-compose 配置。发布包里一般会提供一份示例编排文件里面定义了知识库后端、解析服务、检索服务、前端界面等几个容器的启动参数。我把整个项目克隆到本地目录在项目目录下执行docker compose up -d第一次启动需要拉取镜像这个过程根据网络情况可能持续一段时间是比较正常的现象不要中途 CtrlC。拉取完成后查看容器状态docker compose ps只要状态显示 Up 就说明服务起来了。注意一下日志输出确认没有报数据库连接失败、端口被占用这类致命错误。默认情况下前端界面会映射到某个本机端口在浏览器里访问 http://localhost:端口 就能看到知识库的管理界面。我在 Windows 下遇到的一个典型问题是 Docker Desktop 本身没起来导致 compose 命令直接提示没法连接 Docker 守护进程。这种问题大概率不是 WeKnora 的问题先去检查 Docker Desktop 右下角图标状态再检查服务列表里 docker 相关服务有没有被禁用。需要提醒的是不同版本的镜像名和默认端口可能有变化具体以你下载到的 docker-compose 文件里的参数为准不要硬套网上旧文章的端口号。部署完成后在登录页完成管理员账号初始化然后就可以进入系统实践了。3.2 Linux 服务器部署资源规划与关键配置Windows 本机部署适合体验和测试但要真正给团队用一般会放到 Linux 服务器上。部署步骤和 Docker 方案类似只是有几个点需要额外注意。资源规划方面根据我自己的体验一个承载几个 GB 文档知识库、并发量不高比如五六个人同时用的服务CPU 给 4 核以上、内存给 16GB 以上会比较舒服。如果文档量很大或者会话并发要求高内存和 CPU 要按需上调。向量化模型和重排模型如果跑在 CPU 上也能用就是速度会明显慢有条件的话推荐给模型推理分配一块独立 GPU显存建议至少 8GB模型计算和检索服务的延迟会低很多。服务器上执行 docker compose 之前记得先确认防火墙或安全组策略保证外部访问端口是放开的。这一点经常被忽略很多人在服务器上部署完同一台机器上访问没问题换了办公电脑就访问不了排查半天发现是安全组没放行端口。Docker 服务的配置上我习惯在 compose 文件里把数据目录用卷挂载出来比如把 MySQL、向量数据、上传的文件持久化到宿主机目录。原因很直接容器本身随时可能被删掉重建如果不做数据持久化一次 docker compose down 就可能把所有知识库数据全部清空。我看过太多同行犯这个错误重新建库倒不难重新处理文档才让人崩溃。3.3 用 Ollama 接本地模型数据不出内网的大模型方案WeKnora 支持对接多种模型服务使用外部 API 是最简单的方式但对很多企业来说数据安全是第一位的。文档内容本来就是要保密的再送到公网 API 去生成答案很多项目根本过不了合规评估。这时候最常用的方案就是本地模型 Ollama。关于 Ollama它就是一个大模型本地管理工具一条命令就能把模型跑起来同时提供 OpenAI 风格的 API。我的推荐流程是先在服务器上安装 Ollama然后拉取一个生成能力够用的模型ollama pull qwen2.5:7b模型体积根据参数大小从几 GB 到几十 GB 不等下载前先评估一下磁盘空间。拉取完成后验证模型服务是否正常ollama serve然后回到 WeKnora 的管理界面配置大模型来源填写 Ollama 的 API 地址。由于 Ollama 默认监听的是本机地址如果 WeKnora 跑在同一台服务器上地址直接填 http://localhost:11434 就能连通。如果两者不在同一台机器需要把 Ollama 的监听地址改成可访问的 IP同时注意网络安全配置。这种本地模型方案的优势很明显数据全程在私有网络内流转不依赖外部接口服务对“私有化部署”这个诉求非常匹配。本地模型的选择上我的经验是 7B 到 14B 参数量级别的模型在知识和逻辑能力上已经能应付大部分文档问答。参数量太低比如 3B 以下回答会明显单薄参数量太高比如 70B 级别普通单卡跑不动部署成本会大幅上升。先拿 7B 跑通整个链路如果回答质量确实不够再考虑升级模型规模。3.4 部署完成后的功能自检清单服务部署完不要急着把几十个文档全部批量导入。我建议先做一次最小化的自检确保整条链路是通的。我的自检顺序是这样的第一步新建一个知识库上传一份格式简单、内容清晰的 PDF 或 Markdown 文件比如一篇几千字的产品说明。第二步确认文件解析成功没有出现解析报错。第三步打开界面里的问答对话问一个“文档里直接写明答案”的问题比如从文章中摘一个事实性细节来问。第四步问一个需要跨段落整合才能回答的问题测试检索和切片是否足够合理。第五步如果配置了本地模型再到后台观察调用日志确认模型请求确实发给了 Ollama。这五步都能通过基本说明部署没问题。如果某一步失败那正好按第 5 章的排查清单去检查定位问题会快很多。4. 知识库搭建与调优让检索命中率实打实提高4.1 文档“解析失败”的常见原因为什么传上去的内容没生效部署只是开始真正花时间的是知识库搭建。我遇到的第一个大坑是“文档解析失败”。你可能遇到过这种场景文件上传显示成功了但在问答里怎么问都答不出来或者界面上直接提示解析失败。把时间拉长看几乎所有的解析失败都能归到几类原因上。第一类扫描版 PDF。严格说扫描件本质是图片不是文本。文件里根本没有可抽取的文本层解析器自然什么都读不出来。这种文件必须先做 OCR光学字符识别把图片里的文字转出来。解决办法是内容重要的话用带 OCR 能力的工具提前转一遍输出成文本 PDF 之后再上传或者选择能自动做 OCR 的解析方案。第二类PDF 被加密或设置了编辑权限。许多企业内部发的制度文件都有权限保护遇到这类文件解析器会报错因为无法直接读取内容。要先把文件解密并去掉限制另存为新的 PDF 再上传。第三类超长表格或复杂版式。比如几十页的财务汇总表、多层嵌套的审批流程表这种内容在抽取时容易乱甚至被打断。我的建议是核心内容尽量转成 CSV 或结构化文本再入知识库如果一定要用原始 PDF那就把它拆成小文件再传降低单文件的解析压力。第四类文件已经损坏或不完整。这类最隐蔽因为文件在本地打开正常但解析服务读取到最后直接报错。排查时先看解析日志再尝试用其他工具另存一份。这四类问题背后有一个共同思路知识库系统的解析能力是有边界的复杂文档应该先在外部处理好再喂给系统。把“解析成功率 100%”这个期望改成“让文档达到系统能理解的标准”后续会顺利很多。4.2 切块策略块大小、重叠与元数据怎么定文档解析成功之后下一个直接影响回答质量的环节是文本切片。切块太长或太短都会有问题。切块太大比如一个块有 1000 字以上检索时召回的一个片段里可能混杂了多个主题信息大模型从中间挑答案不仅容易答偏还会浪费上下文窗口。切块太小比如几十个字一个块信息会被切得支离破碎检索召回的片段也无法提供完整的事实依据回答经常只能答出局部细节。我的经验值是中文文档环境下默认切块可以设在 256 到 512 字之间重叠区域保持在 50 到 100 字。重叠的目的是避免句子被从中间硬生生切开让同一句话能出现在相邻两个块中检索时无论落到哪一块都能找到完整表达。这个思路可以类比切水果切完还要留一点边缘保证每一块都带着完整信息。具体场景还要再灵活一些。操作手册类文档内容大多按步骤组织我会倾向于小一点的块让检索尽可能精确到某一步制度规范类文档逻辑完整的一段话往往更重要块可以稍微放大。如果系统支持按 Markdown 标题切片就会更好。以“#”“##”作为边界来切比纯按字数硬切要合理得多能保证切片不会切断语义。还有一点容易被忽略元数据。给切片打上“来源文档”“章节标题”之类的标签问答时返回的引用会清晰很多排查某个答案来自哪里也方便。别省这一步后续维护知识库时能省很多事。4.3 提高匹配度topK、阈值与查询改写“怎么提高匹配度”是知识库使用的高频问题。我以前也以为匹配度低是模型不行后来发现参数配置的贡献可能比模型本身更大。检索时要注意的第一项参数是 topK即召回多少个候选片段。K 值太小容易漏掉信息K 值太大重排和生成环节会收到大量噪声反而干扰回答。我一般从 10 到 20 之间开始调。如果问题答案分散在多个段落就把 K 调大一点如果问题很精准K 调小反而更能保证回答聚焦。第二项参数是相似度阈值。如果阈值设置过高能通过检索的片段变少结果经常是“没有找到相关内容”阈值设置过低一些不太相关的片段也能进来回答会变得含糊。我的调法是拿几个典型问题反复测试记录每次检索结果的相关性分数分布找出“有效片段”和“无效片段”之间的分数分界线然后以此为参考设置阈值。第三项容易被忽略的是查询改写。有些提问方式对检索极不友好比如用户问“它一般多久需要维护”文档里的表达是“日常保养周期为三个月”。“它”指代不明、提问过于口语化直接检索就容易匹配失败。在 Agent 或多轮场景下系统可以对用户问题做语义补全把口语提问改写成适合检索的表达比如“设备日常保养周期是多久”召回效果会明显改善。前端能做的反方向优化是在知识库里给文档补充别名和关键词把同义词覆盖进去。我自己常用的一个技巧是把历史高频问题整理成“典型问答对”直接放进知识库。有些内容无论怎么切、怎么调参数检索效果都一般但以“问-答”形式存储后检索命中率会非常高。这就类似于在搜索引擎里直接命中标准答案页效果比纯靠语义检索要好得多。4.4 从本地笔记到团队知识库和 Obsidian 联动的可能热搜里频繁出现两个词的组合“WeKnora”和“Obsidian”。很多知识管理爱好者已经在 Obsidian 里积累了庞大的 Markdown 笔记库他们想知道能否把这套笔记体系接入知识库。我的结论是可以而且天然适配。Obsidian 的笔记本质是 Markdown 文本而 Markdown 恰恰是知识库解析器支持最好的格式之一。没有 PDF 扫描件、没有加密权限问题、没有复杂表格的困扰几乎不会遇到前面说的那些解析失败问题。联动的思路可以按两种场景来做。如果你只是个人使用让知识库读取某个笔记目录就可以完成联动如果你是团队使用更推荐建立一套持续同步的机制。做法很直观把 Obsidian 的笔记仓库用 Git 管理然后在服务器上定时拉取最新的笔记内容再通过 WeKnora 的文件目录同步或者重新导入功能更新知识库。这样笔记侧更新完同步到服务器知识库也会跟着更新。但要注意一点Obsidian 笔记的个人化表达非常强很多简写、标签、待办标记不适合直接检索。我建议在导入知识库前单独设置一个“已发布笔记”目录只把整理过、表达完整的笔记放进知识库。那些随手记的碎片、还在草稿阶段的想法不进知识库反而更省心。用这种方式相当于给个人笔记加了一层语义检索入口。以前在 Obsidian 里找内容靠文件名和全文搜索只能做字面匹配明明脑子里有概念就是想不起关键词接入知识库之后可以按语义提问把“我记得我写过某段关于数据库索引优化的话”变成“数据库索引失效的主要场景有哪些”检索体验完全不同。5. 常见问题速查与排错心得5.1 文档解析失败排查表结合前面的经验我把解析失败的问题整理成一张速查表遇到问题可以按表格对号入座。问题现象常见原因处理方式上传 PDF 后提示解析失败文件是扫描版图片无文本层先 OCR 成文本 PDF再上传PDF 无法读取文件有密码或编辑权限受限解密、去除权限限制后另存为再上传文件上传成功但问答检索不到解析实际失败只是界面提示不明显查看解析任务日志定位具体报错表格类文档内容混乱复杂表格/长表格版式抽取困难转成 CSV 或拆分成小文件上传所有文件都解析失败解析服务未启动或配置错误检查解析服务容器状态和依赖组件5.2 服务启动与运行期的典型故障除了解析问题服务本身也可能出故障这里列我自己遇到过的三个典型情况。第一个是启动阶段内存不足。前面提过Docker Desktop 默认内存配额可能不够多个容器一起拉起来后系统直接卡死或者个别容器反复重启。解决办法是提前在 Docker 配置里调内存并在启动后观察容器日志是否出现 OutOfMemory 字样。Linux 服务器上是检查一下机器是否因为内存不足走了 swap那也会让服务响应变慢到没法用。第二个是端口冲突。WeKnora 的几个组件会占用多个端口如果你本机已经跑了其他开发服务可能正好和默认端口撞上。检查端口占用netstat -ano | findstr 端口号如果确实冲突修改 docker-compose 里的映射端口即可不要改动容器内部端口否则有可能导致容器之间互相访问不通。第三个是模型服务没起来。有时候界面能打开、知识库也能管理但一问问题就报错。最常见的场景是大模型服务没有正常启动或者 API 地址配置不对。如果用的是 Ollama先去命令行手动拉一下模型看看再用 curl 测一下 API 是否能通。这种问题通常不是 WeKnora 自身的 bug而是外部模型服务连带导致的。5.3 回答质量差时的排查顺序回答质量差我建议按下面的顺序排查而不是直接换一个更大的模型。第一步看检索结果。进入问答调试面板查看召回的知识片段是否和问题真正相关。如果不相关问题在切块方式、检索参数或文档质量上先优化这里。第二步看重排结果。如果召回的片段本来相关但排序靠后的片段被忽略了问题在重排。第三步看提示词和生成参数。如果召回和重排都没问题答案是模型组织语言的能力不足这时再考虑换更强模型。第四步看多轮交互。如果是后续追问答偏了问题在上下文理解需要启用并调优 Agent 能力。有一个非常典型的例子我本来怀疑模型太菜仔细一看调试面板召回的内容全是文档里“产品参数表”内容而用户问的是“故障排除方法”两者只有轻微文字重叠。这其实是典型的关键词检索把方向带偏了。调整了切片粒度并提高语义检索权重后回答质量立刻不一样。这个案例说明先看检索再动模型能省下大量无用的调参时间。5.4 升级与数据备份版本更新要留一手WeKnora 这种开源项目迭代速度不慢你可能隔段时间就想升级到新版本获得新的解析能力、Agent 功能或者 bug 修复。升级本身不复杂但要注意数据兼容性。我的习惯是升级前先做三件事第一件备份知识库数据包括向量索引数据、数据库数据和上传的原始文档第二件记录当前自定义的配置项比如模型 API 地址、检索参数、切片设置第三件查看更新日志确认新版有没有数据库结构变更或配置项变更。如果是跨大版本升级最好不要原地升级而是新起一套环境导入备份做个完整验证确认没问题后再让团队切换。这个习惯的本质是控制风险。很多时候“升级失败”不是新版有问题而是旧数据格式和新版组件不兼容。留好备份、先小范围验证升级就不是什么让人心虚的事。最后再分享一点个人实操体验折腾 WeKnora 这段时间我的感受是知识库工程里最花时间的不是部署而是“把文档质量搞上去”和“把检索参数调到位”这两件事。技术组件都是现成的真正拉开效果差距的是对文档的治理能力和对检索链路的理解。如果你刚开始接触建议先拿一个小而精的知识库跑通全链路再逐步扩大规模不要一上来就导入大量混乱的文档那样只会让问题排查变得极其痛苦。另外本地小模型做知识库问答完全可行只是效果预期要合理——先确保检索链路准确再用小模型也能做出实用的内部问答系统。后面如果想继续深入还可以研究怎么把 Agent 工作流和更多企业内部工具串起来这块的想象空间同样不小。
阅读完成 · 觉得有帮助？
