WeKnora 详解系列 · 第 03 篇
各位数码圈的老铁们，我是叨叨数码。
上一篇我们聊了怎么把文档接进来、三种对话模式怎么选。那篇文章发出后，公众号后台收到最多的一条留言是：
"叨叨，我问的问题它回答得不够准啊！""叨叨，我们公司用的豆包大模型，能接进去吗？""叨叨，我们 IM 用的是钉钉，不是企业微信，咋办？"
问到点子上了。
这三个问题，其实分别对应 WeKnora 三大底层能力：检索引擎、模型集成、IM/对象存储集成。这一篇，咱把这三件事一次说透。
按照数码圈"测完硬件要拆开看内部构造"的惯例——今天咱们不聊表面，把 WeKnora 拆开看。
一、为什么"答得不够准"？问题大概率出在检索
很多人在用 RAG 系统时，第一反应是"模型不够好"。其实反过来——80% 的"答得不准"，问题出在检索，不在生成。
这么说吧：大模型再聪明，如果喂给它的资料就是错的、张冠李戴的、缺头少尾的，输出的答案也不可能对。这就是为什么 WeKnora 在"检索"这一层下了血本。
它给了你6 种检索策略，可以自由组合：
| BM25 稀疏检索 | ||
| 稠密向量检索 | ||
| GraphRAG 图谱检索 | ||
| 父子分块 | ||
| HNSW 加速 | ||
| 多维索引 |
数码类比：
BM25 = 按文件名搜文件（老办法，但稳定） 稠密检索 = 以图搜图（语义层匹配） GraphRAG = 看人物关系网追线索（推理式查找） 父子分块 = 看报纸先看标题、再看正文（保留上下文）
实战建议：别只用一种，至少开两种
叨叨的经验之谈——
对于大多数企业知识库场景，BM25 + 稠密检索 + 父子分块这个组合拳基本能打 90% 的问题。GraphRAG 性能开销大，建议只在"关系推理"重灾区（比如法务、合规、医学）才上。
v0.5.2 之后还加了一个 "自适应 3 层分块" 的能力——系统会自动判断文档该切多细，你还能实时预览分块结果。这功能类似剪映的"智能切片"，新手友好度直接拉满。
二、检索架构长啥样？一张图看懂
光说"几种策略"太空，咱看个全貌：
看到了吗？一条问题进来，可能同时走三条路，最后再融合排序。
这就是为啥 WeKnora 的回答"看起来聪明"——背后是多路召回 + 智能融合的工程化结果，不是单纯靠 LLM 一张嘴硬编。
▲ Agent 模式下的多路检索 + 工具调用流程（来源：官方 docs/images/agent-qa.png）
HNSW 加速到底牛在哪？
v0.6.2 之后，WeKnora 在 pgvector 上默认开了 HNSW（Hierarchical Navigable Small World）索引，专门针对 1024 维向量优化。
数码类比一下：
- 没用 HNSW
- 百万级向量查询，像你在应用商店搜 App，要等 5-10 秒 - 用了 HNSW
- 百万级向量查询，毫秒级返回，快到没感觉
代价是占内存（数码圈叫"功耗换性能"），但对绝大多数企业场景是值得的。
三、20+ 大模型：总有一款你顺手的
现在回答第二个问题："我们公司用豆包，能接吗？"
答案是：能，而且 WeKnora 接了 20+ 家。
直接上表，按"国产 / 海外 / 本地"分类：
| 海外主力 | ||
| 国产主力 | ||
| 聚合平台 | ||
| 本地部署 | ||
| 国产新势力 |
怎么挑？叨叨给个三步决策法：
记住，模型是可换的。WeKnora 整个 LLM 接入层是抽象的，你想用哪家就 .env 改一行的事。
Embedding 模型：容易被忽视的"幕后英雄"
说完 LLM，还有个关键角色——Embedding 模型（负责把文字变成向量的）。
WeKnora 支持的 Embedding 方案：
- Ollama
（本地跑 BGE、GTE 系列） - BGE
（智源开源，中文表现优秀） - GTE
（阿里达摩院，中文 SOTA） - Zhipu Embedding
（v0.6.1 引入） - Gemini Embedding
（v0.6.1 引入） - OpenAI 兼容 API
（覆盖国内大多数厂商）
叨叨建议：中文场景用 BGE-large-zh 或 GTE-Qwen2-7B-instruct，几乎不会错。
四、8+ 向量库：数据量大了怎么换
现在回答一个进阶问题："我们公司有上亿条数据，pgvector 顶得住吗？"
老实讲，pgvector 在百万级以下是无敌的（简单、稳、不用额外维护）。但到了亿级，还是建议上专用向量库。
WeKnora 支持的向量库：
| pgvector（默认） | ||
| Milvus | ||
| Weaviate | ||
| Qdrant | ||
| Tencent VectorDB | ||
| Elasticsearch | ||
| OpenSearch | ||
| Apache Doris |
数码类比：
pgvector = 128GB 手机（够用、好维护） Milvus = 专业相机存储卡（量大、贵、专业） Qdrant = PCIe 4.0 固态（性能怪兽） Doris = NAS + 监控大盘（分析 + 存储二合一）
v0.6.3 还加了一个 "知识库检索扇出"（KB retrieval fan-out）的能力——可以同时查多个向量库再合并结果，跨库联邦检索直接拉满。
五、7+ 对象存储 + 7+ IM 渠道：别让"周边"拖后腿
最后回答第三个问题："我们用钉钉，咋办？"
WeKnora 在 IM 渠道这一块，简直是"友商天花板"。7+ 家国内外 IM 渠道全支持：
| 企业微信 | ||
| 飞书 | ||
| 钉钉 | ||
| Slack | ||
| Telegram | ||
| Mattermost | ||
| 微信 |
看到没？你公司用啥，它就接啥。
而且 IM 集成的细节做得相当到位：
- 斜杠命令
（v0.3.5）：在 IM 里直接 `/ask 问题` 即可 - 问答队列
（v0.3.5）：高峰期排队不丢消息 - 引用回复
（v0.3.6）：在群里 @ 机器人回复具体某条消息，上下文不丢 - 基于线程的会话
（v0.3.6）：多人协作不串台
这体验，叨叨直呼"用过回不去"。
对象存储：上传大文件不卡死
7+ 对象存储也是大差不差全支持：
默认走本地存储就行，如果你们公司本来就在用某家云的对象存储，对接起来 10 分钟搞定。
六、网络搜索：6 家随便切，Agent 自己挑
最后一个容易忽视的组件——网络搜索 Provider。
在 ReAct Agent 模式下，Agent 会自动判断"这个问题要不要上网搜"。WeKnora 支持 6 家搜索源：
DuckDuckGo（默认） Bing Google Tavily（专为 AI 优化） 百度 SearXNG（自建元搜索，隐私首选）
叨叨建议：
- 国内项目
- 百度为主、Tavily 兜底 - 海外项目
- Tavily 优先（专为 Agent 设计，结构化结果） - 私有化部署
- SearXNG（不依赖任何外部 API）
▲ 模型、检索、搜索源都能在设置界面里换（来源：官方 docs/images/settings.png）
小结：这一章我们聊了啥
来，回顾一下：
- 检索是 RAG 系统的"地基"
- 6 种策略可组合，BM25 + 稠密 + 父子分块能打 90% 场景 - 20+ LLM 随便换
- 海外 / 国产 / 聚合 / 本地四类全覆盖，挑模型用"三步决策法" - 8+ 向量库按规模选
- 百万级用 pgvector，亿级上 Milvus / Weaviate / Qdrant - 7+ IM 渠道原生支持
- 钉钉、企微、飞书、Slack、Telegram、微信……你公司用啥就接啥 - 7+ 对象存储 + 6 种网络搜索
- 周边组件也支持得很到位
一句话总结这一章的核心：WeKnora 是个"乐高积木"——每个零件都能拆下来换。这才是它敢喊"企业级"的真正底气。
