创新实训个人工作-初步搭建（二）

一、思考

在完成 AI 问答页的基础搭建后，我开始思考：如果这个页面真的面向用户使用，它应该像什么？

我觉得他的回答必须要更加专业，可以在生活中可以真实可用。

所以后续打磨，我主要围绕两条线展开：

• 让回答更像餐饮顾问，而不是普通聊天
• 让用户能直接拿回答去点餐

二、知识增强和回答结构化

如果只是把用户问题直接扔给大模型，回答很容易泛化，像普通闲聊。
但餐饮场景的价值在于“更具体、更贴上下文”。

我在后端逐步补了一个轻量 RAG 链路（后续接入知识库之后可以考虑加入向量化，让这个功能更加专业），主要思路是：

• 本地知识样本
• 轻量 query rewrite
• 中文关键词匹配
• 标签加权
• 意图分路检索
• 去重与去噪排序
• 检索日志落库

知识样本覆盖的内容主要有四类：

• 菜品术语解释
• 过敏原与风险提示
• 点餐表达
• 常见菜品知识

这样一来，AI 问答就不再只是“模型随便生成一段”，而是会结合命中的知识结果来回答。因为是其他队友负责的知识库的构建所以需要这种开会后再进行接入，目前知识本地的知识样本。

三、点餐功能添加

用户在真实场景里最容易卡住的不是知道这道菜有风险，而是：

• 知道有风险之后，怎么问店员？
• 不吃生食、少辣、过敏，这句话怎么说？
• 去日本、韩国、英语环境下，该怎么表达？
• 能不能直接播给店员听？

所以我后面专门把 ordering_phrase 做成了一个独立子能力。

它不只是返回一句文本，而是会生成一个结构化卡片，大概包含：

• 目标语言
• 简洁版表达
• 礼貌版表达
• 中文翻译
• 发音辅助
• 备注

而且它支持多种场景：

• 询问是否含花生/奶/过敏原
• 表达少辣
• 表达不吃生食
• 请求推荐更安全的菜
• 明确想点某一道菜

最后一点很重要。因为我后面发现，用户意图不总是“帮我判断能不能吃”，有时用户其实已经下定决心（比如说不能吃生食但是坚定点刺身饭）：

• 我就是想点刺身饭
• 给我生成点单句
• 这是给朋友点的

如果系统一味只告诉用户“你不能吃”“不建议点”，体验会很差。
后来我调整了后端逻辑：在“明确点单意图”场景下，优先顺着用户的真实意图，先给可用表达，再补风险提醒，而不是只做劝退。

四、多语言和语音播放、收藏复用

点餐表达一旦做出来，自然就会走到下一步：
用户看得懂句子，不代表用户敢开口说。

所以我继续把多语言和 TTS 接了进去。

目前支持的目标语言主要有（后面开会讨论具体应该要支持多少语言比较好）：

• 英语
• 日语
• 韩语

语言来源也做了优先级判断：

1. 用户问题文本里显式提到的语言
2. 页面显式选择的语言
3. 用户偏好语言
4. 默认回退到英语

在语音这块，前端不是只用本地 TTS，而是已经和后端 TTS 接口打通：

• 后端负责调用云端 TTS 合成
• 前端负责播放音频
• 如果云端失败，再回退本地 TTS
• 如果都失败，也不崩，保留文本展示

一旦点餐表达可用了，另一个自然的问题就是：
用户有没有可能经常重复用同一类表达？

答案当然是会。比如：

• 我对花生过敏，这种确认句我以后还会用
• 我不吃生食，这种表达会反复出现
• 少辣、礼貌确认、请店员推荐安全选项，这些都是高频句

所以我把项目里原本只有雏形的收藏页，逐步改成了“点餐表达收藏页”。

收藏后，用户可以：

• 本地持久化保存
• 查看收藏内容
• 复制 simple / polite 表达
• 播放语音
• 删除

点击收藏

可以在收藏页面看到。

五、收获

到目前为止，这个 AI 问答模块已经基本具备了演示价值和继续扩展的结构基础。
后续推进应该会是：

• 接入真实用户偏好
• 接入真实菜单历史
• 升级知识库和检索质量
• 进一步打磨点餐表达翻译与语音体验
• 目前前端比较不美观，等开发差不多再打磨