Dingfan X.

UART DMA 首字节丢失与 USB 32 字节截断排查

Sun, 31 May 2026 00:00:00 GMT

排查 Cortex-M0 上 UART DMA 接收的两个问题。一是高波特率下首字节丢失——115200 下字节时间只有 87 μs，临界区稍长就会在 ISR 启用 DMA 之前 overrun，9600 下 1 ms 的余量则没问题；解法是让 UART 中断不被典型临界区屏蔽，或干脆用循环 DMA 让接收脱离 ISR 时序。二是低概率 32 字节截断——稳定的 32 这个数字指向 USB Bulk 端点的 wMaxPacketSize，叠加 CH340 内部缓冲与缺 ZLP 的行为，相邻包之间的 UART 静默期偶尔会超过帧超时。

现象

一个跑在 Cortex-M0 上的项目，UART 接收在 9600 波特率下表现正常，但切到 115200 后，有较高概率丢失首字节。

原因

当前实现是第一个字节到达触发 UART 中断，中断里申请 buffer 并启动 DMA。也就是说，UART 中断必须在第二个字节到达之前完成 buffer 申请 + DMA 配置 + 使能，否则数据寄存器 RDR 会被覆盖（硬件上对应 Overrun Error）。如果首字节到达时主流程刚好处在关中断的临界区内，UART 中断被挂起，等临界区退出再处理时，首字节已经被后续字节冲掉了。

为什么 9600 几乎不出问题，而 115200 频繁出问题？算一下就清楚。

UART 按常见的 8-N-1 帧格式（1 起始位 + 8 数据位 + 1 停止位 = 10 bit/字节）：

9600 baud：10 / 9600 ≈ 1042 μs/byte
115200 baud：10 / 115200 ≈ 86.8 μs/byte

也就是说，从首字节进入 RDR 到下一字节到来，9600 下有大约 1 ms 的窗口，115200 下只有约 87 μs。典型嵌入式工程的临界区——Flash 操作、跨外设的多寄存器配置、嵌套保护——持续几十到上百微秒并不少见。87 μs 这个值正好踩在易出问题的边界上；1 ms 则给到了非常充裕的余量，绝大多数合理时长的临界区都容纳得下。

几种解决方向

方案一：分级临界区

提供两套临界区：传统的全关中断用于真正需要原子性的场景；另一套关除 UART 外的所有中断用于需要保留 UART 实时响应的场景。

理想情况下这应该用优先级阈值屏蔽来实现——Cortex-M3 及以上有 BASEPRI 寄存器，可以"只屏蔽优先级低于某阈值的中断"，UART 中断放进 BASEPRI 不屏蔽的范围就好。但 Cortex-M0 实现的是 ARMv6-M，只有 PRIMASK，要么全开要么全关，没有原生的阈值机制，只能手动操作 NVIC 的 ISER/ICER 来做选择性 mask。嵌套临界区、ISR 中再次进出临界区、关中断期间 NVIC 状态的保存/恢复都需要小心，否则容易引入更隐蔽的问题。

方案二：循环 DMA + Idle Line 触发

UART 持续运行在 Circular DMA 模式，DMA 通道不停搬运，每 ms 轮询 buffer 来判断是否有新数据，进而及时将数据拷贝出去。

这条路最干净，根本上规避了中断响应来不及的问题，因为 DMA 在数据搬运上完全不依赖 CPU。代价是 DMA 通道数。部分入门级 MCU 上 DMA 通道有限，多个通讯口子并存时不一定排得开。

一个未消除的低概率现象：32 字节截断

不论方案一二，进一步测试都发现一个极低概率现象：长帧偶尔会在第 32 字节处被截断。

错误模式高度一致——总是 32 字节。如果是判帧机制本身的概率性失效（比如硬件计时器抖动、中断丢失），截断点应当随机分布。这么稳定的 32，必然对应着某个真实存在的 32 字节边界。

回想起之前调试 USB 串口时遇到过的32 字节整倍数数据发不出去问题，这指向了 USB 协议的一个参数：wMaxPacketSize。

根据 USB 2.0 Specification 第 5.8.3 节，Full-Speed Bulk 端点的 wMaxPacketSize 只能是 8、16、32 或 64 之一（USB-Serial 转换器普遍走 Bulk 端点）。我使用的上位机连接的 USB-Serial 转换器协商出 32 字节。

这里值得展开一下：USB-Serial 转换器有不同的芯片实现，常见的 FTDI（Future Technology Devices International，一家苏格兰公司，FT232/FT2232 等 USB-Serial 芯片的老牌厂商）和 CP210x 协商出来通常是 64 字节，而 CH340/CH341 系列协商出来恰好是 32 字节。换言之，32 字节这个特征已经把芯片范围缩得相当窄。

可能的具体诱因

