ylhan/note_sync
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
19 Commits 1 Branch 0 Tags
f5b825bd4a3a605278fef1793089d9f8e9f3ed3a
Commit Graph
19 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
ylhan f5b825bd4a 重命名: deepseek论文md加_abstract后缀, 消除与pdf同名冲突(修复SilverBullet 404) 2026-09-20 17:52:13 +08:00
ylhan 14c280ffee 新增: DeepSeek 全部 33 篇官方论文(原文 PDF 走 Git LFS + 中文精读笔记与索引) 2026-09-20 17:11:49 +08:00
ylhan f600fa5871 新增: 备忘(硬件资料链接)与待办清单 2026-09-20 10:51:34 +08:00
ylhan 84cd60799a 输入法笔记: 新增开机自启章节, 规范格式并顺延章节编号 2026-09-17 00:31:41 +08:00
ylhan a01b75cfb5 输入法笔记: 补充无法切换时添加中州输入法的说明及截图 2026-09-17 00:23:28 +08:00
ylhan 8a12b2de6a 整理: 输入法笔记结构化, 清除知乎追踪链接与远端图床图片 2026-09-17 00:17:20 +08:00
ylhan f0dce05ac1 新增 Pipecat Flows 兼容性 spike 结论 
交接文档规定"未经 spike 结论，不进入 Phase 3"。本次完成 Phase 1 spike，
7 项验证全部通过，并给出可进入 Phase 2 的结论。

新增 P1-Flows兼容性Spike结论.md

核心结论：
- **不装 pipecat-ai-flows**。Pipecat 1.10 内置 Flows（pipecat.flows），
  装独立包会报错提示卸载；独立包 1.4.0 会把 pipecat 降到 1.4.0
- **复用 DeepSeekLLMService**，不写 FallbackProvider 适配器。它自带
  DeepSeekLLMAdapter 处理 reasoning_content 回传（P0 踩过的坑），
  thinking 默认 disabled。代价是失去本地 vLLM 降级
- 实测：中文流式 14–22 块/回复、工具参数无重复拼接、回灌后出最终回答、
  worker.cancel() 立即终止、role_message 生效

定位了 5 个坑（4 个 Flows 相关 + 1 个环境）：
1. FlowManager.initialize 是协程但签名显示 -> None，漏 await 静默失效，
   role_message/task_messages/工具全部不生效而 LLM 照样回复，极易误判
2. 必须用 PipelineRunner 跑 worker；直接 run() 会让工具执行失败，
   异常被转成通用错误串，handler 从不执行，默认日志看不到
3. respond_immediately 默认 True，initialize 会立刻触发一轮回复，
   做归因测试时不清空观察窗口会归因错
4. role_message 与 task_messages 各产生一条 system 消息，
   两者不要同时用（切回本地 vLLM 时会 400）
5. NLTK punkt_tab 本地也需预装，否则 setup 超时卡住

对现有功能的影响：分句 TTS、RTVI、记忆身份不受影响；
SearXNG 工具需迁移；本地 vLLM fallback 会失去。
第四节给出 Phase 3 的最小生产集成 diff 要点。
 2026-09-16 13:13:52 +08:00
ylhan 05933d168f 记录 SearXNG 私有搜索服务部署 2026-09-16 11:14:06 +08:00
ylhan 26182e971e 更新 Pipecat 实时链路实验结论 2026-09-16 09:50:38 +08:00
ylhan 2ef6fe215c 新增 Pipecat 传输层实验报告；方案 §10 记录当前卡点 
背景：方案文档写"Pipecat 作为唯一会话管线框架"，但核实后发现
代码里它只在 requirements.txt 里（零引用）。于是做实验验证架构问题：
Pipecat 该用多深——只做传输（A），还是按框架 service 模型重构（B）。

新增 P0-Pipecat传输层实验报告.md

- 传输层跑通：信令（47–280ms）、ICE 连通、data channel、双向媒体轨
- 帧路由未通：自定义处理器的 process_frame 调用次数为 0，
  连自己注入的 StartFrame 都没进去；引擎从未运行
