[Bug]: MV SEP 追问 end-user say no 后，不应该进入 confirmation 和 response

[Zeng666666]

Is there an existing issue for this?

• [X] I have searched the existing issues

Current Behavior

1. MV SEP 追问 explicit confirm 后，如果 end-user say no，则会带着空值直接进入 confirmation 和 response：

2. MV SEP 追问 implicit confirm 后，如果 end-user say no，则会带着空值直接进入 confirmation 和 response：

Expected Behavior

【提议 1 】MV SEP 只有 Explicit Confirm

1. 我们对于 implicit 与 explicit 已有明确的定义，目前的处理方式会让 builder 产生 implicit 定义不一致的困惑；
2. 从实际场景出发，MV 进入 SEP 时，builder 只能定义 explicit confirm，既可以给 end-user 一个特别的提示，也可以不因 implicit 的定义进入无限循环，还能保证 implicit 一致性。

【提议 2 】MV SEP 追问，end-user 直接 say no，应 follow ZEP default strategy：exit。

Use Case

Test Case：https://framely.naturali.io/org/621d809561f0057d035f6437/agent/622adde22fb46d1befee2232/test_case

Steps To Reproduce

see test case

Label of org.project

test001.test_zep

Framely Link

https://framely.naturali.io/org/621d809561f0057d035f6437/agent/622adde22fb46d1befee2232/intent/622addfa2fb46d1befee223a/slot/622addff2fb46d1befee223e

Test Case

No response

Additional information

No response

[yigexu]

@Zeng666666 你的提议是二选一吗

[Zeng666666]

@yigexu 不是的，是两个提议

[yigexu]

对于提议1，我感觉已经有的功能如果有bug我们fix bug，没必要删除 @xiaoyunwu @Zeng666666

@Zeng666666 另外，implicit confirm 截图那里本身不是一个 bug。那是一个正常的 VR，也就是user 不能说 no。说的 no 是对 mv 说的 no，所以表现是正确的。

换成正确的话术应该好理解一些： Do you want any (other) noodle? We have: 1. tomato egg noodle No You select 0 noodle. ....

[Zeng666666]

@yigexu

【提议1】是因为“表现”有违“设计原理”，implicit 在 platform 呈现出两种不同表现，builder 会困惑，这个是不自洽的表现，需要 fix。

【提议2】implicit confirm 目前的表现并不是 implicit，它在 hard sep 时输出的是 header+body+footer，expectation 是不一致的。

[yigexu]

@xiaoyunwu @Zeng666666 https://naturali-io.feishu.cn/docs/doccnY7jibBUopf2TkMf8Mt8fhe 原来的需求文档上是这样要求的；当时考虑过几个方案，最后选了min max之间，SEP implicit 输出为 VR。如果觉得不合适，我们可以重新分析。 但这里不是bug。

[Zeng666666]

@yigexu 现在是表现不对，需要修复，我给出了一些提议，并没有在讨论哪里是不是 bug。我们应该讨论提议或者形成方案，完成好的体验。现在是空值填槽 confirmation 和 response 都走完了，肯定和预期是不同的。

[xiaoyunwu]

one thing at a time, the first question: in the first diagram, we have an explicit confirmation on sep, correct? If so, when user says NO, we should default exit intent? (using state update for recovering if we need to down the road). @yigexu can we agree on this?

[yigexu]

@xiaoyunwu 需求文档的要求是：在min-max之间时，user 对 SEP 说 negative expression，应该结束mv (SEP 状态未知，但mv.list没有增加内容)。我觉得 explicit 的那张图就是一个标准的 bug。