USB 是基于 1 ms 帧调度的协议。Full-Speed 上 SOF（Start of Frame）每 1 ms 发送一次，把总线时间切片。每个 wMaxPacketSize 大小的数据需要等到主机发起一次 IN/OUT 事务才能传输。Bulk 传输优先级最低，遵循"带宽可用时执行"原则——理论上一帧可以塞下多个 Bulk 包（32 字节 payload 在 12 Mbps 上传输不过 ~21 μs），但实际能不能塞下取决于等时/中断传输的占用、主机控制器对 Bulk 队列的调度，以及主机端 USB 驱动到用户态的数据通路是否被及时调度。

FTDI 的 AN232B-04 应用笔记里明确指出：

USB does not transfer data using interrupts. It uses a scheduled system and as a result, there can be periods when the USB request does not get scheduled and, if handshaking is not used, data loss will occur.

For a USB device, data transfer is done in packets. If data is to be sent from the PC, then a packet of data is built up by the device driver and sent to the USB scheduler. This scheduler puts the request onto the list of tasks for the USB host controller to perform. This will typically take at least 1 millisecond to execute because it will not pick up the new request until the next 'USB Frame' (the frame period is 1 millisecond).

因此，在 OS 用户态进程被抢占、驱动线程让出 CPU、或 USB 主机控制器队列被高优先级设备占据的瞬间，确实存在 Bulk 传输被推迟数十毫秒的可能。

把视角进一步收窄到具体芯片——CH340 系列在这件事上还有两个值得注意的硬件行为，都被 Linux 内核 ch341.c 驱动源码及相关 commit 历史明确记载：

第一，CH340A 在 OUT 方向（主机 → CH340 → UART）默认会在内部缓冲数据直到收满 32 字节才向 UART 转发，除非驱动主动设置某个寄存器的 bit 7 来关闭这个行为。源码注释：

CH341A buffers data until a full endpoint-size packet (32 bytes) has been received unless bit 7 is set. (linux/drivers/usb/serial/ch341.c)

第二，CH340 系列不会主动发 ZLP。Linux 内核 2021 年的一次 commit 把 ch341 driver 的 bulk-in 缓冲改回端点大小，理由是 "These devices do not appear to send a zero-length packet when the transfer size is a multiple of the bulk-endpoint max-packet size." 而 USB 规范规定，Bulk 传输结束的标志之一就是出现一个长度小于 wMaxPacketSize 的短包；如果一次传输恰好是 wMaxPacketSize 的整数倍，发送端必须额外发一个 ZLP 来显式告知接收端"传输结束"，否则接收端会持续等待。这就是之前32 字节整倍数发不出去的根源（Argon Blue 的这篇博客对 ZLP 在 CDC 中的角色描述得很清楚，虽然 CH340 不走 CDC，但 ZLP 机制是共通的）。

把这几条线索叠起来，32 字节截断的更完整解释是：

数据从上位机 App → USB Driver → CH340 → UART → 设备。芯片以 32 字节为最小调度单元在 USB 与 UART 间转发；正常情况下若干个 32 字节包紧密相连，UART 端看起来是连续的字节流。但当主机系统负载、驱动调度、或者 ZLP 行为缺失带来的等待，使得两个相邻 32 字节包之间的 UART 静默期超过设备侧的字符间帧超时，UART 接收端就判定当前帧结束，把已经收到的 32 字节抛给上层。多个因素叠加，恰好对应到 32 字节这个稳定的截断边界。

需要承认，这条解释链不是单一因果，更像是一个具备这些条件就有概率出现的复合现象。低概率也正是 USB 调度抖动 + 硬件缓冲 + 主机负载的偶发交叠所致。

验证与解决方向

短期排查：

换一台 wMaxPacketSize 非 32 字节的主机做对照，看截断频率是否消失
增大字符间帧超时做对比，逼近真实调度抖动的上限

长期解法：

协议层不要单纯依赖字符间超时来判帧。更稳健的做法是长度前缀 + CRC，或者 SLIP 风格的 framing。这样即使 USB 端引入了几十毫秒抖动，也能从字节流正确恢复出帧边界
如果产品形态允许，避免在传输链路上引入有已知缺陷的 USB-Serial 芯片

参考资料

USB 2.0 Specification, Section 5.8.3 Bulk Transfer Packet Size Constraints
FTDI Application Note AN232B-04, Data Throughput, Latency and Handshaking Processes between Hardware and a Software Driver
USB in a NutShell — Chapter 4: Endpoint Types
Argon Blue: Much ado about nothing: USB zero-length packets
ARM Cortex-M0 Devices Generic User Guide, 特别是 PRIMASK 与 NVIC 章节
linux/drivers/usb/serial/ch341.c 中关于 CH341A 32 字节缓冲行为的注释
"USB: serial: ch341: fix character loss at high transfer rates" 的 revert commit log，明确记录了 CH341 不发 ZLP 的行为

