一、问题背景
当前系统因全量表结构送入大模型导致 Token 超限（31693＞16384），为解决该问题，先后提出两种 Schema 优化方案：
- 仅对数据库表建立向量索引
- 对数据库表 + 表字段建立二级向量索引
经架构分析，二级索引方案存在明显过度设计，现将对比与结论整理如下。
二、方案核心对比
2.1 索引量级对比
| 场景 | 仅表级索引 | 表+字段二级索引 | 增量倍数 |
|---|---|---|---|
| 10 张表 × 20 字段 | 10 条向量 | 210 条向量 | ×21 |
| 50 张表 × 50 字段 | 50 条向量 | 2550 条向量 | ×51 |
| 100 张表 × 50 字段 | 100 条向量 | 5100 条向量 | ×51 |
结论：引入字段级索引后，向量数据量膨胀 10～50 倍，显著增加向量库存储与同步成本。
2.2 匹配复杂度对比
| 维度 | 仅表级索引 | 表+字段二级索引 |
|---|---|---|
| 向量查询次数 | 1 次（问题→表） | 2 次及以上（问题→表→问题→字段） |
| 逻辑复杂度 | 简单直接 | 需关联表与字段、聚合相关性、排序过滤 |
| 系统开销 | 低，单次 Qdrant 查询 | 高，多轮查询 + 内存聚合 |
| 延迟表现 | 稳定可控 | 明显增加，高并发下易抖动 |
结论：二级索引明显提升匹配难度与系统复杂度，且收益与成本不成正比。
2.3 实际业务价值对比
| 场景 | 仅表级索引 | 表+字段二级索引 |
|---|---|---|
| 常规业务问数（销售额、订单量、地区、时间） | 完全满足 | 无明显收益 |
| 宽表（单表＞50 字段） | 可通过规则裁剪优化 | 有一定收益，但实现过重 |
| 大数量表（＞50 张） | 从根源解决 Token 问题 | 同样依赖表筛选，字段索引不解决本表问题 |
| AI 字段选择能力 | 可完全交给大模型自主完成 | 重复实现模型已有能力 |
结论：
- 常规企业场景（单表 20～40 字段）：字段级索引无明显收益
- 仅在极端宽表（＞80～100 字段）+ 精细化字段查询下有有限收益
- 当前系统 Token 超限根源是表数量过多，而非字段过多
三、关键问题判断
- Token 爆炸的真实原因
全库表结构一次性送入，而非单表字段过多。 - 大模型能力边界
只要给出正确的表和精简字段列表，大模型可自主选择所需字段，无需系统提前过滤。 - 过度设计判定
表+字段二级索引提升了工程复杂度、部署成本、维护难度，但对当前核心问题改善有限。
四、推荐优化路线（低成本、高可靠）
在仅表级向量索引基础上，增加轻量优化，即可彻底解决问题：
- 表级向量检索
根据用户问题语义匹配 Top3～5 张相关表，从源头控制表数量。 - 表描述极度精简
不罗列全量字段、外键、类型细节，只保留业务含义。 - 字段规则化裁剪
自动剔除系统字段（update_time、creator、ext_json 等），单表只展示常用字段。 - 保留降级机制
向量库不可用时自动回退到全表查询，保证系统可用性。
五、总结论
- 表+字段二级索引确实加剧索引量与匹配难度，属于针对当前场景的过度设计。
- 仅表级索引方案足够解决 Token 超限问题，结构更简单、性能更稳定、落地更快。
- 大宽表场景优先使用规则裁剪，不依赖字段向量，实现成本更低、效果可预期。
- 建议采用：表级向量索引 + 主题域/规则过滤 + 精简 Schema 作为最终落地方案。