常见建议FAQ / 客服问答300-800 tokens政策文档 / 操作手册500-1200 tokens技术文档800-1500 tokens法律合同 / 长报告1000-2000 tokens代码按函数、类、模块切不只按 token比如你的知识库是客服/政策类比较推荐chunk-size: 800chunk-overlap: 120top-k: 4Embedding 最大 token 和 Chunk Size 的关系Embedding 最大 token决定 chunk 不能超过多少Chunk Size决定检索颗粒度Overlap避免切断上下文TopK决定召回多少段上下文LLM 上下文窗口决定最终能塞多少 chunk 给模型完整关系如下文档- 按 chunk-size 切块- 每个 chunk 必须小于 embedding max token- 每个 chunk 生成 embedding- 问题生成 embedding- 检索 TopK chunk- TopK chunk 总长度必须小于 LLM 上下文窗口- LLM 生成答案例如Embedding 模型最大输入8192 tokensLLM 上下文窗口128k tokenschunk-size800 tokenstopK4最终进入 LLM 的上下文大约800 * 4 3200 tokens 比较健康如果设置chunk-size6000topK10那就是6000 * 10 60000 tokens虽然没超过 128k但检索颗粒度很粗噪声非常大引用也不精准。总结max token 是边界chunk size 是调优参数overlap 是保险topK 是召回量LLM context 是最终容量建议chunk size * topK 占 LLM context 的 5% - 20% 比较合适一般是10%因为LLM context 里不只放 RAG chunk还要放system prompt用户问题历史对话工具调用说明引用格式要求安全约束模型输出预留 tokens实用公式RAG上下文预算 LLM context * 10%topK RAG上下文预算 / chunk size不仅要看公式还要看评估指标RecallK正确文档有没有进来引用准确率source 是否准确答案准确率回答是否正确噪声率无关 chunk 是否太多延迟和成本上下文越大越贵越慢