EEPROM 页回绕问题调试记录

Fri, 08 May 2026 00:00:00 GMT

记录一下今天遇到的一个 bug，由于软件 eeprom 配置错误导致写回绕，数据丢失 + 数据覆盖，虽然定位到问题后解决比较简单，但搜集线索和排查耗费了较多时间。

现象

设备从远端持续下载数据过程中始终失败，预期应该持续接收直到传输完成。

线索

通过与触发问题的同事交流以及自己调试排查，收集到几条线索：

问题只在带真实 EEPROM/Flash 的硬件上复现，在 mock 掉 EEPROM 和 Flash 的纯软件仿真环境里，下载流程完全正常。
出问题的数据都集中在 EEPROM 地址的起始区域，几份数据的存储地址很近。
问题点并不集中于传输，设备启动阶段也观察到异常，共同点是两者都依赖 EEPROM 里的同一片区域。
触发点在传输，不传输则遇不到，比如正常启动时不会遇到该问题。
仅一款设备存在问题，其它型号正常。
连续操作下，第一次下载前数据正常；第一次下载失败后读出"异常 A"；第二次下载失败后读出"异常 B"。异常本身有确定的模式，不是随机扰动。

推测

基于上述几条线索，基本可以确定

代码逻辑无问题：因为 mock 的 eeprom 和 flash 并不存在问题。而且若程序有问题，如何解释问题不集中在一处呢？
问题与 eeprom 有关，但与 eeprom 硬件故障无关：异常点处数据集中，异常模式稳定，若 eeprom 硬件故障，则不会保持稳定的异常模式。
问题与数据传输时，与 eeprom 有关的数据项具有强关联。因为触发点很确定。

验证

事后回顾时，发现当时解决问题时的思路不够清晰，但是也不算糊涂。

先去确认了当前工程的 eeprom 配置，发现工程配置的芯片型号是 XXXX，查阅的对应的 datasheet：

Page Write The Page Write mode allows up to 256 bytes to be written in a single Write cycle, provided that they are all located in the same page in the memory: that is, the most significant memory address bits, b16–b8, are the same. If more bytes are sent than will fit up to the end of the page, a "roll-over" occurs, i.e. the bytes exceeding the page end are written on the same page, from location 0.

发现它的 page size 大小是 256 bytes，于是请硬件同事确认该 eeprom 容量是否真的是 1Mbit（对应 256 bytes 的 page size），发现并不是，而是 500kbit，那么实际的 page size 就应该是 128 bytes。

同时 datasheet 中提到了一个重要的机制 “roll-over”。但是在事后分析前，先简单将配置调整为 128 bytes 的 page size，尝试复现问题来确认解决是否有效，果然发现问题已经消失。

分析

当工程的 page size 配置为 256 bytes，实际物理 eeprom 的 page size 为 128 bytes 时，就会导致当写入的数据在 256 bytes 以内，但又恰好超过了 eeprom 中以 128 bytes 为倍数的物理边界时，就会导致驱动程序认为当前写入安全，未超出 256 bytes 的上界，不需要拆包直接写，但是实际硬件并非如此，没有被拆包的就会发生上述 “roll-over” 现象。导致 eeprom 前面已经写入的数据被覆盖掉，进而设备业务逻辑出现异常。

但是这是事后分析猜得出的，实际上确实是思路不够清晰。本应该首先检查传输阶段哪些数据会向 eeprom 中写入，写入地址是多少，写入字节数是多少，是否会撞到特殊点处，比如 2 的幂次倍数据，数据是否跨页等。但是误打误撞从配置角度切入，发现了问题症结，然后从现象反推原因。

后来为了确认，再次复现复盘了一下，发现实际写入过程与推理一致，传输过程中有几项需要写入 eeprom 的数据比较大块（130 bytes），恰好就踩到了 eeprom 128 bytes 的物理边界上，且由于写入地址非常接近 128 bytes 边界，所以回绕后的数据快追上数据头了，也就导致不仅自身传输业务受到了影响，在写入地址前的所有业务都受到了影响，但比较容易观测的只有设备启动时的异常。

修复

除了修改掉软件配置外，同时新增两个防御性措施：

Mock 行为对齐硬件：mock 的实现也按真实的 page size 模拟 wrap-around 行为，否则会导致 mock 反而掩盖了问题。
在 mock 程序上新增几组 unit test：跨页写入、起始地址恰好在 page 末尾、单次写满整页等。

结论

越是接近答案，越要保持头脑清晰
Mock 须以复现硬件的关键约束为目标，包括 page size、写入耗时、边界行为等。

Chunking Strategies for RAG

Tue, 05 May 2026 00:00:00 GMT

