跳到本文

模型与持久化

连接中断后,如何确认内容与费用

显示、历史、网关用量和账本是四份不同的事实。沿原请求逐项查询,才能判断内容保存到了哪里、结果是否送达,以及费用是否入账。

先把四个问题分开

一次回答涉及多个完成时刻:文字到达浏览器、内容写入历史、网关保存最终用量、应用提交费用。它们沿同一请求关联,却不是同一个操作。浏览器离线可以与其中任何一个时刻交错,单凭界面停在哪一行,无法判断其余结果。

想知道哪些内容还能读回,查 Chat 的已提交历史;想知道网关保留了什么计数,查 YaoDel 的原请求结果;想知道实际扣费,查 Yaoledge 的授权与账本。查询沿用原会话、轮次和网关请求的对应关系,并分别保留查询成功、结果缺失或查询失败。

应用授权后,边缘网关执行一次供应商调用;响应分成客户端输出与持久结果两条路径,保存的结果继续通知原应用。
一次模型调用,分别交付输出与最终结果先固定原应用的授权与执行目标,再区分两条返回路径:增量送往客户端,终态用量交给控制器保存并通知原应用。两条路径可独立推进,位置不表示谁先完成。
每个问题读取自己的记录
可见事实读取依据能够确认什么
屏幕曾显示浏览器收到的临时增量当时的本地显示进度
历史已保存已提交引用与轮次状态能重读的前缀与结束状态
网关用量原请求持久结果及通知状态已保存计数与交付进度
费用已入账原授权、终态与用量账本实际费用与分摊

从历史中的确定前缀开始

用一个示意情形说明:页面已显示 A、B、C、D 四段,只有 A 到 C 的检查点完成发布。此时连接中断,重新打开后能确认的是 A 到 C。D 曾经出现,不等于它已经保存;这组字母仅表示内容顺序,不是实际输出或性能数据。

Chat 先把内容写到私有对象存储,再发布属于原会话和轮次的有序引用。只有当前历史中已提交的引用可以参与重读、导出和下一轮输入。显式停止会在原预算内尝试保存尾段,浏览器断开不做这个额外保存;重新读取不会继续供应商流,也不会重发原推理。

上方显示 A、B、C 与临时的 D,下方仅保存 A、B、C;两行逐段对齐,区分可见进度和可重读历史。
屏幕已显示的内容,可能还未进入历史上下对齐同一段内容:浏览器已显示 A–D,已提交历史只有 A–C。D 的虚线表示临时进度;重新打开时,只能从已提交的确定前缀继续阅读。字母表示顺序,不表示时间或性能。

再查网关真正保存的终态

YaoDel 只从完整匹配的供应商终态整体采信四项用量。终态事件可以先发往客户端,结果提交另行推进;反过来,结果也可以在客户端输出失败后仍然保存。因此,收到终态不能代替持久结果查询,看不到回答也不能证明结果没有保存。

查询需要原应用标识与网关请求标识。Chat 取得响应头中的网关标识后会保留它,但自己的轮次标识不是上游幂等键,二者不能互换。若当时没有取得该标识,应保留关联缺失这一事实,不能猜造另一个身份来重新执行。

最终候选先保存为待通知结果,再进入处理已确认或到期未确认状态;通知重试不改变保存的结果,也不重跑模型。
结果保存与通知确认,分别核对先看结果是否保存,再看通知是否获得确认。重送沿用同一个不可变结果;已确认表示原应用确认处理,到期未确认仍不能推断费用为零。
结果查询中的几个不同判断
观察含义不应得出的结论
已保存 ERROR,四项为零网关保留了明确的错误候选供应商没有做过任何工作
成功查询但结果缺失本次读取没有对应保留结果原调用一定没有发出
查询失败尚未取得所需观察等同于缺失或零值
通知到期未确认网关未按期确认应用处理应用一定没有记账

费用回到原授权与结算记录核对

Yaoledge 在授权时保存账户、模型、目标和费率,不预扣本次费用,也不保留一个资金上限。收到匹配的最终用量后,按原价格计算费用,再按结算时的账户状态分配额度、积分与超额。页面是否在线不参与这一决定。

如果账本已经提交,确认回复却丢失,YaoDel 可以重送同一结果。应用读出已关闭的原请求并确认,不再次记账。重送结果与重新请求推理有不同影响:后者会产生新的执行机会,不能用来修复一条未确认的通知。

原推理查询可以区分“已授权、尚无最终入账结果”和“已关闭”,并给出原费率、终态与金额。前者只是本地账务状态,不说明模型仍在运行。完整的零用量结果可以关闭请求而不扣费;缺失通知不能被自行补成这种零结果。

用一条有边界的查询路径定位问题

面对“回答停了,但费用似乎已经变化”的反馈,先取得原会话和轮次,再核对已保存的网关请求关联。读取历史回答内容保存到哪里,读取 YaoDel 原结果回答网关保留了什么,读取 Yaoledge 原账务回答实际如何结算。每一步都可以停在“尚未取得观察”,不需要用重新推理补齐证据。

若某一步成功取得结果,继续沿同一原请求核对;若查询失败,保留失败与最近已知的时间范围。已保存结果的通知状态帮助解释交付进展,却不会改变结果本身,也不能替应用账本推断是否扣费。

  1. 从原会话确认内容

    读取已提交历史与原轮次状态,保留确定前缀。

  2. 从原请求确认结果

    使用实际取得的网关标识,分别观察保存结果与通知状态。

  3. 从原授权确认费用

    核对原价格、终态用量和账务提交,不以页面离线推断零费用。

  • 重复通知处理同一保存结果

    接收方以原请求的持久去重保证业务只处理一次。

  • 重新推理不是结果恢复

    另一轮模型调用会产生新的执行机会,不能修复原来的未知。

让每个验证场景排除一个具体误判

有用的验证不只观察页面出现了错误,而要安排可区分的时序,并与独立预期比对。以下是设计要求关注的情形,描述的是应验证的结果,不是已经完成的实测报告。

观察仍要沿用原会话、轮次及网关请求绑定。查询失败时保留未确认;保留旧读数时说明观察时间。操作的下一步来自原记录与当前权限,不能由一段日志、超时或没有看到事件来推导新的执行许可。

  1. 显示后、发布前断线

    让 D 已显示但检查点未提交。重开后核对仅 A–C 可读,并观察没有第二次上游调用。

  2. 终态输出后延迟保存确认

    允许完整终态先结束客户端流。核对结果提交继续使用原候选,输出无需等待其确认。

  3. 记账后丢弃通知回执

    重复交付同一终态,核对原请求只对应一次费用与一次日报增量。

  4. 区分零、缺失和读取失败

    分别提供这三种观察,检查界面和运维结果没有把它们合并成同一个“零费用”。