解读

面试官真正想考察的是：

1. 在国内真实业务场景下，面对百亿/千亿参数大模型的长上下文瓶颈（普遍 4k～8k 有效长度），如何低成本、高保真、可工程化地把 20k token 的检索结果喂给模型，同时不触发 OOM、不超时、不丢关键信息。
2. 是否理解滑动窗口摘要与普通分段摘要、递归摘要、语义去重的差异，能否给出可落地的 LLMOps 流程（含离线实验、在线服务、监控回环）。
3. 是否具备**“token 经济学”意识：在GPU 显存**、RT、TP99 延迟、用户付费意愿之间做权衡。

知识点

1. 滑动窗口摘要（Sliding-window Abstractive Summary）：
   把长文本切成重叠窗口→每窗口调用轻量级摘要模型（如 1.3B 参数以下，国内可落地部署在 A10/A100 24G 卡）→只保留关键信息 sentence embedding→动态压缩到 4k token 以内。
2. 窗口参数设计：
   • 窗口长度=512 token，步长=256 token，重叠率50%，兼顾上下文连贯与计算量。
   • 摘要比例r=0.15，可随信息密度自动调节（国内新闻场景 r=0.12，医疗法规 r=0.25）。
3. 信息保留策略：
   • 先检索后摘要：用粗排分数过滤 Top-N（N=100 文档），再做窗口摘要，避免**“摘要垃圾”**。
   • 关键词锚定：把用户 query 中的实体、业务敏感词（如“年化利率”“不良反应”）强制保留，防止合规风险。
4. 推理加速：
   • 采用INT8 量化+TensorRT落地，单卡 A10 可并发 80 QPS，TP99 < 800 ms。
   • 对窗口摘要模型做动态批拼接（continuous batching），显存利用率提升 35%。
5. LLMOps 监控：
   • 摘要幻觉率=（摘要引入的新实体数/原文实体数），红线**<3%**。
   • 信息召回率=下游任务准确率下降幅度，<1.5% 视为可发布。
   • 通过Kafka 回捞用户点击日志，每日增量微调摘要模型，7 天滚动更新。

答案

分五步落地，全部在国内机房完成，不调用境外 API，满足等保 3 级与**《生成式 AI 管理办法》**要求：

1. 检索粗排
   用自研 6B 向量化模型（已做词表裁剪+领域 post-pretrain）把 20k token 文档库粗排，取Top-100 文档（约 12k token），过滤低分<0.42 的文档，减少后续 40% 计算量。

2. 滑动窗口切分
   对 12k token 按512/256 重叠切片，得 24 个窗口；保留窗口级标题、段落号，方便可解释性输出。

3. 轻量摘要
   调用1.3B 参数摘要模型（已用10GB 中文领域数据微调，INT8 量化后显存 2.1 GB），每窗口生成80 token 摘要，共 24×80≈1.9k token；关键实体强制复制到摘要，防止**“数字漂移”**。

4. 二次去重&融合
   用SimCSE 中文句向量做聚类阈值 0.82去重，冗余句删除后剩余约 1.2k token；再按原文时间倒序拼接，头部插入用户 query 扩展词（同义词、拼音、缩写），最终 1.2k+0.3k=1.5k token。

5. 动态扩容到 4k
   若下游任务需要更多细节，递归式二次摘要：对 1.5k 摘要再次滑动窗口（1024/512），生成 0.6k 超级摘要；原文与超级摘要做 token 级交叉，保留差异句+超级摘要，动态填充至 4k 上限，信息密度提升 2.7 倍，幻觉率 2.1%，下游问答 F1 下降 0.8%，满足上线标准。

拓展思考

1. 异构窗口：对表格、段落、标题采用不同窗口长度（表格 256，段落 512，标题 128），摘要模型共享参数，显存节省 18%。
2. 强化学习压缩：用RLHF把摘要模型 reward 设计成**“摘要 token 数负对数 + 下游任务 reward”**，自动学习最优压缩率，3 万条标注数据即可收敛。
3. 端边协同：在运营商机房做窗口摘要，边缘节点只存 4k 结果，中心大模型做生成，骨干网流量下降 72%，**符合国内“东数西算”**政策导向。