本文基于 Pinecone 文章和与 Claude 的讨论整理。后续会持续补充阅读其他文献（尤其是 Liu et al. 2023 等原始论文）后的修正与扩展。目前文中 Claude 提供的数据未经验证，无法保证可靠，但大方向的正确与否是很显然的，比如几种 chunk method 的效率和成本。

1. Chunking 的本质：信息完整度 vs 信息纯度的权衡

文章开头那句被反复引用的话：finding chunks that are big enough to contain meaningful information, while small enough to enable performant applications and low latency responses.

简而言之：chunk size 是在"信息完整度"和"信息纯度"之间做权衡。

太小 → 损失完整度。每块讲不清一件事，单独看缺乏必要的上下文。
太大 → 损失纯度。每块讲了太多事，关键信号被稀释。

这个 framing 比”找一个合适的大小“更有指导意义——它说明 chunk size 不是一个绝对最优值，而是与语料、query 分布、模型能力共同决定的一个平衡点。

2. chunk size 的双重影响：检索 vs 生成

chunk size 在 RAG pipeline 的两个阶段产生不同的影响，需要分别考虑。

检索阶段:

chunk 太小 → 单个 chunk 信息缺乏上下文（比如没有主语的孤儿 chunk，it / this / above 等回指词），embedding 字面信息不足，检索时召不回。
chunk 太大 → 多个话题被压缩成一个向量，每个话题的信号都被稀释，精确 query 难以匹配上。

生成阶段:

chunk 太小 → 单个 chunk 信息不足，需要更多 chunk 才能拼出完整答案，挤占 LLM 的 context 预算。
chunk 太大 → 输入 token 数增加，推理延迟上升、成本上升，且触发 lost-in-the-middle。

这个双重影响解释了为什么 chunk size 没有简单公式可衡量的根本原因。因此优化应该面向两个阶段同时存在的多个失败模式来进行。

3. 被混淆的损失机制

读这篇文章时踩过的坑：把 embedding 容量瓶颈和 lost-in-the-middle 混为一谈。虽然它们都是长文本上的信息丢失”，但发生在不同阶段、由不同机制造成。

机制 A：Embedding 的容量压缩损失

发生在检索阶段。embedding 模型把任意长度的文本压缩成一个固定维度的向量（比如 1024 维）。这是极度有损的压缩——输入越长，单位 token 能”占用“的向量空间越少。

类比：embedding 维度像一张固定分辨率的画布。

1024 维 ≈ 1024 像素的画布
一个句子 → 一张画布画一个苹果，细节清晰
整本书 → 同样大小的画布画整个超市，全糊成一片

实际后果：把整个参考文档编码成单个向量，向量只能粗粒度地代表“这是一份某领域的文档”。当用户 query 是某个具体细节问题时，embedding 距离对不上，细节信息已经在压缩中丢失了。

这就是为什么 chunking 不只为适配 context window，还要充分考虑 embedding 模型的有损压缩，以保留更多细节。

机制 B：Lost-in-the-Middle

发生在生成阶段。Liu et al. (2023) 的实验显示：把回答问题所需的关键信息放在长 context 的不同位置，准确率呈 U 型曲线——开头和结尾最高，中间最低。这是 LLM 注意力机制和训练数据分布共同导致的结构性问题。

需要特别注意“中间”指的是 LLM prompt 中物理位置的中间，而不是"被压缩进 embedding 时丢失的中间信息"。这两个"中间"完全是不同的概念。

两个机制的对照

维度	Embedding 压缩损失	Lost-in-the-Middle
发生阶段	检索阶段(建索引时)	生成阶段(LLM 推理时)
涉及模型	embedding 模型	生成式 LLM
损失原因	固定维度向量容量有限	注意力机制 + 训练分布偏置
“中间”含义	没有"中间"概念，是整体压缩	LLM prompt 中物理位置的中间

4. RAG vs Long Context：为什么前者还没被淘汰

目前 LLM 的 context 已经越来越大，DeepSeek v4 甚至具备 1M 的上下文空间，那么 RAG 是否依然需要？

答案是肯定的。

最开始我的理解是，如果没有 RAG，那么 LLM 应该要自己去从整个输入中寻找需要的信息，但是 Claude 对我的理解进行了纠正：LLM 不在 context 里"搜索"信息。它的工作方式是每生成一个 output token 都对整个 context 做一次 attention 计算。所谓塞 200k 进去让模型自己找，实际上是让模型为每个生成步骤都消化一遍 200k token。因此基于这个认识，回答可以从如下几个方面展开：

Quality：lost-in-the-middle 导致中间内容被忽略,回答质量反而下降。

Latency：Self-attention 复杂度是 O(n²)。100k tokens 比 5k tokens 在 prefill 阶段不是慢 20 倍，而是慢约 400 倍(理论上限)。直接体现为 TTFT(Time To First Token)显著上升。

