大模型面试题：如何保证实时性和多轮对话一致性？

m0_65481401

487人浏览 · 2026-05-08 21:51:52

m0_65481401 · 2026-05-08 21:51:52 发布

1. 面试官想考察什么？

这个问题主要考察你有没有真正理解大模型应用的工程链路。

实时性关注的是：

系统能不能快速响应用户请求

多轮对话一致性关注的是：

系统能不能记住当前会话状态，保证前后回答不冲突

很多同学会回答：

用缓存、流式输出、带上历史上下文。

这个回答不能说错，但比较浅。更好的回答应该从 请求链路优化 和 会话状态管理 两个角度展开。

2. 1 分钟标准回答

面试时可以这样回答：

我会从实时性和多轮一致性两个方面处理。

实时性方面，首先使用流式输出，降低用户感知延迟；其次在模型侧选择合适大小的模型，并通过推理加速、并发控制、缓存等方式提升响应速度。在输入侧，要做 Prompt 精简和上下文裁剪，避免每轮都把完整历史塞给模型。对于 RAG 场景，还要优化向量检索、控制 TopK、合理使用 Rerank，并设置超时降级策略。

多轮一致性方面，我会以 Session 为单位维护状态，包括最近几轮对话、历史摘要、用户当前意图、关键实体、已检索文档和工具调用结果。每轮请求进来后，先判断是新问题还是追问，如果是追问，就结合历史上下文做 query rewrite。比如用户上一轮问差旅报销，下一轮问“那上海呢”，系统要能还原成“上海差旅报销标准是多少”。

总体上，实时性和一致性需要平衡。简单问题走轻量链路，复杂问题再启用 RAG、Rerank 或多轮检索。

3. 实时性怎么保证？

实时性可以从这几个点回答。

3.1 流式输出

流式输出可以让用户尽快看到首 token。

它不一定减少总生成时间，但能明显降低用户感知等待时间。

3.2 模型和部署优化

不是所有问题都要用最大模型。

可以做模型分层：

简单问题：小模型 / 快模型
复杂问题：大模型
高风险问题：更强模型 + 校验

部署上可以结合：

vLLM、KV Cache、batching、模型量化、并发队列

3.3 Prompt 精简和上下文裁剪

Prompt 越长，延迟越高。

所以不能每轮都带完整历史，而是保留：

最近几轮原文
历史摘要
当前任务状态
关键实体

无关历史要丢弃，避免拖慢速度和污染上下文。

3.4 缓存

常见缓存包括：

Query Cache：相同问题复用结果
Retrieval Cache：复用检索结果
Answer Cache：标准 FAQ 直接返回

但缓存要注意权限、文档版本和数据时效，不能把过期答案返回给用户。

3.5 RAG 检索优化

RAG 链路通常比较耗时，可以优化：

控制 TopK
向量检索 + BM25 混合检索
只对少量候选做 Rerank
缓存热门 query 的检索结果
对检索和 Rerank 设置超时

Rerank 能提升准确率，但会增加延迟，所以不能无脑对大量候选做精排。

3.6 超时降级和限流

线上系统要有降级策略：

Rerank 超时 → 使用向量检索排序
大模型超时 → 切换小模型
检索失败 → 使用缓存或提示稍后重试
高并发 → 排队、限流、熔断

这样可以避免单个模块拖垮整条链路。

4. 多轮对话一致性怎么保证？

多轮一致性的核心是：

不要只保存聊天记录，而要维护会话状态。

4.1 Session 状态管理

每个会话维护一个 Session，例如：

{
  "topic": "差旅报销",
  "intent": "查询报销标准",
  "city": "上海",
  "used_docs": ["员工差旅报销制度2024"],
  "summary": "用户正在咨询差旅报销标准"
}

这样比单纯把历史对话塞进 Prompt 更稳定。

4.2 短期上下文 + 历史摘要

最近几轮对话可以保留原文。
更早的历史可以压缩成摘要。

这样既能保持上下文，又能控制 token 数量。

4.3 意图识别和 Query Rewrite

用户多轮追问时，经常会省略信息。

比如：

