多模态与实时交互面试题

面向 AI 应用开发工程师、RAG/知识库和实时语音应用岗位。本题库默认读者已经理解 embedding、向量检索、基础 Agent 和常见 Web API，重点训练如何把文档、图片、音视频和实时语音做成可解释、可授权、可恢复的生产系统。

已有 结构化与多模态 RAG 介绍统一证据模型、表格、Layout-aware PDF、视觉 RAG 和音视频 RAG 的基础设计；RAG 数据工程与企业知识库 介绍入库、权限、增量索引和回滚。本篇更偏面试中的系统设计、故障定位和取舍回答。

使用说明

扫描合同里的一个金额既可能是 OCR 错了小数点，也可能是图片版本过期。答案要能回到页码和框选区域，实时语音还要处理打断和迟到结果，不能只展示一段看似顺滑的文字。

每道题按“考察点 -> 回答脉络 -> 详细参考答案 -> 常见追问及答案 -> 扣分点”组织。回答这类题时，不要只说“接一个视觉模型”或“用 WebSocket 做流式”，应同时说明输入表示、状态边界、证据定位、权限、时延预算、取消和失败恢复。

一、文档解析与多模态 RAG

Q1：为什么企业 PDF 不能直接抽成一段文本后做向量检索？

考察点：是否理解 PDF 的版面语义、阅读顺序和证据定位问题。

回答脉络：先说明纯文本丢失了什么，再给出解析管线，最后说明检索和引用如何利用结构。

详细参考答案：

PDF 不是“带分页符的文本文件”，它通常只记录页面上的绘制对象。双栏文章、页眉页脚、脚注、浮动图片、表格、公式和扫描页都可能让普通文本抽取产生错误阅读顺序。即使文字内容没有丢，用户也可能需要知道“第 12 页右下角的表格单元格”，单纯的段落文本无法可靠定位。

生产管线至少分为：判断 born-digital、扫描或混合 PDF；抽取文本对象；对扫描区域执行 OCR；检测标题、段落、列表、表格、图和页眉页脚；恢复阅读顺序；按区域和章节切分；建立文本、关键词和视觉索引。每个区域保存页码、bbox、旋转角度、阅读顺序、OCR 置信度、文档版本和 ACL。

查询时先用文本和结构化元数据召回候选区域；命中表格、公式、盖章或低置信 OCR 时，再把对应页面裁剪图交给视觉模型复核，而不是每次都发送整份 PDF。生成上下文同时保留区域文字、相邻标题、表头和原图定位。这样既控制成本，也能解释答案来自哪一页哪一块。

常见追问及答案：

• 扫描 PDF 没有文本层怎么办？ 先做页面分类和 OCR，保存原图与识别结果；低置信区域进入人工复核或回答降级，不能把 OCR 猜测当确定事实。
• 为什么不只用多模态模型直接看整份 PDF？ 整份输入成本高、上下文不可控、引用难复现，而且模型可能忽略小字体和跨页表格。应先结构化解析，再按需视觉复核。

扣分点：只说“OCR 后向量化”；不提阅读顺序、坐标、版本和低置信处理；引用只能定位到文件名。

Q2：如何设计 PDF/OCR 的数据模型，支持可追溯引用？

考察点：是否能把文本、坐标、版本和解析过程建模为可审计证据。

回答脉络：先给区域级 schema，再说明派生物、版本和权限传播。

详细参考答案：

我会以“文档版本 -> 页面 -> 区域 -> 派生物”为层级。区域记录可以类似：

{
  "document_id": "contract-123",
  "document_version": "sha256:...",
  "page": 12,
  "bbox": [84, 210, 522, 436],
  "rotation": 0,
  "block_type": "table",
  "reading_order": 7,
  "text": "...",
  "ocr_confidence": 0.86,
  "extractor_version": "layout-2026-09",
  "acl_snapshot": "policy-abc"
}

bbox 必须说明原点、单位和旋转规则，否则前端高亮会错位。表格、图片、缩略图、OCR 文本和 embedding 都是派生物，必须带回源文档版本和权限标签。重新 OCR 或更换版面模型后生成新索引版本，不要覆盖旧结果，以便复现历史答案。

引用服务端生成 evidence_id，将声明绑定到 document_id + version + page + bbox。前端打开引用时重新做授权，不能直接发一个绕过权限的永久截图 URL。解析失败和 OCR 低置信度也要进入状态字段，让回答器可以选择拒答或请求上传清晰页面。

常见追问及答案：

• 为什么要保留原图？ OCR 可能错读数字、公式和手写内容，原图是复核和争议处理的依据。
• 版本只保存文件 hash 够吗？ 还应保存导入时间、解析器版本、权限快照和来源系统版本，否则无法解释同一文件为什么得到不同证据。

扣分点：只有一列 text；坐标没有坐标系；派生图片没有 ACL；更新时原地覆盖导致无法复现。

Q3：表格 RAG 和普通文本 RAG 的核心差异是什么？

考察点：是否知道表头、单位、类型和聚合不能靠相似度完成。

回答脉络：先指出行语义依赖表头，再讲多种表示和查询路径，最后说明数值验证。