Cost：input token 按量计费。每次 query 处理整份文档是巨大浪费——RAG 的本质是把全文档 attention换成top-k chunk attention，n 从 200k 降到 2k，计算和计费都降两个数量级。

架构清晰性：RAG 把检索和生成职责分离，可以独立优化、独立替换、独立评估。这是软件设计层面的清晰性，仅有 long context 的方案做不到。

那如果将 prompt caching 机制考虑进来呢？答案是 prompt caching 虽然可以缓存重复使用的 prompt 前缀，缓解部分 cost 问题。但它不能解决 quality 和 lost-in-the-middle 问题，因此总体上 RAG 仍然具备优势。

关于 prefill 和 decoding

LLM 推理延迟实际由两段组成:

Prefill 阶段：处理整个输入 prompt，这一步是 O(n²)，决定 TTFT
Decoding 阶段：逐个生成 output token，借助 KV Cache 每个新 token 是 O(n)

KV Cache 解决的是 decoding 阶段的重复计算，但 prefill 阶段躲不开 O(n²)。所以“长 context 慢”的痛点主要在 prefill。这也是 prompt caching 能缓解 cost 的原因——它本质上是缓存 prefill 的中间结果(K/V)。

5. 几种 Chunking 方法

文章里的方法分类一开始读起来比较散，整理成层级会清楚得多:

Fixed-size chunking(不看内容,纯按 token 数切)
Content-aware chunking(看内容决定切分)
├── Sentence / paragraph splitting(NLTK, spaCy)
├── Recursive Character Splitter(LangChain)
├── Document structure-based(Markdown / HTML / LaTeX / PDF)
└── Semantic Chunking(Kamradt)
Contextual Chunking with LLMs(独立维度)

注意 Contextual Chunking 不在切分方法的层级里——它是对已切好的 chunk 做上下文增强，正交于切分方法。这是下一节要讨论的关键。

6. 切分与增强的正交性

Semantic Chunking ≠ Contextual Chunking。虽然两者都涉及 LLM 或 embedding，名称相似，但解决的问题完全不同。

	Semantic Chunking	Contextual Chunking
解决的问题	在哪里切?	切完之后每块缺上下文怎么办？
利用 LLM/embedding 做什么	用 embedding 距离检测话题切换	用 LLM 给每个 chunk 生成上下文摘要
输出	不同大小的 chunk	增强后的 chunk（原文 + 摘要）
是否互斥	否，可以组合使用	否，可以组合使用

把它们拆开来看，一个 RAG 系统的 chunking 设计实际上是两个独立维度的组合:

切分维度(必选其一):    fixed-size | recursive | doc-structure | semantic
增强维度(可选叠加):    none | heading prefix | contextual chunking | ...

这种正交分离的思维意味着可以独立调试每个维度——先选定切分方法，再决定要不要叠加增强；或者先验证基础切分够不够好，再考虑是否需要 contextual 增强。

7. Recursive 的本质:用形式逼近语义

Recursive Character Splitter 的默认分隔符列表是 ["\n\n", "\n", " ", ""]，按优先级递归切分。它通常比 fixed-size 更”聪明“，因为它利用的不是语义信号本身，而是人类书写习惯的代理信号(proxy signal)。人写作时会用 \n\n 表示话题切换、\n 表示句子结尾——这些都是结构形式，不是语义。Recursive 的核心假设是”形式边界 ≈ 语义边界“。

这个假设在格式良好的文档上成立，但形式边界并非永久成立，比如：

同一段落里也可能切换话题(\n\n 失灵)
一个话题可能跨多段(\n\n 过度切分)

理解了 Recursive 是 proxy signal 之后，就知道它什么时候会失灵——结构形式与实际话题边界不一致的文档（语音转写、聊天记录、不规范笔记）。这种文档恰好是 Semantic Chunking 的舞台。

8. Semantic Chunking 的真实成本

很多教程会推荐 Semantic Chunking 作为"更聪明"的选择，但生产环境很少用它。原因是成本：

	Recursive	Semantic
计算成本	接近 0，纯字符串处理	每个句子都要 embedding
处理时间	1MB 文档 < 1 秒	1MB 文档约几分钟
API 调用	0	数千到数万次
工程复杂度	几行代码	需处理 batch、阈值调参

Pinecone 用 "experimental" 形容它不是说效果差——而是性价比还没到能作为默认选项的程度。处理 100k 文档的语料库时，semantic 切分一次可能要跑几小时，这对快速迭代是致命的。

生产系统里更常见的组合是 "Recursive 或 structure-based 切分 + contextual chunking 增强"——避开 semantic 的预处理代价,但通过后处理弥补语义自洽性。这又是正交分离思维的应用。