- 现象：连接全对、音轨协商成功、助手永远不说话，日志里一条错误都没有
- 记下 8 个集成坑，每个都表现为"什么都没发生"
- 结论：实验未能支持 A 方案，反而间接给了 B 更多理由；
  但根因未定位，两种可能必须区分（接线错误 vs 模型不兼容）

方案 §10 更新

- 第 1 步改为"服务端 WebRTC 入口 + 客户端骨架"，状态标注为
  "传输层跑通、帧路由未通"
- 新增 1b 步：查清帧路由根因 → 定 A/B 方案，标为当前卡点
- header 加注实验状态与 A/B 待定
- 架构图补传输层，标注"实验，帧路由未通"

顺带修正

- 局域网于当日重新编址（192.168.0.x → 172.16.1.x），
  架构图里的服务器地址更新
- 报告数量 4 → 5
 2026-09-15 17:55:53 +08:00
ylhan bb4fa3028e 方案：定稿客户端/服务器音频边界，修正下一步顺序 
音频边界（§5 新增章节，从"待定稿"改为"定稿"）

四个问题的决定：
- 传什么：闲置关闭，会话中持续上传（含 0.5–1s 预卷）
  闲置时服务器完全听不到房间声音；会话中上传完整音频流，
  服务端才能做可靠的"说完判定"。唤醒控制的是"是否上传"，
  不是"是否处理"。
- 唤醒：本地。延迟低、断网可响应；它是注意力的门，不是传输的门。
- 打断：客户端判定。三条理由——WebRTC 的 AEC 本来就在客户端跑
  （需要播放参考），客户端麦克风信号已是去回声的；客户端知道自己
  正在播什么，"用户在此刻开口"本地可判，不需额外协议；比服务端
  判定少一个来回，更容易满足 ≤300ms。
- 断线：WebRTC 内建 ICE restart；抖动缓冲 100–200ms 待实测。
  缓冲换稳定性但直接加首音延迟，不能凭感觉设。

同时写明接口约定（上下行各传什么）、三条约束（播放参考须本地可得、
预卷缓冲、上传不等于存储）和这条边界的已知代价。

修正下一步顺序

原顺序把"N5095 WebRTC 客户端"列为第一步，但核实后发现：
代码里 pipecat 一次都没被 import 过（只在 requirements.txt 里），
引擎是独立 asyncio 由测试脚本驱动，**服务端没有任何客户端能连的入口**。
所以第一块是服务端 WebRTC 入口，客户端排第二。

新顺序列出六步并标注每步的状态与阻塞条件，明确说明：
第 2 步用合成音频只能验证传输层，**验不了 AEC 与远场识别**——
那要等真实硬件。
 2026-09-15 13:05:35 +08:00
ylhan 2b6093d392 方案 v2.4 修订：按评审意见修正 8 处 
评审指出的问题，逐条修正：

1. AEC 结论过早
   原文写"WebRTC 自带 AEC，因此解决 P2"，这是把"框架有实现"当成了
   "链路配置正确"。补充了三个前提：麦克风采集与播放参考要正确送入、
   XVF3800 自身 AEC 路由需实测（两处 AEC 串联可能互相干扰）、
   打断判定依赖 AEC 输出质量。P2 该行改标"待验证"。

2. 音频路径旧描述
   第 157 行仍写"N5095 的 TTS"，已改为完整链路：
   服务器 Qwen3-TTS → WebRTC → N5095 USB 播放端点 → XVF3800 AUX → 音箱。
   并补一条：AEC 所需播放参考必须在 N5095 本地可得，不能依赖服务器回放时钟
   （两侧时钟不同步会导致参考信号对不齐）。

3. "N5095 不跑任何推理"不准确
   方案自己安排 N5095 跑 VAD、唤醒、人脸检测，这些也是推理。
   改为"不运行 STT/TTS/LLM 等重型推理"。