详细参考答案：

表格的一行离开表头就失去意义，例如“华东 | 2026-Q2 | 125 | 1,250,000”必须知道列名、单位、币种、空值规则和季度定义。合并单元格、多级表头、脚注和百分比格式也会改变答案。

我会并存三种表示：表级 schema/摘要用于找到正确数据源；行级结构化记录用于过滤和引用；规范化行文本用于语义召回。问题“退款政策怎么规定”走文档检索；“哪个区域退款金额最高”先找到 schema，再由受限查询或计算服务排序，不让模型只看 top-k 文本自己猜全表最大值。

抽取时保存原始显示值和规范值，例如 ¥1.25M 与 1250000，同时记录币种、时区、精度和 OCR 置信度。计算结果由确定性代码完成，答案给出快照时间、中间值和行列引用。评估要覆盖表选择、列定位、单位一致性、聚合结果和越权，而不是只测文本相似度。

常见追问及答案：

• 能不能把每一行转成自然语言再 embedding？ 可以作为召回层，但必须保留结构化字段，并用 SQL/分析引擎做过滤、排序和计算。
• 跨币种求和怎么处理？ 先依据业务口径和汇率快照转换，缺少汇率或口径时拒答，不能让模型直接把数字相加。

扣分点：把表格当段落；让 LLM 负责精确聚合；不保存单位、主键和快照；不做行列级权限。

Q4：图片检索为什么不能只用整图 embedding？

考察点：是否能根据视觉对象和问题粒度选择表示。

回答脉络：列出整图、区域、OCR、caption 和结构化检测的互补关系，再讲召回融合。

详细参考答案：

整图 embedding 擅长主题和构图相似，例如“类似的设备照片”，但不保证能检索小区域的错误码、按钮状态或图表单位。图片系统通常同时保存整图 embedding、区域 embedding、OCR 文本、caption、对象检测坐标和图表结构化数据。检索时并行召回，再按 query-evidence 相关性、资产版本、来源可信度和权限重排。

命中后应把原图或必要裁剪区域交给支持视觉输入的模型，并要求它引用区域。caption 只作为辅助索引，不能替代原图；否则 caption 漏掉的小字、颜色和空间关系会被模型当成事实。相似图片的 hard negative 也很重要：设备外观相同，但版本号、指示灯颜色或图表单位不同，系统必须能区分。

人脸、车牌、工牌和屏幕截图可能含个人信息。索引前要分类、脱敏和设置资产级 ACL，缩略图本身也要受权限控制。

常见追问及答案：

• 图片 caption 有什么价值？ 便于自然语言粗召回、摘要和离线检索，但要标记为模型派生内容，不能当原始证据。
• 区域怎么切？ 由版面/目标检测/人工标注决定，保留父图坐标和裁剪版本；不要只按固定网格切图。

扣分点：把 caption 当真值；只用整图向量；不保留 bbox；忽略缩略图和图片派生物的权限。

Q5：多模态 RAG 的证据如何统一，避免生成层充满分支？

考察点：统一证据模型、定位字段和跨模态融合能力。

回答脉络：先给通用字段，再保留模态特有 payload，最后说明证据融合规则。

详细参考答案：

可以定义统一 Evidence：包含 evidence_id、modality、可读 content、structured_payload、source、locator、时间、授权决策、解析器版本和质量分数。文本定位可以是段落，PDF 是页码加 bbox，表格是表名加主键，代码是 commit 加行号，音频是媒体 ID 加起止时间，图片是资产版本加区域坐标。

通用字段用于引用、权限、缓存和审计，structured_payload 保留模态特有内容，例如表格数值、OCR token、关键帧或 ASR 置信度。融合时不能直接把 cosine、BM25、OCR confidence 和 SQL 精确结果相加，应先做各自质量过滤，再用 RRF 或统一 reranker，最后加上时间、来源和权限规则。

生成模型只接收通过授权和质量检查的证据，并被要求以 evidence_id 绑定声明。若证据冲突，保留来源和版本并显式说明；不要悄悄选一条“看起来最像”的结果。

常见追问及答案：

• 为什么不让模型自己编引用编号？ 模型可能漏号、重复号或引用不存在的来源；编号和 locator 应由服务端生成并校验。
• 视觉和文本证据冲突怎么办？ 检查版本、采集时间、OCR 置信度和来源权威性；无法裁决时输出不确定性并请求人工复核。

扣分点：每种模态一套完全不同协议；分数直接相加；引用不绑定版本和定位；不处理冲突。

Q6：复杂 PDF 中的表格、图表、公式和印章怎样处理？

考察点：是否能针对难点设计分流、复核和拒答策略。

回答脉络：先分类，再用专用抽取器，最后通过交叉校验和低置信降级。

详细参考答案：

先把页面分为文本、表格、图表、公式、印章/手写和混合区域，不同区域使用不同解析器。表格抽取要保留表头层级、跨页关系和单元格坐标；图表尽量恢复系列、坐标轴、单位和图例；公式保存 LaTeX 或结构化表达；印章和手写保留原图并只把识别结果作为低置信候选。

