#RAG

rss · ByteByteGo · 10月19日 15:31 「背景」 Uber 内部平台团队每月在 Slack 支持频道收到约 4.5 万个问题，答案却散落在 Engwiki、内部 Stack Overflow 等文档里，重复问答持续消耗工程师时间。 「方案」 Genie 选择检索增强生成（RAG）而非微调：可直接利用现有文档，文档更新也无需重训模型，但仍需大量收集、整理和评估知识。离线侧用 Spark ETL 抽取内容，经 LangChain 分块、OpenAI 嵌入模型生成向量，再由 Sia 向量库和 Terrablob 索引供 serving leaves 检索；在线侧 Slack 问题进入 Knowledge Service，检索片段后把每个片段连同来源 URL 作为子上下文交给 LLM，要求依据材料作答并附引用，从而把检索失败与生成失败分开排查。回答还提供追问、标记解决和转人工按钮；信息不足时转给平台 on-call，人工接管后 Genie 静音。用户反馈分为 Resolved、Helpful、Not Helpful、Not Relevant，经 Kafka 汇入 Hive 并形成看板；评估用 LLM-as-judge 检查答案的幻觉与相关性，也评估源文档质量并给出改进建议。Uber 报告 Genie 于 2023 年 9 月上线，一年内覆盖 154 个 Slack 频道、回答逾 7 万个问题，helpfulness 为 48.9%，节省约 1.3 万工程小时。 「启示」 Genie 的意义不在单个模型，而在于把知识摄取、来源引用、人工兜底和反馈评估连成可运营的支持闭环；把检索与生成分开评估，并将源文档质量纳入闭环，是更可迁移的经验。 标签: RAG, LLM evaluation, internal support, knowledge retrieval, production architecture

rss · ByteByteGo · 10月17日 15:30 「背景」 RAG 智能体要先把文档切成可检索的片段，边界如何确定会直接影响检索质量、上下文完整性与处理成本。 「方案」 ByteByteGo 的这篇短文并列梳理了八种思路：固定大小按 token 切分并保留少量重叠；递归法先从段落切，过大再退到行、词和字符；文档型利用标题、章节或 HTML 标签等原有结构；语义法比较相邻句向量，在相似度骤降处开新块。其余四种中，LLM 型让模型把文本改写成独立命题，质量高但大语料成本昂贵；智能体型由代理判断文件类型（代码、合同、表格）后逐文件选择方法；晚分块先让整篇文档经过嵌入模型，再按常规边界切分并在边界内做均值池化；分层法则按章节、段落、句子组织成层级。文章基本停留在概念说明，没有实现细节、基准或系统性的权衡比较。原文附带的读者评论进一步指出，晚分块受嵌入模型上下文窗口约束（原论文使用的 jina-embeddings-v2 为 8K token），超长文档仍要先切宏块，因此只是把边界选择推到更粗粒度；它能让“其营收增长 3%”保留全文中的指代，但智能体分块是否优于“递归切分加重排序器”仍缺少实测。 「启示」 从这篇概览可见，分块没有单一最优解，实际系统要在结构保真、语义连贯、窗口限制和成本之间折中。在缺乏对照评测时，更复杂的分块未必胜过简单的递归切分配合重排序器。 标签: RAG, chunking strategies, late chunking, retrieval-augmented generation, newsletter roundup