2025-08-22 模拟面试（六）

大模型应用方向

1. 在问答中，如何实现流式回答

流式回答能够让用户看到字是一个一个蹦出来的，体验非常友好，核心技术其实就是 ReadableStream 温馨提示：可以使用微软封装好的流式库@microsoft/fetch-event-source

一、什么是 ReadableStream？

它是一个表示异步数据流的对象。数据从一个“源”源源不断的产生，而你可以按照顺序，分块地（chunk by chunk）读取和处理这些数据，而不需要等所有数据都加载到内存中。

二、核心概念与工作原理

ReadableStream 背后有三个核心角色协同工作：

  1. 底层源

    1. 这是数据的真正生产者。对于 fetch 来说，底层源就是网络套接字。
    2. 它有一个方法 start，当流被创建时自动调用。源在这里开始生产数据。
    3. 它通过一个 ReadableStreamDefaultController 对象将生产出的数据塞入流中，或者在数据生产完毕时关闭工作流，或者异常的时候发出错误的信号

  2. 消费者（也就是前端）：

    1. 通过调用 Stream.getReader()创建一个读取器（Reader），这个读取器会锁定这个流。
    2. 读取器提供了一个核心方法：reader.read()。它返回一个 Promise.resolve 后得到一个包含（value，done）的对象。

  3. 队列

    1. 这是一个内部的缓冲区，如果生产者生产的数据速度快于消费者处理的速度，数据会暂时存放在队列中，从而实现“背压”管理。
三、高级用法与技巧
  1. 有时候用户想停止回答，这时候需要将流停止掉
  2. 一般可以和后端约定好使用 done 关键字来处理流式完毕后的效果
  3. 建立连接，接受数据会有一段时间，可以先在页面上动态显示......，一旦数据传输就立即渲染接受到的数据

2. 在问答中，如何实现流式录音

流式录音的核心是浏览器的 MediaDevices API 和 MediaRecorder API

  1. 获取音频流（MediaDevices.getUserMedia()）：首先从用户的麦克风回去一个实时的音频数据量（MediaStream）。
  2. 录制音频流（MediaRecorder）：然后使用 MediaRecorder 对象来录制这个 MediaStream。
  3. 处理数据块（ondataavailable 事件）：MediaRecorder 的核心在于，它不会一次性给你一个完整的录音文件。相反，它会按照你设定的时间间隔（timeslice）或当数据块达到一定大小时，不断地触发 ondataavailable 事件，并提供一个包含音频数据的 Blob 对象（通常编码为 webm 或 wav 片段）。
// 1. 获取麦克风权限和音频流
const stream = await navigator.mediaDevices.getUserMedia({ audio: true });

// 2. 创建 MediaRecorder 实例，指定编码格式
mediaRecorder = new MediaRecorder(stream, {
  mimeType: "audio/webm;codecs=opus",
});

// 3. 定义数据处理函数：当有数据可用时触发
mediaRecorder.ondataavailable = (event) => {
  if (event.data.size > 0) {
    // 方案A: 实时上传每一个数据块到服务器
    uploadAudioChunk(event.data);
  }
};

mediaRecorder.onstop = () => {
  console.log("录音停止");
};

// 4. 启动录音器，并设置每 1000ms（1秒）产生一个数据块
mediaRecorder.start(1000); // timeslice 参数是关键！
挑战与注意事项

  1. 服务器端拼接：方案一需要服务器端能够接收无序到达的音频块，并能根据 session_id 等标识符将它们正确拼接成一个完整的音频文件。这比听起来要复杂。

  2. 格式兼容性：audio/webm 格式兼容性很好，但如果你需要 mp3 等格式，可能在浏览器内无法直接录制，需要服务器转码或使用专门的库（如 lamejs 编码 PCM 数据）。

  3. 错误处理与重试：网络可能不稳定，上传某个音频块可能会失败。需要决定是重试、跳过还是中止整个录音过程。

  4. 内存管理：如果选择在客户端存储所有块（audioChunks 数组），长时间录音会导致内存占用过高。真正的流式应该录一块、传一块、丢一块。

  5. 流式录音无法在 http 环境下使用，需升级至 https

3. 在问答中，如何实现文字播报

前端实现 TTS 主要有三种方案，其选择取决于对音质、成本、延迟和隐私的要求。

方案一：使用浏览器原生 Web Speech API。最快捷的方式，无需网络请求，直接在用户浏览器中合成语音。

// 可以设置音量大小，中英文，语速等
// 创建 SpeechSynthesis 实例
const synthesis = window.speechSynthesis;
// 创建一个话语对象
const utterance = new SpeechSynthesisUtterance(text);
// 开始播放
synthesis.speak(utterance);