数值型内容应做一致性检查，例如表格列求和是否接近页脚总计、图表标签是否与 OCR 值一致、公式变量是否完整。冲突或低置信时，不应给出看似精确的答案，而应指出页码和区域并请求用户确认。解析器每次升级都要用固定版面回归集比较区域检测、表格结构和引用坐标。

常见追问及答案：

• 表格跨页怎么避免重复或漏行？ 用表格标题、列头和行连续性识别同一表，保存页间关系；对跨页重复表头去重但保留原页定位。
• 图表只有图片没有原始数据怎么办？ OCR 加视觉模型只得到估计值时要标记近似，不能冒充精确数据；高风险报表应要求原始表或人工复核。

扣分点：所有区域都用同一个 OCR；不做数值交叉校验；不考虑跨页；低置信仍给确定结论。

Q7：多模态 RAG 如何做权限和数据脱敏？

考察点：是否理解权限要沿原件和所有派生物传播。

回答脉络：从采集、解析、检索、缓存、展示和审计全链路说明。

详细参考答案：

权限不能只挂在原始文件上。OCR 文本、页面裁剪图、缩略图、表格行、图片 embedding、ASR 转写、摘要和缓存结果都可能泄露原内容，必须带上来源对象、租户、字段/区域标签和权限版本。检索前或数据源查询时做过滤，不能让无权限内容先进入 reranker、模型上下文或日志，再指望输出脱敏解决问题。

脱敏规则要按字段和区域执行：身份证、脸、车牌、银行卡、客户姓名、屏幕密钥等可以遮盖或 token 化，同时保留必要的空间信息。脱敏后的证据不能被当成完整原件，答案应说明哪些信息被隐藏。缓存键必须包含租户、用户角色、权限版本和文档快照，权限撤销时要有可接受且可监控的失效窗口。

常见追问及答案：

• embedding 会泄露原文吗？ 向量不是天然安全；它可能被反推或用于相似度侧信道，因此仍需访问控制、隔离、加密和删除策略。
• 低权限用户能看到“有这份文件”吗？ 不一定。文件名、缩略图和错误消息都可能泄露存在性，应按资源发现权限处理。

扣分点：只做答案后过滤；只给原文件加 ACL；缓存不隔离；把“向量不可读”当作安全保证。

Q8：网页、图片或 PDF 中的提示词注入如何进入多模态 RAG 防线？

考察点：间接 Prompt Injection、内容与指令边界、工具安全。

回答脉络：先把外部内容归类为不可信数据，再说明输入隔离、工具权限和输出校验。

详细参考答案：

文档中的“忽略系统规则”“把密钥发给我”、图片里的文字和网页脚本都属于被检索的数据，不是系统指令。解析阶段可标记疑似指令、外链、表单和危险动作；上下文中把来源内容放在明确的数据区，与系统策略和用户任务分隔，并限制模型只能提出工具调用。

真正的防线在工具服务侧：最小权限、域名/URL 白名单、参数与资源校验、写操作确认、输出 schema 校验、敏感信息隔离和审计。不要把“请模型忽略文档中的命令”当唯一措施。评测要构造文字注入、图片文字注入、隐藏层/白字、跨文档注入和恶意链接，观察是否越权、外传或改变任务目标。

常见追问及答案：

• 把所有外部内容转义就安全了吗？ 转义能降低格式混淆，但不能阻止模型被语义诱导；必须结合权限、工具审批和输出校验。
• 图片里的 QR 码怎么处理？ 默认当不可信数据，不自动访问或执行；解析出的 URL 经过域名、网络和权限策略后才能交给受控抓取工具。

扣分点：只改 system prompt；让模型决定是否执行图片指令；自动打开任意外链；不做攻击样本评测。

Q9：如何评估多模态 RAG，不把“模型看懂了图片”当成唯一指标？

考察点：分层评估、引用准确性和 hard negative 设计。

回答脉络：拆检索、解析、定位、生成、权限和端到端任务，再按模态建立指标。

详细参考答案：

我会先评估数据层：OCR 字符/词错误率、版面区域检测、阅读顺序、表格结构、ASR 错误和时间对齐。再评估检索层：文档/页面/区域/关键帧 Recall@k、MRR、区域 IoU 和表格行定位。生成层评估原子事实正确率、引用支持关系、引用完整性、低置信拒答和单位一致性。系统层增加权限暴露率、P95/P99 延迟、成本和索引更新时延。

测试集要有 hard negative：外观相同但版本号不同的设备图、相同表格但币种不同的页面、OCR 易混淆的数字、跨页重复表头、相同发言人的音频和无答案样本。每个结论绑定可验证 evidence ID，不能只用 LLM judge 评价流畅度。

常见追问及答案：

• 为什么不能只测 VQA 准确率？ VQA 数据集不覆盖企业 ACL、版本、引用、脱敏、注入和实时更新；它只能补充能力测试。
• 区域引用怎么验？ 同时验页面/帧是否正确、bbox 是否覆盖支持内容、前端高亮是否对齐和用户是否有权访问。

扣分点：只报最终准确率；没有定位和权限指标；没有 hard negative；忽略成本与尾延迟。

