评估项目一览表（详细请看附件PDF）

属灵书籍 AI 知识库 RAG 系统 · v2.4

一、已纳入 v2.4 的项目（基准线，无需决策）

项目	用处	收益	人力	费用
BM25 中文检索	★★★★★ 核心，不可或缺	精确命中经节、人名、专有术语	已完成	$0
Dense 语义检索（Jina-v5）	★★★★★ 核心，不可或缺	跨段落深层语义理解，覆盖BM25盲区	已完成	按查询计费，少量使用 ~$5–15/月
Reranker（Jina-reranker-v3）	★★★★★ 防幻觉最后防线	三路统一评分，拦截低质召回	已完成	按查询计费，少量使用 ~$3–10/月
Top-1 Margin δ 判定	★★★★☆ 高	防止证据模糊时被迫作答，减少幻觉	已完成（v2.4新增）	$0
三态输出 + 多段落一致性声明	★★★★☆ 高	强制区分「能答/部分能答/不能答」，防止系统神学式整合	已完成（v2.4新增）	$0
IK 分词 + 神学自定义词典	★★★★☆ 高	防止「称义」被拆成「称+义」，保证BM25术语完整性	已完成	$0

二、Sparse 路方案（待决策，需评测集数据支撑）

Sparse 路整体质量增益预估 +3–12%，但仅作用于约 10–35% 的查询场景。建议在评测集建立后，以实测 False Negative 数据决策是否值得投入。

方案	用处	收益	人力	费用
方案 A：Elastic Cloud ELSER	★★☆☆☆ 有限（仅英文字段有效，中文无贡献）	+3–8% 召回覆盖（英文术语扩展场景）	低，1–2天配置	$95–250/月，持续支出，有厂商锁定风险
方案 B：本地 Platinum ELSER	★★☆☆☆ 有限，同方案A	+3–8%，与方案A相同	中，需管理自托管ES	授权费不透明，数千美元/年起，不推荐
方案 C：Hetzner CX52 + BGE-M3 ONNX（CPU）	★★★☆☆ 中等（中英双语，优于ELSER）	+5–12% 召回覆盖，中英文均受益	高，3–5天工程投入	€32.40/月（服务器）+ API ~€15–25/月，合计 €50–80/月

三、质量优化项（性价比由高到低）

项目	用处	收益	人力	费用
Semantic Anchor（语义锚点）	★★★★☆ 高，性价比最优	Reranker 精排质量 +2–5%，对代词多、段落孤立的《生命读经》尤其有效	低，0.5–1天	一次性 $3–12（Claude API 批量生成），之后 $0
Concept Diff Check（神学漂移拦截）	★★★★☆ 防御性价值高	阻止 Query Rewrite 偷偷引入未提及的神学概念，保护系统权威性	低，工程 0.5天 + 神学禁止词表整理 1–2天	$0
Recall Contract（召回责任制）	★★★☆☆ 中，调优工具	不直接提升质量，但建立可观测性：能定位「是哪路出了问题」	中，3–5天	$0（纯代码逻辑）
Doctrinal Drift Rate 指标	★★★☆☆ 中，监测工具	量化幻觉中「教义跑偏」的比例，比 False Positive 更精细	持续人工抽查，2–4小时/批次	$0，但需要有神学判断力的标注者

四、基础设施项（前置条件）

项目	用处	收益	人力	费用
评测集建立（100–200条）	★★★★★ 所有后续决策的依据	没有它，所有阈值和优化方向都是猜测	高，5–10天标注工作	$0 直接成本，人工时间为主要投入
ONNX O2 量化优化（BGE-M3）	★★★★★ 若选方案C则必做	CPU 推理从 3–8s 压到 0.8–2s，性能提升 3–4倍，免费	低，0.5天（或直接用 Hugging Face 预转换权重）	$0

总结

现在已经是一套架构扎实的系统，BM25 + Dense + Reranker 三件套已经覆盖绝大多数使用场景，v2.4 的 Margin 判定和一致性约束也把幻觉风险压到了合理水平。当前最值得花时间的两件事，一是建评测集——没有数据就没有决策依据；二是做 Semantic Anchor + Concept Diff，加起来不超过两天工时、成本几乎为零，却能把 Reranker 精排质量和系统可信度都往上推一截。Sparse 路不是不好，而是在数据证明它有贡献之前，没必要为它每月多付 €50–250。先把便宜的事做完，再用数字说话。

On Fri, Mar 6, 2026 at 11:50 AM Samuel Liu <chenshiliu@gmail.com> wrote:

好的，有需要费用的，也可以。没问题，

作出好品质的答案是第一优先，

On Fri, Mar 6, 2026 at 11:44 AM Stephen Su <yestephensu@gmail.com> wrote:

v2.3 修改意见最终审核

必须修改（不改会出问题）

1. 砍掉 Sparse 路，改为两路 BM25 + Dense

这不是”修改意见”，是评估对话里已经确认的现实：ELSER 昂贵、BGE-M3 API 残缺、A1 CPU 跑 sparse 查询太慢。v2.3 文档还写着三路，但实际上三路已经不可行了。文档要更新，否则会误导自己后续开发。

2. Top-1 Margin δ 纳入决策逻辑

v2.3 已经把 Margin 列为评测指标，但没用到决策里。这个补丁逻辑极简（一行 if），成本为零，但直接解决”两段落分数相近时被迫回答”的幻觉漏洞。这是真实的缺陷，修复代价极低。

可以考虑（性价比合理，但不急）

3. 语义去重分桶优化（O(n²) → 分桶）

当前 Top-20 的量级下完全不是问题，但如果以后扩展到 Top-50 再改也来得及。实现也简单，按 message_id 分桶就行。不急，等真的感到慢了再加。

4. Concept Diff Check（Rewrite 反漂移）

有价值，但实现成本不低——需要维护一个 forbidden_concepts 列表，且这个列表本身就需要神学判断来维护。个人项目里 Prompt 硬约束已经够用，这个是”锦上添花”。等系统跑起来、发现真实漂移问题了再加。

忽略（负优化或过度工程）

5. Recall Contract Monitor（三路召回责任制）

思路很好，但对个人项目是纯开销：需要维护命名实体列表、神学术语表、写日志监控逻辑，换来的是一个诊断工具而非功能提升。两路架构下 BM25 和 Dense 各自的问题直接从结果质量就能感知到，不需要专门的监控层。忽略。

6. Semantic Anchor 字段（离线 Claude 生成摘要）

要对每个 chunk 额外调用一次 Claude 生成语义锚点，再存一个不可检索字段。成本：入库费用翻倍，维护复杂度上升，但 Reranker 的提升是边际的。忽略。

7. 神学术语密度门控（Sparse 术语密度过滤）

Sparse 路已经砍掉了，这条优化的前提不存在。自动忽略。

8. Doctrinal Drift Rate 评测指标

这是博士答辩级别的指标，需要人工标注”哪些神学概念属于漂移”，维护成本极高。个人项目用 False Positive 指标就够了，FP 里本来就包含了神学漂移的情况。忽略。