WeKnora：有据问答、限定记忆与可维护运维
WeKnora RAG 架构：事件插件、中间状态与可恢复输出
沿问答插件管线理解检索、重排、上下文与 SSE，避免混淆阶段完成、内容送达和答案正确。
你将学会
- 请求特征决定管线如何组装
- 保留中间结果，才能定位问题
- 流式输出负责交付，不负责证明事实
开始前需要
- 了解 HTTP 与容器基本概念
- 理解文档段落和模型提供方的区别
分清入库、检索、答案支持和记忆范围，并设计基于证据的验收练习。
先看结论
- 请求能力决定阶段顺序。
- 检索、重排和合并结果值得分别观察。
- 输出可恢复不等于外部动作恰好执行一次。
请求特征决定管线如何组装
架构文档描述由事件管理器注册插件，并按请求动态组装阶段。没有知识库和联网搜索时可走纯聊天路径；RAG 请求则加入问题理解、并行检索、重排、合并、数量截断和上下文组织，再进入生成。可选能力决定是否插入额外阶段。
同一事件内部，注册顺序决定 next 调用形成的嵌套链。插件可以先处理再调用 next，也可以等待内部执行后再做后处理。因此仅阅读一列插件名称，无法推断全部先后关系；文档对 Wiki 加权与重排的关系给出了具体说明。
保留中间结果，才能定位问题
ChatManage 将请求配置、中间管线状态和运行时句柄分开。SearchResult、RerankResult、MergeResult 分别对应不同检查点，能够帮助区分没有候选、排序不佳、上下文丢失和生成缺乏依据，不能把它们当作最终答案的三个同义副本。
文档说明并行检索会克隆状态，但不复制运行时上下文。这是设计说明，不是本系列已完成并发正确性验证的证明。同样，无检索结果时的兜底可能输出模型文本；即使显示在同一个聊天窗口，也不应被描述为知识库原文支持的回答。
流式输出负责交付，不负责证明事实
结果经过每请求事件总线、流处理器和流管理器，再以 SSE 交付。文档描述内存或 Redis 存储以及断线续传，但多副本部署仍需选择相应的共享流配置。恢复输出不意味着所有外部工具副作用都具备恰好一次执行保证。
取消请求和检索为空需要不同结局。文档将取消检查置于无结果兜底之前，并在回答流开始前发布引用。排查时应分别记录输出进度、来源证据和最终验收。本系列阅读了架构资料，没有运行断线续传或多副本测试。
如何选择
| 比较维度 | 方案 A | 方案 B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
实施步骤
- 1
列出该请求启用的阶段。
- 2
查看各层检索中间结果。
- 3
分别追踪引用与答案事件。
- 4
在受控部署中验证取消和重连。
可复制示例
{
"管线记录": true,
"检索结果": null,
"重排结果": null,
"合并上下文": null,
"交付已恢复": null,
"结论有据": null,
"已测试分布式": false
}常见问题
所有请求都经过完全相同的 RAG 阶段吗？
不是，文档中的构建器根据请求特征动态组装。
SSE 重连成功能说明答案正确吗？
不能，交付连续性与证据质量是不同属性。
资料来源
- WeKnora / website-docs/02-architecture/04-rag-pipeline.md来源核查 2026-09-14
- WeKnora / README.md来源核查 2026-09-14