Q10：多模态索引如何增量更新、回滚和保持引用稳定？

考察点：版本化索引、派生物一致性和发布治理。

回答脉络：先定义不可变快照，再讲异步构建、原子切换、差异验证和回滚。

详细参考答案：

原始文件、解析结果、embedding 和视觉派生物都应带 source_version。更新时先写入新的不可变快照，异步完成 OCR、版面、表格、图片和向量构建，跑 schema、ACL、引用坐标和回归评估，再通过索引别名或版本指针原子切换。旧版本在保留窗口内继续可查询，引用中的版本 ID 保证历史答案能复现。

部分区域解析失败时不要悄悄覆盖旧索引；可以按区域保留上一版并标记混合状态，或阻止发布。回滚不仅切回向量索引，还要切回解析器配置、权限快照和证据服务版本。删除请求要能传播到原件、派生物、缓存、日志索引和备份保留策略。

常见追问及答案：

• 为什么不能原地更新向量？ 容易出现文本、向量、图片和 ACL 版本不一致，导致引用和权限难以复现。
• 新文档何时可见？ 以可验证的索引发布事件为准，向用户显示 indexed_at 或生效时间，不要把上传成功当成已经可检索。

扣分点：只更新向量库；没有快照和别名切换；失败时部分覆盖；回滚只恢复模型不恢复证据链。

二、实时语音交互链路

Q11：实时语音助手的端到端链路如何拆解？

考察点：是否能建立从音频到语音的状态和时延预算。

回答脉络：按 VAD、ASR、理解/检索、LLM、工具、TTS、播放和观测拆解，并说明并行关系。

详细参考答案：

典型链路是：客户端采集音频；VAD 判断开始和结束；音频帧通过 WebRTC 或 WebSocket 上传；流式 ASR 产生 interim/final transcript；对稳定片段做意图识别、检索或工具准备；LLM 生成文本增量或动作；TTS 把文本增量转为音频；客户端边收边播，同时处理打断和取消。

不要把所有步骤串行等待。ASR 产生稳定前缀时可以预取检索；LLM 输出句子边界后即可启动 TTS；工具读操作可以与后续准备并行，写操作仍需确认。链路事件带 turn_id、sequence、时间戳和模型/版本信息，方便区分“用户没说完”“模型慢”“TTS 缓冲”到底耗时在哪里。

时延预算至少拆为采集与上行、ASR 首字、LLM 首 token、工具等待、TTS 首音频和播放缓冲。目标不是只优化总时长，而是降低用户听到第一段有效反馈前的等待，并保证最终答案正确。

常见追问及答案：

• 为什么先等 final transcript？ 会增加停顿；可以用 interim 预测或预取，但真正执行高风险动作必须等待稳定文本和确认。
• 语音助手一定要用端到端语音模型吗？ 不一定。VAD+ASR+LLM+TTS 更容易替换、调试和审计；端到端模型可能降低延迟但增加可观测和局部控制难度。

扣分点：只说“语音转文字再调用 LLM”；不提流式、并行、turn 状态和打断；只看总耗时。

Q12：VAD 如何影响实时体验？端点检测应该怎样设计？

考察点：语音起止判断、误切和尾延迟的权衡。

回答脉络：先说明 VAD 的输入输出，再讲 hangover、静音阈值、噪声和业务场景调参。

详细参考答案：

VAD 不只是一个布尔函数，它要输出语音概率、开始时间、结束候选和可能的噪声状态。过于激进会把一句话切成多段，过于保守会在用户说完后等待太久。常见做法是使用起始阈值、结束阈值和 hangover 时间：连续若干帧超过起始阈值才开始一轮；结束后保留少量尾部音频，等待短暂静音确认。

不同场景要不同策略：客服问答可以偏快；数字、地址和姓名需要更长尾部并结合 ASR 稳定性；车载环境要处理风噪和音乐；多人会话要配合说话人或回声消除。端点事件应可取消，如果用户在 hangover 期间继续说话，恢复当前 turn 而不是生成空答案。

常见追问及答案：

• 只用固定 500ms 静音阈值可以吗？ 不稳健。噪声、语言、用户习惯和网络抖动不同，应基于 VAD、ASR 稳定度和场景动态调整。
• VAD 误判如何评估？ 记录语音起止偏差、误触发率、漏检率、切分导致的 ASR 错误和额外等待，按环境分桶。

扣分点：把 VAD 当简单开关；不处理噪声、回声和用户续说；没有起止偏差指标。

Q13：流式 ASR 的 interim 和 final 结果如何使用？

考察点：部分结果、修订、稳定前缀和下游副作用控制。

回答脉络：区分可变文本和已确认文本，再讲预取、展示和提交边界。

详细参考答案：

interim 是可能被后续音频修订的猜测，final 是 ASR 服务确认的片段，但 final 也可能因分段策略存在轻微边界调整。客户端展示可以实时更新 interim；服务端可以用稳定前缀预取检索、准备候选工具，但不能据此执行退款、发消息或修改数据等副作用。

