从“聊天”到“办事”：我用DeepSeek的FunctionCall，给内部系统加了个智能航班查询助手

从“聊天”到“办事”我用DeepSeek的FunctionCall给内部系统加了个智能航班查询助手能不能帮我查下明天上海飞北京的航班——这是公司行政小张第17次跑来问我。作为技术负责人我意识到单纯靠人工处理这类高频重复请求不仅低效还严重消耗团队精力。于是一个大胆的想法诞生了能否让AI助手直接从聊天窗口对接公司内部航班系统实现自助查询1. 需求起源当聊天机器人遇到业务痛点公司内部使用的航班管理系统原本就有完善的API接口但普通员工需要登录特定平台、填写复杂表单才能完成查询。我们曾尝试用传统聊天机器人解决这个问题但效果始终不理想关键词匹配的局限性早期基于规则的机器人只能识别固定句式比如查询航班出发地目的地一旦用户说帮我看看去上海的飞机系统就直接卡壳参数提取的模糊性当用户输入下周二上午的航班传统NLP模型很难准确解析出2024-03-05 08:00-12:00这样的结构化数据业务逻辑的复杂性实际查询涉及多级联动如先查航班号再查余票而聊天机器人只能做单轮交互典型问题场景举例用户输入: 我想订下周从深圳到成都的机票 传统机器人回复: 请输入精确日期YYYY-MM-DD、出发城市和到达城市这正是FunctionCall技术大显身手的场景——让大模型理解自然语言的同时还能精准触发后端业务系统。2. 技术选型为什么选择DeepSeek在评估了多个大模型平台后我们最终选择了DeepSeek的FunctionCall方案主要基于三个维度的考量对比维度方案A通用模型方案B开源框架DeepSeek方案意图识别准确率78%85%92%参数提取精度需要额外训练依赖标注数据开箱即用系统对接成本高需开发适配层中需封装接口低原生支持特别是DeepSeek对中文口语化表达的优秀处理能力让最终用户体验产生了质的飞跃// 用户输入: 帮我看看清明节后第一天早班机 // DeepSeek生成的函数调用参数 { function: search_flights, arguments: { date: 2024-04-06, time_range: 06:00-09:00, departure: , destination: } }提示选择大模型平台时建议用实际业务语句进行压力测试。我们准备了200条真实员工查询作为测试集DeepSeek在模糊日期解析如下个月末和地点别称如魔都对应上海场景表现最佳。3. 核心实现从自然语言到API调用的魔法整个系统的架构可以分为三个关键层次3.1 函数定义层采用JSON Schema严格定义航班查询接口的契约这是确保大模型正确调用业务系统的基石flight_schema { name: get_flight_info, description: 查询指定条件的航班信息, parameters: { type: object, properties: { departure: { type: string, description: 出发城市如北京 }, destination: { type: string, description: 到达城市如上海 }, date: { type: string, format: date, description: 日期格式YYYY-MM-DD }, time_range: { type: string, enum: [morning, afternoon, evening, ], description: 时段筛选 } }, required: [departure, destination] } }3.2 业务适配层为了解决内部系统认证和参数转换问题我们开发了轻量级的适配服务认证处理在函数执行时自动注入API Token参数清洗将模型输出的参数转换为内部系统需要的格式结果过滤对返回的航班数据做隐私脱敏处理典型转换逻辑示例def convert_time_range(input_str): # 将早班机等口语转换为具体时间范围 mapping { 早班机: 06:00-09:00, 上午: 09:00-12:00, 中午: 11:00-14:00, 下午: 12:00-18:00, 晚班机: 18:00-24:00 } return mapping.get(input_str, )3.3 交互优化层通过设计多轮对话策略提升用户体验参数补全机制当用户只说查去广州的机票时自动追问请问从哪个城市出发模糊日期处理内置节假日日历能准确解析春节前一周等复杂时间表达结果增强展示在返回航班号的同时附加机型、座位图等扩展信息4. 避坑指南实战中积累的经验在项目落地过程中我们踩过几个值得分享的坑4.1 参数提取优化初期遇到的最大挑战是地点别名识别。例如用户输入飞往羊城模型应该输出destination: 广州但系统有时会错误保留羊城导致API调用失败解决方案是构建地点别名映射表并在函数执行前进行参数后处理city_alias { 羊城: 广州, 魔都: 上海, 蓉城: 成都, # ...其他别名 } def normalize_city_name(name): return city_alias.get(name, name)4.2 错误处理策略我们设计了分级错误处理机制模型级错误当参数明显缺失时如只有目的地没有出发地让模型直接追问用户系统级错误当API返回4xx错误时自动重试并降级返回缓存数据业务级错误当查询无结果时建议相近日期或附近机场的航班注意千万不要直接向用户展示原始错误信息如API 500错误。我们定义了一套友好的错误提示模板比如系统正在升级请稍后再试。4.3 性能优化技巧缓存策略对热门查询如北京-上海 今天的结果缓存5分钟批量处理当检测到连续相似查询时如不同日期的同一航线合并API请求超时控制设置函数调用的超时阈值我们设为3秒避免用户长时间等待5. 效果与反思数字背后的故事上线三个月后系统交出了一份令人惊喜的成绩单查询效率提升平均响应时间从人工处理的5分钟降至8秒人力成本降低行政团队每月节省约120小时航班查询工时用户体验改善NPS净推荐值达到72分远超传统工单系统但更让我意外的是涌现出的新用法有同事用帮我找最便宜的周末往返机票来规划差旅财务部接入系统自动获取航班号完成报销校验会议室智能屏集成了航班状态查询功能这个项目给我的最大启示是AI技术落地的关键不在于模型的复杂度而在于对业务场景的深度理解。就像航班查询这个看似简单的功能真正做好需要理解员工实际如何描述行程比如用下周midweek代替周三知晓业务系统的特殊约束如内部API对机场代码的特定要求设计符合工作习惯的交互方式支持中途修改查询条件在技术选型上DeepSeek的FunctionCall展现出了三大优势精准的意图识别即使面对查清明小长假最后一天晚班机这样的复杂表达也能准确提取参数灵活的模式配置通过JSON Schema可以快速适配各种业务接口稳定的生产表现在日均3000查询的压力下保持99.2%的成功率现在当看到同事自然地和AI助手对话查航班时我常想起项目初期有人质疑为什么不直接做个查询页面答案很简单最好的界面就是没有界面。当技术足够理解人的时候人就不需要去适应技术了。