9. 工程选型的多维权衡

把所有方法放进一个三维矩阵:

方法	Quality	Speed	Cost
Fixed-size	一般	极快	极低
Recursive	较好	极快	极低
Doc-structure	好(前提:结构存在)	快	低
Semantic	好	慢	高
+ Contextual 增强	提升	略慢	略高

工程选型不是”选最好的“，而是在 quality / speed / cost 三角形里找项目能接受的点。语音转写场景可以接受 semantic 的高成本，因为没别的选择；规范文档场景就完全没必要付 semantic 的代价。

数据规模也是一个隐含约束:

小数据集(< 1k 文档)：怎么选都行,成本差异微不足道
中等数据集(1k - 100k 文档)：开始要权衡，semantic 的预处理时间显著
大数据集(> 100k 文档)：semantic 几乎不可行，必须用更便宜的方法 + 后处理增强

10. 把 chunk size 当超参数搜索

文章最后给出的调优指南本质上是一个超参数搜索：

With a representative dataset, create the embeddings for the chunk sizes you want to test and save them in your index (or indices).

把它翻译成操作步骤：

构建 query 集：从真实使用场景采样问题，人工标注每个 query 应该命中的 gold chunk
dev / test split:按 7:3 分，test set 锁起来不看
候选 size 列表：[128, 256, 512, 1024]
每个 size 切分 → embed → 建索引：用不同 namespace 隔离
在 dev set 上跑 query：评估 recall@k、MRR 等指标
选出 dev set 上最优 size
在 test set 上验证一次：报告最终性能;如果与 dev 差距大说明 dev 上 overfit

起初向 Claude 阐述我的想法时，说的是训练集和测试集，后来它纠正了我：RAG 评估的标准术语是 dev set / test set,不是”训练集/测试集“——因为 RAG 系统里没有”模型训练“这一步，调的是 pipeline 工程参数,不是模型权重。

结合之前的量化探索，考虑进阶一步：Monte Carlo 重采样验证稳定性。多次随机重采样 dev/test split，看选出的“最优 chunk size”在不同 split 下是否稳定。如果 256 在 split 1 是最优、512 在 split 2 是最优，说明信号很弱，需要更大的 query 集才能做出可靠决策。

参考

Hello, World

Tue, 05 May 2026 00:00:00 GMT

这是博客上线后的第一篇文章,只是用来验证流程。

后面会陆续把已经写好的笔记搬过来,从 chunking 学习笔记开始。

note-agent Tag System Design

Tue, 05 May 2026 00:00:00 GMT

note-agent 在处理部分语料时，存在 tag 推荐过于宽泛的现象（例如对一篇关于豆包的新闻只输出 AI 和 付费）。在与 Claude 讨论时进一步发现：即便换上更精准的 tag，多个 tag 之间也存在「维度混杂」的扁平化问题——主体、概念、项目归属被塞进同一个命名空间。两个问题的本质相通，于是写下这篇关于 tag 设定的标准与最佳实践。

1. tag 与 folder 的正交性

原则

类似于 chunking design，能由文件结构本身提供的信息，就不必再让 LLM 通过语义来生成——这是工程上“用确定性换概率性”的常规手段。一篇笔记的 folder 路径已经具备了大方向的前置信息，如：当一级目录是 AI/ 时，所有归入此目录的笔记天然具有"AI 类"属性，再用 AI 作 tag 是信息冗余。

因此 tag 设计的第一条规范是：tag 与 folder 提供的信息应当非冗余——禁止 tag 与目录名重复。

关于"正交"一词的语义说明

此处的"正交"采用 The Pragmatic Programmer 第 10 章给出的工程语义[2]：

"Two or more things are orthogonal if changes in one do not affect any of the others."

即独立、解耦、信息不重复编码——比数学上严格的"内积为零、互信息为零"要弱。Wikipedia 的 Orthogonality (programming) 词条也沿用此约定[3]。tag 与 folder 在严格数学意义上不可能完全独立（folder 路径会限制 tag 的合理取值），但可以做到工程意义上的非冗余：改 folder 不必同步改 tag，反之亦然。

2. tag 命名的 schema

衡量一个 agent 的可靠性需要充分的 eval 支撑。为了让 eval 能稳定打分，应当优先建立机械可验证的命名规则——能用正则解决的事情就不要消耗 LLM token：

专有名词：保留官方英文写法或 PascalCase（如 ByteDance、OpenAI、iPhone、GPT-4、LLaMA）
概念类 tag：全小写 + kebab-case（ai-monetization、ai-chatbot、ad-driven-growth）
禁止：空格、下划线混用、中文（与代码标识符的英文规范保持一致）、与目录名重复的词