每个结果带 turn_id、segment_id、revision、文本、时间范围和置信度。下游维护可回滚的草稿状态：新 revision 替换尚未提交的区间，只有在端点确认和业务校验后才提交任务。实体如金额、账号和地址要做格式校验，低置信时请求用户重复确认。

常见追问及答案：

• interim 预取错了怎么办？ 预取结果绑定 revision，revision 变化就取消或标记过期；预取不能产生不可逆副作用。
• ASR 说错一个数字怎么避免？ 使用数字/实体专门后处理、上下文词表和读回确认，关键字段让用户确认后再执行。

扣分点：把 interim 当最终事实；没有 revision；预取直接触发写工具；不校验敏感实体。

Q14：LLM、工具和 TTS 如何流水线化，又不让用户听到错误内容？

考察点：增量生成、句子边界、工具状态和可撤回输出。

回答脉络：先区分可播报文本和内部草稿，再讲工具调用边界、TTS 分片和错误收口。

详细参考答案：

LLM 可以流式输出，但不能每个 token 都直接送 TTS。服务端应维护文本缓冲，按标点、长度和语义稳定性形成可播报片段；低风险闲聊可以较早播报，高风险事实先完成检索和校验。工具调用是内部状态，工具结果返回后重新生成或修正文本，不能让 TTS 抢先承诺“已经退款”。

TTS 使用带序号的音频 chunk，客户端按序播放并支持丢弃尚未播放的 chunk。每个 chunk 绑定 turn_id 和文本版本；如果工具失败或用户打断，只播放到安全边界并发送 cancel。对涉及价格、时间、数量和动作状态的句子，最好在播报前做结构化校验或使用模板。

常见追问及答案：

• 先播“我来查一下”是否安全？ 这是低承诺的进度反馈，可以先播；不要在事实尚未确认前播报结果和完成承诺。
• TTS 生成后发现事实错了怎么办？ 停止未播放音频，发送纠正或转人工；记录已播放内容，不能假设用户没有听到。

扣分点：token 到一段音频直接播放；工具结果未返回就承诺；没有音频版本和取消机制。

Q15：实时语音中的打断（barge-in）怎么实现？

考察点：全链路取消、播放状态与新旧 turn 隔离。

回答脉络：先检测打断，再取消生成/工具/TTS/播放，最后建立新 turn 并处理已发生副作用。

详细参考答案：

打断通常由客户端检测到用户语音、服务端 VAD 检测到上行音频，或用户点击停止。收到 interrupt(turn_id, reason) 后，服务端要取消该 turn 的 LLM 流、TTS 任务、未开始的工具调用和网络发送；客户端立即清空待播放音频并停止当前播放器。所有异步任务使用取消令牌和 fencing/版本号，迟到结果即使到达也不能写回当前会话。

关键是区分“已播放”“已执行但结果未知”和“尚未执行”。读操作通常可以取消；写操作如果已经提交，不能假装撤销，应查询状态、返回处理中或走补偿流程。新 turn 使用新的 turn_id，但可继承明确的会话状态和未完成任务引用。打断事件、已播放文本和副作用状态都要审计。

常见追问及答案：

• 取消 HTTP 请求就够了吗？ 不够。下游模型、TTS、工具、队列和播放器都可能继续运行，必须传播取消并拒绝迟到写入。
• 用户说“停”时工具已经扣款怎么办？ 查询业务状态并进入人工/补偿流程，不要重复扣款或声称取消成功。

扣分点：只在前端停播放；没有 turn 版本；忽略已提交副作用；迟到结果可以覆盖新回答。

Q16：如何处理实时语音中的“半句话”和多轮上下文？

考察点：turn 状态、指代解析、上下文裁剪和可恢复会话。

回答脉络：定义 turn 状态机，再讲草稿、确认和上下文摘要。

详细参考答案：

我会把 turn 分为 LISTENING、PARTIAL、FINALIZING、THINKING、SPEAKING、INTERRUPTED、COMPLETED、FAILED 等状态。半句话只存在于当前 turn 草稿，不应污染长期记忆；用户停顿后继续说，要根据 VAD/ASR 的窗口决定是否合并，而不是每次停顿都提交。

跨轮上下文只保留已确认的用户意图、实体、工具结果和必要摘要，原始音频与完整转写按保留策略存储。指代如“把它改成明天”要先解析当前对象和时间，再在工具侧验证对象归属。网络断线恢复时，客户端带最后确认的事件序号，服务端返回权威 turn 状态和可继续的文本/音频边界。

常见追问及答案：

• 短暂静音要不要马上结束 turn？ 不一定。对自然对话保留短暂合并窗口，对命令型场景可以更快结束；调参要看切分错误和尾延迟。
• 完整录音都放上下文可以吗？ 会增加成本和隐私风险。应保存结构化摘要、必要证据和可回溯引用，按权限取原始内容。

扣分点：只有一个 isSpeaking 布尔值；半句话直接写长期记忆；上下文无限增长；断线后从头重放造成重复副作用。

三、WebSocket、SSE 与 WebRTC

Q17：实时语音为什么常用 WebRTC，而不是只用 WebSocket？

考察点：传输层能力、媒体时延和系统复杂度权衡。