优点：

  1. 零成本：无需支付任何 TTS API 费用。
  2. 极低延迟：本地合成，无需网络传输。
  3. 隐私性好：文本内容不会离开用户设备。 缺点：
  4. 音质 robotic：声音机械感强，不够自然动听。
  5. 语音有限：可选音色（Voice）取决于用户操作系统和浏览器，质量参差不齐。
  6. 控制力弱：对语音的情感、风格等控制极其有限。
  7. 错误：对于表情符号则会直接读符号

方案二：使用第三方 TTS API（音质最佳） 将大模型生成的文本发送到专业的 TTS 服务商（如科大讯飞, OpenAI TTS, ElevenLabs, Azure Speech, Google Cloud TTS），获取高质量音频流返回前端播放。 核心关键点：将一段话分割成 N 块，分片传输给服务商，这样体验效果更佳，不至于等待久，延迟多。难点就是如何断句发送，不然会有分裂感

优点：

  1. 音质顶级：声音自然、富有表现力，接近真人。
  2. 高度可控：可选择不同音色、语种、语速，甚至情感风格（ ElevenLabs 等）。
  3. 功能强大：支持 SSML（语音合成标记语言），实现更精细的控制（如停顿、强调、读音）。

缺点：

  1. 产生费用：按字符数或请求次数收费。
  2. 网络延迟：需要额外的网络请求。
  3. 隐私问题：文本内容需要发送给第三方。

4. 在大模型的图像管理中，如何实现图像标注

图像识别主要是大模型处理，其实和前端感知并不大。前端要做的就是拿到大模型返回的图片识别相关数据，一般会有特征坐标。前端拿到特征坐标就可以绘制一个跟图片一模一样的 div 框，同时可以用 span 进行标注

优点： 极其简单：使用基础的 HTML 和 CSS 即可。 天然可交互：每个框和标签都是独立的 DOM 元素，可以轻松添加 hover、click 事件，并利用 CSS 过渡（transition）实现平滑动画效果。 易于调试：可以直接在浏览器开发者工具中检查和修改每个元素的样式。 缺点： 性能极差：如果识别对象很多（几十上百个），会产生大量 DOM 元素，导致页面重绘缓慢，内存占用高，比较卡顿。 坐标缩放复杂：需要处理图片缩放后的坐标映射，如果需要处理图像拖动，那么更加复杂和可能性的卡顿。

其他可能性方案：

  1. canvas，数据较多，不需要无损缩放，学习成本较高
  2. svg 需要无损缩放，学习成本比较高
  3. WebGL 数据量庞大，学习成本陡峭

4. 在大模型的 pdf 管理中，如何实现 pdf 关键字/词/句的标注

核心挑战

  1. 文本与坐标的提取：PDF 中的文字位置信息（坐标）不是天然暴露的，需要解析 PDF 文件来获取。
  2. 多页处理：PDF 是多页文档，标注系统需要能跨页、分页处理。
  3. 精准定位：如何将大模型返回的“第 X 段”或“某个词”的描述，精准地映射到 PDF 页面上的具体坐标。
  4. 渲染与交互：PDF 通常以 canvas 或 iframe 方式渲染，在其上叠加交互式标注层需要精巧的设计。

方案一：基于文本节点（Text Layer）的标注（推荐用于文本高亮） 这是最常见和精准的方案，尤其适合基于文本内容的标注（如高亮、下划线、划词翻译）。值得注意的是：pdf 会缩放，所以标注也需要同步处理，也是一笔不小的开销

工作原理：

  1. 使用 PDF 渲染库（如 pdf.js）渲染 PDF，并启用文本层。
  2. 库会为每个文本字符生成一个透明的 span 元素，并精确定位。这些 span 共同构成了可选择的文本层。
  3. 大模型返回的结果是文本片段（例如：“本合同第 3 条第 2 款所述的内容”）或关键词列表。
  4. 前端在文本层中搜索这些文本片段，找到对应的 DOM 节点，获取其位置和尺寸。 根据找到的节点位置，在其上方绘制标注（用 div 绝对定位或操作 CSS）。

优点：

  1. 精度极高：直接基于文本坐标，标注位置分毫不差。
  2. 可交互性强：标注与文本关联，易于实现点击、悬停显示详情等交互。
  3. 支持文本选择：用户仍然可以选中和复制底层文字。

缺点：

  1. 依赖文本层：如果 PDF 是扫描件（图片型 PDF），没有内嵌文本层，此方法失效。 性能考虑：
  2. 对于超长文档，遍历所有文本项可能有一定开销。

results matching ""

    No results matching ""