4. 架构变更理由说过重
   原文称"N5095 跑不动可用的语音模型"，但 P0 数据证明它能跑
   Zipformer STT（RTF 0.22）和 Piper TTS（RTF 0.36）。
   改为"N5095 能完成低配本地语音，但达不到当前的目标音质与延迟"——
   音质达标的 Qwen3-TTS 在它上面 RTF 1.86，在服务器上 0.09。

5. 客户端/服务器音频边界未定义（新增一节）
   传什么（持续音频 vs 带预卷的语音段）、唤醒在哪端、打断谁判定、
   断线抖动如何恢复——四个问题列了选项与权衡，给出当前倾向，
   并标注必须在做 WebRTC 客户端之前定稿，否则接口要返工。

6. STT 是最大功能风险
   在 §5 表格和 §10 各标出：中文真人识别率至今无可信数据，
   音频硬件到手后应优先录制本人语音算 CER，并与 SenseVoice /
   faster-whisper large-v3 对比。

7. 首音延迟需按真实链路重测
   当前 1545ms 是非流式、无 VAD、无传输、无播放缓冲的数据。
   补入必须计入分句等待、WebRTC 抖动、播放缓冲，并测 P50/P95。

8. 尾部旧状态与重复段
   §10 重写：原文还写"继续确认 Ubuntu 版本""未做实机测试"，
   与 v2.4 实际进度冲突。改为已完成/下一步/风险/待办四段。
   删除 §5 中完全重复的 P0 测试说明段。

同时采纳评审给出的下一步顺序：先闭环实时语音链路
（WebRTC 客户端 → 真实音频 → AEC/打断/STT 正确率），
再推 ESP32 表情，最后摄像头/多人/电机。
 2026-09-15 12:49:42 +08:00
ylhan bdd6bfb63d AI桌面陪伴助手：方案更新至 v2.4，代码剥离到独立仓库 
代码剥离
- 助手本体、TTS 服务、P0 基准脚本、ESP32 固件移到 ~/workspace/ai-companion
  （独立 git 仓库），本目录只留方案、P0 报告与硬件记录
- 因此删除 esp32_smile_test.ino / esp32_touch_eyes.ino
- 同时移除已失效的 .gitignore（原本只为挡住模型体积，代码已搬走）

方案 v2.4 重大变更：架构从"单机"改为"服务器即助手、本地为客户端"
- 起因：实测 N5095 无 AVX2，跑不动可用的语音模型
- N5095 降为客户端/外设桥，只做 USB 接入、DoA、WebRTC 客户端
- 实施阶段表加进度列（P0/P1/P3/P4a 部分完成），新增三条验收要求
- 采购清单按实际到货更新，标出屏幕形态待确认（2.8寸 vs 原定1.28寸圆屏）

技术栈（实测更新）
- LLM：DeepSeek deepseek-flash（云端，必须关思考）；本机 27B 已停用
- TTS：Qwen3-TTS 1.7B（服务器 3090）；vits-zh-ll 因音色不满意被替换
- STT：Zipformer int8 未变，中文识别率仍是未闭合项

新增两份 P0 报告
- P0-Qwen3TTS报告.md：TTS 换型过程与实测
- P0-DeepSeek验证报告.md：四条路径验证

两份旧报告加了状态说明（结论仍有效但选型已变），
并修正了随代码移走而失效的引用与复现命令。
 2026-09-15 11:08:56 +08:00
ylhan 152b919b25 添加子目录 2026-09-14 17:02:12 +08:00
ylhan 525e9f20d9 feat: 添加ESP32触摸眼睛动画及接线文档 2026-09-14 16:51:31 +08:00
ylhan 62d5acaecd docs: 完善AI桌面陪伴助手实施规划与采购方案 2026-09-12 18:21:41 +08:00
ylhan 14090b625a docs: 新增 AI 桌面陪伴助手方案（N5095+ESP32 架构定稿） 2026-09-12 16:12:07 +08:00
ylhan e103738081 更新: 新增杂项笔记, 修正sshwifty密钥, 同步AI_compiler子模块 2026-08-26 22:42:33 +08:00
ylhan 8a4210f380 将 note 笔记库同步到 note_sync，AI_compiler 作为 submodule 2026-08-20 17:42:14 +08:00