回答脉络：比较媒体传输、网络适应、安全和服务端处理，再给场景选择。

详细参考答案：

WebSocket 是可靠的双向消息通道，适合发送 JSON 事件、文本 token、工具状态和音频帧，服务端实现简单。WebRTC 面向实时媒体，提供 RTP、抖动缓冲、丢包恢复、拥塞控制、回声消除和 NAT 穿透，适合持续上行/下行音频和低延迟通话。

选择取决于场景：浏览器到自有语音服务、音频量可控且需要统一事件时，可以 WebSocket 搭配二进制 PCM/Opus；多人通话、弱网、双向媒体和自然打断更适合 WebRTC，控制面仍可用 HTTPS/WebSocket。WebRTC 不会自动解决业务状态、权限、录音保留和工具安全，媒体面与控制面要分开授权和审计。

常见追问及答案：

• WebRTC 里还能用 WebSocket 吗？ 可以。信令、会话控制和业务事件常走 HTTPS/WebSocket，音频媒体走 WebRTC。
• 为什么不能只看平均网络延迟？ 语音体验受抖动、丢包、缓冲增长和重传影响，应看首音频、连续播放、卡顿和端到端尾延迟。

扣分点：把 WebRTC 说成更快的 WebSocket；不提 NAT、拥塞和回声；忽略控制面安全。

Q18：SSE、WebSocket 和轮询如何选择？

考察点：通信方向、代理兼容、断线恢复和业务语义。

回答脉络：先按数据流方向和实时要求分类，再讲重连、背压和基础设施限制。

详细参考答案：

SSE 是服务端到客户端的单向文本事件流，浏览器重连语义简单，适合任务进度、文本 token 和通知；客户端上行可以另走 HTTPS。WebSocket 是双向长连接，适合语音帧、打断、实时状态和双向控制，但需要自己设计心跳、重连、背压和事件序号。轮询实现最简单，适合低频状态查询或不支持长连接的环境，不适合高频 token/音频。

无论哪种方式，重要事件都应先持久化，带 event_id/sequence 和 schema 版本。SSE 可用 Last-Event-ID 或业务 cursor 补发；WebSocket 重连后显式发送最后确认序号。代理缓冲、空闲超时、最大消息、压缩和连接数都要压测；不能把“连接还在”当成事件已送达。

常见追问及答案：

• SSE 能传音频吗？ 可以编码但效率差，通常不适合持续二进制媒体；音频使用 WebRTC 或 WebSocket 二进制帧更合适。
• 断线重连会不会重复播报？ 客户端根据事件序号和音频 chunk 序号去重，服务端区分可重放事件和一次性副作用。

扣分点：只按“实时/不实时”选择；没有事件序号和补发；不考虑代理缓冲和重复消费。

Q19：实时流式接口如何设计事件协议？

考察点：事件顺序、幂等、版本和客户端兼容。

回答脉络：给出统一 envelope，再区分 transcript、text、audio、tool 和状态事件。

详细参考答案：

事件 envelope 至少包含 event_id、session_id、turn_id、sequence、type、schema_version、created_at 和 payload。payload 例如 transcript.partial、transcript.final、response.text.delta、response.audio.chunk、tool.started、tool.result、turn.interrupted、error。sequence 在单一 turn 内单调递增，跨连接可通过持久化事件表恢复。

客户端不能假设每个 delta 都到达或只到达一次：文本按版本合并，音频按 chunk 序号播放，tool 结果按 tool_call_id 去重。事件 schema 采用向后兼容策略，未知事件可以安全忽略并通过状态查询补齐。错误事件要区分可重试、需用户操作、权限拒绝和未知提交状态。

常见追问及答案：

• 为什么还要有状态查询接口？ 流连接可能断开、事件丢失或客户端崩溃，状态查询提供权威快照，不依赖日志重放。
• sequence 和时间戳哪个能排序？ sequence 用于业务顺序，时间戳用于观测；分布式节点时钟不可靠，不能只按时间戳排序。

扣分点：事件只有字符串 message；没有 schema/version；把网络送达当业务成功；没有权威状态查询。

四、取消、重连、人工接管与可靠性

Q20：实时会话断线重连如何做到不丢状态、不重复执行？

考察点：会话持久化、事件重放、幂等和未知状态。

回答脉络：区分客户端临时断线与服务端任务状态，再讲 cursor、租约和写操作状态查询。

详细参考答案：

会话的权威状态不能只在 WebSocket 内存中。turn、已确认 transcript、工具调用、审批、音频播放边界和最后事件序号写入持久化存储。客户端重连时提交 session_id、认证上下文和最后确认的 sequence，服务端校验权限后补发可重放事件，并返回当前快照。

工具调用使用幂等键，例如 session_id + turn_id + tool_call_id。断线时如果写请求结果未知，不要直接重试；先查询业务状态或使用幂等提交接口。长任务用租约和 fencing token 防止旧 Worker 迟到写入。音频可以从安全边界重新播放，但必须避免把已经听过的副作用确认重复播报成新成功。

常见追问及答案：