确立后将这些规则作为硬约束写入 system prompt，并在 eval 框架中加入正则校验层，不符合命名规范的 tag 直接扣分。这样就把 tag 质量分解成两个非冗余的维度：

维度	验证方式	成本
命名合规性	regex（机械、确定）	接近零
语义准确性	LLM judge	消耗 token

前者免费且确定，后者才需要消耗推理成本——这是又一条工程上"非冗余分解"的应用。

关于 LLM judge 的可靠性

一个常见的疑虑是：tag 本身就是 LLM 生成的，再让 LLM 来 judge 不是循环吗？

并不是。原因有三：

生成与判别不对称：生成 tag 时模型要平衡多个目标（具体性、规范性、与 folder 不冗余等），判别时只需回答单一窄问题，注意力集中，错误率远低于生成。
实证支持：Zheng et al. (2023) 的研究表明，强 LLM judge（如 GPT-4）与人类专家的一致率可达 80% 以上，与人类专家之间的互相一致率持平[4][5]。
缓解偏差：让 judge 模型与生成器不同（例如用 DeepSeek 生成、用 Claude judge），可直接规避 self-enhancement bias[4]。

但 LLM-as-judge 不是无脑可信的，需要：

拆解为多个单维度 yes/no 判别而非整体打分
用 30-50 条人工标注样本做小规模校准，确认 judge 与人工的一致率 ≥ 75% 后再大规模部署
警惕 position bias、verbosity bias、self-enhancement bias 等已知偏差[4]

这一步在思路上等同于量化策略的 out-of-sample 验证：先在小样本上证明评估器自身可靠，再用它去评估大规模产出。

3. tag 命名的 namespace

问题：扁平 namespace 的维度混淆

目前个人笔记中的 tag 存在维度混淆，例如：

Doubao —— 主体（这篇笔记关于谁/是什么）
ai-monetization —— 概念（涉及什么思想/范畴）
note-agent —— 项目归属（属于哪个工程）
wechat —— 来源（笔记从哪里导入，例如经由微信渠道同步）

这四类 tag 处于同一个扁平的 namespace 时会带来一个隐蔽问题：当未来搜索 note-agent，预期返回的是该项目的设计文档，还是为这个项目搜集的语料？两种意图会冲突，扁平 tag 不会告诉用户它们的区别。

这本质上是上一节"正交性"的同一原则反过来用——不同维度的信息不应当挤进同一个命名空间。

解决方案：用 `/` 显式声明维度

Obsidian 原生支持嵌套 tag，使用 / 作为分层符号[6][7]。建议规划如下 namespace：

Namespace	含义	命名规范	例子
`project/`	项目归属	kebab-case（匹配 repo 名）	`project/note-agent`, `project/dlms-agent`, `project/stock-system`
`topic/`	概念 / 方法论	kebab-case	`topic/orthogonality`, `topic/eval-design`, `topic/prompt-engineering`
`subject/`	真实世界主体（人 / 公司 / 产品）	保留原始大小写	`subject/Doubao`, `subject/ByteDance`, `subject/OpenAI`
`type/`	笔记类型	kebab-case	`type/news-summary`, `type/design-doc`, `type/retrospective`
`source/`	笔记的导入来源	kebab-case	`source/wechat`, `source/rss`, `source/manual`

渐进原则：schema 应被使用反推，而非先验设计

不要一开始就启用全部 namespace。建议先用 project/ 加无前缀的混合 tag（subject、topic 暂时混在一起）跑两到四周，观察实际检索行为缺什么——

"我想看所有 note-agent 的设计文档" → 需要 type/design-doc
"我想看所有提到正交性的笔记" → 需要 topic/orthogonality
"我想看所有从微信同步过来的内容" → 需要 source/wechat

让 pain point 来驱动 namespace 的扩张。这与量化系统中"先有信号再加约束"的开发节奏是一致的：结构源于使用，而不是反过来。

4. 从设计到落地：本站的标签体系实现

上面三节确立了原则，但"写在文档里的规范"会随时间漂移。真正让它生效的，是把规则代码化为唯一事实源，并在构建期强制执行——不合规就直接 fail build。本站（Astro）的落地方式如下，所有规则集中在 src/lib/tags.ts 一处。

4.1 命名空间白名单

在第 3 节草案的基础上补齐了 series/，最终启用六个命名空间：

Namespace	含义	每篇上限	命名
`subject/`	文章关于的核心对象（人 / 公司 / 产品 / 技术实体）	2	原始大小写 / PascalCase
`topic/`	概念 / 方法论 / 议题	不限	kebab-case
`type/`	文章体裁（封闭枚举）	1（惯例）	见 4.2
`project/`	所属工程项目，匹配 repo 名	1	kebab-case
`series/`	连载系列，把多篇文章串成一条阅读路径	1	kebab-case
`source/`	内容的导入来源 / 渠道	1	kebab-case

