针对代码生成任务，给出在有限算力下的高效检索设计建议。
Practical Code RAG at Scale: Task-Aware Retrieval Design Choices under Compute Budgets
- 根据任务类型选择检索策略：纯代码任务用词级分块的BM25，自然语言转代码用稠密编码器。
- 小预算下32-64行分块最佳，大上下文窗口时整文件检索更优，延迟差异可达200倍。
- 词级分块比基于BPE的分块快得多，且性能不降，适合资源受限场景。
我们在真实算力预算下研究面向代码生成任务的检索设计。基于Long Code Arena中的代码补全与缺陷定位两个任务，系统比较了不同上下文窗口大小下三种配置：(i) 分块策略，(ii) 相似度评分方式，(iii) 切分粒度。结果表明：(1) 对于PL-PL任务，词级分块的稀疏BM25显著优于稠密方法，速度高出一个数量级；(2) 对于NL-PL任务，专用稠密编码器（Voyager-3系列）表现更优，但延迟高100倍；(3) 最优分块大小随可用上下文变化：小预算下32-64行分块最佳，16000词符上下文时整文件检索具竞争力；(4) 简单行级分块在各预算下性能接近语法感知分块；(5) 不同配置间延迟差异达200倍，基于BPE的分块效率极低。因此，我们基于任务需求、模型约束和计算效率，提出可落地的代码相关RAG系统设计建议。
原文摘要 · Abstract (English)
We study retrieval design for code-focused generation tasks under realistic compute budgets. Using two complementary tasks from Long Code Arena -- code completion and bug localization -- we systematically compare retrieval configurations across various context window sizes along three axes: (i) chunking strategy, (ii) similarity scoring, and (iii) splitting granularity. (1) For PL-PL, sparse BM25 with word-level splitting is the most effective and practical, significantly outperforming dense alternatives while being an order of magnitude faster. (2) For NL-PL, proprietary dense encoders (Voyager-3 family) consistently beat sparse retrievers, however requiring 100x larger latency. (3) Optimal chunk size scales with available context: 32-64 line chunks work best at small budgets, and whole-file retrieval becomes competitive at 16000 tokens. (4) Simple line-based chunking matches syntax-aware splitting across budgets. (5) Retrieval latency varies by up to 200x across configurations; BPE-based splitting is needlessly slow, and BM25 + word splitting offers the best quality-latency trade-off. Thus, we provide evidence-based recommendations for implementing effective code-oriented RAG systems based on task requirements, model constraints, and computational efficiency.
Thank you to arXiv for use of its open access interoperability. PaperDance 不是 arXiv 官方产品；中文卡片由大模型生成，请以原文为准。