• 重连后能否让模型继续生成？ 可以，但要用可恢复的 checkpoint 或重新根据权威状态生成，不能把可能重复的临时 token 当事实。
• 客户端没有保存 cursor 怎么办？ 服务端可以从最近确认的 turn 状态重新同步；必要时提示用户从当前状态继续，而不是盲目重放全部动作。

扣分点：把连接当会话；重连直接重跑工具；没有幂等键；不处理未知提交状态。

Q21：实时助手什么时候应该转人工？转人工时传什么？

考察点：风险分级、上下文交接和人工可操作性。

回答脉络：先定义触发条件，再讲最小必要交接包和权限继承。

详细参考答案：

转人工触发包括：高风险动作需要审批、用户明确要求、连续低置信或多次失败、情绪/投诉信号、权限争议、工具状态未知、实时 SLA 即将超时和检测到安全攻击。转人工不是简单把完整聊天记录复制过去，而是生成结构化交接包：用户与租户（按坐席权限脱敏）、目标、已确认事实、证据 ID、已执行工具及结果、未完成步骤、风险、待用户确认项和录音/转写引用。

人工接管后，Agent 的自动写权限应暂停或降级，避免人与 Agent 同时操作。坐席可以继续查询，但敏感内容仍按 RBAC/ABAC 过滤。交接事件带版本和责任人，人工结果回写任务状态；若恢复自动化，必须重新确认边界，不能沿用过期批准。

常见追问及答案：

• 为什么不把完整录音都给坐席？ 可能超出权限和保留范围，且噪声大；按需提供时间片和证据引用更可控。
• Agent 已经说错了怎么办？ 交接包明确标记未确认和可能错误的内容，坐席不能把模型猜测当事实。

扣分点：转人工只是一个按钮；没有交接状态；自动化权限未暂停；把完整敏感记录无差别转发。

Q22：如何给实时交互做时延、质量和成本评估？

考察点：实时指标分解、用户体验和多目标取舍。

回答脉络：分别讲音频体验、语义质量、可靠性、安全和成本，按分位数与场景分桶。

详细参考答案：

实时语音不能只看平均响应时间。关键指标包括：用户停止说话到 ASR final 的延迟、首个文本 delta、首个有效音频（TTFA）、首个可理解词、端到端 turn 完成时间、音频卡顿率、打断响应时间、VAD 起止偏差、ASR WER/CER、工具成功率、转人工率和任务成功率。所有延迟至少看 P50/P95/P99，并按设备、网络、语言、场景和是否调用工具分桶。

成本包括 ASR 音频时长、LLM 输入/输出、视觉或检索调用、TTS 音频、连接和存储。可以用低成本模型做 VAD/路由，复杂任务升级；但不能为了首音频快而播报未经验证的事实。线上还要监控断线率、重连恢复率、权限拒绝、敏感内容拦截和用户投诉。

质量评估要包含无答案、噪声、口音、数字实体、打断、工具超时、注入和人工接管样本。发布门禁先看安全和副作用，再看任务成功率、TTFA 和成本，不用一个加权平均数掩盖高风险退化。

常见追问及答案：

• TTFA 和 TTFT 有什么关系？ TTFT 是生成首个文本 token 的时间；TTFA 是用户获得首个可播放音频的时间，还包含 TTS 和播放缓冲，二者不能混用。
• 用户觉得快但任务错了能接受吗？ 不能。快速反馈可以是低承诺进度提示，任务结果必须经过证据和业务校验。

扣分点：只报总耗时或平均值；忽略首音频、打断和卡顿；不按场景分桶；为了延迟牺牲正确性和安全。

五、综合系统设计题

Q23：设计一个支持“看合同、问表格、语音追问”的企业助手。

考察点：多模态路由、统一证据、权限和实时会话的组合设计。

回答脉络：先画数据与请求链路，再分别落到离线入库、在线路由、引用、安全、实时层和评估。

详细参考答案：

离线侧接入合同 PDF、Excel、图片和音频，保存不可变原件快照；PDF 经过版面/OCR/表格解析，Excel 保留 schema 和类型，图片建立 OCR/区域/整图索引，音频建立 ASR、说话人和时间轴。所有派生物统一成带 evidence_id、版本、locator、时间和 ACL 的证据对象。

在线侧先认证用户和租户，解析文本或 ASR transcript，路由到文本、表格、SQL、视觉或音视频检索器，结果经权限过滤、去重、质量检查和 rerank 后组装上下文。金额计算由结构化工具完成；合同条款引用页码和 bbox；图片引用资产和区域；会议结论引用媒体时间段。生成器输出声明与 evidence ID 的绑定。

语音层使用 WebRTC 或 WebSocket 传媒体，SSE/WebSocket 传状态；VAD/ASR 流式处理，LLM/TTS 流水线化，所有 turn、工具调用和音频 chunk 带序号。打断传播取消令牌，写操作需要读回确认和用户确认。重连按 cursor 恢复，未知副作用先查状态。

部署前用固定版面、权限、注入、噪声和实时回归集验收，线上看引用完整性、未授权暴露率、TTFA、ASR 错误、工具成功率、断线恢复和成本。索引和模型均版本化，支持灰度和回滚。

常见追问及答案：

