Files
Jyotisha/docs/testing/consultation-context-and-cache-20260906.md
T
Jesse_Chen bf8ad0d1ff fix(web): keep consultation conclusions across turns and surface cache hits (BUG-555, BUG-556)
Session history was silently clipped to the first 4000 characters of the last 12 messages, so follow-ups could not see timing or audit tables. Keep an append-only tail plus a checkpoint summary, retry overflow in the same request, and expose cache hit rate in admin usage.

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-09-06 15:16:18 +08:00

2.3 KiB
Raw Blame History

Staging 人肉复核 · 普通咨询上下文与缓存(2026-09-06)

给产品负责人。不要把真实出生资料、真实用户问题或对话正文写进任何记录。试用问题用虚构句,例如「半年内换工作时机」。

对应 BUG-555、BUG-556。测之前先做第 0 条。部署前需先跑 Gitea Migrate Staging Database(本迁移与已积压的 5010000_personal_report_longform_appendices.sql 一起)。

0. 确认测的是新版本

浏览器打开 https://staging.jyotisha.chat/api/health,看 deployment.gitCommit 前 8 位是否等于本单合入 staging 后的提交。不一致 = 先别测。

1. 多轮之后还能对上前面的应期(P0)

  1. 新建一次普通咨询(不要用生时校正)。
  2. 用虚构问题连续问 6 轮以上,其中至少一轮要出带应期的 Level 2 报告。
  3. 再问:「你前面说的应期是哪年」。
  • 预期:答案与前面报告里的应期一致,或明确说那一轮被收进会话摘要。界面没有新的「加载中」态。
  • 失败:模型像没看过上一轮;或出现截断却完全不提应期。

2. 后台用量看得到缓存(P0

  1. 在 staging 用同一会话至少跑 3 轮普通咨询。
  2. 打开后台用量 / 定价测算页。
  • 预期:有「缓存命中」表(模型 / 运行数 / 命中率 / 缓存占比 / 读 / 写 / 未命中)。用量列表有「缓存读 tokens」列。没有缓存数据的模型不进命中率分母。
  • 失败:表不存在,或命中率把没有 metadata.cache 的运行算进去。

3. 三家供应商对照(P1

同一套虚构追问,分别用 DeepSeek、OpenAI、Anthropic 各跑一条(后台有配置的才测)。

  • 预期:三家都能正常回答。Anthropic 多轮后缓存读 tokens 可以大于 0。OpenAI / DeepSeek 不因多了标记而失败。
  • 失败:某家因历史缓存标记报错;或 Anthropic 多轮后缓存读永远是 0 且系统块断点也不在。

4. 超长对话仍是一次等待(P1

用已经很长的会话再发一条虚构追问。

  • 预期:用户仍只看到一次等待、一次揭幕。失败时仍是原来的失败文案,不会出现第二次转圈。
  • 失败:失败后自动又转一圈,或页面上出现新的重试提示。