# YORO混合架构：Text-to-SQL的"只检索一次"智能路由方案

> 一种创新的Text-to-SQL生成架构，通过轻量级路由器将查询智能分配到纯参数化、混合压缩或完整Graph-RAG三种推理路径，实现80%的提示词令牌削减。

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-06-16T23:06:33.000Z
- 最近活动: 2026-06-16T23:20:58.971Z
- 热度: 159.8
- 关键词: Text-to-SQL, 大语言模型, RAG, 令牌优化, 智能路由, 数据库, 微调, 开源项目
- 页面链接: https://www.zingnex.cn/forum/thread/yoro-text-to-sql
- Canonical: https://www.zingnex.cn/forum/thread/yoro-text-to-sql
- Markdown 来源: ingested_event

---

## 原作者与来源

- 原作者/维护者：Dhritimannandi
- 来源平台：github
- 原始标题：yoro-hybrid-architecture
- 原始链接：https://github.com/Dhritimannandi/yoro-hybrid-architecture
- 来源发布时间/更新时间：2026-06-16T23:06:33Z

## 原作者与来源\n\n- **原作者/维护者**: Dhritimannandi\n- **来源平台**: GitHub\n- **原始标题**: yoro-hybrid-architecture\n- **原始链接**: https://github.com/Dhritimannandi/yoro-hybrid-architecture\n- **发布时间**: 2026年6月16日\n\n---\n\n## 项目背景：Text-to-SQL的令牌成本困境\n\n将自然语言问题转换为SQL查询（Text-to-SQL）是数据库交互领域的重要研究方向。传统的解决方案通常采用检索增强生成（RAG）模式：将数据库的完整模式（schema）作为上下文输入大语言模型，让模型据此生成SQL。\n\n这种方法虽然有效，但存在一个明显的效率问题：数据库模式往往包含数十张表、数百个字段，将其全部塞进提示词会消耗大量令牌（tokens）。对于复杂的企业级数据库，模式描述可能占据数千个令牌，不仅增加了API调用成本，还可能挤占留给实际问题和推理过程的上下文空间。\n\nYORO（You Only Retrieve Once）混合架构正是为了解决这一问题而提出的。其核心洞察是：并非所有查询都需要完整的模式信息。通过让模型在训练阶段内化模式知识，许多常见查询在推理时可以实现"零模式令牌"。\n\n---\n\n## 核心创新：三路径智能路由\n\nYORO架构的最大亮点是其轻量级路由器设计。对于每个传入的自然语言问题，系统会将其分配到三条推理路径之一：\n\n### 路径A：YORO纯参数化（YORO Pure）\n\n适用于标准聚合查询和已知模式的问题。在这种模式下，提示词仅包含数据库ID和问题本身，完全不包含任何模式信息，平均仅需约50个令牌。这之所以可行，是因为专家模型在微调阶段已经将数据库模式内化到了参数中。\n\n### 路径B：YORO混合（YORO Hybrid）\n\n适用于涉及多表连接、术语歧义等中等复杂度的问题。系统会从完整模式中提取相关的子集进行压缩，提示词包含数据库ID、问题和压缩后的模式子集，平均消耗约500-800个令牌。\n\n### 路径C：Graph-RAG回退（Graph-RAG Only）\n\n适用于全新或高度复杂的查询，作为兜底方案。提示词包含完整的压缩模式，平均约3900个令牌，与传统方法相当。\n\n---\n\n## 路由器实现：无需LLM的复杂度评分\n\n路由器的实现非常巧妙：它不依赖额外的LLM调用（那样会增加延迟和成本），而是使用基于关键词的复杂度评分算法，在约1毫秒内完成决策。\n\n评分系统会分析问题的多个特征：\n\n**增加复杂度的信号**：\n- 涉及地理位置的连接查询\n- 统计分析类问题\n- 数据协调、透视表需求\n- 窗口函数分区\n- 问题长度超过120个字符\n\n**降低复杂度的信号**：\n- 简单的TOP-N查询\n- 单一聚合操作\n- 时间范围过滤\n- 使用常见业务词汇（支付、评价、配送等）\n\n根据计算出的复杂度分数，系统应用简单的阈值规则：低于0.55走路径A，低于0.80走路径B，否则走路径C。\n\n---\n\n## 架构组件详解\n\n项目包含五个核心模块，形成完整的处理流水线：\n\n### 1. 模式分析器（Schema Profiler）\n\n读取数据知识层（DKL）Excel文件，生成三种模式表示：\n- CodeS格式：完整的类型和样本值（用于离线数据生成）\n- PICARD格式：简化的表:列列表（用于混合路径）\n- YORO提示：仅数据库ID+问题（用于纯参数化路径）\n\n### 2. 合成数据生成器\n\n实现三阶段合成流程：\n- 骨架提取：剥离表名列名，生成可复用的SQL模板\n- SQL生成：用真实模式值填充模板\n- NLQ生成：将SQL转换回自然语言问题\n\n### 3. 微调格式化器\n\n支持两种训练数据格式：\n- OpenAI兼容格式：用于Azure OpenAI微调\n- HuggingFace/PEFT格式：用于Mistral-7B + LoRA\n\n通过`hybrid_ratio`参数控制训练数据中包含压缩模式上下文的比例，让专家模型同时学习纯YORO和混合格式。\n\n### 4. 混合推理路由器\n\n核心创新模块，实现前述的复杂度评分和路径选择逻辑。\n\n### 5. 流水线编排器\n\n提供统一的CLI接口，支持三种模式：\n- setup：生成合成训练数据\n- benchmark：运行44问题路由基准测试\n- generate：处理单个问题\n\n---\n\n## 基准测试结果\n\n项目在Olist巴西电商数据集上进行了44个问题的基准测试，结果令人印象深刻：\n\n| 路径 | 问题数 | 占比 | 平均令牌数 | 相比基线削减 |\n|------|--------|------|------------|--------------|\n| A - YORO Pure | 26 | 60% | 50 | -98.7% |\n| B - YORO Hybrid | 11 | 25% | ~700 | -82% |\n| C - Graph-RAG | 7 | 15% | ~3900 | 0% |\n| **加权混合** | **44** | **100%** | **~560** | **-85.6%** |\n\n总体而言，混合路由策略实现了约80%的提示词令牌削减，同时保持了SQL准确性。这意味着在保持相同查询质量的前提下，可以显著降低API调用成本，或释放更多上下文空间用于复杂推理。\n\n---\n\n## 技术启示与应用前景\n\nYORO架构的意义不仅限于Text-to-SQL领域。它展示了一种通用的效率优化思路：通过问题复杂度分析进行自适应资源分配。\n\n这种模式可以推广到其他AI应用场景：\n- 文档问答：简单问题用轻量级模型，复杂问题调用大模型\n- 代码生成：常见模式用缓存模板， novel 需求用完整生成\n- 多模态处理：根据输入特征选择不同的处理管道\n\n关键在于找到合适的"复杂度代理指标"——不需要完美的预测，只需要足够好的启发式规则，就能在大部分情况下做出正确的资源分配决策。\n\n---\n\n## 局限性与注意事项\n\n尽管YORO架构很有前景，但用户应当了解其局限性：\n\n首先，专家模型的微调需要领域特定的训练数据，这意味着迁移到新数据库时需要重新进行数据合成和模型微调。\n\n其次，复杂度评分器基于启发式规则，对于训练数据中未覆盖的查询类型可能做出错误的路由决策。虽然路径C作为兜底方案可以降低风险，但仍需监控和迭代优化评分规则。\n\n最后，当前实现主要针对特定数据集（Olist电商数据），在更复杂的企业级数据库（数百表、复杂关系）上的表现还需要进一步验证。\n\n---\n\n## 结语\n\nYORO混合架构为Text-to-SQL领域带来了一个重要的效率优化思路：与其对所有查询一视同仁地投入计算资源，不如通过智能路由实现差异化处理。这种"按需分配"的哲学不仅适用于数据库查询，也为更广泛的AI系统设计提供了启发。在计算成本日益成为关注焦点的今天，这类注重效率的架构创新将变得越来越重要。