默认你已把离线建索引与在线查询拆开。周末常被浪费在几类重复问题上：embedding 时内存暴涨、重启后路径对不上、或悄悄改了 chunk 参数却没有固定评测集导致回归不可见。可结合我们LLM 与 OpenClaw 自动化专题博文里的网关与预拉取思路；需要平台背景时看首页；若要专用远程算力做通宵索引，请直接打开购买页比对节点与配置。
场景
私有代码与工单。 更需要按函数、标题等结构切分，而不是单一 token 窗口。建议结构感知拆分并保留适中 overlap，避免 diff 把可检索单元打得过碎。
PDF 与混合 OCR。 固定字符窗往往更稳；overlap 是表格行被拦腰截断时的保险。召回方差会偏大，应尽早准备评测脚本。
高 QPS、语料静态的问答。 缩短单块正文、收紧 metadata 过滤，把批处理成本压在索引阶段，保证查询延迟平稳。Apple Silicon 上通常中等批量、持续喂满比极小微批更高效。
多语种或强合规语料。 分块策略要与 embedder 使用的同一套 tokenizer 对齐；中英混排时有效 token 数可能相差三成以上。若需按客户删除数据，chunk ID 与持久化布局必须支持定点 tombstone，而不是每次重建整张 HNSW。
数据准备
先规范化空白、去掉重复页眉页脚，并在 embedding 前把源路径 + 字节偏移或页码写进 metadata。Overlap 的 2026 实用起点：散文可先试chunk 长度的 10%–20%；技术文档在 chunk 约 512–1024 token 时，可试固定 64–128 token 的 overlap。答案常跨块边界就加大 overlap；冗余干扰 reranker 则减小。
在句级滑窗（更顺、预处理更慢）与定长字符窗（吞吐可预期）之间二选一或混用：例如 Markdown 走句级，PDF 走定长。务必把预处理器版本号与向量快照一起记录，才能在出问题时 diff 回归而不是靠猜。
把这些旋钮暴露在环境变量里，CI 与远程任务才能逐字复现：
export RAG_CHUNK_SIZE=768
export RAG_CHUNK_OVERLAP=96
export RAG_EMBED_BATCH=24
export RAG_MAX_CHARS_PER_CHUNK=3200最小可审计的 CLI 形态（按你的栈替换模块名即可）：
python -m app.rag_index \
--chunk-size "${RAG_CHUNK_SIZE}" \
--overlap "${RAG_CHUNK_OVERLAP}" \
--embed-batch "${RAG_EMBED_BATCH}" \
--persist-dir "${RAG_VECTOR_DIR}"向量库对比
下表面向本地优先、统一内存约 16–64 GB 的 Mac，给出经验量级。内存峰值会随 batch、向量维度和是否常驻原文而变，请当作数量级参考。
| 形态 | Chunk overlap | Embed batch | 索引阶段内存峰值（量级） | 向量配额 / 上限思路 | 持久化路径（示例） |
|---|---|---|---|---|---|
| 嵌入式 SQLite / 单文件 | 偏低（5%–12%）→ 行数更少 | 8–16 | 约 2–6 GB + 模型 | 单 DB；用最大行数、PRAGMA 页大小间接封顶 | ~/Library/Application Support/yourapp/rag/sqlite_vec.db |
| Chroma 持久化客户端 | 中等；注意 chunk ID 去重 | 16–32 | 约 4–10 GB + 模型 | 按 collection 分段文件；盯 inode 与磁盘占用 | ~/Library/Application Support/yourapp/chroma |
| LanceDB（列式） | 大语料下较灵活 | 24–48 | 约 6–14 GB + 模型 | 按表分片；大批量 upsert 后做 compaction | ~/Library/Application Support/yourapp/lancedb |
| Qdrant（本机） | 配合 payload 过滤调参 | 32–64 | 约 8–18 GB（含守护进程） | 配置里限制 collection 规模 / 磁盘水位 | Docker volume 或 /usr/local/var/qdrant |
配额纪律：同时限制文档条数与落盘字节；破坏性重建前先快照持久化目录。macOS 上建议数据根落在 ~/Library/Application Support 或独立 APFS 卷，便于 Time Machine 与远程 rsync 单根同步。
export RAG_VECTOR_DIR="$HOME/Library/Application Support/yourapp/vectors"
export CHROMA_TELEMETRY_DISABLED=1
export OMP_NUM_THREADS=8评测与回归
冻结一份黄金问题集（30–100 条）并带期望引用片段。每次改分块或换 embedding，都复跑：Hit@k、若有标注可算 MRR，以及同机型上的p95 延迟。评测产物里记下 tokenizer 哈希、模型 revision、chunk 参数。
远程长跑索引任务验收清单（租用 Mac 或 CI Agent）：
- 起飞前：磁盘配额 ≥ 2×（语料 + 向量估算）；日志里留存
df -h与ulimit -n。 - 确定性：锁文件版本固定；embedding 权重校验通过；若栈内有随机采样则固定
RAG_SEED。 - 可恢复：chunk ID 幂等；崩溃后在
RAG_VECTOR_DIR下写 checkpoint。 - 可观测：墙钟时间、每秒插入行数、峰值 RSS（macOS 可用
/usr/bin/time -l或采样分析）。 - 放行条件：指标相对基线在约定阈值内；人工抽查 5 条对抗问；
RAG_VECTOR_DIR打 tarball 并附 manifest SHA-256。
最后一步可与自动化专题里「依赖同步应像镜像一样无聊」同一套工程习惯：索引管线也要可重复、可审计。
FAQ
embedding batch 越大越快吗？ 超过统一内存舒适区触发 swap 后反而变慢。建议在 {8,16,24,32,48} 上扫一遍，选吞吐增益开始变平的拐点。
一个向量库通吃？ 至少拆 dev/prod collection；多租户 SaaS 建议每租户独立持久化根目录，配额与备份更简单。
多久全量重建？ 换 embedding 模型必重建；仅改分块策略要先证明评测净收益再推广。metadata 能映射 chunk→源时，优先增量或局部重建。
要强制 Metal / Core ML 吗？ 若运行时支持，可在上百条探针向量上验证数值一致或误差可接受后再开；仅测速不验数值，CPU/GPU 路径漂移曾坑过不少团队。
ANN 参数呢？ 把 ef_construct、M 等视作与 chunk、batch 同一矩阵：拉高通常增加构建期内存与磁盘，过低则伤召回。验收清单里与分块、batch 一并快照。
小结：chunk overlap、embedding batch、内存峰值与持久化路径是联动旋钮。写进环境变量、在远程任务上设验收门槛，并在上线前做回归，才能把本地 RAG 从「能跑」推到「敢上生产」。