Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
我们有 summary,但模型还是忘,因为 summary 太像自然语言:“用户提到了一些订单信息”。
那不行。写成结构化更稳:order_id=xxx、confirmed=true、source_turn=2。模型看得懂,系统也能校验。
order_id=xxx
confirmed=true
source_turn=2
还有一种是工具结果丢了。模型查过订单,但下一轮工具返回不在上下文里,它就又查。
工具结果也分长期和短期。订单状态这种会变,别永久写死;用户已授权查询这种可以保留。
历史截断前是不是要让模型自己决定保留什么?
可以让模型参与摘要,但最终要有程序规则兜底关键槽位。完全让模型决定,出错时很难复盘。
我们后来每轮都跑“状态抽取”,模型输出 JSON,后端校验字段,失败就不用。稳定很多。
前端也能帮一点,用户已填写信息放在表单态,不要都混在聊天里。
我回去改:聊天历史截断前先抽关键事实,摘要结构化,订单号进入会话状态。
记得加回放测试。截断 bug 靠人工聊天很难稳定复现。
你好!看起来您对这段对话很感兴趣,但您还没有一个账号。
厌倦了每次访问都刷到同样的帖子?您注册账号后,您每次返回时都能精准定位到您上次浏览的位置,并可选择接收新回复通知(通过邮件或推送通知)。您还能收藏书签、为帖子顶,向社区成员表达您的欣赏。
有了你的建议,这篇帖子会更精彩哦 💗