· 全部指南
分块大小的黄金法则
文本分块是 RAG 系统的第一道关卡。过大的分块会导致信息稀释，过小则破坏语义连贯。实践中，技术文档适合 256-512 tokens 的中等分块，而法律文本需要 1024+ tokens 的大分块保持条款完整性。使用 Towalles 的 rag-chunk-analyzer 可在浏览器本地测试不同分块效果，无需上传敏感数据。
混合分块策略往往更有效：先按段落分块，再对复杂段落进行二级分块。例如 API 文档可将方法说明作为主分块，参数详情作为子分块。记住最终目标——让每个分块成为能独立回答问题的语义单元。
嵌入维度的隐藏成本
768 维嵌入不是万能解。高维度虽能捕获细微语义差异，但会显著增加计算开销。使用 embedding-size-calculator 比较不同模型：384 维的 all-MiniLM-L6 在多数场景下性能接近 768 维模型，但存储需求降低 50%。隐私敏感场景建议在浏览器本地计算嵌入。
维度选择应考虑检索规模。千万级文档可能需要 1024+ 维保持区分度，而十万级文档用 384 维即可。实验表明，当维度超过数据复杂度所需时，准确率提升会趋于平缓，但延迟持续增长。
上下文预算的动态分配
LLM 的上下文窗口是稀缺资源。context-budget-planner 可模拟不同分配方案：保留 20% 给系统指令，50% 给检索结果，30% 给生成输出是个好的起点。实时调整比例能显著改善响应质量——当检索结果置信度高时，可压缩指令占比。
长上下文不等于高质量。将 8K token 窗口全部分给检索内容可能导致关键信息被淹没。实验显示，3-5 个精确定位的中等分块（总计 1.5K-2K tokens）通常优于 10+ 个大分块。这也减少了嵌入计算的开销。
端到端优化检查清单
启动 RAG 管线前：1) 用领域文本测试至少 3 种分块方案 2) 选择与数据规模匹配的最小有效嵌入维度 3) 设置上下文预算的动态调整规则。所有测试都可在 Towalles 工具链中本地完成，避免数据外泄风险。
持续监控三个关键指标：检索命中率、LLM 响应相关性和端到端延迟。当业务数据分布变化时，需要重新评估分块策略。记住：优化的 RAG 系统是动态平衡的艺术，不是静态参数的集合。
切片是产品决策
切片大小与重叠会改变召回、延迟与成本。换嵌入模型前，先用固定问题集测量。重叠有助于边界问题，但会倍增 token。
元数据很重要
每个切片保存来源 URL、updated_at 与 ACL 标签。没有授权元数据的检索会造成看起来像「聪明回答」的数据泄漏。
评估
跟踪 hit@k、有据性抽查与单次回答成本。语料刷新后质量下降时，先 diff 切片统计，再责怪 LLM。
安全
嵌入前脱敏密钥。向量库可能以意外方式记住敏感字符串——按敏感存储对待。
RAG 运维清单
动生产前先写操作程序：输入、期望输出、负责人与回滚。Towalles 上的工具便于本地检查样例，不能替代变更控制。
前置条件
- 有代表失败案例的脱敏 fixture。
- 清楚谁是真相来源（应用、网关、CMS 或网络设备）。
- 能在非生产环境或用合成数据复现问题。
步骤
- 用 fixture 复现，记录精确命令或 UI 路径。
- 按需用格式化、哈希或解析工具与已知正确样例对照。
- 做最小修复；同一变更里避免顺手重构。
- 补充回归测试或清单项，避免下一任 on-call 重复踩坑。
- 更新 runbook：症状 → 检查 → 修复。
善后
观察 24–72 小时错误率与支持工单。若做过一次性数据修复，安排后续防止复发。工单里保留截图与哈希，不要留真实密钥。
反模式
- 把生产密钥贴到公开页面「只是看一下」。
- 上线却不写回滚说明。
- 把本地绿色演示当成多区域生产的证明。