subject/ 限两个，是为了逼出"这篇到底关于谁"的取舍——主体一多，检索时的指向性就被稀释（呼应第 3 节的维度混淆问题）。

4.2 type 作为封闭枚举

type/ 的取值不是自由文本，而是一个受控集合：retrospective / case-study / methodology / study-note / design-doc / news-summary / meta / note。新增体裁必须先改枚举、再使用——避免"随手造一个新 type"造成同义碎片。

4.3 受控词表与同义词

历史写法与同义词集中登记，构建期会拒绝非规范写法并指向规范标签（如 rag → subject/RAG、learning-note → type/study-note）。这等价于 Stack Overflow 的 tag synonyms[8]：永远只让一个规范标签存在，别让 llm 与 LLM 各自成页。

4.4 三道关口，一个事实源

关口	触发时机	作用
zod `superRefine`（内容 schema）	`astro build` / `astro check`	不合规直接 fail build，并指出文件与原因
`npm run lint:tags`（vitest）	本地 / CI	全量扫描所有文章（含草稿），给出可读报告
标签页渲染	构建产出	按命名空间分组、显示标签说明，复用同一份白名单

命名合规性由正则（机械、零成本）守住，语义准确性才留给人工 / LLM judge——正是第 2 节"非冗余分解"的直接落地：能用确定性手段解决的，就不消耗推理成本。

4.5 标签说明（tag-wiki）

每个标签页顶部可显示一句定义（来自 TAG_DESCRIPTIONS），借鉴 Stack Overflow 的 tag-wiki：让标签不只是过滤器，也是一个有解释的索引入口。

4.6 仍然遵循"结构源于使用"

以上数量上限与枚举都是起点而非教条，且全部集中在一处可改。第 3 节的渐进原则依然成立：让真实的检索 pain point 驱动枚举与命名空间的演化，而不是先验地一次配全。

参考

[1] Denvir, B. T. (1979). On orthogonality in programming languages. ACM SIGPLAN Notices, 14(7), 18–30. https://dl.acm.org/doi/10.1145/953029.808475

[2] Hunt, A., & Thomas, D. (2019). Topic 10: Orthogonality. In The Pragmatic Programmer: Your Journey to Mastery (20th Anniversary Edition). Addison-Wesley. https://www.oreilly.com/library/view/the-pragmatic-programmer/9780135956977/f_0028.xhtml

[3] Wikipedia. Orthogonality (programming). https://en.wikipedia.org/wiki/Orthogonality_(programming)

[4] Zheng, L., Chiang, W.-L., Sheng, Y., et al. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. NeurIPS 2023. https://arxiv.org/abs/2306.05685

[5] Evidently AI. LLM-as-a-judge: a complete guide to using LLMs for evaluations. https://www.evidentlyai.com/llm-guide/llm-as-a-judge

[6] Obsidian Help. Tags. https://obsidian.md/help/tags

[7] Obsidian Forum. Nested tags. https://forum.obsidian.md/t/nested-tags/169

[8] Stack Overflow Help. What are tag synonyms and how do they work? https://stackoverflow.com/help/tag-synonyms

Dingfan X.

UART DMA 首字节丢失与 USB 32 字节截断排查

现象

原因

几种解决方向

一个未消除的低概率现象：32 字节截断

可能的具体诱因

验证与解决方向

参考资料

EEPROM 页回绕问题调试记录

现象

线索

推测

验证

分析

修复

结论

Chunking Strategies for RAG

1. Chunking 的本质：信息完整度 vs 信息纯度的权衡

2. chunk size 的双重影响：检索 vs 生成

3. 被混淆的损失机制

机制 A：Embedding 的容量压缩损失

机制 B：Lost-in-the-Middle

两个机制的对照

4. RAG vs Long Context：为什么前者还没被淘汰

关于 prefill 和 decoding

5. 几种 Chunking 方法

6. 切分与增强的正交性

7. Recursive 的本质:用形式逼近语义

8. Semantic Chunking 的真实成本

9. 工程选型的多维权衡

10. 把 chunk size 当超参数搜索

参考

Hello, World

note-agent Tag System Design

1. tag 与 folder 的正交性

原则

关于"正交"一词的语义说明

2. tag 命名的 schema

关于 LLM judge 的可靠性

3. tag 命名的 namespace

问题：扁平 namespace 的维度混淆

解决方案：用 / 显式声明维度

渐进原则：schema 应被使用反推，而非先验设计

4. 从设计到落地：本站的标签体系实现

4.1 命名空间白名单

4.2 type 作为封闭枚举

4.3 受控词表与同义词

4.4 三道关口，一个事实源

4.5 标签说明（tag-wiki）

4.6 仍然遵循"结构源于使用"

参考

解决方案：用 `/` 显式声明维度