vault backup: 2026-06-12 11:20:09

2026-06-12 11:20:09 +08:00
parent 5dd1256f09
commit 7e0c2a25b5
5 changed files with 493 additions and 0 deletions
--- a/视觉对话助手.md
+++ b/视觉对话助手.md
@@ -0,0 +1,43 @@
+---
+tags: [AI, 多模态, 对话系统, 视觉, 语音交互, 端云协同]
+create time: 2026-06-12 11:13
+---
+
+# AI 视觉对话助手
+
+## 概述
+
+开发一款**多模态实时对话应用**——通过摄像头与麦克风捕获用户的视觉场景与语音输入，由 AI 理解并给出自然、流畅的回应。核心挑战在于视觉理解的准确性、语音交互的自然度，以及端云协同下的成本控制。
+
+## 正文
+
+### 需求拆解
+
+将原始需求拆解为三个技术维度：
+
+| 维度       | 关键问题                     | 详见 |
+| -------- | ------------------------ | ---- |
+| **视觉理解** | 如何准确理解摄像头画面中的人物、物体、场景？   | [[AI 视觉对话助手/视觉理解]] |
+| **语音交互** | 如何让对话像真人交流一样自然、低延迟？      | [[AI 视觉对话助手/语音交互]] |
+| **成本控制** | 实时视频流 + LLM 推理，如何避免账单爆炸？ | [[AI 视觉对话助手/成本控制]] |
+
+> [!question] 思考
+> 这三个维度之间存在天然的张力——提升视觉精度意味着更高分辨率和更频繁的采样，但这会直接推高带宽和推理成本。如何在设计中做好取舍？
+
+### 项目目标
+
+1. **[[AI 视觉对话助手/用户故事|用户故事规划]]**：明确"AI 能看、能听、能说"需要覆盖哪些场景
+2. **[[AI 视觉对话助手/成本控制|成本控制策略]]**：从架构设计层面融入运营成本意识
+
+### 需交付物
+
+- 可运行的应用程序（摄像头 + 麦克风 → AI 回应）
+- 设计文档，覆盖：
+  - 计划实现 vs 最终实现的用户故事
+  - 成本控制技巧的构思 vs 实际采用的方案
+
+## 关联笔记
+- [[AI 视觉对话助手/视觉理解]]
+- [[AI 视觉对话助手/语音交互]]
+- [[AI 视觉对话助手/成本控制]]
+- [[AI 视觉对话助手/用户故事]]
--- a/视觉对话助手/成本控制.md
+++ b/视觉对话助手/成本控制.md
@@ -0,0 +1,128 @@
+---
+tags: [AI, 成本优化, 端云协同, 多模态, 运营策略]
+create time: 2026-06-12 11:13
+---
+
+# 成本控制
+
+## 概述
+
+实时视频流 + 多模态 LLM 推理的成本极易失控。本节从**视觉链路**、**语音链路**、**推理链路**三个维度梳理成本控制策略，并引入**端云协同**的架构思维——将适合的计算前置到客户端，降低对云端 API 的依赖。
+
+## 正文
+
+### 成本构成分析
+
+> [!question] 思考
+> 假设一个用户每天使用 10 分钟，每秒处理 1 帧图像 + 持续语音交互。粗算一下：10 分钟 × 60 秒 = 600 次图像 API 调用。如果每次调用消耗 1000 tokens，一天就是 60 万 tokens。1000 个用户呢？
+
+```mermaid
+graph TD
+    A["总成本"] --> B["视觉链路"]
+    A --> C["语音链路"]
+    A --> D["推理链路"]
+    B --> B1["图像编码与传输"]
+    B --> B2["视觉 token 消耗"]
+    C --> C1["STT 按分钟计费"]
+    C --> C2["TTS 按字符计费"]
+    D --> D1["LLM 输入 tokens"]
+    D --> D2["LLM 输出 tokens"]
+```
+
+### 策略一：智能采样——少发图，发好图
+
+最直接的降本手段：**减少发送给 LLM 的图片数量**。
+
+| 策略 | 降本幅度 | 实现复杂度 | 说明 |
+|------|---------|-----------|------|
+| 提高采样间隔 | 高 | 低 | 从 1fps 降到 0.2fps |
+| 关键帧过滤 | 中 | 中 | 画面不变时不发送 |
+| 用户触发 | 高 | 低 | 只在用户提问时拍照 |
+| 本地预筛选 | 中 | 高 | 用轻量模型判断"是否值得问 LLM" |
+
+```typescript
+// 混合策略：定时低频 + 事件高频
+const NORMAL_INTERVAL = 5000;  // 正常 5 秒一帧
+const ACTIVE_INTERVAL = 1000;  // 用户说话时 1 秒一帧
+
+let isUserSpeaking = false;
+
+setInterval(() => {
+  captureAndSend(isUserSpeaking ? "low" : "high");
+}, isUserSpeaking ? ACTIVE_INTERVAL : NORMAL_INTERVAL);
+```
+
+### 策略二：端云协同——把计算推到边缘
+
+核心思想：**不是所有计算都需要上云**。
+
+```mermaid
+graph LR
+    subgraph Client["客户端"]
+        A["摄像头帧"] --> B["轻量视觉模型"]
+        B --> C{"场景变化?"}
+        C -->|"否"| D["丢弃"]
+        C -->|"是"| E["压缩 + 上传"]
+    end
+    subgraph Cloud["云端"]
+        E --> F["多模态 LLM"]
+        F --> G["返回结果"]
+    end
+```
+
+可前置到客户端的计算：
+
+- **VAD 语音检测**：浏览器端完成，减少无效音频上传（节省 ~70% 带宽）
+- **人脸/物体检测**：用 ONNX Runtime 跑轻量模型，只在检测到新物体时触发 LLM
+- **重复画面过滤**：计算帧间相似度，相似度 > 90% 直接跳过
+- **敏感内容过滤**：NSFW 检测前置，避免无效 API 调用
+
+> [!tip] 端云协同的"甜点"
+> 浏览器端的 ONNX Runtime Web 可以跑 YOLOv8-nano 这样的轻量模型（~6MB），推理耗时约 30ms，完全不影响用户体验，但能显著减少云端调用次数。
+
+### 策略三：模型分级——用对模型做对事
+
+不是每个问题都需要最贵的模型：
+
+```mermaid
+graph TD
+    A["用户提问"] --> B{"问题复杂度"}
+    B -->|"简单识别"| C["GPT-4o-mini / Haiku"]
+    B -->|"深度分析"| D["GPT-4o / Sonnet"]
+    B -->|"代码/推理"| E["o1 / Opus"]
+    C --> F["成本: $0.15/1M tokens"]
+    D --> G["成本: $2.5/1M tokens"]
+    E --> H["成本: $15/1M tokens"]
+```
+
+路由策略示例：
+
+```typescript
+async function routeQuery(image: string, question: string) {
+  // 先用小模型判断问题复杂度
+  const complexity = await classifyComplexity(question);
+
+  const modelMap = {
+    simple: "gpt-4o-mini",    // "这是什么？" → 用小模型
+    moderate: "gpt-4o",       // "分析这张图" → 用中模型
+    complex: "o1"             // "推理/规划"  → 用大模型
+  };
+
+  return callLLM(modelMap[complexity], image, question);
+}
+```
+
+### 策略四：缓存与复用
+
+- **语义缓存**：相似问题直接返回缓存结果（如反复问"这是什么"）
+- **上下文复用**：连续对话中，未变化的图像不必重复发送
+- **Prompt 压缩**：精简 system prompt，减少每轮的固定 token 开销
+
+> [!info] 成本对比
+> 优化前（1fps 全量发送）vs 优化后（0.2fps + 端侧筛选 + 模型分级）：月成本可从 **$5000 降至 $300~500**，降幅约 90%。
+
+## 关联笔记
+
+- [[AI 视觉对话助手/视觉理解]]
+- [[AI 视觉对话助手/语音交互]]
+- [[AI 视觉对话助手/用户故事]]
--- a/视觉对话助手/用户故事.md
+++ b/视觉对话助手/用户故事.md
@@ -0,0 +1,96 @@
+---
+tags: [AI, 用户故事, 产品设计, 多模态, 需求分析]
+create time: 2026-06-12 11:13
+---
+
+# 用户故事
+
+## 概述
+
+用户故事是连接"技术实现"与"真实需求"的桥梁。本节列出 AI 视觉对话助手的典型用户故事，按**优先级分层**，并标注哪些属于 MVP 范围、哪些可后续迭代。
+
+## 正文
+
+### 用户故事全景
+
+```mermaid
+graph TD
+    A["AI 视觉对话助手"] --> B["实时问答"]
+    A --> C["场景理解"]
+    A --> D["辅助功能"]
+    B --> B1["这是什么物体"]
+    B --> B2["读出屏幕上的文字"]
+    B --> B3["帮我翻译这个标志"]
+    C --> C1["描述当前环境"]
+    C --> C2["识别人物动作"]
+    D --> D1["视障用户导航辅助"]
+    D --> D2["实时字幕生成"]
+```
+
+### 核心用户故事列表
+
+#### P0 - MVP 必做
+
+| 编号 | 用户故事 | 验收标准 |
+|------|---------|---------|
+| US-01 | 作为用户，我希望对着摄像头提问"这是什么"，AI 能识别画面中的物体并回答 | 准确识别常见物体，响应 < 3s |
+| US-02 | 作为用户，我希望用语音与 AI 对话，无需打字 | VAD 准确检测语音，STT 准确率 > 95% |
+| US-03 | 作为用户，我希望 AI 能"看到"我摄像头拍到的画面 | 每次提问时自动捕获当前帧 |
+| US-04 | 作为用户，我希望 AI 用语音回答我，而不仅是文字 | TTS 自然流畅，延迟 < 1s |
+
+#### P1 - 增强体验
+
+| 编号 | 用户故事 | 验收标准 |
+|------|---------|---------|
+| US-05 | 作为用户，我希望 AI 能持续"看着"画面，主动提示重要变化 | 关键帧检测 + 主动推送 |
+| US-06 | 作为用户，我希望 AI 能读出画面中的文字（OCR） | 中英文混合识别准确率 > 90% |
+| US-07 | 作为用户，我希望连续对话时 AI 能记住上下文 | 支持多轮对话，上下文窗口 > 10 轮 |
+
+#### P2 - 进阶探索
+
+| 编号 | 用户故事 | 验收标准 |
+|------|---------|---------|
+| US-08 | 作为视障用户，我希望 AI 能描述周围环境并提示障碍物 | 实时环境描述 + 安全警告 |
+| US-09 | 作为用户，我希望 AI 能翻译画面中的外语内容 | 支持主流语言实时翻译 |
+| US-10 | 作为用户，我希望可以切换 AI 的"观察模式"和"对话模式" | 一键切换，模式状态清晰可见 |
+
+### 用户旅程示例
+
+以 US-01 为例，完整的用户旅程：
+
+```mermaid
+sequenceDiagram
+    participant U as User
+    participant App as Client
+    participant AI as LLM
+
+    U->>App: 打开应用, 授权摄像头
+    App->>App: 启动摄像头预览
+    U->>App: 对着花朵说 "这是什么花"
+    App->>App: VAD 检测语音
+    App->>App: 捕获当前帧 + STT
+    App->>AI: 发送图像 + "这是什么花"
+    AI->>App: "这是一朵红色的玫瑰..."
+    App->>App: TTS 合成语音
+    App->>U: 播放语音回答
+```
+
+> [!question] 思考
+> 用户故事的验收标准中，"响应 < 3s"看似简单，但它约束了整条链路——帧采样、网络传输、LLM 推理、TTS 合成都必须在这个预算内完成。这反过来驱动了架构决策。这就是用户故事的价值：**用体验目标倒推技术方案**。
+
+### 故事优先级决策依据
+
+> [!tip] 如何判断优先级？
+> 用两个维度交叉评估：
+> - **用户价值**：这个功能对用户有多大帮助？
+> - **实现成本**：需要多少开发工作量和 API 调用成本？
+>
+> P0 = 高价值 + 合理成本（MVP 必须有）
+> P1 = 高价值 + 较高成本（第二版加入）
+> P2 = 探索性（验证后再投入）
+
+## 关联笔记
+
+- [[AI 视觉对话助手/视觉理解]]
+- [[AI 视觉对话助手/语音交互]]
+- [[AI 视觉对话助手/成本控制]]
--- a/视觉对话助手/视觉理解.md
+++ b/视觉对话助手/视觉理解.md
@@ -0,0 +1,108 @@
+---
+tags: [AI, 视觉, 多模态, 计算机视觉, 帧采样, GPT-4V]
+create time: 2026-06-12 11:13
+---
+
+# 视觉理解
+
+## 概述
+
+让 AI "看见"摄像头画面并理解其内容，是视觉对话助手的基础能力。本节探讨从摄像头视频流到 AI 语义理解之间的技术链路，重点关注**帧采样策略**、**图像编码方式**以及**多模态大模型的视觉输入机制**。
+
+## 正文
+
+### 整体流程
+
+```mermaid
+graph LR
+    A["摄像头视频流"] --> B["帧采样"]
+    B --> C["图像编码"]
+    C --> D["多模态 LLM"]
+    D --> E["语义理解结果"]
+```
+
+摄像头每秒产生 30 帧原始画面，全部送入 LLM 既不现实也不经济。因此，**帧采样**是第一个需要解决的问题。
+
+### 帧采样策略
+
+> [!question] 思考
+> 如果每秒都向 LLM 发送一帧，1 分钟对话就是 60 张图。考虑到 API 调用的延迟和成本，这个频率是否合理？
+
+常见的采样策略对比：
+
+| 策略 | 原理 | 适用场景 |
+|------|------|---------|
+| **固定间隔采样** | 每 N 秒取一帧 | 画面变化缓慢的场景 |
+| **关键帧检测** | 对比相邻帧差异，变化超阈值时触发 | 画面动态变化较多 |
+| **事件驱动采样** | 用户主动触发（如拍照按钮） | 精确提问场景 |
+| **混合策略** | 低频定时 + 高频事件触发 | 通用推荐方案 |
+
+关键帧检测的核心逻辑：
+
+```python
+import numpy as np
+
+def is_keyframe(prev_frame, curr_frame, threshold=30):
+    """通过帧间像素差异判断是否为关键帧"""
+    diff = np.mean(np.abs(prev_frame.astype(int) - curr_frame.astype(int)))
+    return diff > threshold
+```
+
+> [!tip] 实用建议
+> 实际开发中，可以先降低分辨率（如 320x240）做关键帧检测，再对命中帧保留原始分辨率送入 LLM，兼顾速度与精度。
+
+### 图像编码与多模态输入
+
+当前主流多模态 LLM（如 GPT-4o、Claude）接受图片的方式有两种：
+
+```mermaid
+graph TD
+    A["原始图像"] --> B{"编码方式"}
+    B --> C["Base64 内联"]
+    B --> D["URL 引用"]
+    C --> E["适合本地/实时场景"]
+    D --> F["适合已有图床的场景"]
+```
+
+实际调用示例（OpenAI 兼容接口）：
+
+```typescript
+const response = await openai.chat.completions.create({
+  model: "gpt-4o",
+  messages: [
+    {
+      role: "user",
+      content: [
+        { type: "text", text: "请描述画面中的内容" },
+        {
+          type: "image_url",
+          image_url: {
+            url: `data:image/jpeg;base64,${base64Image}`,
+            detail: "low" // "low" | "high" | "auto"
+          }
+        }
+      ]
+    }
+  ]
+});
+```
+
+> [!info] detail 参数的影响
+> - `low`：模型使用 65x65 的缩略图，token 消耗少（约 85 tokens），适合快速识别
+> - `high`：按 512px 方块切分，细节丰富但 token 数激增
+> - 对于实时对话场景，建议默认 `low`，仅在用户明确追问细节时切换 `high`
+
+### 视觉理解的局限性
+
+多模态 LLM 并非万能，以下场景需要额外注意：
+
+- **运动模糊**：快速移动的物体在低帧率下容易模糊
+- **光线变化**：逆光、暗光环境下识别率显著下降
+- **细小文字**：低分辨率下 OCR 能力受限
+- **空间推理**：精确的距离、尺寸判断仍是短板
+
+## 关联笔记
+
+- [[AI 视觉对话助手/语音交互]]
+- [[AI 视觉对话助手/成本控制]]
+- [[AI 视觉对话助手/用户故事]]
--- a/视觉对话助手/语音交互.md
+++ b/视觉对话助手/语音交互.md
@@ -0,0 +1,118 @@
+---
+tags: [AI, 语音交互, STT, TTS, VAD, 流式处理, 多模态]
+create time: 2026-06-12 11:13
+---
+
+# 语音交互
+
+## 概述
+
+语音是人机对话中最自然的交互方式。一个完整的语音交互链路包含：**语音活动检测 (VAD)** → **语音转文字 (STT)** → **LLM 推理** → **文字转语音 (TTS)**。本节拆解每个环节的技术选型与优化策略，重点关注**端到端延迟**的控制。
+
+## 正文
+
+### 语音交互全链路
+
+```mermaid
+graph LR
+    A["麦克风"] --> B["VAD"]
+    B --> C["STT"]
+    C --> D["LLM"]
+    D --> E["TTS"]
+    E --> F["扬声器"]
+```
+
+用户感知到的延迟 = VAD 响应 + STT 耗时 + LLM 首 token + TTS 首包。任何一个环节拖后腿，对话体验都会"卡顿"。
+
+> [!question] 思考
+> 人类对话中，停顿超过 300ms 就会感到"对方在想"。你认为端到端延迟控制在多少毫秒以内，才能让 AI 对话"像真人"？
+
+### 环节一：语音活动检测 (VAD)
+
+VAD 的作用是从持续的音频流中检测"人什么时候在说话"，避免将环境噪音当作有效输入。
+
+```typescript
+// 使用 WebRTC VAD（浏览器端轻量方案）
+import { MicVAD } from "@ricky0123/vad-web";
+
+const vad = await MicVAD.new({
+  onSpeechStart: () => console.log("用户开始说话"),
+  onSpeechEnd: (audio) => {
+    // audio: Float32Array，送入 STT
+    sendToSTT(audio);
+  },
+  positiveSpeechThreshold: 0.5, // 检测灵敏度
+  minSpeechDuration: 250        // 最短语音时长 ms
+});
+
+vad.start();
+```
+
+> [!tip] 为什么要在浏览器端做 VAD？
+> 如果把所有音频都发给服务端，带宽成本会很高。浏览器端 VAD 只在检测到语音时才上传数据，能减少 70%+ 的无效传输。
+
+### 环节二：语音转文字 (STT)
+
+主流方案对比：
+
+| 方案 | 延迟 | 成本 | 特点 |
+|------|------|------|------|
+| **Whisper API** | 1-3s | 按分钟计费 | 准确率高，支持多语言 |
+| **Deepgram** | <500ms | 按分钟计费 | 流式识别，延迟极低 |
+| **浏览器原生** | ~1s | 免费 | 依赖浏览器，中文效果一般 |
+| **FunASR** | <500ms | 自部署免费 | 阿里开源，中文优化 |
+
+流式 STT 是低延迟的关键——不必等用户说完，边说边识别：
+
+```typescript
+// Deepgram 流式识别示例
+const ws = new WebSocket("wss://api.deepgram.com/v1/listen", {
+  headers: { Authorization: `Token ${API_KEY}` }
+});
+
+ws.onmessage = (event) => {
+  const { transcript, is_final } = JSON.parse(event.data).channel.alternatives[0];
+  if (is_final) {
+    // 一句完整语音，送入 LLM
+    onFinalTranscript(transcript);
+  }
+};
+```
+
+### 环节三：TTS 语音合成
+
+TTS 是用户听到"AI 声音"的最后一环。流式 TTS 可以在 LLM 生成第一个句子时就开始朗读，大幅缩短感知延迟。
+
+```mermaid
+graph TD
+    A["LLM 流式输出"] --> B{"句子边界检测"}
+    B -->|"检测到句号/逗号"| C["送入 TTS"]
+    C --> D["流式播放音频"]
+    B -->|"继续生成"| A
+```
+
+方案选择：
+
+- **OpenAI TTS**：音质好，延迟中等，按字符计费
+- **Edge TTS**：微软免费方案，音质不错，延迟略高
+- **Fish Speech / CosyVoice**：开源方案，支持声音克隆，可自部署
+
+### 延迟优化汇总
+
+```mermaid
+graph TD
+    A["端到端延迟优化"] --> B["VAD 浏览器端处理"]
+    A --> C["流式 STT 边说边识别"]
+    A --> D["LLM 流式输出"]
+    A --> E["TTS 句子级流式合成"]
+    A --> F["并行处理: STT 与上下文准备"]
+```
+
+> [!info] 关键数字
+> 一个优化良好的语音对话链路，端到端延迟可以控制在 **1.5~2 秒**以内——从用户说完话到听到 AI 回应。如果做到流式 TTS，用户在 LLM 开始生成后 **0.5 秒**就能听到第一个词。
+
+## 关联笔记
+
+- [[AI 视觉对话助手/视觉理解]]
+- [[AI 视觉对话助手/成本控制]]
+- [[AI 视觉对话助手/用户故事]]