search.xml

<?xml version="1.0" encoding="utf-8"?>
<search>
  <entry>
    <title>Adaptive RAG（二）：Retrieval Gate 怎么判断该不该检索</title>
    <url>/2026/06/10/AI-Adaptive-RAG-Retrieval-Gate/</url>
    <content><![CDATA[<p>上一篇把 Adaptive RAG 的问题收束到一个工程动作：先做显式 retrieval gate。它不是为了替代 Self-RAG、FLARE 或 DRAGIN，而是先给系统建立一个可观测的判断层：当前状态到底该不该检索。</p>
<p>这篇继续往下走，讨论 retrieval gate 应该吃什么信号、输出什么结论，以及怎么评测它。</p>
<span id="more"></span>

<h2 id="要解决的问题"><a href="#要解决的问题" class="headerlink" title="要解决的问题"></a>要解决的问题</h2><p>不要把低置信度直接等同于检索需求。低置信度可能来自语言表达困难、格式约束复杂、候选答案接近，也可能只是模型在一个不需要外部事实的问题上犹豫。</p>
<p>反过来，高置信度也不代表答案被证据支持。模型可以非常自信地复述一个错误事实。</p>
<p>所以 retrieval gate 的判断目标应该是 evidence gap，而不是 confidence gap。它要回答的是：继续生成前，当前结论是否缺少外部证据、是否需要查证、是否存在冲突材料，以及检索的收益是否超过成本。</p>
<h2 id="主线判断"><a href="#主线判断" class="headerlink" title="主线判断"></a>主线判断</h2><p>Retrieval Gate 的主线不是训练一个更聪明的二分类器，而是建立一条检索责任边界。</p>
<p>Gate 必须解释为什么查、查什么、何时不查，以及失败后如何降级。只要这些信息没有被记录，后面再强的 retriever 和 reranker 都只能修补局部效果，无法回答系统级问题：这次错误到底是不该检索、没检索、query 错了，还是证据接入错了。</p>
<h2 id="最小抽象"><a href="#最小抽象" class="headerlink" title="最小抽象"></a>最小抽象</h2><p>一个可用的 retrieval gate 不应该只看最后一段 prompt。输入可以分成四层：</p>
<ul>
<li>任务层：是否要求事实核验，是否有时间、版本、实体等易变信息；</li>
<li>状态层：当前子问题是什么，已有证据覆盖了哪些结论；</li>
<li>模型层：候选答案是否分歧，关键槽位是否缺失；</li>
<li>成本层：延迟预算、上下文窗口、检索次数和 rerank 成本。</li>
</ul>
<p>输出也不能只是 yes&#x2F;no：</p>
<figure class="highlight json"><table><tr><td class="code"><pre><span class="line"><span class="punctuation">&#123;</span></span><br><span class="line">  <span class="attr">&quot;should_retrieve&quot;</span><span class="punctuation">:</span> <span class="literal"><span class="keyword">true</span></span><span class="punctuation">,</span></span><br><span class="line">  <span class="attr">&quot;reason_code&quot;</span><span class="punctuation">:</span> <span class="string">&quot;missing_fact&quot;</span><span class="punctuation">,</span></span><br><span class="line">  <span class="attr">&quot;query_intent&quot;</span><span class="punctuation">:</span> <span class="string">&quot;verify-current-claim&quot;</span><span class="punctuation">,</span></span><br><span class="line">  <span class="attr">&quot;required_evidence&quot;</span><span class="punctuation">:</span> <span class="punctuation">[</span><span class="string">&quot;source&quot;</span><span class="punctuation">,</span> <span class="string">&quot;version&quot;</span><span class="punctuation">,</span> <span class="string">&quot;date&quot;</span><span class="punctuation">]</span><span class="punctuation">,</span></span><br><span class="line">  <span class="attr">&quot;budget&quot;</span><span class="punctuation">:</span> <span class="punctuation">&#123;</span></span><br><span class="line">    <span class="attr">&quot;max_candidates&quot;</span><span class="punctuation">:</span> <span class="number">20</span><span class="punctuation">,</span></span><br><span class="line">    <span class="attr">&quot;max_context_tokens&quot;</span><span class="punctuation">:</span> <span class="number">1800</span></span><br><span class="line">  <span class="punctuation">&#125;</span><span class="punctuation">,</span></span><br><span class="line">  <span class="attr">&quot;fallback&quot;</span><span class="punctuation">:</span> <span class="string">&quot;answer_with_uncertainty&quot;</span></span><br><span class="line"><span class="punctuation">&#125;</span></span><br></pre></td></tr></table></figure>

<p>这里的 <code>reason_code</code> 是优化入口。它能把失败分成不该检索却检索、该检索却没检索、query intent 错、证据要求过宽、成本预算过紧或 fallback 不合理。</p>
<h2 id="工程闭环"><a href="#工程闭环" class="headerlink" title="工程闭环"></a>工程闭环</h2><p>Gate 之后通常接 query builder。这里要避免把模型尚未验证的猜测直接写进 query。模型猜出的实体应该标记成 assumption，而不是事实。</p>
<p>评测 gate 时，需要单独标注 <code>should_retrieve</code>、触发原因、实际决策、检索后证据是否支持答案，以及最终答案是否因检索改善。核心指标包括 trigger precision、trigger recall 和 support gain。</p>
<p>要警惕一个假阳性：检索发生了，答案也对了，但证据并没有支撑答案。这个样本不能算 retrieval gate 成功，因为系统只是多走了一步碰巧没有坏掉。</p>
<h2 id="设计取舍"><a href="#设计取舍" class="headerlink" title="设计取舍"></a>设计取舍</h2><p>Retrieval Gate 的训练信号有三种来源。第一种是人工标注，直接标出某一步是否需要检索；它最清晰，但成本高。第二种是弱监督，根据答案是否依赖外部证据、检索后是否改善、无检索是否出错来反推标签。第三种是在线反馈，把引用证据、回退和人工修正变成 gate 的长期信号。</p>
<p>工程上更常见的是混合策略：先用规则保护高风险场景，再用弱监督扩大样本，最后用人工抽检校准边界。不要一开始就把 gate 完全交给模型，因为 gate 的错误会改变后续上下文，错误样本也会变得难以解释。</p>
<p>证据预算也要和 retrieval gate 绑定。retrieve&#x3D;true 不代表无限拉文档。gate 应该同时输出预算：查几个 query、每个 query 取几段、是否需要 rerank、是否需要二次检索。这样检索才是有成本意识的动作。</p>
<h2 id="评测矩阵"><a href="#评测矩阵" class="headerlink" title="评测矩阵"></a>评测矩阵</h2><p>Retrieval Gate 的评测不能只看最终 QA 分数。至少需要 trigger precision、trigger recall、unnecessary retrieval rate、evidence support rate 和 answer attribution rate。</p>
<p>trigger recall 低说明 gate 太保守；trigger precision 低说明检索噪声多；evidence support rate 低说明 query 或 retriever 有问题；answer attribution rate 低说明生成层没有正确使用证据。把这些指标拆开，才能知道下一步该调 gate、改 query、换证据组织，还是修生成模板。</p>
<h2 id="失败归因"><a href="#失败归因" class="headerlink" title="失败归因"></a>失败归因</h2><p>最典型的坏 gate 有三种。第一种是焦虑型 gate，一不确定就查，导致系统成本高、上下文噪声多。第二种是自信型 gate，模型语言很流畅，却在缺事实时跳过检索。第三种是追随型 gate，根据已经生成的错误中间结论继续检索，把错误路径越走越深。</p>
<p>排查时不要只看最终答案。要回放每一次 gate 输入、gate 输出、query、证据和生成片段。只要能定位到该查没查、不该查却查、query 写错还是证据没用上，Adaptive RAG 才具备可迭代性。</p>
<h2 id="小样本推演"><a href="#小样本推演" class="headerlink" title="小样本推演"></a>小样本推演</h2><p>一个回答生成到中途时出现了三个信号：实体名称含糊、已有证据相互冲突、继续生成会给出具体数字。一个可用的 gate 会输出类似 <code>entity_ambiguous + evidence_conflict</code> 的 reason code，并把 query 限制在“澄清实体”和“验证冲突事实”上。</p>
<p>如果 gate 只看到低置信度就触发全文检索，结果可能召回很多相似段落，却没有解决实体歧义。这样的检索看起来勤奋，实际是在把不确定性扩散到更大的上下文。</p>
<h2 id="直接结论"><a href="#直接结论" class="headerlink" title="直接结论"></a>直接结论</h2><p>retrieval gate 的价值不是让 Adaptive RAG 看起来更复杂，而是把检索从隐式 prompt 技巧变成显式责任边界。它负责判断何时查证、为什么查证、查什么、查到什么程度，以及失败时如何降级。</p>
<p>当 gate、query builder、retriever、reranker、evidence validator 都有日志和指标时，RAG 才能进入真正的工程迭代。否则每次效果波动都只能归因给“模型不稳定”。</p>
<p>下一步阅读：<a href="/2026/06/10/Agentic-Coding-Governance/">Agentic Coding 工程治理：多模型协作先定义责任边界</a></p>
]]></content>
      <tags>
        <tag>AI</tag>
        <tag>RAG</tag>
        <tag>LLM</tag>
        <tag>Open Source</tag>
      </tags>
  </entry>
  <entry>
    <title>Adaptive RAG（一）：何时检索比检索多少更重要</title>
    <url>/2026/06/10/AI-Adaptive-RAG-Retrieval-Scheduling/</url>
    <content><![CDATA[<p>RAG 最容易被讲成一个检索增强公式：切块、向量化、取 top-k、拼进 prompt、让模型回答。这个公式很实用，但它默认了一件事：系统在回答之前已经知道自己缺什么信息。</p>
<p>复杂任务里，这个假设经常不成立。问题可能在生成到一半才暴露，证据可能和当前结论冲突，召回内容也可能只是语义相似而不是事实支撑。于是 Adaptive RAG 真正要解决的不是“多检索一些”，而是：系统什么时候应该承认当前上下文不够，并把检索变成下一步可验证动作。</p>
<span id="more"></span>

<h2 id="要解决的问题"><a href="#要解决的问题" class="headerlink" title="要解决的问题"></a>要解决的问题</h2><p>固定检索的失败通常不来自某一个 retriever 太弱，而来自检索时机和信息需求没有被显式建模。</p>
<p>一个简单 RAG 流程会在用户问题进入后立刻检索。这样做稳定、便宜、容易缓存，但它把不同问题压成同一个接口：不管是事实核验、多跳推理、摘要归纳还是工具调用后的验证，都先取一批相似片段。</p>
<p>这会带来三个工程问题。语义相关不等于证据支持；召回时机固定会浪费上下文窗口；失败原因不可分解，无法判断错误来自触发、query、召回、rerank 还是生成。</p>
<p>所以 Adaptive RAG 的第一性问题不是 top-k，而是 evidence gap detection：当前状态是否真的缺少外部证据。</p>
<h2 id="主线判断"><a href="#主线判断" class="headerlink" title="主线判断"></a>主线判断</h2><p>Adaptive RAG 的主线不是把检索次数调多，而是把“为什么需要外部证据”变成系统状态。</p>
<p>如果检索只是 top-k 参数，系统只能在召回质量上打转；如果检索是 evidence gap 的响应，系统就能把触发、query、证据支持和最终生成拆开评估。这个区别决定了后续是继续堆上下文，还是能真正进入可调试的工程闭环。</p>
<h2 id="最小抽象"><a href="#最小抽象" class="headerlink" title="最小抽象"></a>最小抽象</h2><p>一个更稳的抽象不是“某个 token 需要检索”，而是“当前状态暴露了一个证据缺口”：</p>
<figure class="highlight text"><table><tr><td class="code"><pre><span class="line">information_need = &#123;</span><br><span class="line">  state: 当前子问题、生成阶段或工作流节点,</span><br><span class="line">  uncertainty: 不确定性来自模型分歧、槽位缺失还是证据冲突,</span><br><span class="line">  evidence_gap: 需要什么外部证据才能继续,</span><br><span class="line">  action: 是否检索、查什么、查哪里、如何验证</span><br><span class="line">&#125;</span><br></pre></td></tr></table></figure>

<p>Self-RAG、FLARE、DRAGIN 这类方法的启发在于把检索放进生成过程，但落地时仍然要回答一个更朴素的问题：这次检索为什么发生。</p>
<p>GraphRAG 和 KG-RAG 则解决证据组织问题，把文本块升级为实体、关系、社区摘要和路径。它们适合跨文档、多跳、关系密集的场景，但不应该替代最基础的触发和验证机制。</p>
<h2 id="工程闭环"><a href="#工程闭环" class="headerlink" title="工程闭环"></a>工程闭环</h2><p>第一版 Adaptive RAG 更适合先做显式 Retrieval Gate：</p>
<figure class="highlight text"><table><tr><td class="code"><pre><span class="line">State Snapshot</span><br><span class="line">  -&gt; Retrieval Gate(reason_code)</span><br><span class="line">  -&gt; Query Builder(query, assumptions)</span><br><span class="line">  -&gt; Hybrid Retriever(candidates)</span><br><span class="line">  -&gt; Reranker(ranked_candidates)</span><br><span class="line">  -&gt; Evidence Validator(supported / unsupported / conflict)</span><br><span class="line">  -&gt; Generate or Rollback</span><br></pre></td></tr></table></figure>

<p>Gate 不能只输出 yes&#x2F;no。它至少要输出 reason code，例如 <code>missing_fact</code>、<code>stale_context</code>、<code>entity_ambiguous</code>、<code>evidence_conflict</code>、<code>cost_guard</code>。这样后续评测才能分清是不该检索却检索了，还是该检索却没检索。</p>
<p>评测也要拆成触发质量、证据质量和系统质量。尤其要看 evidence support rate，把“召回到了相似内容”和“召回到了能支撑答案的证据”区分开。没有这个指标，Adaptive RAG 很容易退化成 expensive RAG。</p>
<h2 id="设计取舍"><a href="#设计取舍" class="headerlink" title="设计取舍"></a>设计取舍</h2><p>检索触发可以按强度分成五类。最弱的是固定触发，也就是每个问题都查；它稳定但成本高，且容易把相似但无关的片段带进上下文。第二类是显式控制信号，让模型在需要外部知识时发出 retrieve 请求。第三类是置信度或熵触发，用生成分布的不确定性作为信号。第四类是信息需求分类器，直接判断当前步骤是否需要外部证据。第五类是工作流路由，让不同节点决定是否进入检索分支。</p>
<p>这些方案没有绝对优劣。固定触发适合高召回冷启动，显式信号适合可解释训练闭环，置信度触发适合弱标注场景，信息需求分类适合离线评测，工作流路由适合复杂系统。真正的取舍，是在触发精度、漏检风险、检索成本和可调试性之间选平衡点。</p>
<p>query 构造也要谨慎。很多系统会让模型先猜一个中间结论，再拿这个结论去检索。这个策略在简单问题上有效，但在多跳问题里会把未验证假设写进检索条件。更稳的做法是把 query 写成待验证的信息需求，而不是已经相信的事实。</p>
<h2 id="失败归因"><a href="#失败归因" class="headerlink" title="失败归因"></a>失败归因</h2><p>Adaptive RAG 的常见失败不是没查到，而是系统不知道自己为什么查。如果触发器过敏，系统会在每个推理节点都检索，退化成高成本的固定 RAG。如果触发器保守，模型会在最需要事实校验时跳过检索。如果 query 由早期猜测生成，错误假设会被检索结果强化。如果证据接入没有分层，短证据会被长上下文稀释，模型最后仍然按自身偏好回答。</p>
<p>因此，调 Adaptive RAG 不应该先换 embedding 或向量库，而应该先看触发日志、query 变形和证据支持关系。retriever 是执行器，信息需求才是调度器。</p>
<h2 id="小样本推演"><a href="#小样本推演" class="headerlink" title="小样本推演"></a>小样本推演</h2><p>假设模型正在回答一个依赖版本差异的问题：前半段推理可以来自已有上下文，但当它要给出具体接口行为时，当前状态暴露出 <code>stale_context</code> 和 <code>missing_fact</code> 两个缺口。</p>
<p>这时 gate 不应该简单地说“检索 yes”，而要记录：缺的是版本证据，query 应围绕接口行为和版本号构造，召回结果必须能直接支持或推翻当前结论。如果检索后只拿到语义相似的教程，而没有版本证据，这次检索应被标为 unsupported，而不是继续塞进 prompt。</p>
<h2 id="直接结论"><a href="#直接结论" class="headerlink" title="直接结论"></a>直接结论</h2><p>Adaptive RAG 的核心不是“多检索几次”，而是让检索成为可记录、可回放、可评估的动作。第一版系统最应该做的是显式 Retrieval Gate：说明为什么触发，构造了什么 query，召回了哪些候选，证据是否支持当前结论，以及这次检索带来了多少延迟和成本。</p>
<p>只要这条链路清楚，后面再替换成 Self-RAG、FLARE、DRAGIN 或 GraphRAG，都有比较基线。否则系统只是把更多上下文交给模型碰运气。</p>
<p>下一步阅读：<a href="/2026/06/10/AI-Adaptive-RAG-Retrieval-Gate/">Adaptive RAG（二）：Retrieval Gate 怎么判断该不该检索</a></p>
]]></content>
      <tags>
        <tag>AI</tag>
        <tag>RAG</tag>
        <tag>LLM</tag>
        <tag>Open Source</tag>
      </tags>
  </entry>
  <entry>
    <title>ASR 特征归一化：CMVN 解决的不是数值美观，而是通道偏移</title>
    <url>/2021/08/24/ASR-CMVN/</url>
    <content><![CDATA[<p>语音识别里的特征归一化很容易被当成预处理细节：把均值拉到 0，把方差压到 1，然后继续训练模型。这个理解没有错，但它没有说清楚 CMVN 真正解决的问题。</p>
<p>CMVN 要处理的是录音设备、信道、说话环境和能量尺度带来的系统性偏移。它不是为了让特征“好看”，而是为了让声学模型少花容量去适配无关的通道差异。</p>
<span id="more"></span>

<h2 id="要解决的问题"><a href="#要解决的问题" class="headerlink" title="要解决的问题"></a>要解决的问题</h2><p>ASR 特征通常来自频谱或倒谱空间。同一句话在不同麦克风、不同音量、不同环境下，语义内容没有变，但特征分布会整体漂移。如果模型直接学习这种漂移，就会把说话内容和采集条件混在一起。</p>
<p>这会带来两个后果。第一，训练集和线上环境不一致时，识别效果容易波动。第二，模型会浪费参数容量去拟合信道差异，而不是发音和词序本身。</p>
<p>CMN（Cepstral Mean Normalisation）只减均值，CMVN（Cepstral Mean Variance Normalisation）同时处理均值和方差。它们的核心都是把每段语音或每个窗口内的统计尺度拉回到相对稳定的空间。</p>
<h2 id="主线判断"><a href="#主线判断" class="headerlink" title="主线判断"></a>主线判断</h2><p>CMVN 的主线不是把特征标准化成固定形状，而是把无关的信道偏移从声学建模里剥离出去。</p>
<p>它的收益取决于环境差异、统计窗口和实时约束。离线任务里可以追求更稳定的全局统计，在线任务里则必须面对窗口延迟和冷启动边界。把 CMVN 当成默认开关，会掩盖真正需要评估的取舍。</p>
<h2 id="最小抽象"><a href="#最小抽象" class="headerlink" title="最小抽象"></a>最小抽象</h2><p>可以把 CMVN 看成一个局部滤波器：</p>
<figure class="highlight text"><table><tr><td class="code"><pre><span class="line">feature_t -&gt; feature_t - mean(window)</span><br><span class="line">feature_t -&gt; (feature_t - mean(window)) / std(window)</span><br></pre></td></tr></table></figure>

<p>这个抽象有两个关键点。第一，它处理的是特征统计分布，而不是语音内容。第二，它需要一个统计窗口，窗口越长越稳定，延迟越高；窗口越短越实时，统计越不稳。</p>
<p>离线训练时，可以基于整段语音或全训练集统计。在线识别时，只能用滑动窗口或历史缓存，这就引入了响应时间和边界效应。</p>
<h2 id="工程闭环"><a href="#工程闭环" class="headerlink" title="工程闭环"></a>工程闭环</h2><p>CMVN 是否值得保留，不能只看单条样本效果，应该看三个维度。</p>
<ul>
<li>准确率：字错率、词错率或关键实体召回是否改善；</li>
<li>延迟：在线滑动窗口是否增加首包或尾包时间；</li>
<li>鲁棒性：不同设备、不同音量、不同噪声条件下是否更稳定。</li>
</ul>
<p>在传统 GMM-HMM、DNN-HMM 或较浅的声学模型里，CMVN 往往很有价值。端到端模型和大规模预训练模型吸收了更多数据分布，特征归一化的重要性会下降，但并不代表它永远无用。只要输入分布漂移明显，CMVN 仍然是一个低成本诊断点。</p>
<h2 id="小样本推演"><a href="#小样本推演" class="headerlink" title="小样本推演"></a>小样本推演</h2><p>可以构造一个四组对照：同一批语音分别来自近讲麦、远场麦、高音量和低音量。模型不变，只比较不开 CMVN、全局 CMVN、说话人级 CMVN、滑动窗口 CMVN。</p>
<p>如果全局 CMVN 提升离线 WER，但滑动窗口版本首包明显变慢或开头几个字变差，结论就不是“CMVN 有用或无用”，而是统计窗口和实时性没有同时满足。</p>
<h2 id="直接结论"><a href="#直接结论" class="headerlink" title="直接结论"></a>直接结论</h2><p>CMVN 的工程定位是“消除无关通道偏移”，不是固定必须打开的预处理模板。离线任务可以优先验证全局或说话人级统计；实时任务要额外评估滑动窗口带来的延迟和边界误差。</p>
<p>如果模型已经足够强、训练覆盖足够广，CMVN 可能收益很小；如果线上设备、音量或环境差异明显，它仍然值得作为第一批鲁棒性实验。</p>
<p>下一步阅读：<a href="/2021/08/29/ASR-CTC/">ASR CTC：没有帧级标注时，如何把音频和文本对齐</a></p>
<h3 id="References"><a href="#References" class="headerlink" title="References"></a>References</h3><p>[1] <a href="http://www.apsipa.org/proceedings/2020/pdfs/0000532.pdf">Significance of CMVN for Replay Spoof Detection</a></p>
]]></content>
      <tags>
        <tag>ASR</tag>
        <tag>Feature-engineering</tag>
      </tags>
  </entry>
  <entry>
    <title>ASR 数据质量流水线：伪标签、切分与可追溯评测</title>
    <url>/2026/06/10/ASR-Data-Quality-Pipeline-Open-Source/</url>
    <content><![CDATA[<p>ASR 数据工程最容易被低估。模型指标波动时，很多人先调模型结构，但真正的问题常常在数据：切分不稳、伪标签质量不清、噪声样本混入、热词和实体覆盖不足、评测集不可追溯。</p>
<p>一条可用的数据质量流水线，核心不是“多收一点音频”，而是让每个样本都能解释来源、标签、置信度和进入训练集的理由。</p>
<span id="more"></span>

<h2 id="要解决的问题"><a href="#要解决的问题" class="headerlink" title="要解决的问题"></a>要解决的问题</h2><p>语音数据的成本高，人工标注慢。pseudo-label 可以快速扩大数据规模，但也会把模型错误重新灌回训练集。切片策略、静音边界、重采样、文本规范化和标签清洗都会影响最终 WER。</p>
<p>如果没有质量记录，训练效果变差时无法判断是模型退化，还是新数据污染。</p>
<h2 id="主线判断"><a href="#主线判断" class="headerlink" title="主线判断"></a>主线判断</h2><p>ASR 数据质量首先是标签契约问题，其次才是过滤规则问题。</p>
<p>音频片段、文本标签、CTC blank 边界、噪声标记、伪标签来源和评测回流必须指向同一个训练目标。只要这些对象没有对齐，数据越多，模型越容易学到互相冲突的监督信号。很多 WER 波动看起来像模型不稳，本质上是数据账本没有把“为什么保留这条样本”说清楚。</p>
<h2 id="最小抽象"><a href="#最小抽象" class="headerlink" title="最小抽象"></a>最小抽象</h2><p>可以把 ASR 数据样本看成一个 ledger entry：</p>
<figure class="highlight text"><table><tr><td class="code"><pre><span class="line">audio_id</span><br><span class="line">segment_range</span><br><span class="line">transcript</span><br><span class="line">pseudo_label_source</span><br><span class="line">confidence</span><br><span class="line">quality_flags</span><br><span class="line">normalization_version</span><br><span class="line">reason code</span><br><span class="line">eval_split</span><br></pre></td></tr></table></figure>

<p>这里的 <code>reason code</code> 很关键。保留样本、丢弃样本、降权样本都应该有原因，例如低置信、重叠语音、噪声过强、文本规范化失败、实体疑似错误。</p>
<h2 id="工程闭环"><a href="#工程闭环" class="headerlink" title="工程闭环"></a>工程闭环</h2><p>流水线至少分四层。</p>
<p>第一层是音频质量画像：采样率、时长、静音、截断、音量、噪声、重复样本。</p>
<p>第二层是文本规范化：大小写、标点、数字、热词、实体、语言混杂和非法字符。</p>
<p>第三层是伪标签仲裁：多模型一致性、置信度、CER&#x2F;WER 估计、人工抽检和 reason code。</p>
<p>第四层是评测追踪：每次训练记录数据版本、过滤规则、评测集版本和失败样本分布。</p>
<p>只有这四层都可追溯，才能在指标波动时定位到具体数据决策。</p>
<h2 id="反直觉点"><a href="#反直觉点" class="headerlink" title="反直觉点"></a>反直觉点</h2><p>最容易踩坑的是把噪声标签当成“忽略”。例如在 transcript 中加入 NOISE 这类 token，看上去是在告诉模型某段是背景声，但对 CTC 来说它仍然是一个 non-blank 目标。模型会被训练成在某些声学区域输出一个显式 token，而不是在不确定区域保持 blank。</p>
<p>这会造成两个后果。第一，背景声、非目标人声和转写文本被塞进同一条标签通道，模型不知道哪些是要识别的文字，哪些只是样本状态。第二，评测时如果再把这些 token 过滤掉，就形成了训练目标和评测目标不一致：训练时要求输出，评测时又假装它不存在。</p>
<p>pseudo-label 也有类似问题。多模型一致只能说明候选文本相近，不能说明切片边界、重叠语音、ITN 和热词都可靠。伪标签要进入主训练集，必须带上来源、置信度、过滤原因和后续评测回流。</p>
<h2 id="排障路径"><a href="#排障路径" class="headerlink" title="排障路径"></a>排障路径</h2><p>当一轮训练变差时，不要先改模型结构。先把样本按数据来源、过滤规则、规范化版本、音频时长、信噪比分桶，再看 WER&#x2F;CER 的插入、删除、替换分别在哪些桶里变坏。</p>
<p>如果删除错误增加，优先查切片边界、静音过长、低能量片段和 blank 学习是否被污染。如果插入错误增加，优先查噪声片段、非目标人声、重复音频和文本规范化。若实体或热词召回下降，重点查词表、ITN、伪标签仲裁和人工抽检样本。</p>
<p>关键是保留被过滤掉的样本列表。很多数据规则看起来提高了总体指标，却可能删掉了难例；短期变好，长期会让模型越来越不认识真实输入。</p>
<h2 id="评测设计"><a href="#评测设计" class="headerlink" title="评测设计"></a>评测设计</h2><p>一个可复盘的 ASR 数据评测至少需要三张表。样本表记录 audio_id、segment_range、transcript、pseudo_label_source、confidence、quality_flags、normalization_version 和 reason code。指标表记录 WER&#x2F;CER、插入、删除、替换、关键实体召回、长短音频分桶和噪声分桶。回流表记录每次训练后哪些样本变差、哪些规则命中、哪些样本被移入或移出。</p>
<p>这三张表要能 join 到一起。只有这样，评测才不是“模型掉点了”，而是能说清楚“某一类数据决策导致某一类错误上升”。数据质量流水线的终点不是干净数据集，而是可解释的数据决策。</p>
<h2 id="小样本推演"><a href="#小样本推演" class="headerlink" title="小样本推演"></a>小样本推演</h2><p>假设一次训练后总体 WER 只下降了 0.2，但长音频删除错误上升，短音频插入错误下降。这个结果不能简单判定为“新数据有效”。更可能的解释是：过滤规则删掉了一部分噪声短片段，让插入错误下降；同时长片段切分或 blank 边界被新标签扰动，导致删除错误上升。</p>
<p>这时下一步不是继续加数据，而是回到样本账本：长音频里哪些样本来自伪标签，哪些命中了噪声标记，哪些经过文本规范化，哪些在上轮被移入训练集。只要能把这些样本拉出来，模型问题就会变成数据决策问题；拉不出来，就说明流水线还没有形成闭环。</p>
<h2 id="直接结论"><a href="#直接结论" class="headerlink" title="直接结论"></a>直接结论</h2><p>ASR 数据质量流水线的目标不是一次性清洗干净，而是把样本生命周期变成可审计过程。pseudo-label 可以用，但必须带来源、置信度、过滤原因和评测回流。</p>
<p>下一步阅读：<a href="/2026/06/10/ASR-Noise-Structured-Extraction-Evaluation/">ASR 噪声下的结构化抽取评测：从文本相似到实体归因</a></p>
]]></content>
      <tags>
        <tag>Open Source</tag>
        <tag>ASR</tag>
        <tag>Data</tag>
        <tag>Evaluation</tag>
      </tags>
  </entry>
  <entry>
    <title>ASR CTC：没有帧级标注时，如何把音频和文本对齐</title>
    <url>/2021/08/29/ASR-CTC/</url>
    <content><![CDATA[<p>ASR 训练里有一个基础矛盾：音频是长帧序列，文本是短标签序列，但训练数据通常只有整句转写，没有每个字对应哪几帧的强制对齐。CTC（Connectionist Temporal Classification）解决的就是这个问题。</p>
<p>它的核心不是一个普通 loss，而是一套弱对齐建模方式：允许模型在不知道帧级标签的情况下，对所有可能对齐路径求和，再优化目标文本的总概率。</p>
<span id="more"></span>

<h2 id="要解决的问题"><a href="#要解决的问题" class="headerlink" title="要解决的问题"></a>要解决的问题</h2><p>给定语音输入 $X&#x3D;[x_1,x_2,…,x_T]$ 和文本输出 $Y&#x3D;[y_1,y_2,…,y_U]$，ASR 需要学习 $X$ 到 $Y$ 的映射。困难在于：</p>
<ul>
<li>$T$ 和 $U$ 长度不同，比例不固定；</li>
<li>哪些帧对应哪个字符事先不知道；</li>
<li>静音、拖音、重复字符都会让对齐路径不唯一。</li>
</ul>
<p>如果必须先做精确帧级标注，训练成本会非常高。CTC 的价值就是把这个强标注需求去掉。</p>
<p><img src="/2021/08/29/ASR-CTC/CTC.png"></p>
<h2 id="主线判断"><a href="#主线判断" class="headerlink" title="主线判断"></a>主线判断</h2><p>CTC 的主线不是一个 loss 公式，而是在没有帧级标注时管理对齐不确定性。</p>
<p>blank、重复折叠和路径求和让训练变得可行，但也引入了新的诊断问题：模型到底是声学分不清，还是 blank 过强、输入过短、解码约束太弱。CTC 工程调试要围绕这些对齐信号展开。</p>
<h2 id="最小抽象"><a href="#最小抽象" class="headerlink" title="最小抽象"></a>最小抽象</h2><p>CTC 引入 blank 符号，把一个标签序列扩展成多条可折叠路径。折叠规则很简单：先合并连续重复，再删除 blank。</p>
<p>以 <code>hello</code> 为例，路径可以包含重复字符和 blank：</p>
<figure class="highlight text"><table><tr><td class="code"><pre><span class="line">h h e _ _ l l l _ l l o -&gt; h e _ l _ l o -&gt; hello</span><br></pre></td></tr></table></figure>

<p>这样，同一个文本可以对应很多帧级路径。CTC loss 计算的是这些合法路径概率之和：</p>
<p>$$p(Y|X)&#x3D;\sum_{A \in A_{X,Y}}\prod_{t&#x3D;1}^{T}p_t(a_t|X)$$</p>
<p>直接枚举路径不可行，所以 CTC 用动态规划做前向后向求和。</p>
<p><img src="/2021/08/29/ASR-CTC/CTC_dp.png"></p>
<p><img src="/2021/08/29/ASR-CTC/CTC_compute.png"></p>
<h2 id="工程闭环"><a href="#工程闭环" class="headerlink" title="工程闭环"></a>工程闭环</h2><p>CTC 的工程判断要分训练和解码两部分。</p>
<p>训练阶段关注 loss 是否稳定下降、blank 概率是否长期过高、短句和长句是否都能收敛。CTC 对输入长度和标签长度很敏感，过短输入或过长标签会直接导致不可对齐。</p>
<p>解码阶段通常从 greedy search 或 beam search 开始：</p>
<ul>
<li>greedy search 每帧取最大概率，速度快但容易局部错误；</li>
<li>beam search 保留多个候选路径，可以接语言模型，但成本更高。</li>
</ul>
<p><img src="/2021/08/29/ASR-CTC/CTC_loss.png"></p>
<p><img src="/2021/08/29/ASR-CTC/CTC_loss_def.png"></p>
<p>CTC 的主要缺陷是条件独立假设。每个时间步输出相对独立，语言层面的长程依赖较弱，因此常见做法是在 CTC 后接语言模型、与 AED 联合训练，或用 Transducer 类结构改进流式建模。</p>
<h2 id="小样本推演"><a href="#小样本推演" class="headerlink" title="小样本推演"></a>小样本推演</h2><p>一个小样本可以包含三类句子：单字短句、重复音节句、长句。训练后分别看每类样本的 frame-level posterior。</p>
<p>如果短句几乎全是 blank，可能是 blank bias 或输入长度设置问题；如果重复音节被折叠丢失，要检查 blank 是否足以分隔重复标签；如果长句尾部删除严重，要看 encoder 下采样后长度是否仍满足 CTC 对齐约束。</p>
<h2 id="直接结论"><a href="#直接结论" class="headerlink" title="直接结论"></a>直接结论</h2><p>CTC 最适合作为“无帧级对齐训练”的基础工具。它让 ASR 可以从整句转写直接学习，但也把语言建模能力留给了解码器、外部语言模型或联合模型。</p>
<p>工程上不要只把 CTC 当 loss 名称看。真正要观察的是：输入和标签是否可对齐、blank 是否正常、beam search 是否带来稳定收益、错误主要来自声学混淆还是语言约束不足。</p>
<p>下一步阅读：<a href="/2021/08/24/ASR-LAS-model/">LAS 模型：把语音识别改写成听、对齐、拼写</a></p>
<h3 id="References"><a href="#References" class="headerlink" title="References"></a>References</h3><p>[1] <a href="https://distill.pub/2017/ctc/">Sequence Modeling With CTC</a><br>[2] <a href="https://xiaodu.io/ctc-explained/">CTC Explained</a><br>[3] <a href="https://zhuanlan.zhihu.com/p/42719047">CTC 解读</a></p>
]]></content>
      <tags>
        <tag>ASR</tag>
        <tag>ASR-Classic</tag>
        <tag>Loss</tag>
      </tags>
  </entry>
  <entry>
    <title>LAS 模型：把语音识别改写成听、对齐、拼写</title>
    <url>/2021/08/24/ASR-LAS-model/</url>
    <content><![CDATA[<p>传统 ASR 通常把声学模型、发音词典和语言模型拆成多个模块。LAS（Listen, Attend and Spell）提出的是另一种问题表述：能不能让模型先听完整段语音，再通过 attention 找到相关声学片段，最后像拼写一样输出字符序列。</p>
<p>这篇文章不把 LAS 当成历史模型罗列，而是把它看成端到端 ASR 的一个关键抽象：<strong>对齐不必显式写死，可以由 decoder 在生成时学习</strong>。</p>
<span id="more"></span>

<h2 id="要解决的问题"><a href="#要解决的问题" class="headerlink" title="要解决的问题"></a>要解决的问题</h2><p>语音识别最难的部分之一是对齐。音频帧很多，文字标签较短，而且两者长度比例不固定。传统系统通过 HMM、词典和语言模型显式管理这个问题，工程上可控，但模块多、训练链路长。</p>
<p>LAS 试图把问题压成一个序列到序列任务：输入是声学特征序列，输出是字符或子词序列。模型需要自己学习什么时候关注哪段音频。</p>
<h2 id="主线判断"><a href="#主线判断" class="headerlink" title="主线判断"></a>主线判断</h2><p>LAS 的主线不是把 ASR 改成 seq2seq，而是把对齐从显式规则交给生成过程学习。</p>
<p>这个转变带来更强的条件生成能力，也带来 attention 漂移、长音频不稳定和流式部署困难。理解 LAS 的价值，重点不在复现一个历史结构，而在看清端到端 ASR 如何把声学、对齐和语言建模揉进同一条解码链路。</p>
<h2 id="最小抽象"><a href="#最小抽象" class="headerlink" title="最小抽象"></a>最小抽象</h2><p>LAS 可以拆成两个部分。</p>
<p>Listener 是编码器，通常使用 pyramidal BiLSTM 压缩时间维度，把长音频帧变成更短的高层表示。时间下采样很重要，否则 decoder 每一步都要在过长的帧序列上做 attention。</p>
<p>Speller 是带 attention 的 decoder。它在每个输出步根据历史字符和 attention context 预测下一个字符。</p>
<p><img src="/2021/08/24/ASR-LAS-model/LAS_flow.png"></p>
<p>这个结构的本质是：</p>
<figure class="highlight text"><table><tr><td class="code"><pre><span class="line">audio frames -&gt; listener states -&gt; attention context -&gt; next character</span><br></pre></td></tr></table></figure>

<p>CTC 假设时间步相对独立，LAS 则把输出历史纳入 decoder。它更像翻译模型，因此语言建模能力更强，但训练和解码也更依赖数据规模与搜索策略。</p>
<h2 id="工程闭环"><a href="#工程闭环" class="headerlink" title="工程闭环"></a>工程闭环</h2><p>评估 LAS 这类 attention ASR，不能只看最终 WER。至少要看四件事。</p>
<ul>
<li>对齐是否稳定：长音频、重复词、静音段是否导致 attention 漂移；</li>
<li>解码是否可控：beam size、长度惩罚和外部语言模型如何影响结果；</li>
<li>延迟是否可接受：完整 attention 更适合离线，流式化需要额外结构；</li>
<li>错误是否可解释：插入、删除、重复和漏识别分别来自 encoder、attention 还是 decoder。</li>
</ul>
<p>LAS 的历史价值在于证明端到端 ASR 可以直接学习声学到文本的映射。但在实时和长音频场景里，attention 漂移、解码成本和流式约束会变成主要工程问题。</p>
<h2 id="小样本推演"><a href="#小样本推演" class="headerlink" title="小样本推演"></a>小样本推演</h2><p>可以用三条样本观察 LAS 的风险：短命令、包含重复词的句子、超过训练平均长度的长句。短命令看 decoder 是否过度依赖语言先验，重复词看 attention 是否跳过或重复，长句看注意力是否从声学尾部漂移。</p>
<p>如果短命令输出很流畅但和音频不符，这不是语言模型“强”的好事，而是声学约束不够；如果长句后半段开始幻觉，说明 attention 和长度控制需要单独评估。</p>
<h2 id="直接结论"><a href="#直接结论" class="headerlink" title="直接结论"></a>直接结论</h2><p>LAS 适合用来理解端到端 ASR 的基本范式：encoder 压缩语音，attention 做软对齐，decoder 负责条件生成。它不是现代 ASR 的终点，但很多后来的 AED、Transducer 和 Speech-LLM 结构都能从这里看出影子。</p>
<p>下一步阅读：<a href="/2026/06/10/Speech-LLM-Audio-Token-Alignment/">语音大模型工程：音频 token、LLM 主干与对齐契约</a></p>
<h3 id="References"><a href="#References" class="headerlink" title="References"></a>References</h3><p>[1] <a href="https://arxiv.org/abs/1508.01211">Listen, Attend and Spell</a><br>[2] <a href="https://github.com/AzizCode92/Listen-Attend-and-Spell-Pytorch">Listen-Attend-and-Spell-Pytorch</a></p>
]]></content>
      <tags>
        <tag>ASR</tag>
        <tag>ASR-Classic</tag>
        <tag>Deep-learning</tag>
        <tag>Attention</tag>
      </tags>
  </entry>
  <entry>
    <title>多语种 ASR：低资源、口音和统一部署之间的取舍</title>
    <url>/2022/04/22/ASR-Multilingual/</url>
    <content><![CDATA[<p>多语种 ASR 不是把多个单语模型简单合并。它真正要解决的是三个工程问题：低资源语种数据不足，口音和方言带来分布偏移，多语种部署让模型数量和维护成本快速上升。</p>
<p>如果只把多语种识别理解成“一个模型识别很多语言”，很容易忽略它背后的取舍：共享越多，迁移越强，但语种之间的干扰也越明显。</p>
<span id="more"></span>

<h2 id="要解决的问题"><a href="#要解决的问题" class="headerlink" title="要解决的问题"></a>要解决的问题</h2><p>世界上大部分语种都不是高资源语种。单独为每个语种收集大量标注数据、训练模型、维护词表和解码配置，成本很高。即使是普通话或英语，真实场景也会遇到口音、方言、跨语种夹杂和专有名词问题。</p>
<p>多语种 ASR 的价值在于让高资源语种的声学和表示能力迁移到低资源语种，同时减少部署系统里的模型数量。但它也会引入共享建模的副作用：语言边界模糊、发音空间冲突、词表膨胀和高资源语种压制低资源语种。</p>
<h2 id="主线判断"><a href="#主线判断" class="headerlink" title="主线判断"></a>主线判断</h2><p>多语种 ASR 的主线不是让一个模型覆盖更多语言，而是管理共享表示带来的迁移收益和语言干扰。</p>
<p>共享声学层可以帮助低资源语种，统一 tokenizer 可以降低维护成本，但高资源语种也可能压制低资源语种，语言边界也可能在 code-switching 中变模糊。多语种工程的核心是先定义评测分组，再谈模型规模。</p>
<h2 id="最小抽象"><a href="#最小抽象" class="headerlink" title="最小抽象"></a>最小抽象</h2><p>可以把多语种 ASR 看成三个共享层次。</p>
<p>第一层是声学表示共享。不同语言的人声、音素、韵律和噪声环境有共性，自监督预训练和跨语种迁移学习主要利用这一层。</p>
<p>第二层是符号空间共享。可以共享音素、字节、字符或子词。共享越细，覆盖越广；共享越粗，语言特异性越强。</p>
<p>第三层是任务和部署共享。一个模型是否需要自动识别语言、是否允许用户指定语言、是否支持 code-switching，都会影响训练标签和解码策略。</p>
<h2 id="工程闭环"><a href="#工程闭环" class="headerlink" title="工程闭环"></a>工程闭环</h2><p>多语种模型不能只看平均 WER。平均值会掩盖低资源语种被牺牲的问题。更合理的评测包括：</p>
<ul>
<li>每个语种独立 WER&#x2F;CER；</li>
<li>高资源和低资源语种的分组指标；</li>
<li>口音、方言、噪声条件下的鲁棒性；</li>
<li>code-switching 场景下的语言边界错误；</li>
<li>单模型部署节省的成本是否抵消精度损失。</li>
</ul>
<p>技术路线上，可以从跨语种迁移学习、多任务学习、自监督学习、共享音素集和统一 tokenizer 几个方向组合。第一版系统不要同时追求所有能力，应该先明确主目标：低资源迁移、口音鲁棒、统一部署，还是跨语种混说。</p>
<h2 id="小样本推演"><a href="#小样本推演" class="headerlink" title="小样本推演"></a>小样本推演</h2><p>一个最小实验可以只选三组数据：高资源语种、低资源语种、混说样本。分别比较单语模型、多语种联合模型和高资源预训练后低资源微调。</p>
<p>如果平均 WER 下降，但低资源语种 CER 上升，说明共享带来的收益被平均值掩盖了；如果混说样本语言边界错得更多，就要检查 tokenizer、语言标签和解码约束，而不是只扩大训练集。</p>
<h2 id="直接结论"><a href="#直接结论" class="headerlink" title="直接结论"></a>直接结论</h2><p>多语种 ASR 的核心不是“支持更多语言”，而是在共享表示和语种特异性之间找平衡。工程上先把语种分布、评测分组和部署目标定义清楚，再决定是做单语微调、多语种联合训练，还是使用预训练模型做迁移。</p>
<p>下一步阅读：<a href="/2026/06/10/ASR-Data-Quality-Pipeline-Open-Source/">ASR 数据质量流水线：伪标签、切分与可追溯评测</a></p>
<h3 id="References"><a href="#References" class="headerlink" title="References"></a>References</h3><p>[1] <a href="https://arxiv.org/abs/2202.12576">A Survey on Multilingual Automatic Speech Recognition</a></p>
]]></content>
      <tags>
        <tag>ASR</tag>
        <tag>ASR Low-resource</tag>
        <tag>ASR Multilingual</tag>
      </tags>
  </entry>
  <entry>
    <title>ASR 噪声下的结构化抽取评测：从文本相似到实体归因</title>
    <url>/2026/06/10/ASR-Noise-Structured-Extraction-Evaluation/</url>
    <content><![CDATA[<p>ASR 结果用于结构化抽取时，评测不能只看整句文本相似度。真实系统关心的是关键实体有没有抽对、位置是否合理、错误来自识别还是 NER、以及噪声会不会把下游结构化结果带偏。</p>
<p>因此，ASR + NER 的评测要从“文本像不像”转到“实体是否可归因”。</p>
<span id="more"></span>

<h2 id="要解决的问题"><a href="#要解决的问题" class="headerlink" title="要解决的问题"></a>要解决的问题</h2><p>同样的 WER 可能对应完全不同的下游影响。一个虚词错了可能无关紧要，一个地址、姓名、编号或时间错了会直接破坏结构化结果。</p>
<p>如果只看 ASR 文本 precision &#x2F; recall 或整体 WER，无法解释实体错误来自哪里：是 ASR 没识别出来，还是 NER 没抽出来，还是文本规范化把实体改坏了。</p>
<h2 id="主线判断"><a href="#主线判断" class="headerlink" title="主线判断"></a>主线判断</h2><p>ASR 后接结构化抽取时，核心不是把 F1 算得更细，而是把错误拆回 ASR、抽取模型、span 对齐和后处理四个层次。</p>
<p>只要这四层混在一个分数里，系统就不知道该补语音数据、修实体模型、改对齐策略，还是调整规范化规则。precision 和 recall 只有在错误可归因时才有工程意义。</p>
<h2 id="最小抽象"><a href="#最小抽象" class="headerlink" title="最小抽象"></a>最小抽象</h2><p>评测样本至少要同时保留三层信息：</p>
<figure class="highlight text"><table><tr><td class="code"><pre><span class="line">reference_text</span><br><span class="line">asr_text</span><br><span class="line">reference_entities</span><br><span class="line">predicted_entities</span><br><span class="line">alignment</span><br><span class="line">error_reason</span><br></pre></td></tr></table></figure>

<p><code>alignment</code> 用来把实体 span 对齐到 ASR 输出；<code>error_reason</code> 用来区分漏识别、替换、插入、边界错误、实体类型错误和规范化错误。</p>
<h2 id="工程闭环"><a href="#工程闭环" class="headerlink" title="工程闭环"></a>工程闭环</h2><p>指标要拆成三组。</p>
<p>ASR 层看 WER&#x2F;CER、关键词召回、实体词召回。</p>
<p>NER 层看 entity precision、entity recall、span F1、type accuracy。</p>
<p>归因层看实体错误中有多少来自 ASR，有多少来自抽取模型，有多少来自后处理规则。</p>
<p>这样才能决定下一步该做什么：补噪声数据、加热词、改 NER 训练集、调整规则，还是优化文本规范化。</p>
<h2 id="反直觉点"><a href="#反直觉点" class="headerlink" title="反直觉点"></a>反直觉点</h2><p>实体 span 的绝对位置匹配在干净文本上合理，在 ASR 输出里往往过严。识别前面多出一个字，后面所有位置都会漂移；这时把实体判错，会高估下游模型问题。相反，全文搜索又过松：只要同名实体在整段文本里出现，就可能把远处的错误位置算成正确。</p>
<p>更稳的折中是局部对齐。先做 reference 与 ASR 输出的字符级对齐，再在标注实体附近开一个窗口判断预测是否命中。它允许 ASR 带来的轻微漂移，但不允许系统从全文任意位置捡一个同名字符串来冒充正确实体。</p>
<p>另一个反直觉点是 false positive 不一定都是模型错。标注集可能漏标，尤其是长尾实体。评测脚本应该把“疑似未标注实体”单独导出复核，而不是直接压进 FP。</p>
<h2 id="排障路径"><a href="#排障路径" class="headerlink" title="排障路径"></a>排障路径</h2><p>排障时先做实体级表，而不是直接看总体 F1。每个实体样本保留 reference 片段、ASR 片段、预测片段、局部窗口、实体类型、是否命中、错误原因。</p>
<p>然后按路径归因：reference 有而 ASR 无，是识别漏召回；ASR 有而抽取无，是 NER 漏召回；ASR 有、NER 有但边界偏移，是 span 问题；文本和 span 都对但类型错，是分类问题；预测多出来但 reference 没有，要进入漏标复核。</p>
<p>这张表做出来以后，下一步动作才清楚。ASR 漏召回高，补音频或热词；NER 漏召回高，补标注和负例；span 偏移高，改对齐；后处理错误高，修规则。</p>
<h2 id="评测设计"><a href="#评测设计" class="headerlink" title="评测设计"></a>评测设计</h2><p>大规模评测可以分两阶段。第一阶段用多模式匹配快速找候选实体，避免每条样本都跑重模型。第二阶段才进入局部对齐、类型判断和错误归因。</p>
<p>报告里不要只放一个 micro F1。至少拆出实体词召回、span F1、type accuracy、ASR-caused error rate、NER-caused error rate 和 normalization-caused error rate。这样即使总分不变，也能看到错误在系统内部是否发生迁移。</p>
<h2 id="小样本推演"><a href="#小样本推演" class="headerlink" title="小样本推演"></a>小样本推演</h2><p>考虑两个 ASR 输出，它们的 WER 都是 10%。第一个错在虚词和语气词，结构化实体完整；第二个只错了一个关键实体，但下游字段全部偏掉。若评测只看 WER，这两个样本几乎等价；若看结构化输出，它们的影响完全不同。</p>
<p>再考虑同名实体重复出现的情况。全文搜索会把第二处同名实体当成第一处的命中，绝对 span 又会因为 ASR 插入一个字而全部判错。局部对齐窗口的价值就在这里：它既承认 ASR 会漂移，又要求预测出现在正确语义邻域内。</p>
<h2 id="直接结论"><a href="#直接结论" class="headerlink" title="直接结论"></a>直接结论</h2><p>ASR 噪声下的结构化抽取评测，关键不是把所有错误合成一个分数，而是把错误分解到 ASR、NER、span 对齐和后处理。只有错误可归因，系统才知道下一轮应该改模型、改数据还是改规则。</p>
<p>下一步阅读：<a href="/2026/06/11/Speech-Dialog-Data-Synthesis-Quality-Gates/">语音对话合成数据工程：Schema、口语化与质量闸门</a></p>
]]></content>
      <tags>
        <tag>Open Source</tag>
        <tag>ASR</tag>
        <tag>Evaluation</tag>
        <tag>NER</tag>
      </tags>
  </entry>
  <entry>
    <title>ASR 特征前端：从原始波形到可训练的声学表示</title>
    <url>/2021/08/24/ASR-preprocess/</url>
    <content><![CDATA[<p>ASR 模型看到的通常不是原始波形，而是一组经过短时分析和频率压缩的声学特征。预加重、分帧、加窗、傅里叶变换、Mel 滤波这些步骤看起来像传统信号处理清单，但它们共同解决一个问题：<strong>把连续、非平稳的语音波形变成模型可以稳定学习的局部谱表示</strong>。</p>
<span id="more"></span>

<h2 id="要解决的问题"><a href="#要解决的问题" class="headerlink" title="要解决的问题"></a>要解决的问题</h2><p>语音信号是非平稳的。整段音频的统计属性会随时间变化，但在几十毫秒的短窗口内又近似平稳。ASR 前端要利用这个短时平稳性，把波形切成局部片段，再提取频域能量分布。</p>
<p>典型流程如下：</p>
<p><img src="/2021/08/24/ASR-preprocess/preprocess_flow.png"></p>
<p>这条链路的目标不是追求“最复杂的特征”，而是让模型输入满足三个条件：时间局部、频率可解释、尺度相对稳定。</p>
<h2 id="主线判断"><a href="#主线判断" class="headerlink" title="主线判断"></a>主线判断</h2><p>ASR 前端的主线不是选择哪种特征更传统，而是定义训练和推理共同遵守的输入契约。</p>
<p>预加重、分帧、加窗、Mel 滤波和 log 压缩都可以替换，但不能在训练、评测和线上推理之间悄悄变化。只要输入契约漂移，模型看到的就不是同一个任务，后续排查会被误导成模型结构或数据规模问题。</p>
<h2 id="最小抽象"><a href="#最小抽象" class="headerlink" title="最小抽象"></a>最小抽象</h2><p>预处理可以压成四步。</p>
<p>预加重增强高频信息：</p>
<p>$$y[n]&#x3D;x[n]-\alpha x[n-1], \alpha \in [0.9,1.0]$$</p>
<p>分帧加窗把非平稳信号切成短时平稳片段。常见设置是 16 kHz 采样率下 25 ms 帧长、10 ms 帧移，也就是 400 个采样点窗口和 160 个采样点步长。窗函数减少频谱泄漏，Hamming 窗比矩形窗更适合作为默认选择。</p>
<p>DFT&#x2F;FFT 把每帧从时域转到频域，得到能量谱。Mel 滤波器再把线性频率压到更接近人耳感知的频率尺度：</p>
<p>$$mel(f)&#x3D;2595\log_{10}(1+\frac{f}{700})$$</p>
<p><img src="/2021/08/24/ASR-preprocess/mel_filter.png"></p>
<p>最后通常取 log，得到 log Mel filterbank 或 MFCC 类特征。</p>
<h2 id="工程闭环"><a href="#工程闭环" class="headerlink" title="工程闭环"></a>工程闭环</h2><p>前端参数不能脱离模型和场景单独优化。至少要记录：</p>
<ul>
<li>采样率、帧长、帧移；</li>
<li>Mel 滤波器个数和频率范围；</li>
<li>是否使用预加重、CMVN 或能量特征；</li>
<li>是否和训练、推理、数据增强保持一致；</li>
<li>改动后 WER、实时率和边界音素错误是否变化。</li>
</ul>
<p>很多 ASR 问题看起来是模型问题，实际来自前端不一致。例如训练用 16 kHz，推理输入却被错误重采样；训练和推理的 log base、Mel 范围或 CMVN 统计不同；切片边界没有保留足够上下文。这些问题不会靠更大模型自动消失。</p>
<h2 id="小样本推演"><a href="#小样本推演" class="headerlink" title="小样本推演"></a>小样本推演</h2><p>一个最小排查样本可以只取三条音频：短静音开头、正常语速短句、含高频辅音的短句。先固定模型不变，只比较训练前端和推理前端输出的特征维度、帧数、均值方差和 Mel 频率范围。</p>
<p>如果同一条音频在两条链路里帧数不同，先不要调 decoder；如果 log base 或重采样不同，WER 下降也不能直接归因给模型。前端排查的目标，是先证明模型输入没有被系统误差污染。</p>
<h2 id="直接结论"><a href="#直接结论" class="headerlink" title="直接结论"></a>直接结论</h2><p>ASR 前端的价值在于把语音变成稳定、局部、可比较的声学表示。现代模型可以弱化部分手工特征，但不能忽略输入契约。只要训练和推理前端不一致，后面的模型再强也会被错误输入拖垮。</p>
<p>下一步阅读：<a href="/2021/08/24/ASR-CMVN/">ASR 特征归一化：CMVN 解决的不是数值美观，而是通道偏移</a></p>
<h3 id="References"><a href="#References" class="headerlink" title="References"></a>References</h3><p>[1] <a href="https://www.cnblogs.com/lxp-never/p/10918590.html#blogTitle7">语音信号预处理及 Python 代码实现</a></p>
]]></content>
      <tags>
        <tag>ASR</tag>
        <tag>Preprocess</tag>
      </tags>
  </entry>
  <entry>
    <title>【Agent Engineering Radar】2026-06-16 Agent 工程技术雷达</title>
    <url>/2026/06/16/Agent-Engineering-Radar-2026-06-16/</url>
    <content><![CDATA[<p>本期信号很明确：agent 技术栈的竞争正在从“哪个框架更会跑 demo”，转向“哪个框架更容易被实现、验证、观测和约束”。公开评测、trace 规范、MCP 工具连接和 skills 基准都指向同一个结论：先建设吸收机制，再选择框架。</p>
<span id="more"></span>

<h2 id="要解决的问题"><a href="#要解决的问题" class="headerlink" title="要解决的问题"></a>要解决的问题</h2><p>Agent 框架和工具更新很快，但直接追新会带来三个风险。</p>
<p>第一，文档 demo 成功不代表真实任务成功。ADK Arena 把 51 个 Python Agent Development Kit 放到同一套自动化流程里比较，框架生成成功率只有 57%，生成成本相差 5.6 倍，单一 benchmark 上的最佳框架可以很强，但中位框架只有 32% 左右任务解决率。<a href="https://arxiv.org/abs/2606.05548">来源：arXiv:2606.05548</a></p>
<p>第二，连接标准不等于可信执行。MCP 解决 AI 应用和外部系统的连接问题，但身份、权限、预算、审计和禁用开关仍然要自己做。<a href="https://modelcontextprotocol.io/docs/getting-started/intro">来源：MCP 官方文档</a></p>
<p>第三，skills 不一定带来收益。SWE-Skills-Bench 测了 49 个公开 SWE skills，很多 skill 没有提升 pass-rate，版本不匹配还会伤害结果。<a href="https://arxiv.org/abs/2603.15401">来源：arXiv:2603.15401</a></p>
<h2 id="主线判断"><a href="#主线判断" class="headerlink" title="主线判断"></a>主线判断</h2><p>Agent Engineering Radar 的主线不是收集新闻，而是把外部技术信号压缩成可验证的工程吸收机制。</p>
<p>框架、协议、benchmark、skills 每周都会出现新材料。真正有价值的雷达不是列链接，而是判断哪些变化会影响本地工程决策：是否要试验、如何设安全边界、用什么指标进入或退出主栈。</p>
<h2 id="最小抽象"><a href="#最小抽象" class="headerlink" title="最小抽象"></a>最小抽象</h2><p>可以把 agent 技术栈拆成四层。</p>
<p>框架层负责 agent loop、状态和工具调用。</p>
<p>连接层负责 MCP、API、文件系统、浏览器和终端。</p>
<p>观测层负责 trace、span、成本、错误和 artifact 记录。OpenInference 已经覆盖 LLM 调用、检索、工具调用等上下文，OpenTelemetry 也在推进 GenAI 和 Agent spans 语义约定。<a href="https://arize-ai.github.io/openinference/">来源：OpenInference</a> <a href="https://opentelemetry.io/docs/specs/semconv/gen-ai/">来源：OpenTelemetry GenAI semantic conventions</a></p>
<p>评测层负责 smoke、benchmark、dialogue task 和安全门槛。Dialogue SWE-Bench 提醒我们，交互式 coding agent 的澄清和对话能力与一次性解题不是同一维度。<a href="https://arxiv.org/abs/2606.13995">来源：arXiv:2606.13995</a></p>
<h2 id="工程闭环"><a href="#工程闭环" class="headerlink" title="工程闭环"></a>工程闭环</h2><p>本周真正该做的是小闭环，而不是迁移主栈。</p>
<ol>
<li>建一个最小 agent smoke suite，覆盖工具调用、文件修改、测试、恢复和 trace。</li>
<li>给每次 agent 实验记录成功率、成本、步数和失败类型。</li>
<li>MCP server 默认进入 Trial 清单，必须通过权限和日志检查后再进入常用工具集。</li>
<li>Skills 做 paired eval，同一任务有 skill &#x2F; 无 skill 各跑一组，比较成功率、token 和错误类型。</li>
</ol>
<p>Terminal-Bench 2.0 和 TerminalWorld 也说明，终端任务需要单独评估命令规划、环境感知、文件副作用和恢复能力，不能只用 coding benchmark 替代。<a href="https://www.tbench.ai/">来源：Terminal-Bench</a> <a href="https://arxiv.org/abs/2605.22535">来源：arXiv:2605.22535</a></p>
<h2 id="小样本推演"><a href="#小样本推演" class="headerlink" title="小样本推演"></a>小样本推演</h2><p>看到一个新的 agent framework 时，不应该先迁移项目，而是先放进 Trial 清单。最小验证可以是三类任务：只读检索、受限文件修改、失败恢复。每类记录成功率、工具调用次数、成本、trace 完整度和越权风险。</p>
<p>如果 demo 很强但 trace 不完整、权限不可控或失败后无法恢复，它就只能保留在观察区。雷达的作用是避免被单点亮点牵着走。</p>
<h2 id="直接结论"><a href="#直接结论" class="headerlink" title="直接结论"></a>直接结论</h2><p>Agent Engineering 的技术视野要保持开放，但吸收机制要收紧。框架、协议、skills、benchmark 都可以跟进；真正进入主技术栈的，只应该是能被验证、能被观测、能被回滚的部分。</p>
<p>下一步阅读：<a href="/2026/06/10/Agentic-Coding-Governance/">Agentic Coding 工程治理：多模型协作先定义责任边界</a></p>
]]></content>
      <tags>
        <tag>AI</tag>
        <tag>Open Source</tag>
        <tag>Evaluation</tag>
        <tag>Agent</tag>
        <tag>Engineering</tag>
      </tags>
  </entry>
  <entry>
    <title>Agentic Coding 工程治理：多模型协作先定义责任边界</title>
    <url>/2026/06/10/Agentic-Coding-Governance/</url>
    <content><![CDATA[<p>代码生成工具越来越强，多模型协作也越来越常见。但真正的问题已经不是“哪个模型会写代码”，而是多个代理如何共享上下文、谁能写文件、谁负责审查、如何避免互相覆盖，以及如何验证最终结果。</p>
<p>Agentic Coding 的难点更像工程治理，而不是单纯模型能力。</p>
<span id="more"></span>

<h2 id="要解决的问题"><a href="#要解决的问题" class="headerlink" title="要解决的问题"></a>要解决的问题</h2><p>如果所有 agent 都能同时读、写、运行命令和发布，系统很快会失控。一个 agent 做探索，一个 agent 改代码，另一个 agent 又根据旧上下文审查，最后 integrator 不知道该相信谁。</p>
<p>多代理系统最危险的不是某个模型犯错，而是错误被协作流程放大。</p>
<h2 id="主线判断"><a href="#主线判断" class="headerlink" title="主线判断"></a>主线判断</h2><p>Agentic Coding 更像一个权限和证据控制系统，而不是多个模型的群聊。</p>
<p>多模型协作真正危险的地方，不是某个模型写错一段代码，而是错误在上下文传递、并行写入、审查缺证据和发布动作里被放大。治理重点不是让 agent 更多，而是让每个 agent 的职责、权限、证据和退出条件可审计。</p>
<h2 id="最小抽象"><a href="#最小抽象" class="headerlink" title="最小抽象"></a>最小抽象</h2><p>一个稳定流程至少区分四类角色：</p>
<ul>
<li>explorer：只读探索代码，回答具体问题；</li>
<li>worker：负责明确文件范围内的实现；</li>
<li>reviewer：检查风险、回归和测试缺口；</li>
<li>integrator：合并结果、运行验证、决定是否发布。</li>
</ul>
<p>同一文件或同一行为边界，在同一阶段只应该有一个写入者。其他角色可以读、审、提建议，但不要并发修改同一处。</p>
<p>MCP、浏览器控制、终端和 GitHub 连接器都应该按权限分层：read-only、scoped-write、privileged。默认读，需要写入或发布时再提升权限。</p>
<h2 id="工程闭环"><a href="#工程闭环" class="headerlink" title="工程闭环"></a>工程闭环</h2><p>Agentic Coding 的状态机可以压成：</p>
<figure class="highlight text"><table><tr><td class="code"><pre><span class="line">explore -&gt; propose -&gt; apply -&gt; review -&gt; verify -&gt; publish</span><br></pre></td></tr></table></figure>

<p>每个状态都要定义允许工具、写入边界、交付物和 handoff 内容。handoff 里保留已验证事实、拒绝过的假设、触碰文件、测试证据、剩余风险和下一步动作。</p>
<p>验证也要分三类：</p>
<ul>
<li>静态验证：格式、lint、类型、配置检查；</li>
<li>行为验证：测试、构建、端到端 smoke；</li>
<li>变更验证：diff 审阅、敏感信息扫描、发布前检查。</li>
</ul>
<p>如果 agent 修改了验证脚本本身，还要确认验证规则没有被放松。</p>
<h2 id="反直觉点"><a href="#反直觉点" class="headerlink" title="反直觉点"></a>反直觉点</h2><p>更多 agent 不一定更强。每增加一个 agent，就增加一次上下文压缩、意图解释和结果合并的成本。适合分出去的是边界清楚、只读可完成、输出能被验证的任务；不适合分出去的是最终写入、发布、敏感操作、删除和范围含糊的任务。</p>
<p>并行探索通常有价值，并行写入通常危险。同一文件、同一行为边界、同一阶段只应该有一个写入者。其他角色可以读、审、提建议，但不要同时修改同一处。</p>
<p>reviewer 也不能只给主观意见。reviewer 输出必须带证据位置、风险等级、复现方式和建议验证命令，否则 integrator 无法判断是否采纳。</p>
<h2 id="实现契约"><a href="#实现契约" class="headerlink" title="实现契约"></a>实现契约</h2><p>一个稳定状态机可以压成 explore、propose、apply、review、verify、publish。每个状态都定义允许工具、写入边界、交付物和 handoff 内容。</p>
<p>五条不变量值得硬编码：最终写入者唯一；发布动作只由 integrator 执行；subagent 输出必须带证据和不确定性；自动修复必须能被测试或静态检查验证；handoff 不只写结论，还要写被排除的路径。</p>
<h2 id="排障路径"><a href="#排障路径" class="headerlink" title="排障路径"></a>排障路径</h2><p>Agentic Coding 出问题时，要归到状态和角色。reviewer 找不到证据，是 explorer 输出不够结构化。worker 改错范围，是任务边界没有锁定。integrator 合并后测试失败，是 handoff 没有保留验证条件。发布后发现敏感内容，是发布前检查不在状态机里。</p>
<p>每次协作最好留一份 evidence ledger：读过哪些文件、修改了哪些文件、运行了哪些命令、哪些假设被证伪、哪些风险还没覆盖。它应该是事实账本，不是聊天摘要。</p>
<h2 id="小样本推演"><a href="#小样本推演" class="headerlink" title="小样本推演"></a>小样本推演</h2><p>一个合理的协作例子是：explorer 只读代码并产出证据位置，worker 只改限定文件，reviewer 只检查风险和测试缺口，integrator 负责最终合并、验证和发布。这个流程看起来慢，但每个状态都有清楚的责任归属。</p>
<p>反过来，如果两个 agent 同时改同一文件，reviewer 只能看到聊天摘要，integrator 不知道哪些命令真实跑过，发布前也没有权限回放，那么多模型协作只是在扩大不确定性。Agentic Coding 的效率，来自证据复用和边界清楚，而不是并发修改更多文件。</p>
<h2 id="直接结论"><a href="#直接结论" class="headerlink" title="直接结论"></a>直接结论</h2><p>Agentic Coding 的关键不是把多个模型接到一起，而是明确角色、权限、状态和验证。没有边界的多代理系统，只会把单模型的不确定性放大成协作层面的不确定性。</p>
<p>下一步阅读：<a href="/2026/06/16/Agent-Engineering-Radar-2026-06-16/">【Agent Engineering Radar】2026-06-16 Agent 工程技术雷达</a></p>
]]></content>
      <tags>
        <tag>AI</tag>
        <tag>Open Source</tag>
        <tag>Agent</tag>
        <tag>Coding</tag>
      </tags>
  </entry>
  <entry>
    <title>CCA 与 SSVEP 频率识别：为什么线性相关仍然有效</title>
    <url>/2019/07/15/CCA-application-in-SSVEP-frequency-detection/</url>
    <content><![CDATA[<p>脑机接口里的 SSVEP 频率识别有一个很实际的问题：训练数据少、个体差异大、信号噪声高，但系统仍然需要快速判断用户注视的是哪个闪烁频率。</p>
<p>CCA（Canonical Correlation Analysis）看起来是一个传统线性统计方法，却长期在 SSVEP 中有效。原因不在于它复杂，而在于它抓住了任务里最稳定的结构：刺激频率和脑电响应之间的相关性。</p>
<span id="more"></span>

<h2 id="要解决的问题"><a href="#要解决的问题" class="headerlink" title="要解决的问题"></a>要解决的问题</h2><p>SSVEP 是由周期性视觉刺激诱发的脑电响应。不同频率的闪烁刺激会在 EEG 中产生对应频率及其谐波成分。系统要做的事情，就是从多通道脑电信号里判断当前响应最接近哪个候选频率。</p>
<p>采集示意如下：</p>
<p><img src="/2019/07/15/CCA-application-in-SSVEP-frequency-detection/SSVEP_collect.jpg"></p>
<p>频域上可以看到刺激频率及谐波处的能量峰：</p>
<p><img src="/2019/07/15/CCA-application-in-SSVEP-frequency-detection/SSVEP_signal.png"></p>
<p>如果训练数据充足，可以训练复杂模型；但 BCI 场景常常数据有限、校准时间短。CCA 的优势就是不强依赖大量训练数据。</p>
<h2 id="主线判断"><a href="#主线判断" class="headerlink" title="主线判断"></a>主线判断</h2><p>CCA 在 SSVEP 里的主线不是传统方法对抗深度学习，而是在低数据条件下利用任务结构。</p>
<p>候选刺激频率已知，参考信号可以直接构造，EEG 多通道响应又和频率及谐波相关。CCA 把这些先验变成一个轻量基线，所以它经常比“直接上深度模型”更适合作为第一版系统。</p>
<h2 id="最小抽象"><a href="#最小抽象" class="headerlink" title="最小抽象"></a>最小抽象</h2><p>CCA 比较的是两组变量的最大线性相关。放到 SSVEP 里，一组变量是多通道 EEG，另一组是候选频率构造出的参考信号：</p>
<p>$$\sin 2\pi ft,\cos 2\pi ft,\sin 4\pi ft,\cos 4\pi ft,…$$</p>
<p>对每个候选频率，CCA 都计算 EEG 与参考信号之间的最大相关系数，相关性最高的频率就是预测结果。</p>
<p><img src="/2019/07/15/CCA-application-in-SSVEP-frequency-detection/CCA.png"></p>
<p>公式展开较长，核心可以理解成一个约束优化问题：寻找 EEG 通道加权和参考信号加权，使两者相关性最大。</p>
<p><img src="/2019/07/15/CCA-application-in-SSVEP-frequency-detection/CCAFormula.png"></p>
<h2 id="工程闭环"><a href="#工程闭环" class="headerlink" title="工程闭环"></a>工程闭环</h2><p>CCA 的局限也很清楚。</p>
<p>第一，相位漂移。不同受试者对同一刺激的响应时滞不同，固定参考信号可能无法对齐所有人。</p>
<p>第二，线性假设。真实 EEG 包含噪声、伪迹和非线性成分，CCA 默认响应可以由参考频率线性解释。</p>
<p>第三，短窗性能。长时间窗里频率特征更稳定，短时间窗里信噪比下降，识别更难。</p>
<p>因此后续方法通常沿着两条路改进：要么增强相关分析本身，要么引入少量训练数据学习个体化空间滤波。DCCA 用深度网络表达非线性相关，但需要更多训练数据：</p>
<p><img src="/2019/07/15/CCA-application-in-SSVEP-frequency-detection/DCCA.png"></p>
<p>TRCA 则从任务相关成分出发，用训练数据学习更适合当前受试者的空间滤波：</p>
<img src="/2019/07/15/CCA-application-in-SSVEP-frequency-detection/TRCA.png" width=256 height=256/>

<h2 id="小样本推演"><a href="#小样本推演" class="headerlink" title="小样本推演"></a>小样本推演</h2><p>一个小样本实验可以只选 8Hz、10Hz、12Hz 三个候选频率，每个频率采几段短窗 EEG。先用 CCA 计算每段与三个参考信号的相关系数，再画出正确频率和次高频率之间的 margin。</p>
<p>如果长窗 margin 明显、短窗 margin 接近 0，瓶颈不是分类器不够复杂，而是窗口太短导致频率证据不足；如果某个受试者所有频率 margin 都低，就优先检查相位、导联和个体化空间滤波。</p>
<h2 id="直接结论"><a href="#直接结论" class="headerlink" title="直接结论"></a>直接结论</h2><p>CCA 在 SSVEP 中有效，是因为它用很低的数据成本抓住了刺激频率和脑电响应之间的稳定相关结构。它不是所有 EEG 问题的通用答案，但在候选频率明确、训练数据有限、需要快速部署的 BCI 任务里仍然是很强的基线。</p>
<p>后续优化不应只问“能不能换成深度学习”，而要问：短窗、相位漂移、个体差异和校准成本哪个才是当前系统的主要瓶颈。</p>
<p>下一步阅读：<a href="/2021/08/24/ASR-preprocess/">ASR 特征前端：从原始波形到可训练的声学表示</a></p>
<h3 id="References"><a href="#References" class="headerlink" title="References"></a>References</h3><p>[1] Frequency Recognition Based on Canonical Correlation Analysis for SSVEP-Based BCIs<br>[2] Deep Canonical Correlation Analysis<br>[3] Enhancing detection of SSVEPs for a high-speed brain speller using task-related component analysis</p>
]]></content>
      <tags>
        <tag>CCA</tag>
        <tag>EEG</tag>
      </tags>
  </entry>
  <entry>
    <title>PEFT 工程取舍：省参数只是入口，部署路径才是边界</title>
    <url>/2026/06/10/PEFT-Engineering-Tradeoffs/</url>
    <content><![CDATA[<p>PEFT 常被理解成“少训练一些参数”。这句话没错，但它只说了训练成本，没有说清楚工程边界。真正的选择不是参数越少越好，而是训练显存、适配能力、推理开销、上下文占用、版本管理和回滚方式之间的取舍。</p>
<p>如果不把这些约束写清楚，LoRA、Prefix-Tuning、P-Tuning、QLoRA 很容易被比较成一张简单榜单，而不是可复用的工程组件。</p>
<span id="more"></span>

<h2 id="要解决的问题"><a href="#要解决的问题" class="headerlink" title="要解决的问题"></a>要解决的问题</h2><p>全量微调成本高、版本重、回滚慢。PEFT 的目标是让模型在较低训练成本下适配新任务，同时尽量不破坏基础模型能力。</p>
<p>但“低成本”有不同含义。LoRA 省的是可训练参数和显存；Prefix-Tuning 省的是模型权重改动，但占用上下文或 attention 前缀；QLoRA 降低训练显存，但引入量化配置和稳定性问题。</p>
<p>所以 PEFT 选择的第一步不是问哪个方法更先进，而是问当前瓶颈在哪里：训练显存、数据规模、推理延迟、多任务切换，还是上线回滚。</p>
<h2 id="主线判断"><a href="#主线判断" class="headerlink" title="主线判断"></a>主线判断</h2><p>PEFT 方法本质上是在选择训练图和部署形态，而不只是选择更少的可训练参数。</p>
<p>LoRA、Prefix-Tuning、P-Tuning、QLoRA 的差异不只在参数量，而在它们如何改变显存、上下文窗口、推理路径、adapter 管理、合并策略和回滚方式。省参数只是入口，部署边界才是决策依据。</p>
<h2 id="最小抽象"><a href="#最小抽象" class="headerlink" title="最小抽象"></a>最小抽象</h2><p>可以把 PEFT 方法按“改哪里”来理解。</p>
<p>LoRA 在权重矩阵旁边加入低秩更新。它生态成熟、训练稳定、容易合并到基础模型，也适合多 adapter 管理。它的主要变量是 rank、target modules、alpha、dropout、学习率和数据规模。</p>
<p>Prefix-Tuning 和 P-Tuning 把可训练信息放到输入或注意力前缀里。它们和模型主体解耦更强，但会改变上下文窗口和缓存形态。如果任务本身已经依赖长上下文，前缀成本不能忽略。</p>
<p>QLoRA 把量化和 LoRA 结合，让较小显存也能训练大模型。它降低了进入门槛，但 dtype、量化方式、优化器状态和梯度检查点都会影响收敛稳定性。</p>
<h2 id="工程闭环"><a href="#工程闭环" class="headerlink" title="工程闭环"></a>工程闭环</h2><p>PEFT 实验不能只记录最终指标。每个 adapter 都应该进入 registry：</p>
<figure class="highlight text"><table><tr><td class="code"><pre><span class="line">base_model</span><br><span class="line">dataset_version</span><br><span class="line">target_modules</span><br><span class="line">rank / alpha / dropout</span><br><span class="line">learning_rate</span><br><span class="line">quantization_config</span><br><span class="line">eval_set</span><br><span class="line">merge_status</span><br><span class="line">serving_runtime</span><br><span class="line">rollback_path</span><br></pre></td></tr></table></figure>

<p>这个 registry 的价值在部署阶段才会显现。多 adapter 是否动态加载，是否共享 batch，是否合并权重，合并后如何版本化，推理框架是否支持对应 dtype，都会影响线上复杂度。</p>
<p>如果没有 registry，团队很容易把 prompt 改动、数据变更和 adapter 行为混在一起，最后无法复现实验结果。</p>
<h2 id="反直觉点"><a href="#反直觉点" class="headerlink" title="反直觉点"></a>反直觉点</h2><p>参数更少不一定更简单。Prefix-Tuning 和 P-Tuning 看起来不改模型主体，但会占用上下文或改变 attention 前缀形态。对长上下文任务来说，前缀消耗的是最稀缺的资源。</p>
<p>LoRA 往往是更稳的默认起点，不是因为它永远最好，而是因为训练、合并、分发、回滚和多 adapter 管理更成熟。QLoRA 能降低显存门槛，但 dtype、量化配置、优化器状态和梯度检查点都会影响稳定性。</p>
<p>所以选型不要从方法名开始，而要从瓶颈开始：训练显存不足、数据较少、推理延迟敏感、多任务切换频繁、还是上线回滚成本高。</p>
<h2 id="评测设计"><a href="#评测设计" class="headerlink" title="评测设计"></a>评测设计</h2><p>PEFT 对照实验至少固定四件事：同一个 base model、同一批训练数据、同一套 eval set、同一套推理模板。否则方法差异会被数据和 prompt 差异掩盖。</p>
<p>指标要拆成两组。训练侧看显存、训练时长、收敛稳定性、目标任务提升和通用能力保持。部署侧看推理延迟、上下文占用、adapter 加载方式、合并后效果、版本化和 rollback path。</p>
<h2 id="排障路径"><a href="#排障路径" class="headerlink" title="排障路径"></a>排障路径</h2><p>PEFT 失败常见于三个地方。第一，target modules 选错，adapter 没有作用到关键路径。第二，数据太少或太窄，adapter 只记住格式。第三，评测没有区分基础能力保持和目标任务提升，导致模型在目标样本上看似变好，却牺牲了通用能力。</p>
<p>因此，每次实验都要保留 adapter registry：base model、dataset version、target modules、rank、alpha、dropout、learning rate、quantization config、eval set、merge status、serving runtime 和 rollback path。没有 registry，就无法复现一次看似成功的微调。</p>
<h2 id="小样本推演"><a href="#小样本推演" class="headerlink" title="小样本推演"></a>小样本推演</h2><p>如果任务依赖长上下文，Prefix-Tuning 看起来参数少，实际上可能把上下文预算吃掉，导致有效输入被挤压。如果部署要求频繁切换多个轻量任务，LoRA 的 adapter 管理和动态加载能力就比单次训练分数更重要。如果训练显存是唯一瓶颈，QLoRA 可以先验证方向，但不能跳过精度和稳定性复核。</p>
<p>所以 PEFT 选型应该像系统设计，而不是像排行榜。先写清楚当前限制：显存、延迟、上下文、切换频率、合并策略、回滚成本。再用小规模实验验证方法，而不是先选一个热门方法再解释它为什么合适。</p>
<h2 id="直接结论"><a href="#直接结论" class="headerlink" title="直接结论"></a>直接结论</h2><p>PEFT 是一组工程组件，不是一个统一算法。LoRA、Prefix-Tuning、P-Tuning、QLoRA 的核心差异，不只是训练参数量，而是它们如何改变训练图、上下文窗口、推理路径和版本管理。</p>
<p>选型时先写清楚瓶颈，再做小规模对照实验；上线前先确认 adapter registry、评测集、合并策略和回滚路径。否则省下的训练成本会在部署和排障阶段还回去。</p>
<p>下一步阅读：<a href="/2026/06/10/Speech-LLM-Audio-Token-Alignment/">语音大模型工程：音频 token、LLM 主干与对齐契约</a></p>
]]></content>
      <tags>
        <tag>LLM</tag>
        <tag>Open Source</tag>
        <tag>PEFT</tag>
        <tag>Fine-tuning</tag>
      </tags>
  </entry>
  <entry>
    <title>LLM 与语音模型推理服务：先把延迟拆成可观测链路</title>
    <url>/2026/06/10/LLM-Speech-Inference-Serving-Observability/</url>
    <content><![CDATA[<p>推理服务的问题经常被简化成“换更快的框架”。vLLM、SGLang、Triton 都很重要，但如果系统不能解释一次请求的延迟来自排队、预填充、解码、音频前端、网络还是后处理，换框架只是碰运气。</p>
<p>语音和 LLM 结合后，延迟问题更复杂：音频切片、流式 partial、模型队列、token 生成和系统超时会叠在一起。</p>
<span id="more"></span>

<h2 id="要解决的问题"><a href="#要解决的问题" class="headerlink" title="要解决的问题"></a>要解决的问题</h2><p>线上推理关注的不是平均速度，而是尾延迟和稳定性。一个服务平均很快，但 p99 经常超时，用户体验仍然不可接受。</p>
<p>语音模型还多了几个阶段：音频读取、重采样、特征提取、chunk 组织、ASR 或 speech encoder 推理、LLM 解码、流式输出。任何一层都可能放大延迟。</p>
<h2 id="主线判断"><a href="#主线判断" class="headerlink" title="主线判断"></a>主线判断</h2><p>推理服务选型之前，必须先把延迟拆成可观测链路。</p>
<p>vLLM、SGLang、Triton 只能优化它们覆盖的那一段。若 p99 来自排队、预处理、音频编码、tokenizer、后处理或下游消费，替换解码框架并不会解决问题。先定位瓶颈，再谈框架。</p>
<h2 id="最小抽象"><a href="#最小抽象" class="headerlink" title="最小抽象"></a>最小抽象</h2><p>可以把请求生命周期拆成：</p>
<figure class="highlight text"><table><tr><td class="code"><pre><span class="line">ingress</span><br><span class="line">  -&gt; queue</span><br><span class="line">  -&gt; preprocess</span><br><span class="line">  -&gt; prefill / encode</span><br><span class="line">  -&gt; decode / stream</span><br><span class="line">  -&gt; postprocess</span><br><span class="line">  -&gt; response</span><br></pre></td></tr></table></figure>

<p>vLLM 和 SGLang 主要优化 LLM serving 的调度、KV cache、batch 和解码吞吐；Triton 更适合做模型服务编排和算子级部署。它们解决的是不同层次的问题，不能用单一 benchmark 直接替代系统观测。</p>
<h2 id="工程闭环"><a href="#工程闭环" class="headerlink" title="工程闭环"></a>工程闭环</h2><p>服务必须记录分阶段指标：</p>
<ul>
<li>queue wait；</li>
<li>preprocess time；</li>
<li>prefill 或 encoder time；</li>
<li>first token &#x2F; first partial latency；</li>
<li>tokens per second；</li>
<li>p50 &#x2F; p95 &#x2F; p99；</li>
<li>timeout reason；</li>
<li>batch size、dtype、KV cache 命中情况。</li>
</ul>
<p>对流式语音系统，还要单独看 partial 的稳定性：早出结果是否经常回滚，回滚是否影响下游，semantic end 或 turn-taking 判断是否被延迟拖垮。</p>
<p>没有这些指标，优化就会变成只看 GPU 利用率。GPU 忙不代表服务健康，GPU 不忙也可能是队列、网络或调度策略出了问题。</p>
<h2 id="反直觉点"><a href="#反直觉点" class="headerlink" title="反直觉点"></a>反直觉点</h2><p>GPU 利用率高不一定代表服务健康。它可能说明 batch 足够大，也可能说明请求在队列里等太久。GPU 利用率低也不一定代表模型快，可能是 CPU 前处理、线程锁、网络或调度策略把请求挡在模型外。</p>
<p>吞吐优化和交互优化经常冲突。离线批处理希望合更大的 batch，实时语音更关心 first partial、first token 和取消响应速度。把两类请求放进同一套队列策略，很容易让吞吐变好、体验变差。</p>
<p>全局 timeout 也不够。一个请求超时，必须知道它死在 queue、preprocess、encode、prefill、decode 还是 postprocess。否则告警只能说“慢了”，不能指导修复。</p>
<h2 id="可观测闭环"><a href="#可观测闭环" class="headerlink" title="可观测闭环"></a>可观测闭环</h2><p>每个 request id 都要贯穿 ingress、queue、preprocess、encode、first partial、first token、decode、postprocess 和 response。日志至少保留输入长度、音频时长、batch size、输出 token 数、取消原因和 timeout reason。</p>
<p>面板先做三张就够。第一张是端到端延迟分解；第二张按音频时长、文本长度、batch 和输出 token 分桶看 p95&#x2F;p99；第三张按失败原因分桶。三张面板能回答大部分早期问题：请求太长、队列太深、编码慢、解码慢、后处理慢，还是预算配置不合理。</p>
<h2 id="排障路径"><a href="#排障路径" class="headerlink" title="排障路径"></a>排障路径</h2><p>若 queue wait 高，先查并发、限流和调度策略。若 first token 慢但后续 token 快，查 prefill、编码和输入长度。若 first token 快但总耗时长，查 decode 吞吐和下游消费。若只有 p99 变差，查长输入、异常重试、锁竞争和资源抖动。</p>
<p>只有这些归因跑通以后，vLLM、SGLang、Triton 的比较才有意义。否则框架选择会变成单次 demo 的主观印象。</p>
<h2 id="小样本推演"><a href="#小样本推演" class="headerlink" title="小样本推演"></a>小样本推演</h2><p>假设线上 p99 突然变差，但平均延迟几乎不变。若没有链路分解，最容易误判成模型变慢。真正的原因可能是长音频比例上升、某个 CPU 后处理线程阻塞、队列合批策略等待过久，或者下游消费速度下降。</p>
<p>request id 贯穿全链路后，排查会变成一个很具体的问题：慢请求是否集中在长输入，是否 queue wait 高，是否 first token 高，是否 decode tokens per second 下降，是否 postprocess 异常重试。只有能回答这些问题，框架替换才是有依据的优化，而不是重新抽签。</p>
<h2 id="直接结论"><a href="#直接结论" class="headerlink" title="直接结论"></a>直接结论</h2><p>推理框架选型前，先把延迟链路拆开并落日志。vLLM、SGLang、Triton 都可以进入候选，但判断依据应该是分阶段延迟、吞吐、p99、资源利用和失败原因，而不是单次 demo 的响应速度。</p>
<p>下一步阅读：<a href="/2026/06/10/Speech-Batch-Consistency-Debugging/">音频模型 Batch 一致性排查：从有效输入区间到逐层 diff</a></p>
]]></content>
      <tags>
        <tag>LLM</tag>
        <tag>Engineering</tag>
        <tag>Speech</tag>
        <tag>Inference</tag>
      </tags>
  </entry>
  <entry>
    <title>Personal VAD 2.0 工程化：把目标说话人判断做成闭环</title>
    <url>/2026/06/09/PVAD2-engineering-loop/</url>
    <content><![CDATA[<p>普通 VAD 只回答“这里有没有人声”。Personal VAD 要回答更难的问题：这里有没有目标说话人的声音。这个差异会把任务从声学检测推进到说话人条件建模。</p>
<p>项目代码可参考：<a href="https://github.com/fclearner/Personal-vad-2.0">Personal-vad-2.0</a></p>
<span id="more"></span>

<h2 id="要解决的问题"><a href="#要解决的问题" class="headerlink" title="要解决的问题"></a>要解决的问题</h2><p>真实语音场景里，经常不只一个人说话。普通 VAD 能检测语音活动，却无法区分当前语音是否来自目标说话人。对于个性化唤醒、会议选择性转写、目标说话人增强和说话人相关过滤，这个能力不够。</p>
<p>Personal VAD 的核心矛盾是：模型既要保持 VAD 的帧级时序敏感，又要利用 speaker embedding 识别目标说话人。</p>
<h2 id="主线判断"><a href="#主线判断" class="headerlink" title="主线判断"></a>主线判断</h2><p>PVAD 的难点不在于把 VAD 模型做大，而在于把目标说话人条件落到帧级标注里。</p>
<p>如果数据里没有清晰区分目标说话人、非目标说话人、静音和噪声，模型很容易退化成普通 VAD。speaker embedding 不是魔法开关，它只有和采样、标签对齐、负样本设计一起闭环，才可能带来目标说话人判断能力。</p>
<h2 id="最小抽象"><a href="#最小抽象" class="headerlink" title="最小抽象"></a>最小抽象</h2><p>可以把 PVAD 写成一个条件检测问题：</p>
<figure class="highlight text"><table><tr><td class="code"><pre><span class="line">audio_features + target_speaker_embedding -&gt; target_speech_activity</span><br></pre></td></tr></table></figure>

<p>这里的目标不是单独做 speaker verification，也不是单独做 VAD，而是把目标说话人的条件信息注入到帧级检测里。</p>
<p>训练样本至少要覆盖三类情况：目标说话人说话、非目标说话人说话、无人声或噪声。否则模型很容易学成普通 VAD，或者把所有人声都当成目标。</p>
<h2 id="工程闭环"><a href="#工程闭环" class="headerlink" title="工程闭环"></a>工程闭环</h2><p>PVAD 的评测要拆开。</p>
<ul>
<li>VAD 层：speech &#x2F; non-speech 的召回和误报；</li>
<li>说话人层：目标和非目标说话人的区分能力；</li>
<li>时序层：起止边界、短语音、重叠语音和噪声下的稳定性；</li>
<li>训练层：embedding 来源、采样策略、正负样本比例和标签对齐。</li>
</ul>
<p>如果只看总体准确率，很难发现模型到底是在做目标说话人判断，还是只是在检测有没有声音。</p>
<h2 id="反直觉点"><a href="#反直觉点" class="headerlink" title="反直觉点"></a>反直觉点</h2><p>第一阶段不一定要端到端训练 speaker encoder。更稳的路径是先用外部 speaker embedding，把“说话人表征是否有用”和“帧级检测是否可学”拆开。若外部 embedding 都没有收益，问题大概率在数据定义、目标映射或标签边界，而不是模型容量。</p>
<p>随机 embedding 是一个很有价值的对照。若随机 embedding 也能提升，说明模型可能只是学到了额外参数或采样偏差，而不是目标说话人信息。若固定外部 embedding 有收益，再考虑轻量投影层、条件归一化或注意力注入。</p>
<p>重叠语音不能只当噪声。它是检验 PVAD 是否真正理解目标条件的关键分桶：非目标人声存在时，模型是否还能只激活目标说话人帧。</p>
<h2 id="实验设计"><a href="#实验设计" class="headerlink" title="实验设计"></a>实验设计</h2><p>最小实验矩阵可以是四组：普通 VAD baseline、随机 speaker embedding、固定外部 speaker embedding、外部 embedding 加轻量投影层。每组都看目标说话人召回、非目标误报、静音误报、重叠语音表现和边界偏移。</p>
<p>如果目标召回高但非目标误报也高，模型仍像普通 VAD。若非目标压住了但目标漏检高，embedding 或正样本采样不足。若重叠语音失败，说明条件信息没有在帧级竞争中起作用。</p>
<h2 id="排障路径"><a href="#排障路径" class="headerlink" title="排障路径"></a>排障路径</h2><p>错误样本要按说话人关系拆开，而不是只看总体 F1。目标单人、非目标单人、目标与非目标重叠、噪声静音分别对应不同问题。每类样本都保留音频片段、目标 embedding 来源、帧级标签、预测概率和边界偏移。</p>
<p>PVAD 的进展不应该靠换更大模型来证明，而应该靠这些分桶错误逐步减少来证明。</p>
<h2 id="小样本推演"><a href="#小样本推演" class="headerlink" title="小样本推演"></a>小样本推演</h2><p>如果普通 VAD baseline 已经能把大部分人声找出来，但目标和非目标分不开，说明瓶颈不在声学活动检测。如果加入随机 embedding 后指标也提升，说明模型可能只是吃到了额外参数或采样偏差；只有固定外部 speaker embedding 带来稳定收益，才能说明条件信息真正起作用。</p>
<p>重叠语音样本尤其重要。目标说话人和非目标说话人同时存在时，模型是否只激活目标帧，决定了它是不是 PVAD。若这类样本没有单独分桶，总体 F1 很容易被大量简单静音和单人语音掩盖。</p>
<h2 id="直接结论"><a href="#直接结论" class="headerlink" title="直接结论"></a>直接结论</h2><p>Personal VAD 的工程重点不是把普通 VAD 模型换大，而是把目标说话人条件、帧级标签和负样本设计做成闭环。speaker embedding 只有和训练采样、标签对齐、错误归因一起设计，才会真正改善目标说话人检测。</p>
<p>下一步阅读：<a href="/2026/06/10/Realtime-Speech-Turn-Taking-Evaluation/">实时语音 Turn-taking 评测：从端点检测到可接话判断</a></p>
]]></content>
      <tags>
        <tag>Open Source</tag>
        <tag>ASR</tag>
        <tag>VAD</tag>
        <tag>PVAD</tag>
        <tag>Speaker Embedding</tag>
      </tags>
  </entry>
  <entry>
    <title>音频模型 Batch 一致性排查：从有效输入区间到逐层 diff</title>
    <url>/2026/06/10/Speech-Batch-Consistency-Debugging/</url>
    <content><![CDATA[<p>同一个音频，batch size 不同却输出不同，这是音频模型排障里很典型的问题。它通常不是“模型随机性”一句话能解释的，而是 padding、mask、dtype、subsampling、归一化或缓存边界出了问题。</p>
<p>排查这类问题，关键是把有效输入区间和逐层差异记录下来。</p>
<span id="more"></span>

<h2 id="要解决的问题"><a href="#要解决的问题" class="headerlink" title="要解决的问题"></a>要解决的问题</h2><p>批量推理会把不同长度音频 pad 到同一形状。理论上，mask 应该保证 padding 不影响有效区域。但实际实现里，卷积、subsampling、attention、归一化和 dtype 转换都可能让 padding 泄漏进有效输出。</p>
<p>如果只比较最终文本，很难定位问题。需要比较中间层。</p>
<h2 id="主线判断"><a href="#主线判断" class="headerlink" title="主线判断"></a>主线判断</h2><p>音频 batch 一致性问题要用第一差异层定位，而不是盯着最终文本猜。</p>
<p>最终转写已经经过 encoder、subsampling、mask、解码和后处理，任何一处小数值差异都可能被放大。真正有价值的是找到第一个 divergence 出现的位置。</p>
<h2 id="最小抽象"><a href="#最小抽象" class="headerlink" title="最小抽象"></a>最小抽象</h2><p>排查对象可以写成：</p>
<figure class="highlight text"><table><tr><td class="code"><pre><span class="line">single_sample_output</span><br><span class="line">batched_output</span><br><span class="line">valid_frame_range</span><br><span class="line">mask</span><br><span class="line">dtype</span><br><span class="line">layer_diffs</span><br></pre></td></tr></table></figure>

<p>先确认输入波形、特征、长度和 mask 是否一致，再逐层比较 hidden states。只要找到第一个 divergence 层，排查范围就会大幅缩小。</p>
<h2 id="工程闭环"><a href="#工程闭环" class="headerlink" title="工程闭环"></a>工程闭环</h2><p>建议按顺序检查：</p>
<ol>
<li>音频读取和重采样是否一致；</li>
<li>feature extraction 是否受 batch 影响；</li>
<li>padding 后 valid length 是否正确；</li>
<li>mask 是否覆盖 attention 和 convolution；</li>
<li>subsampling 后长度是否同步更新；</li>
<li>dtype、autocast、dropout 和随机种子是否固定；</li>
<li>cache 或 streaming state 是否被错误复用。</li>
</ol>
<p>最终报告不要只写“batch 不一致”，而要记录最早出现差异的层、差异量级、影响的有效区间和修复后的回归样本。</p>
<h2 id="反直觉点"><a href="#反直觉点" class="headerlink" title="反直觉点"></a>反直觉点</h2><p>不要先怀疑随机性。推理模式下如果 dropout 关闭、输入一致、随机种子固定，单样本和 batch 输出仍然不同，优先怀疑边界处理。padding、mask、subsampling length、归一化和缓存复用都比“模型随机”更常见。</p>
<p>也不要只看 padding。很多音频模型在 subsampling 后会改变时间轴长度，如果 length 没有同步更新，attention mask 看起来存在，实际已经错位。此时 padding 并不是直接污染输入，而是通过错误长度污染后续层。</p>
<p>dtype 也不能一开始背锅。混合精度会放大小误差，但如果第一差异层出现在 mask 或 length 之后，根因通常还是边界契约，而不是浮点精度。</p>
<h2 id="排障路径"><a href="#排障路径" class="headerlink" title="排障路径"></a>排障路径</h2><p>最小复现包可以固定四组：A 单独推理，A+A 组成 batch，A+B 组成混合长度 batch，A+长静音组成极端 padding batch。四组结果一跑，就能初步判断问题是 batch 维处理、长度混合、padding 泄漏，还是特殊输入触发。</p>
<p>随后 hook 中间层。每层记录有效区间内 max diff、mean diff、是否出现 NaN、mask 形状和 length 张量。若前两层 diff 接近零，第三层突然放大，就拆第三层内部路径：attention、卷积、norm、残差、缓存。</p>
<h2 id="实现契约"><a href="#实现契约" class="headerlink" title="实现契约"></a>实现契约</h2><p>Batch 一致性应该进入回归测试，而不是停留在 notebook。测试样本要覆盖短音频、长音频、同音频重复 batch、不同长度混合 batch、极短静音和接近最大长度的样本。</p>
<p>阈值也要分层。hidden state 允许极小浮点误差，离散输出应该完全一致或有明确豁免。报告里写清楚第一差异层、差异量级、有效区间和修复后的回归样本，后续优化才不会把同类 bug 带回来。</p>
<h2 id="小样本推演"><a href="#小样本推演" class="headerlink" title="小样本推演"></a>小样本推演</h2><p>如果 A 单独推理和 A+A batch 结果不同，优先查 batch 维、归一化和并行路径；如果 A 单独推理和 A+A 一致，但 A+B 不一致，重点转向长度混合、padding 和 mask；如果只有 A+长静音出问题，极端 padding 很可能触发了边界 bug。</p>
<p>这三个分叉能快速缩小范围。随后逐层 diff：若输入特征一致、前两层一致、第三层开始放大，就不要再盯最终文本或 beam search，而要拆第三层内部。排障的目标不是解释所有现象，而是找到第一处不该出现的差异。</p>
<h2 id="直接结论"><a href="#直接结论" class="headerlink" title="直接结论"></a>直接结论</h2><p>Batch 一致性问题的核心是边界控制。只要 batch 推理引入 padding，就必须验证 mask、subsampling、dtype 和缓存不会污染有效帧。逐层 diff 比反复猜参数更可靠。</p>
<p>下一步阅读：<a href="/2026/06/10/LLM-Speech-Inference-Serving-Observability/">LLM 与语音模型推理服务：先把延迟拆成可观测链路</a></p>
]]></content>
      <tags>
        <tag>Open Source</tag>
        <tag>ASR</tag>
        <tag>Engineering</tag>
        <tag>Debugging</tag>
      </tags>
  </entry>
  <entry>
    <title>实时语音 Turn-taking 评测：从端点检测到可接话判断</title>
    <url>/2026/06/10/Realtime-Speech-Turn-Taking-Evaluation/</url>
    <content><![CDATA[<p>实时语音系统里，判断用户“说完了”比看起来更难。静音不一定代表结束，短停顿可能只是思考；语义已经完整，也可能还会补充条件。Turn-taking 要解决的不是单纯端点检测，而是系统什么时候可以安全接话。</p>
<span id="more"></span>

<h2 id="要解决的问题"><a href="#要解决的问题" class="headerlink" title="要解决的问题"></a>要解决的问题</h2><p>传统 VAD 或 endpointing 主要看声学静音。实时助手需要更复杂的判断：当前 partial 结果是否语义完整，用户是否可能继续说，系统现在接话是否会打断。</p>
<p>如果判断过早，系统会抢话；判断过晚，交互 latency 会变差。这个 tradeoff 不能只靠经验阈值。</p>
<h2 id="主线判断"><a href="#主线判断" class="headerlink" title="主线判断"></a>主线判断</h2><p>Turn-taking 不是“检测用户说完”，而是在不确定输入下选择系统行动时机。</p>
<p>静音、semantic end、partial 稳定性和 latency 都只是信号，真正的输出不是一个客观标签，而是“现在接话是否值得”。这个判断必须同时考虑抢话成本和等待成本。</p>
<h2 id="最小抽象"><a href="#最小抽象" class="headerlink" title="最小抽象"></a>最小抽象</h2><p>一个 turn-taking 决策至少包含：</p>
<figure class="highlight text"><table><tr><td class="code"><pre><span class="line">audio_state</span><br><span class="line">partial_transcript</span><br><span class="line">semantic end score</span><br><span class="line">silence_duration</span><br><span class="line">rollback_risk</span><br><span class="line">latency_budget</span><br><span class="line">decision</span><br></pre></td></tr></table></figure>

<p><code>semantic end</code> 表示语义是否完成；<code>partial</code> 表示当前流式识别结果仍可能变化；<code>latency_budget</code> 控制系统为了更准愿意等多久。</p>
<h2 id="工程闭环"><a href="#工程闭环" class="headerlink" title="工程闭环"></a>工程闭环</h2><p>评测要同时看三类指标。</p>
<p>第一类是交互延迟：用户停顿后多久系统响应，p95&#x2F;p99 是否可接受。</p>
<p>第二类是打断率：系统是否在用户还没说完时抢答。</p>
<p>第三类是漏接或慢接：用户已经说完但系统迟迟不响应。</p>
<p>离线评测可以用标注的 turn boundary；在线评测还要记录 partial 变化、ASR 回滚、semantic end 分数和最终用户体验。</p>
<h2 id="反直觉点"><a href="#反直觉点" class="headerlink" title="反直觉点"></a>反直觉点</h2><p>静音不等于结束，语义完整也不等于可以接话。用户可能短暂停顿后继续补充，或者语义已经完整但还在列举条件。反过来，语义没有完全闭合时，系统也可能需要轻量反馈，以免交互显得停滞。</p>
<p>所以 Turn-taking 不能脱离系统动作讨论。如果系统接话后可以取消或轻量回滚，策略可以激进一点；如果一旦开口就会明显打断，就必须保守。模型输出的不是“结束事实”，而是“行动风险”。</p>
<p>低首包延迟和语义稳定也天然冲突。ASR partial 越早，越容易回滚；决策越稳，越可能慢。工程上应把识别层和决策层拆开：识别层尽早给候选，决策层用 partial 历史、回滚风险和 semantic end 分数决定是否接话。</p>
<h2 id="排障路径"><a href="#排障路径" class="headerlink" title="排障路径"></a>排障路径</h2><p>第一版评测应该从 timeline 回放做起。把音频能量、partial 文本、semantic end 分数、静音时长、候选边界、决策点和用户后续语音放在一条时间线上。只要能看到系统在什么信号组合下接话，阈值调整就不会变成盲调。</p>
<p>错误样本按四类分桶：正确接话、过早接话、过晚接话、正确等待。过早和过晚不能合并，因为修复方向相反。过早需要提高语义完成阈值或回滚风险权重；过晚需要放松等待策略或降低模型延迟。</p>
<h2 id="评测设计"><a href="#评测设计" class="headerlink" title="评测设计"></a>评测设计</h2><p>指标要同时包含动作质量和时间质量。动作质量看打断率、慢接率、漏接率、正确等待率。时间质量看 decision latency、first response latency、p95&#x2F;p99 和取消后的恢复时间。</p>
<p>最终报告要能回答一个具体问题：当前策略是偏向“少打断但慢”，还是“快响应但抢话多”。没有这个取舍曲线，Turn-taking 指标就只是一堆阈值实验。</p>
<h2 id="小样本推演"><a href="#小样本推演" class="headerlink" title="小样本推演"></a>小样本推演</h2><p>同一个候选边界，600ms 接话和 900ms 接话可能都是“对”的，但代价不同。600ms 可能让交互更快，也可能在用户补充条件时抢话；900ms 更稳，却可能让用户重复或以为系统没听懂。Turn-taking 评测要比较的不是单点准确率，而是这条代价曲线。</p>
<p>因此，每个错误样本都应该回放到时间线：系统在哪个 partial 上做了 decision，semantic end 当时多少，后续 partial 是否回滚，用户后面是否继续说。只看最终边界标签，会丢掉最关键的策略信息。</p>
<h2 id="直接结论"><a href="#直接结论" class="headerlink" title="直接结论"></a>直接结论</h2><p>Turn-taking 不是 VAD 的别名，而是声学、语义和延迟预算共同决定的接话策略。先把 partial、semantic end、silence 和 latency 分开记录，再调阈值或训练模型。</p>
<p>下一步阅读：<a href="/2026/06/10/LLM-Speech-Inference-Serving-Observability/">LLM 与语音模型推理服务：先把延迟拆成可观测链路</a></p>
]]></content>
      <tags>
        <tag>Open Source</tag>
        <tag>ASR</tag>
        <tag>Evaluation</tag>
        <tag>Speech</tag>
      </tags>
  </entry>
  <entry>
    <title>Hexo + GitHub Pages：个人博客先把发布链路跑通</title>
    <url>/2019/07/09/hexo-github-constructBlog/</url>
    <content><![CDATA[<p>个人博客最重要的第一步不是主题多漂亮，而是发布链路是否稳定：本地能写，静态站能生成，GitHub Pages 能托管，域名能访问，后续文章能持续更新。</p>
<p>Hexo + GitHub Pages 的价值在于把这个链路压到足够轻：Markdown 写作、Node.js 生成静态页面、GitHub 托管、域名解析到 Pages。</p>
<span id="more"></span>

<h2 id="要解决的问题"><a href="#要解决的问题" class="headerlink" title="要解决的问题"></a>要解决的问题</h2><p>自建博客常见失败点不是不会写文章，而是发布路径太重。服务器、数据库、后台、主题和域名同时上，很容易让写作被运维打断。</p>
<p>静态博客的思路是把动态能力降到最低：文章在本地生成 HTML，远端只托管静态文件。这样就不需要自建数据库和后端服务。</p>
<h2 id="主线判断"><a href="#主线判断" class="headerlink" title="主线判断"></a>主线判断</h2><p>Hexo + GitHub Pages 的主线不是搭一个页面，而是建立一条低维护成本的写作发布流水线。</p>
<p>静态博客的优势只有在流程可重复时才成立：本地写作、生成、预览、提交、部署、域名验证都应该是可检查动作。否则主题再漂亮，后续每次更新都会变成一次临时运维。</p>
<h2 id="最小抽象"><a href="#最小抽象" class="headerlink" title="最小抽象"></a>最小抽象</h2><p>一条最小发布链路如下：</p>
<figure class="highlight text"><table><tr><td class="code"><pre><span class="line">Markdown posts</span><br><span class="line">  -&gt; Hexo generate</span><br><span class="line">  -&gt; Git commit / deploy</span><br><span class="line">  -&gt; GitHub Pages</span><br><span class="line">  -&gt; Custom domain</span><br></pre></td></tr></table></figure>

<p>先在 GitHub 创建 <code>username.github.io</code> 仓库，再安装 Git、Node.js 和 Hexo CLI。</p>
<p><img src="/2019/07/09/hexo-github-constructBlog/gitbash.png"></p>
<p>Git 身份和 SSH key 的作用是让本地可以稳定推送到 GitHub：</p>
<figure class="highlight bash"><table><tr><td class="code"><pre><span class="line">git config --global user.name <span class="string">&quot;your-github-name&quot;</span></span><br><span class="line">git config --global user.email <span class="string">&quot;your-email@example.com&quot;</span></span><br><span class="line">ssh-keygen -t rsa -C <span class="string">&quot;your-email@example.com&quot;</span></span><br></pre></td></tr></table></figure>

<p><img src="/2019/07/09/hexo-github-constructBlog/ssh.jpg"></p>
<p><img src="/2019/07/09/hexo-github-constructBlog/newSSHKey.jpg"></p>
<p><img src="/2019/07/09/hexo-github-constructBlog/SSHTest.jpg"></p>
<p>Node.js 安装完成后确认 <code>node</code> 和 <code>npm</code> 可用：</p>
<p><img src="/2019/07/09/hexo-github-constructBlog/NodeJsTest.jpg"></p>
<p>Hexo 最小命令集：</p>
<figure class="highlight bash"><table><tr><td class="code"><pre><span class="line">npm install -g hexo-cli</span><br><span class="line">hexo init blog</span><br><span class="line">hexo new my-post</span><br><span class="line">hexo clean</span><br><span class="line">hexo generate</span><br><span class="line">hexo server</span><br><span class="line">hexo deploy</span><br></pre></td></tr></table></figure>

<h2 id="工程闭环"><a href="#工程闭环" class="headerlink" title="工程闭环"></a>工程闭环</h2><p>部署要变成可重复动作，而不是一次性教程。</p>
<p>首先在 <code>_config.yml</code> 中配置 deploy 目标和基础站点信息：</p>
<p><img src="/2019/07/09/hexo-github-constructBlog/BlogConfig1.jpg"></p>
<p><img src="/2019/07/09/hexo-github-constructBlog/BlogConfig2.jpg"></p>
<p>然后安装部署插件：</p>
<figure class="highlight bash"><table><tr><td class="code"><pre><span class="line">npm install hexo-deployer-git --save</span><br><span class="line">hexo clean</span><br><span class="line">hexo generate</span><br><span class="line">hexo deploy</span><br></pre></td></tr></table></figure>

<p>绑定域名时，关键是两边都要配置：域名解析指向 GitHub Pages，仓库或生成目录中保留 <code>CNAME</code> 文件。</p>
<p><img src="/2019/07/09/hexo-github-constructBlog/domain1.jpg"></p>
<p><img src="/2019/07/09/hexo-github-constructBlog/domain2.jpg"></p>
<p><img src="/2019/07/09/hexo-github-constructBlog/domain3.jpg"></p>
<p><img src="/2019/07/09/hexo-github-constructBlog/domain4.jpg"></p>
<p>如果长时间未更新后 <code>hexo server</code> 报错，通常是依赖漂移或本地服务包缺失，可以在博客根目录重新安装服务依赖：</p>
<figure class="highlight bash"><table><tr><td class="code"><pre><span class="line">npm install hexo-server --save</span><br></pre></td></tr></table></figure>

<h2 id="小样本推演"><a href="#小样本推演" class="headerlink" title="小样本推演"></a>小样本推演</h2><p>最小闭环可以只用一篇测试文章验证：先本地 <code>hexo generate</code>，确认目标 HTML 出现在 <code>public/</code>；再本地预览，确认图片和站内链接可用；最后部署到 Pages，并用自定义域名访问同一个路径。</p>
<p>如果本地可见、线上不可见，排查顺序应该是 Pages 分支、CNAME、DNS 和缓存，而不是直接怀疑 Markdown。把这条链路记录下来，博客维护才不会依赖记忆。</p>
<h2 id="直接结论"><a href="#直接结论" class="headerlink" title="直接结论"></a>直接结论</h2><p>Hexo + GitHub Pages 的核心价值是把个人博客的发布成本降到最低。先保证“写作 -&gt; 生成 -&gt; 预览 -&gt; 部署 -&gt; 域名访问”这条链路稳定，再考虑主题、评论、搜索和自动化。</p>
<p>博客系统不需要一开始就复杂。真正值得长期维护的是可重复发布、可备份、可迁移和可验证。</p>
<p>下一步阅读：<a href="/2026/06/10/Agentic-Coding-Governance/">Agentic Coding 工程治理：多模型协作的角色、权限与验证闭环</a></p>
<h3 id="References"><a href="#References" class="headerlink" title="References"></a>References</h3><p>[1] <a href="https://zhuanlan.zhihu.com/p/26625249">Hexo 建站参考</a></p>
]]></content>
      <tags>
        <tag>Blog</tag>
        <tag>Github</tag>
      </tags>
  </entry>
  <entry>
    <title>语音大模型工程：音频 token、LLM 主干与对齐契约</title>
    <url>/2026/06/10/Speech-LLM-Audio-Token-Alignment/</url>
    <content><![CDATA[<p>语音大模型不是把 ASR encoder 接到 LLM 上就结束了。真正困难的是接口契约：音频如何被压成 token，token 如何进入 LLM，文本监督如何约束语音表示，流式场景又如何保证延迟和上下文一致。</p>
<p>如果这个契约不清楚，Qwen3-ASR、Qwen-Omni、WeNet、CTC、AED、speech encoder 和 LLM 主干会变成一堆名词，而不是可排障的系统。</p>
<span id="more"></span>

<h2 id="要解决的问题"><a href="#要解决的问题" class="headerlink" title="要解决的问题"></a>要解决的问题</h2><p>传统 ASR 输出文本，LLM 处理文本。Speech-LLM 想把语音直接纳入语言模型能力，但语音和文本的粒度差异很大：音频帧密集、长度长、噪声多；文本 token 稀疏、语义压缩强。</p>
<p>工程上的关键问题是：语音侧的信息压缩到什么粒度，才能既保留识别所需细节，又不把 LLM 上下文窗口耗尽。</p>
<h2 id="主线判断"><a href="#主线判断" class="headerlink" title="主线判断"></a>主线判断</h2><p>语音大模型首先要定义清楚音频 token 契约，然后才谈架构强弱。</p>
<p>Qwen3-ASR、Qwen-Omni、WeNet、CTC、AED、projector 和 LLM 主干只是组件名。真正决定系统是否可训练、可推理、可排障的是：音频如何变成 token，token 如何进入文本序列，mask 如何定义，训练模板和推理模板是否一致。</p>
<h2 id="最小抽象"><a href="#最小抽象" class="headerlink" title="最小抽象"></a>最小抽象</h2><p>可以把 Speech-LLM 拆成四层。</p>
<p>第一层是音频前端和 speech encoder。WeNet、Qwen3-ASR 这类系统会把声学特征压成更高层的语音表示，常见监督包括 CTC、AED 或混合目标。</p>
<p>第二层是 projector 或 adapter。它负责把 speech encoder 输出映射到 LLM 可消费的向量空间。这里不是简单维度对齐，还包括时间下采样、位置编码和模态边界。</p>
<p>第三层是 LLM 主干。Qwen-Omni 这类多模态系统需要同时处理语音、文本甚至其他模态，因此输入序列必须标记清楚模态、时间和角色。</p>
<p>第四层是输出协议。系统到底输出转写、语义回答、结构化字段，还是边听边生成，会决定训练样本和解码策略。</p>
<h2 id="工程闭环"><a href="#工程闭环" class="headerlink" title="工程闭环"></a>工程闭环</h2><p>对齐问题必须可观测。至少要记录：</p>
<ul>
<li>音频时长到 speech token 数量的压缩比；</li>
<li>CTC 或 ASR 辅助目标是否稳定；</li>
<li>projector 输出是否导致 LLM 上下文过长；</li>
<li>流式场景下 partial 结果是否可回滚；</li>
<li>错误来自声学识别、模态对齐还是语言生成。</li>
</ul>
<p>一个实用排查顺序是先看 ASR 能力，再看对齐层，再看 LLM 生成。如果基础转写已经不稳定，直接调 prompt 或扩大 LLM 很难解决问题。</p>
<h2 id="反直觉点"><a href="#反直觉点" class="headerlink" title="反直觉点"></a>反直觉点</h2><p>强 LLM 可能会掩盖音频对齐错误。模型输出看起来流畅，不代表它真的使用了音频信息；它可能只是依赖文本 prompt 和语言先验补全答案。因此，Speech-LLM 不能只看最终回答，要看音频秒数、encoder 帧数、speech token 数、text token 数、special token 数和 label mask 比例。</p>
<p>CTC&#x2F;AED 辅助目标也不是越多越好。CTC 给帧级约束，AED 给序列生成约束，但如果某个分支在小数据 overfit 测试里都不下降，接到更大的 LLM 上也不会自然变好。辅助 loss 不稳定时，先查 mask、目标权重和梯度路径，而不是继续堆数据。</p>
<p>流式场景还多一层矛盾：低延迟需要早出 partial，稳定语义需要更多上下文。若 partial 和最终生成共用不稳定上下文，系统会频繁回滚。</p>
<h2 id="排障路径"><a href="#排障路径" class="headerlink" title="排障路径"></a>排障路径</h2><p>最小验证集至少包含短音频、长音频、静音、带噪音频、纯转写任务和语义回答任务。每个样本都记录 token 账本：audio_seconds、encoder_frames、speech_tokens、text_tokens、special_tokens、label_mask_ratio、CTC loss、AED loss、generation loss。</p>
<p>如果 speech token 数异常，查前端长度、下采样和 projector。若 label mask 比例异常，查训练模板。若 CTC loss 降而生成 loss 不动，问题可能在 projector 或 LLM 监督；若生成 loss 降而 CTC 不动，声学侧约束没有起作用；两个都不动，先查数据读取、特殊 token 和 mask。</p>
<h2 id="实现契约"><a href="#实现契约" class="headerlink" title="实现契约"></a>实现契约</h2><p>音频 token 契约至少写清四件事。第一，音频压缩比如何计算。第二，音频 token 插入到文本序列的哪个位置。第三，LLM attention 是否允许跨模态自由看。第四，训练和推理使用的特殊 token、模板和长度规则是否完全一致。</p>
<p>只要这份契约缺失，模型名再先进也很难排障。Speech-LLM 的工程成熟度，不在于接了多少组件，而在于每个样本都能解释“音频信息以什么形态进入了语言模型”。</p>
<h2 id="小样本推演"><a href="#小样本推演" class="headerlink" title="小样本推演"></a>小样本推演</h2><p>一个很实用的 sanity check 是静音样本。如果静音经过 encoder 和 projector 后仍然产生大量 speech token，并让 LLM 输出正常文本，说明模型很可能在依赖语言先验，而不是音频证据。另一个检查是长音频样本：speech token 数是否随时长线性膨胀，是否把上下文窗口迅速吃满。</p>
<p>纯转写样本和语义回答样本也要分开看。转写失败通常指向声学或对齐；转写正确但回答错误，才更像 LLM 侧整合问题。两者混在一起评测，会让系统误以为是“综合能力不足”，实际只是接口契约不清。</p>
<h2 id="直接结论"><a href="#直接结论" class="headerlink" title="直接结论"></a>直接结论</h2><p>Speech-LLM 的工程边界在音频 token 契约，而不是模型名字。先定义清楚音频如何压缩、如何接入 LLM、如何监督、如何流式输出，再比较 Qwen3-ASR、Qwen-Omni、WeNet 或其他方案。</p>
<p>下一步阅读：<a href="/2026/06/10/LLM-Speech-Inference-Serving-Observability/">LLM 与语音模型推理服务：队列、流式与可观测性</a></p>
]]></content>
      <tags>
        <tag>LLM</tag>
        <tag>Open Source</tag>
        <tag>ASR</tag>
        <tag>Speech</tag>
      </tags>
  </entry>
  <entry>
    <title>语音对话合成数据工程：Schema、口语化与质量闸门</title>
    <url>/2026/06/11/Speech-Dialog-Data-Synthesis-Quality-Gates/</url>
    <content><![CDATA[<p>合成对话数据的风险不是“生成得不够多”，而是生成得太像模板、太干净、太不符合语音输入的真实噪声。数量扩大很容易，难的是让样本既覆盖任务，又不把模型训练成只会回答标准文本。</p>
<p>所以语音对话合成数据要先设计质量闸门，再谈规模。</p>
<span id="more"></span>

<h2 id="要解决的问题"><a href="#要解决的问题" class="headerlink" title="要解决的问题"></a>要解决的问题</h2><p>对话数据要服务下游训练和评测。它既要有结构化 schema，保证字段、意图、实体和状态可控；又要有口语化表达，覆盖停顿、重复、自我修正、n-best 候选和 ASR 错误。</p>
<p>如果只生成标准书面语，模型上线后会被真实口语击穿。如果只追求随机扰动，样本又会失去任务结构。</p>
<h2 id="主线判断"><a href="#主线判断" class="headerlink" title="主线判断"></a>主线判断</h2><p>合成语音对话数据真正要模拟的是不确定性，而不是生产更整齐的文本。</p>
<p>对话数据越干净，越可能远离真实语音输入。真正有价值的合成样本，要同时保留 schema 约束、口语化扰动、n-best 不确定性、状态变化和失败原因。它不是文本扩增，而是一个可控的交互模拟器。</p>
<h2 id="最小抽象"><a href="#最小抽象" class="headerlink" title="最小抽象"></a>最小抽象</h2><p>一条合成样本至少要包含：</p>
<figure class="highlight text"><table><tr><td class="code"><pre><span class="line">dialogue_id</span><br><span class="line">turns</span><br><span class="line">intent</span><br><span class="line">entities</span><br><span class="line">state</span><br><span class="line">n-best</span><br><span class="line">quality_flags</span><br><span class="line">reason code</span><br></pre></td></tr></table></figure>

<p><code>quality_flags</code> 记录口语化、实体覆盖、逻辑一致性、敏感词、重复和异常格式。<code>reason code</code> 说明样本为什么保留、丢弃或需要人工复核。</p>
<h2 id="工程闭环"><a href="#工程闭环" class="headerlink" title="工程闭环"></a>工程闭环</h2><p>质量闸门可以分三层。</p>
<p>第一层是 schema 校验：字段是否完整、实体是否在合法范围、状态转移是否合理。</p>
<p>第二层是语言质量：是否过于模板化、是否包含自然口语、是否有重复和自我修正。</p>
<p>第三层是训练影响：加入这批数据后，目标任务指标是否提升，错误类型是否减少，是否引入系统性偏差。</p>
<p>每一批合成数据都应该能回溯到生成配置、过滤规则和评测结果。否则数据越多，问题越难定位。</p>
<h2 id="反直觉点"><a href="#反直觉点" class="headerlink" title="反直觉点"></a>反直觉点</h2><p>schema 越严格，不代表数据越好。schema 能保证字段合法，但也容易把样本变成模板填空。模型会学到固定字段顺序，却学不到真实输入里的停顿、重复、修正和候选歧义。</p>
<p>口语化也不是随机加噪。随机插入口头词、重复句子或错别字，可能让文本看起来更像口语，却破坏实体、状态和轮次关系。好的生成流程应该是先生成结构化计划，再生成口语化表达，最后把表达回填到 schema 校验。如果回填失败，这条样本就应该带着 reason code 进入复核，而不是被静默丢弃。</p>
<p>n-best 的价值也常被低估。语音输入里很多错误来自候选不确定性，而不是唯一 transcript 的文字错误。训练样本保留 n-best，可以让模型学会在模糊表达下维持状态。</p>
<h2 id="排障路径"><a href="#排障路径" class="headerlink" title="排障路径"></a>排障路径</h2><p>第一批数据不要追求数量，先跑一个小闭环：固定少量 schema，生成样本，做 schema 回填校验，抽查失败样本，再做一次增量训练。每条失败样本都标明原因：字段缺失、状态冲突、实体漂移、轮次不一致、表达模板化，或者过滤规则过严。</p>
<p>如果加入合成数据后指标没有提升，先不要扩大规模。要看错误分布是否变化：是不是边界样本变好了但常规样本变差了，是不是状态跟踪改善但实体抽取下降了，是不是模型学到了模板口吻。</p>
<h2 id="评测设计"><a href="#评测设计" class="headerlink" title="评测设计"></a>评测设计</h2><p>离线质量看 schema 通过率、字段覆盖率、实体合法率、轮次一致性、口语化比例、重复率和 quality_flags 分布。训练收益看目标任务指标、状态跟踪错误、实体抽取错误、异常输入恢复能力和真实口语样本泛化。</p>
<p>最重要的是增量评测。一次只加入一批合成策略，记录它改善了哪类错误、引入了哪类新偏差。合成数据的目标不是让训练集变大，而是让错误类型变得可控。</p>
<h2 id="小样本推演"><a href="#小样本推演" class="headerlink" title="小样本推演"></a>小样本推演</h2><p>一条合成样本可以先有结构化计划：这一轮要表达哪个 intent，哪些 entities 必须出现，状态从哪里转到哪里。随后再生成口语化表达，比如重复、停顿、自我修正和候选歧义。最后把生成表达重新解析回 schema：如果字段回填失败，这不是小瑕疵，而是训练目标已经漂移。</p>
<p>这样的闭环能避免两类坏数据。第一类是漂亮但无效的文本，看起来像自然对话，实际状态对不上。第二类是合法但僵硬的模板，schema 全过，模型却学不到真实语音输入的不确定性。质量闸门要同时拦住这两类样本。</p>
<h2 id="直接结论"><a href="#直接结论" class="headerlink" title="直接结论"></a>直接结论</h2><p>语音对话合成数据的核心不是生成，而是质量治理。先把 schema、quality_flags、n-best、reason code 和评测回流建起来，再扩大规模。没有这些闸门，合成数据会把训练目标污染成系统性偏差。</p>
<p>下一步阅读：<a href="/2026/06/10/ASR-Data-Quality-Pipeline-Open-Source/">ASR 数据质量流水线：伪标签、切分与可追溯评测</a></p>
]]></content>
      <tags>
        <tag>Open Source</tag>
        <tag>ASR</tag>
        <tag>Data</tag>
        <tag>Evaluation</tag>
      </tags>
  </entry>
</search>