解读

在国内真实业务场景中，大模型输出常被长度限制、实时性要求或合规过滤强制截断，导致用户只能看到“压缩版”答案。面试官想考察的是：

1. 你能否量化压缩带来的信息损失；
2. 你能否用低成本、高体验的方式把遗漏内容还给用户；
3. 整套方案必须可灰度、可监控、可回滚，符合国内监管对生成式 AI 的“安全可控”底线。

知识点

1. 分层摘要算法：用 Token-level ROUGE 或 BERTScore 对原文与压缩文本做差异打分，定位被裁剪片段。
2. 交互式分页协议：在 SSE 流式返回里插入自定义控制符（如 <more id=0>），前端可精准回拉。
3. Prompt Continuation 模板：设计“续写且不重复”的 System Prompt，加入去重指纹（last 64 token hash）防止回旋。
4. 缓存策略：被裁剪片段以用户级 SessionKey+段落ID为键，存入Redis Cluster（带 TTL=24h），避免二次生成。
5. 合规二次审核：展开内容再走一遍敏感词+意识形态双队列审核，审核通过才返回，否则降级到“当前内容已满足合规要求，无法继续”。
6. 埋点与监控：前端点击“展开更多”时上报expand_event，后端记录首屏压缩率、展开率、二次审核拒绝率，用于后续Prompt 压缩参数调优。

答案

我给面试官一个“四步闭环”方案，可直接落地到国内公有云：

第一步，压缩阶段打标记
在模型输出后处理环节，用滑动窗口摘要算法生成 512 token 内的“安全摘要”，同时把被裁剪的段落编号、起始 token 位置、置信度写入X-Compress-Info响应头，前端隐藏缓存。

第二步，前端交互按钮
当检测到响应头存在且置信度<0.95 时，前端在答案底部渲染“展开更多”按钮；点击后携带session_id+paragraph_id调**/api/v1/expand**接口，按钮立刻置灰并显示“审核中”，避免用户重复点击。

第三步，后端续写服务
续写服务收到请求后：

1. 先查 Redis，命中直接返回；
2. 未命中则把原对话历史+去重指纹喂给模型，用**“请继续上文，不要重复最后64个token”**的 System Prompt 生成补全内容；
3. 补全内容过敏感词+意识形态双队列审核，拒绝率>2% 自动回滚到“无法继续”提示；
4. 审核通过写入 Redis 并返回，整个耗时 P99 控制在 1.2s 以内。

第四步，数据回流与优化
把expand_event与审核拒绝样本回流到 LLMOps 平台，每周自动调优摘要阈值；若某类问题连续 3 天展开率>40%，则触发Prompt 扩容，把首屏 token 上限从 512 提到 768，实现动态压缩率调整。

拓展思考

1. 多端一致性：在小程序里，微信对 SSE 支持弱，可改用WebSocket+PB 序列化，同样把控制符埋进去，保证展开行为与 H5 对齐。
2. 成本对冲：续写请求走更低价的蒸馏 6B 模型，用KL 散度对齐原模型分布，成本下降 70%，用户体验无感。
3. 监管升级预留：若未来《生成式 AI 备案新规》要求“展开内容需二次备案”，可在审核通过后把文本先写入MongoDB 归档集合，自动生成 Hash 指纹，方便监管抽查，全程可追踪、可回滚。