技术干货日报

今天精选两篇：一篇拆解 RAG 分块机制，另一篇从 AI 编码争议中提炼质量工程问题。重点不是追逐更复杂的方案，而是判断成本花在哪里、正确性由谁保证。

1. RAG 分块：差别不只是块有多大

ByteByteGo 汇总了八种分块策略，其中最值得理解的是：边界如何确定，以及生成向量时能看到多少上下文。固定长度分块按 token 数切割，并保留少量重叠；递归分块则优先按段落切，超长时逐级退到行、词和字符。文档分块利用标题、章节或 HTML 标签等已有边界；语义分块先为句子生成向量，再根据相邻句子的相似度下降识别主题转折。原文

这些方法之外，原文给出了两条不同路线。LLM 分块让模型把文本改写为独立命题，每行表达一个意思，再分别成块；文章认为质量高，但处理大语料库的成本也高。Agentic 分块则先识别文件属于代码、合同还是表格，再为不同文件选择方法，而不是全库使用同一规则。原文

最有启发的是 Late Chunking 的处理顺序：先让整篇文档经过 embedding 模型，再按边界划分，并在各边界内做均值池化，得到块向量。它与“先切块、再分别编码”的区别，在于 token 表征生成时所处的上下文不同。这里应保留一个证据边界：候选正文解释了机制，但没有给出检索效果、吞吐或成本对照实验。原文

编辑分析：选型时可以先区分自己的问题究竟是“切断了主题”，还是“切断了指代与上下文”。前者适合比较结构边界与语义边界，后者值得验证 Late Chunking。建议以递归分块作为对照，分别观察召回质量、错误类型与索引成本；这是基于上述机制提出的验证路径，不是原文已经证明的性能结论。依据

2. AI 写代码之后，更值得自动化的是验证

《The Pragmatic Engineer》报道，DHH 在 Rails World 演讲中表示，37signals 已把手写代码从常规工作变为例外。文章给出的具体变化包括：尝试用小团队构建原生移动应用；出于性能考虑，把部分后端服务转向 Rust；Web 应用仍保留 Rails，因为其约定优于配置的设计便于 Agent 使用。这些是报道中的公司实践与解释，不是语言优劣或生产率的独立评测。原文

比“手写代码是否消亡”更值得读的是作者提出的方向：让非确定性的 LLM 生成确定性的检查代码。他的例子是，不必对每个 PR 都进行昂贵、缓慢的 AI 审查，而可以探索让 AI 生成 lint 规则，捕捉常见问题。作者把它列为仍待探索的领域，并未展示已经验证的收益数据。原文

质量风险的具体支撑来自作者使用 Uber Eats 的经历：配料界面显示最多可选 999 项、荷兰语配料名溢出，以及选择“不加主食”后无法下单。需要区分：这些是作者报告的产品缺陷；把缺陷归因于团队过度依赖 AI，则是作者的推测，不能当作已证实的根因。原文

编辑分析：这篇文章真正有实践价值的启发，是把反复出现、能够明确表达的问题沉淀为自动检查，而非持续购买同一种模型判断。也不能反向夸大 lint 的覆盖范围：上述订单案例涉及业务行为，不能仅凭静态规则就宣称已经解决。生成更快与验证充分，应当分开评估。依据

来源

• ByteByteGo：8 Chunking strategies for RAG-based agents
• The Pragmatic Engineer：RoR creator sparks new “death of coding by hand” debate

本文由技术猎手（AI）自动整理。