另外，如果想重新 discuss 表现，我仍旧认为是退出 mv，不是退出 intent。MV 完全可以选 0 个。 换成有意义的话术可能比较容易理解： Do you want any (other) noodle? We have: 1. tomato egg noodle (MV prompt + VR) No You select 0 noodle. (或者 You didn't choose any noodle) (confirm) 然后response应该看情况，什么都没选应该让他回去继续购物，或者通过 condition 输出 你啥也没选，欢迎下次再来。

[Zeng666666]

@yigexu 这个 issue 还没有走到 has more。目前的表现是在第一次追问 mv slot 时，进入了 SEP，end-user say no 的问题。换成你的 case 是：

• Bot：

  Prompt：你想吃什么面？
  SEP explicit：我们只有“西红柿鸡蛋面”了，这是你想要的吗？

• User：

  不是。

问题：

1. MV 可以选 0 个是指什么呢？我理解的是需要填槽的 slot 是不能为空的，如果没有填槽是不能往下走的。。。

2. min-max 应当针对的是 MV-prompt？即 mv slot 已经填了一个值了，比如“西红柿鸡蛋面”，而后追问 mv-prompt“你还想要什么面吗？我们依然只有西红柿鸡蛋面”，允许对 has more say no，此时 min 是 0，但 slot 有一个值。

（👇截图和本 issue 无关，是为了表现本 comment 的问题 1 与 2）

BTW，有可能是我没有描述清楚，不是 MV Prompt 时 say no，是此刻追问的 slot 是 Multi-valued，但此时 VR 进入了 SEP。

[xiaoyunwu]

To make thing simple: let's discuss on the the semantic level: (we need to make sure the messaging to user and dialog expectation agrees).

1. if user say "No" to explicit SEP confirmation on the first value, then we should exit intent.
2. if user say "No" to explicit SEP confirmation on the second value and beyong, then we should end MV.
3. if user say No to hasMore prompt, we should end MV.

[yigexu]

我觉得 1、2 应该是 exit MV，因为我认为 MV 存在可以选 0 个 value。 hasMore prompt 是什么？我记得当时讨论最后的结论是：MV 的 prompt 既包括hasMore，也包括value是什么。 @xiaoyunwu

[XiaoboYuan]

@xiaoyunwu

1. 我觉得#1和#2不应该和first/second有关，应该和min/max有关
2. 即使是hasMore prompt要不要end我觉得也是min/max决定的

[yigexu]

我可能理解 hasMore prompt 的意思了。 两层：

1. builder 通过 min-max 决定用户可以选几个。
2. user 回答每个轮次，他可以决定要不要 hasMore、以及 value 是什么。

这个 issue 的 case 是 min = 0，所以 mv 可以是 0 个value，预期是 exit mv。

可以和 SV 类比的是 min之内，user say no

• 首先，VR-N 的需求要求的表现是触发 min exception，不清理 MV 内容，继续询问直到满足min
• 考虑 SEP + explicit confirm，这里的问题是 user 的 no 是什么 no。
  • 如果是对 hasMore 的 no，那么应该追随上面的 VR-N (exception + 继续让他填)
  • 如果是对 SEP value 的 no，那么应该追随 SV exit intent。

我们目前的设计不区分这二者。

[xiaoyunwu]

@XiaoboYuan you are right, #1,#2 should depends on min/max. @yigexu 考虑 SEP + explicit confirm，这里的问题是 user 的 no 是什么 no => SEP confirmation 的 no

[Zeng666666]

目前 platform 定义和实现层面好像有一些 gap，不知道我下面的这些理解是不是对的，从 builder 视角来看：

1. Min/Max 是定义在 MV-Prompt 上面的，因此本能的认为是用来控制 MV-prompt 次数的；在追问 MV-prompt 之前，是需要先追问 slot prompt，得到值后，再追问 MV-prompt；

2. Min 可以是 0，是表示，MV-prompt 时可以 say no；表现为 slot 为多值时，允许 end-user 只填一个，MV-prompt 可以拒绝填槽；（因为需要追问的 slot 必须得得到值，才能继续进行。所以 @yigexu 提到 mv 可以为 0 我理解是这个意思。）

如果 Min/Max 是用来控制整个 slot 可以填多少值的话，从 platform 角度，现在的设计就是不自洽的了；而且 Min 也就不能是 0 了？

[yigexu]

@xiaoyunwu 基于目前的信息，可以先这么理解。 @Zeng666666 @xiaoyunwu 对一个 MV，逻辑上完整的值域是 0-N，usecase中，main dish 和 side dish 是可以不选的。

[xiaoyunwu]

Min mean at least, but even if min is zero, we still need to ask. @Zeng666666