WeKnora：有据问答、限定记忆与可维护运维
WeKnora 性能与成本：分开记录入库、问答和记忆维护
设计模型调用、队列、语义召回和向量回填测量，避免把源码常量误写成整机性能保证。
你将学会
- 不同阶段消耗不同资源
- 语义召回增加覆盖，也增加依赖
- 补向量与同步向量列是不同成本
开始前需要
- 了解 HTTP 与容器基本概念
- 理解文档段落和模型提供方的区别
分清入库、检索、答案支持和记忆范围，并设计基于证据的验收练习。
先看结论
- 入库、问答和维护应分别记账。
- 向量调用超时不是端到端延迟保证。
- 生成缺失向量与同步已有向量列不同。
不同阶段消耗不同资源
入库可能包含解析、分块、向量化和可选增强；问答可能包含改写、检索、重排和生成。智能体工具、Wiki 维护和个人记忆抽取还会增加其他工作。把这些过程压缩成一个响应时间，无法说明成本真正发生在哪里。
使用固定虚构语料，重复运行直接、改写和无答案问题。分别记录解析完成、召回支持、首个有用回答、完整结束和实际提供商用量。本系列没有测量请求延迟、单次问答费用或吞吐量，因此不会给出虚构的节省比例。
语义召回增加覆盖，也增加依赖
向量服务为查询侧向量调用设置两秒超时，语义匹配不可用时退回词法。它是一个依赖调用的源码级时限，而非完整回答一定两秒返回的保证；队列、其他检索阶段和生成仍可能花费额外时间。
个人记忆配置独立指定向量模型，而不会悄悄选择某个知识库的模型。模型身份和维度必须与存储向量一致。排查漏召回时，应记录排名模式、跳过原因和池外命中数量，不能认为勾选语义开关就代表全部历史记录已经可搜索。
补向量与同步向量列是不同成本
源码把缺失向量的单次维护回填限制为两百条，该路径调用模型，向量生成失败时会停止本轮。把已有向量搬入可检索列属于另一种同步，单轮上限两千条，不需要再次调用模型；两种积压必须分开看。
数据库排序可以减少把每条存储向量传给应用的开销，回退路径则在限定范围内传输并评分。但架构差异不等于已测得某个百分比加速。比较配置时同时关注积压年龄与相关性，遗漏关键记忆的更快响应并不是等价结果。
如何选择
| 比较维度 | 方案 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,
"缺失向量": null,
"向量列积压": null,
"已执行基准": false
}常见问题
两秒常量限制整个回答吗？
不是，只限制查询侧的向量生成调用。
同步已有向量还要重新生成吗？
所读同步路径直接移动已有向量数据，不发起新的模型调用。
资料来源
- WeKnora / README.md来源核查 2026-09-14
- WeKnora / internal/application/service/memory/vector.go来源核查 2026-09-14
- WeKnora / internal/application/repository/memory_vector.go来源核查 2026-09-14
- WeKnora / website-docs/03-features/23-memory.md来源核查 2026-09-14