• 为什么不让一个大模型处理全部输入？ 路由可以控制成本、权限和可解释性；不同模态的解析、定位和计算需求不同。
• 如果引用对象被删除怎么办？ 证据服务返回已删除/不可访问状态，答案应失效或重新检索，不能保留一个无权限的旧截图 URL。

扣分点：只有“上传文件+多模态模型”；没有离线版本和权限；语音与 RAG 各自孤立；不讲打断、重连和评估。

Q24：上线后发现语音助手“很快但经常答错数字”，你如何排查？

考察点：跨 ASR、解析、检索、生成和播放的证据链定位。

回答脉络：先冻结样本和版本，再逐层对比原音频、转写、证据、工具结果和最终播报。

详细参考答案：

先按 session_id + turn_id + trace_id 固定问题，保留原始音频访问权限和版本信息，确认错误数字出现在哪一层：VAD 是否截断；ASR 是否把“十五”识别成“十五万”；实体后处理是否改错；表格/SQL 结果是否正确；LLM 是否重新计算；TTS 是否读错；客户端是否把旧 chunk 播放出来。

对数字场景建立结构化校验：金额、日期、百分比、账号等进入 typed slots，和证据或工具结果比对。若 ASR interim 触发了预取，检查 revision 取消是否失效；若最终工具结果正确但播报错误，检查文本到 TTS 的版本和缓存。修复后按语言、噪声、说话速度、数字长度和模型版本分桶回归，不能只挑一个成功样本。

短期可以把数字和高风险结果改成读回确认或模板播报，牺牲少量延迟换正确性；长期需要改进词表、ASR 后处理、证据绑定和发布门禁。

常见追问及答案：

• 为什么不直接换更大的 ASR？ 先定位错误层；若是 TTS 缓存或旧 turn 覆盖，换模型不能解决系统竞态。
• 如何证明修复没有让体验变慢？ 同时比较 WER、数字准确率、TTFA、任务成功率和转人工率，按场景报告分布。

扣分点：只改 prompt 或只换模型；不保留链路版本；不区分 ASR、LLM 和 TTS 错误；没有回归数据。

Q25：如何设计多模态与实时系统的降级策略？

考察点：在模型、网络、解析器和工具失败时安全收口。

回答脉络：按失败层级给降级，先保证安全和可解释，再谈可用性。

详细参考答案：

视觉模型不可用时，可以退回 OCR/文本检索，但要明确“未验证图像细节”；OCR 低置信时返回页面引用并请求用户上传清晰图；TTS 不可用时返回文本；WebRTC 不可用时切换 WebSocket/HTTPS，但降低媒体体验；实时工具超时时返回当前已验证状态和人工入口，不把未知状态说成失败或成功。

降级策略必须受权限和风险约束。不能因为视觉不可用就把原图交给未授权模型，不能因为语音识别不确定就执行敏感动作。每次降级写入原因、版本和用户可见提示，设置超时、熔断和恢复探测。高风险任务宁可拒答/转人工，也不应使用未经验证的猜测路径。

常见追问及答案：

• 降级到更小模型是否总是安全？ 只对已评估的低风险任务开放；权限、工具和输出校验不能随模型变弱而取消。
• 网络恢复后如何恢复实时会话？ 使用持久化状态和 cursor，先同步权威状态，再决定继续、重播或要求用户确认。

扣分点：降级就是“换一个模型”；不区分读写风险；未知状态直接报失败；没有恢复和审计。

Q26：如果让你制定这类系统的发布门禁，你会放哪些硬指标？

考察点：能否把架构原则落实为可执行验收。

回答脉络：先列零容忍安全项，再列质量、实时性、可靠性和成本阈值，并说明分层和回滚。

详细参考答案：

硬门禁包括：未授权文档、图片、音频和跨租户证据暴露率为零；高风险工具未经确认执行次数为零；引用必须指向存在且用户可访问的版本；已取消 turn 的迟到结果不能覆盖新 turn；幂等写操作不能重复提交；敏感日志和录音按策略脱敏。

质量门禁按场景设定，例如 PDF 区域引用准确率、表格数值准确率、数字实体准确率、ASR WER、工具任务成功率、无答案拒答率和人工交接正确率。实时门禁包括 TTFA P95、打断响应 P95、断线恢复率、音频卡顿率和长连接错误率。成本门禁看每分钟音频成本、每任务 token、TTS/视觉调用和重试。

所有指标按语言、设备、网络、租户、模型/解析器版本和风险等级分桶；高风险小流量不能被总体平均掩盖。候选版本先跑 smoke、回归、攻击、权限、故障注入和灰度，失败时通过索引/模型/服务版本指针回滚，并保留事故证据。

常见追问及答案：

• 阈值由谁决定？ 业务、工程、安全和合规共同确认；工程负责可测量和可回滚，不能单方面用平均值拍板。
• 指标波动但没有明显事故怎么办？ 看置信区间和分桶趋势，必要时暂停扩量并抽样人工复核，不要只等用户投诉。

扣分点：只有准确率和平均延迟；没有安全零容忍项；不按版本/场景分桶；没有灰度和回滚。