项目背景
年初，随着人工智能技术的迅猛发展，企业对于智能化应用的需求日益增长。基于现有的地下市政系统 WEB 需求，我们决定在此基础上进行技术升级，尝试在手机钉钉终端开发一款地下市政智能助手。该项目历时半年，作为技术负责人主导了从需求分析到最终上线的全过程，期间积累了大量关于大模型落地应用的实践经验与教训。
团队配置
为确保项目高效推进，团队采用了精简高效的配置模式：
- 项目经理（1 名）：主要负责移动端需求梳理、交互设计以及跨部门进度协调。
- 后端开发（1 名）：负责在钉钉平台实现后端业务逻辑及 API 对接。
- 数据生产与测试（2 名）：专注于样本数据的清洗、标注以及功能测试用例的编写。
- 算法工程师（2 名）：核心角色，负责利用大模型接口实现意图识别、SQL 生成等关键目标。
需求分析
在启动大模型项目前，必须明确需求的必要性与边界，避免盲目跟风。
1. 必要性评估
并非所有场景都适合引入大模型。需充分论证是否真的需要智能终端助手，确保是为了解决实际问题而非为了'智能'而'智能'。只有当传统规则引擎无法满足灵活查询或理解需求时，才考虑引入大模型方案。
2. 思维模式转变
与传统 WEB 开发不同，智能助手的需求边界更为模糊。传统开发只需按固定流程展示功能，而智能助手需处理灵活、抽象的用户提问。例如，用户可能询问'某些数据的分布概况'，这需要系统具备语义理解能力，而非简单的关键词匹配。
3. 交互方式设计
由于大模型内容输出形式相对单一且生成速度较慢，交互设计至关重要。需明确 UI 如何呈现流式输出、如何处理加载状态以及如何引导用户修正问题，以提升用户体验。
4. 应用场景界定
需明确谁在用、何时用、怎么用。例如，一线巡检人员可能在现场通过语音快速查询管线信息，而管理人员可能在办公室进行复杂的数据统计。特殊需求如离线环境支持、数据安全合规等也需在早期确认。
5. 可行性验证
在需求评审阶段，必须评估甲方对大模型理念的接受度、部署环境的兼容性以及数据安全性。任何一项未达标都可能导致项目不可行。
数据准备与优化
一切以生成准确的 SQL 为目标，数据层面的优化直接决定了系统的表现。
1. Schema 精简
根据实际业务需求，剔除长期未被使用的冗余表字段。这不仅能减少 Prompt 的长度，降低 Token 消耗，还能提升大模型的推理速度和准确率。
2. 数据预处理
数据库中应统一单位（如长度、面积），方便后期编写 SQL 更加简洁。同时，对字段定义进行标准化，增强区分度，便于大模型准确理解。例如，将'地铁区间'和'地铁站'的字段定义做明显区分，避免混淆。
3. 性能优化
针对单表大规模数据，需提前建立索引或采用分库分表策略，提升 SQL 查询或统计速度。此外，表之间的关联关系要清晰，避免多表 Join 时的歧义。
4. 信息同步
在前期制作样本的过程中，需求可能会反复变动。必须确保需求变更信息与数据团队实时同步，否则样本质量将无法保证，直接影响模型训练效果。
技术解决方案
1. 问题感知（Intent Recognition）
由于涉及多轮对话，上下文理解是基础。这一步通常由大模型完成，用于判断用户当前问题的意图，并维护对话状态。我们使用了通义千问接口进行意图识别。
2. 问题路由（Routing）
不同的问题需要调用不同的工具或模块。由于工具数量众多，无法全部塞入 Prompt，因此需要设计路由策略。通过分类模型或大模型自身的能力，将问题分发到最合适的处理链路，平衡速度与准确率。
3. 文本转 SQL（Text-to-SQL）
本项目结合了两种技术路线：
- Txt2Api：稳定性较好，适用于大部分标准查询需求。
- Txt2Sql：灵活性高，能解决复杂类需求，但稳定性相对较差。