第一轮：我们公司的差旅报销标准是多少？
第二轮：那上海呢？

第二轮不能直接拿“那上海呢？”去检索，而要改写成：

上海差旅报销标准是多少？

这就是多轮一致性的关键。

4.4 RAG 结果和历史状态融合

RAG 场景下，要记录上一轮使用过的文档、版本和关键事实。

比如上一轮依据的是：

《员工差旅报销制度 2024》

后续追问同一主题时，要优先保持同一资料来源，避免一轮用新版制度，一轮用旧版制度。

4.5 防止上下文污染

如果用户切换话题，就不能继续带旧上下文。

比如前面一直聊报销，用户突然问：

帮我写一段 Java 快排代码

这时就应该识别为新话题，不再带入“差旅报销”的上下文。

5. 实时性和一致性怎么取舍？

两者经常冲突。

为了实时性，可能会减少上下文、跳过 Rerank、使用小模型。
为了一致性，可能要带更多历史、做检索、做事实校验。

比较合理的做法是分层处理：

简单问题：轻量上下文 + 缓存 + 快模型
复杂问题：RAG + Rerank + 较长上下文
高风险问题：引用来源 + 事实校验 + 更强模型

不要所有问题都走最重链路，否则成本和延迟都会很高。

6. 企业知识库问答案例

假设用户连续问：

1. 我们公司的差旅报销标准是多少？
2. 那上海呢？
3. 如果超过标准怎么办？
4. 帮我总结成一段话发给同事。

系统应该这样处理：

第一轮，识别主题是“差旅报销”，通过 RAG 检索公司制度，回答标准，并记录使用的文档。

第二轮，“那上海呢？”是追问。系统要结合 Session，把问题改写成：

上海差旅报销标准是多少？

第三轮，“超过标准怎么办？”仍然属于差旅报销主题，需要补充检索审批规则。

第四轮，用户要求总结，这时不需要重新检索大量文档，可以基于前几轮确认的信息生成一段话。

这个过程中，系统维护的状态类似：

{
  "topic": "差旅报销",
  "city": "上海",
  "standard": "一线城市标准",
  "used_doc": "员工差旅报销制度2024",
  "extra_rule": "超过标准需说明原因并走审批"
}

这样既减少重复检索，又能保证多轮回答前后一致。

7. 常见追问

追问 1：历史对话很长怎么办？

回答：

最近几轮保留原文，较早历史做摘要，关键事实结构化保存，无关历史丢弃。

追问 2：每轮都要重新检索吗？

回答：

不一定。如果是同一主题追问，可以复用上一轮检索结果；如果引入新条件，再补充检索。

追问 3：如何避免前后回答矛盾？

回答：

记录文档来源、版本、关键事实和生效时间。后续同一主题优先复用已确认信息，如果新资料冲突，要明确说明。

追问 4：Rerank 很慢怎么办？

回答：

先粗召回，再只对少量候选做 Rerank。也可以只在复杂问题或低置信场景启用 Rerank。

追问 5：流式输出是不是能减少总耗时？

回答：

流式输出主要降低用户感知延迟，不一定减少总生成时间。总耗时还要靠模型推理、Prompt 长度、检索链路和缓存优化。

8. 可背诵回答模板

我会从实时性和多轮一致性两个方面处理。

实时性方面，首先用流式输出降低用户感知延迟；其次通过模型选型、推理加速、Prompt 精简、上下文裁剪和缓存来减少整体耗时。RAG 场景下要控制 TopK，只对少量候选做 Rerank，并对检索、Rerank、模型调用设置超时和降级。高并发场景下还要做限流、排队和熔断。

多轮一致性方面，我会以 Session 为单位维护状态，包括最近几轮对话、历史摘要、当前主题、关键实体、已检索文档和工具调用结果。每轮请求先判断是新问题还是追问，如果是追问，就结合上下文做 query rewrite。比如“那上海呢？”要还原成“上海差旅报销标准是多少”。

最后，实时性和一致性需要平衡。简单问题走轻量链路，复杂问题再启用 RAG、Rerank 或多轮检索，高风险问题则优先保证事实一致和引用来源。