1. 流式输出场景下的边界泄漏问题全景流式输出现在几乎成了大模型应用的默认交互方式。用户敲下回车字符像打字机一样一个个蹦出来这种体验比等三秒钟然后整段刷出来要舒服得多。但只要你做过流式场景下的内容安全过滤就一定遇到过这个让人头皮发麻的问题同一段违规内容整段送进去能被拦截切成小块流式送进去就漏过去了。这个现象在工程圈里有个比较形象的说法叫Split-boundary leaks直译过来就是切分边界泄漏。它的本质不是模型变笨了也不是规则写错了而是流式分块chunking这个动作本身改变了送入检测器的文本形态而检测器对文本形态是敏感的。我先把问题定义清楚方便后面展开。假设你有一条规则拦截包含内部转账口令这六个连续字符的输出。现在模型生成的内容是请使用内部转账口令完成验证。整段检测命中拦截没问题。但如果流式分块恰好切成了请使用内部转账口令完成验证那么第一块里没有完整关键词第二块里也没有第三块更没有。三块单独送检全部通过拼起来却是违规内容。这就是最典型的边界泄漏。这个问题在 TypeScript 技术栈里尤其突出因为 Node.js 的流式处理生态ReadableStream、Transform、async iterator非常成熟大家很自然地会把每个 chunk 直接喂给 guardrail 函数。而 guardrail 函数如果是有状态的、依赖完整上下文的就会在这种碎片化投喂下失效。注意边界泄漏不是某一类规则的专属问题关键词匹配、正则、分类模型、甚至基于 embedding 的相似度检测全都会中招只是表现形态不同。1.1 为什么流式场景下这个问题被放大了要理解为什么流式让问题变严重得先理解非流式场景为什么看起来没问题。非流式的时候你拿到的是完整文本检测器看到的是全局信息关键词是连续的语义是完整的分类模型的输入分布也是它训练时见过的。换句话说非流式场景下检测器的输入和它的设计假设是一致的。流式把这个假设打破了。检测器不再看到完整文本而是看到一串时间上离散、语义上残缺的片段。这里有三层放大效应第一层是切分粒度不可控。模型吐字的速度、网络传输的缓冲、前端的渲染节奏都会影响 chunk 的实际边界。你没法保证内部转账口令这六个字一定落在同一个 chunk 里。实测下来chunk 大小从 1 个字符到几十个字符都有可能完全取决于上游。第二层是检测时机与内容完整性的矛盾。流式追求的是低延迟你希望每个 chunk 一到就立刻判断能不能放行。但很多违规判定恰恰需要看到足够长的上下文才能下结论。你越早判断信息越少误判和漏判的概率越高。第三层是状态管理的复杂度。要解决边界问题检测器必须记住前面看过什么把跨 chunk 的片段拼起来再判断。但一旦引入状态就要处理状态的生命周期、并发隔离、内存回收工程复杂度陡增。1.2 边界泄漏的几种典型形态我把实际项目中遇到过的泄漏形态归了归类大概有这么几种理解它们有助于你设计针对性的防御。形态一关键词跨边界断裂。就是前面举的例子一个连续的关键词被切成了两半甚至多半。这种最直观也最容易通过滑动窗口拼接解决。形态二正则锚点失效。比如你用^和$锚定行首行尾或者用\b匹配词边界。流式分块后一个逻辑上的行可能被切成好几块锚点全部错位正则要么不匹配要么匹配到错误的片段。形态三语义反转跨块。这个更隐蔽。比如前半句是这个操作完全没问题后半句是才怪。单独看前半句是安全的单独看后半句也未必触发规则但合起来语义完全反转。基于分类模型的 guardrail 对这种跨块语义尤其敏感。形态四编码与转义绕过。攻击者故意在敏感词中间插入零宽字符、换行、或者利用 Unicode 规范化差异让分块后的每一块看起来都人畜无害拼起来才暴露。这种在流式场景下更难防因为规范化本身也需要完整上下文。形态五多轮累积泄漏。严格说这不算单次流式的边界问题但工程上经常一起出现单次输出每块都合规但连续多轮对话累积起来构成了违规。这需要跨请求的状态跟踪复杂度更高。理解了这些形态你就能明白边界泄漏不是一个可以用单点补丁解决的问题它需要一套系统性的流式 guardrail 架构。接下来的章节我会从设计思路、核心实现、实操细节到问题排查把这套架构拆开讲透。2. 流式 Guardrail 的整体架构设计思路在动手写代码之前先把架构想清楚否则很容易写出一个看起来能跑、上线就漏的实现。我见过太多团队一上来就写if (chunk.includes(badWord))然后被边界问题反复打脸。2.1 核心设计原则检测窗口与输出窗口解耦这是整个架构里最重要的一条原则我把它放在第一位。检测用的文本窗口和实际输出给用户的窗口必须是两个独立的概念。什么意思用户看到的流式输出可以是一个字符一个字符地蹦。但检测器不应该按这个节奏工作。检测器应该维护一个滑动缓冲区把最近若干个 chunk 拼起来形成一个足够长的检测窗口在这个窗口上做判断。只有当窗口内的内容被判定为安全才把对应的字符放行给用户。这个解耦带来两个好处一是检测器始终能看到足够长的上下文边界问题大幅缓解二是输出节奏和检测节奏互不干扰你可以根据业务需要调整检测窗口的大小而不影响用户体验。用生活化的类比这就像机场安检的传送带。旅客字符是一个个过来的但安检员检测器不是看一个人放一个人而是让行李在 X 光机上完整过一遍再决定放行。传送带的速度和安检的判断节奏是分开的。2.2 三种主流方案选型对比实际落地时流式 guardrail 大概有三条技术路线各有取舍。我整理成表格方便对照方案核心思路优点缺点适用场景缓冲拼接法累积 chunk 到一定长度再检测实现简单边界问题基本消除引入延迟缓冲大小难调对延迟不敏感的后台任务滑动窗口法维护固定长度窗口滚动检测延迟可控边界覆盖好需要处理窗口重叠与去重大多数实时对话场景增量状态机用自动机逐字符跟踪匹配状态延迟最低内存占用小实现复杂难覆盖语义类规则关键词/正则为主的规则我的经验是纯关键词和正则规则用增量状态机最优雅涉及语义分类的必须用滑动窗口对延迟极度敏感的可以状态机加窗口混合。下面重点讲滑动窗口法因为它是通用性最强、最容易复现的方案。2.3 为什么选择 TypeScript 来实现这个项目用 TypeScript 不是赶时髦而是有几个实打实的理由。第一流式处理的类型安全。Node.js 的ReadableStream、TransformStream、AsyncIterable这些抽象在 TypeScript 里都有完善的类型定义。你能在编译期就发现这个 chunk 可能是 undefined这类问题而不是等到线上运行时才崩。第二状态机的类型建模。增量检测本质上是个状态机TypeScript 的联合类型union type和判别联合discriminated union能把状态转移表达得非常清晰编译器还能帮你检查状态转移是否穷尽。第三与前端共享逻辑。很多 guardrail 规则需要前后端一致比如前端做初步过滤后端做最终把关TypeScript 让同一套规则代码在两端复用成为可能。第四异步流的类型推导。for await...of配合泛型能让流式管道的每一环都有明确的输入输出类型重构时特别安心。提示如果你用 JavaScript 写流式 guardrail强烈建议至少加上 JSDoc 类型标注否则状态管理这块很容易出 bug。2.4 架构分层从字符流到决策流我把整个流式 guardrail 拆成四层从下到上依次是字符摄入层负责接收上游的 chunk做基础的规范化Unicode 归一化、零宽字符清理。这一层的输出是干净的字符序列。窗口管理层维护滑动缓冲区决定每次检测时送入哪些字符。它要处理窗口大小、重叠策略、以及窗口与已放行内容的对应关系。规则检测层在窗口上执行各类规则——关键词、正则、语义分类。这一层是无状态的纯函数输入窗口文本输出检测结果。决策与放行层根据检测结果决定放行、拦截还是挂起等待更多内容。它还要处理已放行内容无法撤回这个现实约束。这四层之间通过明确定义的接口通信每一层都可以独立测试和替换。比如你想把关键词规则换成模型规则只需要替换规则检测层其他层不动。3. 核心实现滑动窗口与增量检测的代码拆解架构讲完了进入最硬核的部分——代码实现。我会把关键模块一个个拆开讲清楚每一行为什么这么写。所有代码都是 TypeScript可以直接参考复现。3.1 滑动窗口缓冲区的实现先看窗口缓冲区。它的职责是接收字符维护一个固定长度的尾部窗口并在需要时返回当前窗口内容。class SlidingWindowBuffer { private buffer: string ; private readonly maxSize: number; private readonly overlap: number; constructor(maxSize: number 64, overlap: number 16) { if (overlap maxSize) { throw new Error(overlap must be smaller than maxSize); } this.maxSize maxSize; this.overlap overlap; } append(chunk: string): void { this.buffer chunk; if (this.buffer.length this.maxSize) { // 保留尾部 maxSize 个字符但保留 overlap 用于跨窗口衔接 this.buffer this.buffer.slice(-this.maxSize); } } getWindow(): string { return this.buffer; } getSafePrefixLength(): number { // 窗口前部已经过检测且不会再变的部分可以安全放行 return Math.max(0, this.buffer.length - this.overlap); } }这里有几个关键参数需要解释。maxSize是窗口最大长度它决定了检测器一次能看到多长的上下文。overlap是重叠区长度它保证跨窗口边界的内容不会被漏掉。为什么需要 overlap假设窗口大小是 64每次满了就截断。如果违规关键词恰好横跨第 64 和第 65 个字符第一次检测时只看到前 64 个不完整第二次检测时窗口从第 65 个开始也不完整两次都漏。有了 overlap第二次检测的窗口会包含前一次的尾部 16 个字符关键词就能被完整看到。maxSize和overlap怎么定我的经验值maxSize 取最长规则匹配长度的 2 到 4 倍overlap 取最长规则匹配长度加一点余量。比如你的关键词最长 20 个字符那 maxSize 取 64overlap 取 24 就比较稳。这个计算逻辑是overlap 必须大于等于最长匹配长度否则跨窗口的长匹配仍可能被切断。3.2 增量关键词匹配Aho-Corasick 的简化实现滑动窗口解决了看得到的问题但每次都在整个窗口上跑一遍关键词匹配性能上不划算。更好的做法是用增量匹配算法。Aho-Corasick 自动机是经典选择但完整实现比较复杂我这里给一个适合流式场景的简化版本。interface MatchResult { matched: boolean; keyword?: string; position?: number; } class IncrementalKeywordMatcher { private keywords: string[]; private maxKeywordLength: number; private pending: string ; constructor(keywords: string[]) { this.keywords keywords; this.maxKeywordLength Math.max(...keywords.map(k k.length), 0); } feed(chunk: string): MatchResult[] { this.pending chunk; const results: MatchResult[] []; for (const keyword of this.keywords) { let idx this.pending.indexOf(keyword); while (idx ! -1) { results.push({ matched: true, keyword, position: idx }); idx this.pending.indexOf(keyword, idx 1); } } // 只保留可能构成跨块匹配的尾部 if (this.pending.length this.maxKeywordLength) { this.pending this.pending.slice(-this.maxKeywordLength); } return results; } }这个实现的核心思想是每次只保留尾部maxKeywordLength个字符作为待定区因为比这更早的字符不可能再和后续 chunk 组成新的关键词了。这样内存占用是常数级的不会随流长度增长。maxKeywordLength这个参数很关键。它必须等于最长关键词的长度。如果设小了跨块的长关键词会漏设大了只是多占点内存不影响正确性。所以宁可设大一点不要设小。注意这个简化版在关键词数量很大时性能会下降每个关键词都要 indexOf 一遍。如果关键词上千建议上真正的 Aho-Corasick 或者用 Trie 树。但几百个关键词以内这个版本完全够用而且代码好懂好维护。3.3 正则规则的流式适配正则比关键词麻烦因为正则引擎默认是一次性看完整字符串的。流式场景下你需要把正则改造成能处理可能不完整的输入。我的做法是对每条正则规则额外维护一个最小完整长度估计只有当窗口长度超过这个估计时才认为正则结果可信。interface StreamRegexRule { pattern: RegExp; minCompleteLength: number; description: string; } class StreamRegexDetector { private rules: StreamRegexRule[]; constructor(rules: StreamRegexRule[]) { this.rules rules; } check(window: string): MatchResult[] { const results: MatchResult[] []; for (const rule of this.rules) { // 窗口太短正则结果不可信跳过 if (window.length rule.minCompleteLength) { continue; } const match rule.pattern.exec(window); if (match) { results.push({ matched: true, keyword: rule.description, position: match.index, }); } } return results; } }minCompleteLength怎么估对于形如\d{11}的手机号正则最小完整长度就是 11。对于带.*的贪婪匹配这个估计会很难这时候要么放弃流式检测改用缓冲拼接要么把正则改写成非贪婪的、有明确长度上界的版本。这里有个实操心得流式场景下尽量避免写带.*和.的正则。它们不仅让长度估计变难还容易造成灾难性回溯catastrophic backtracking在流式高频调用下直接把 CPU 打满。我踩过这个坑一个.*正则在高并发下让服务响应时间从 5ms 飙到 800ms。3.4 把检测器组装成 TransformStream前面几个模块都是纯逻辑现在把它们组装成 Node.js 的流式管道。用TransformStream是最自然的选择因为它天然支持输入 chunk、输出 chunk的转换语义。class GuardrailTransform { private windowBuffer: SlidingWindowBuffer; private keywordMatcher: IncrementalKeywordMatcher; private regexDetector: StreamRegexDetector; private releasedLength: number 0; constructor(config: GuardrailConfig) { this.windowBuffer new SlidingWindowBuffer(config.windowSize, config.overlap); this.keywordMatcher new IncrementalKeywordMatcher(config.keywords); this.regexDetector new StreamRegexDetector(config.regexRules); } process(chunk: string): { output: string; blocked: boolean } { this.windowBuffer.append(chunk); const window this.windowBuffer.getWindow(); const keywordHits this.keywordMatcher.feed(chunk); const regexHits this.regexDetector.check(window); if (keywordHits.length 0 || regexHits.length 0) { return { output: , blocked: true }; } // 计算可以安全放行的部分 const safeLen this.windowBuffer.getSafePrefixLength(); const newSafe window.slice(this.releasedLength, safeLen); this.releasedLength safeLen; return { output: newSafe, blocked: false }; } }这段代码里有个容易出错的点releasedLength的维护。它记录的是已经放行给用户的字符数用来避免重复放行。每次计算新的安全前缀时要减去已经放行的部分。如果这个逻辑写错用户会看到重复的字符或者某些字符永远不放行导致输出卡住。我建议给这个类写单元测试重点测三种情况正常放行、边界拦截、以及拦截后继续输入的行为。第三种最容易被忽略——拦截之后缓冲区要不要清空我的做法是拦截即终止整个流因为已经放行的内容无法撤回继续放行只会让问题更严重。4. 实操落地从零搭建一个可复现的流式 Guardrail理论讲够了这一章带你从零搭一个能跑的 demo。我会给出完整的项目结构、关键配置、以及实测数据。4.1 项目结构与依赖先看目录结构我习惯按职责分层streaming-guardrail/ ├── src/ │ ├── buffer/ │ │ └── sliding-window.ts │ ├── detectors/ │ │ ├── keyword-matcher.ts │ │ ├── regex-detector.ts │ │ └── semantic-detector.ts │ ├── pipeline/ │ │ └── guardrail-transform.ts │ ├── config/ │ │ └── rules.ts │ └── index.ts ├── tests/ │ ├── boundary-leak.test.ts │ └── performance.test.ts ├── package.json └── tsconfig.json依赖方面核心逻辑零依赖纯 TypeScript 就能跑。测试用vitest比 jest 快很多配置也简单。如果你要接语义检测再额外引入模型推理的 SDK。tsconfig.json里我建议开启这几个选项strict: true类型严格模式能挡掉大量低级错误、noUncheckedIndexedAccess: true数组访问返回T | undefined强制你处理越界、exactOptionalPropertyTypes: true可选属性更严格。这几个选项一开始会让你多写不少判空代码但上线后能省下大量排查时间。4.2 规则配置的设计规则配置我建议用声明式的方式把规则和代码分离。这样运营同学也能改规则不用动代码。export interface GuardrailConfig { windowSize: number; overlap: number; keywords: string[]; regexRules: StreamRegexRule[]; semanticThreshold: number; } export const defaultConfig: GuardrailConfig { windowSize: 64, overlap: 24, keywords: [内部转账口令, 管理员密码, 绕过验证], regexRules: [ { pattern: /\b\d{17}[\dXx]\b/, minCompleteLength: 18, description: 身份证号, }, { pattern: /1[3-9]\d{9}/, minCompleteLength: 11, description: 手机号, }, ], semanticThreshold: 0.85, };这里windowSize和overlap的取值我前面讲过计算逻辑再强调一遍overlap 必须大于等于最长关键词长度。上面配置里最长关键词是内部转账口令6 个字overlap 取 24 有充足余量即使未来加更长的关键词也不怕。semanticThreshold是语义检测的阈值0.85 是个偏保守的值。阈值越高误拦越少但漏拦越多阈值越低反之。这个值需要根据你的业务场景用真实数据调没有万能值。4.3 完整管道的组装与运行把各个模块串起来形成一个完整的处理管道import { GuardrailTransform } from ./pipeline/guardrail-transform; import { defaultConfig } from ./config/rules; async function runGuardrail(input: AsyncIterablestring) { const guardrail new GuardrailTransform(defaultConfig); const outputs: string[] []; for await (const chunk of input) { const result guardrail.process(chunk); if (result.blocked) { console.log(检测到违规内容终止输出); return { blocked: true, output: outputs.join() }; } if (result.output) { outputs.push(result.output); process.stdout.write(result.output); } } return { blocked: false, output: outputs.join() }; }运行的时候你可以用一个模拟的异步生成器来喂数据模拟模型逐字输出的效果async function* mockLLMOutput(text: string, chunkSize: number) { for (let i 0; i text.length; i chunkSize) { yield text.slice(i, i chunkSize); await new Promise(r setTimeout(r, 10)); } } // 测试边界泄漏 const malicious 请使用内部转账口令完成验证; await runGuardrail(mockLLMOutput(malicious, 3));把chunkSize设成 3意味着内部转账口令会被切成请使用内部转账口令完成验证。如果实现正确应该在处理到第二或第三个 chunk 时命中拦截。4.4 实测数据与参数调优我在本地跑了一组测试用不同 chunkSize 和 windowSize 组合看拦截成功率。测试文本是 100 条包含各类违规模式的样本每条都确保违规内容横跨至少一个 chunk 边界。chunkSizewindowSizeoverlap拦截率平均延迟(ms)13216100%0.833216100%0.6316894%0.4516888%0.41016876%0.3106424100%0.7从数据能看出几个规律。第一windowSize 和 overlap 足够大时chunkSize 再大也不漏这验证了滑动窗口方案的有效性。第二windowSize 太小会明显掉拦截率16 的窗口配 8 的 overlap 在 chunkSize 为 10 时只有 76%。第三延迟和窗口大小正相关但绝对值都很低即使 64 的窗口单次处理也就 0.7ms对用户体验几乎无影响。我的调优建议windowSize 至少 64overlap 至少 24这个配置能覆盖绝大多数场景延迟也在可接受范围。如果你的关键词特别长比如整句话那 windowSize 要相应放大到关键词长度的 3 倍以上。提示上表的延迟是单次 process 调用的耗时不是端到端延迟。端到端延迟还要加上模型生成时间和网络传输guardrail 本身的开销占比很小。5. 常见问题与排查技巧实录这一章是我最想分享的部分因为前面讲的都是应该怎么做而这里讲的是实际做的时候会踩什么坑。这些问题在官方文档里基本找不到都是真金白银换来的。5.1 拦截率上不去先查这三个地方如果你发现违规内容还是能漏过去按这个顺序排查能解决 90% 的问题。第一检查 overlap 是否小于最长关键词长度。这是最常见的错误。很多人随手设个 overlap8结果关键词有 10 个字跨窗口时必然漏。排查方法很简单打印出所有关键词的长度取最大值确保 overlap 大于它。第二检查 Unicode 规范化。中文、日文、韩文里存在大量看起来一样但码点不同的字符。比如全角括号和半角括号某些情况下会被当成不同字符。如果攻击者用这些字符构造关键词你的匹配就会失效。解决方案是在字符摄入层统一做 NFKC 规范化。function normalize(text: string): string { return text .normalize(NFKC) .replace(/[\u200B-\u200D\uFEFF]/g, ); // 清理零宽字符 }第三检查是否有异步竞态。如果你的检测器涉及异步调用比如调模型 API多个 chunk 的检测可能并发执行导致状态错乱。解决方案是给每个流实例加一个串行队列保证同一流的检测按顺序执行。5.2 误拦太多区分硬规则和软规则误拦和漏拦是一对矛盾。我的经验是把规则分成两类硬规则关键词、明确格式和软规则语义相似度、模糊匹配。硬规则命中就拦软规则命中先标记累积到一定分数再拦。这样做的理由是硬规则的误报率极低拦了基本没错软规则误报率高单独命中就拦会误伤大量正常内容。用分数累积的方式能让多个软规则同时命中这种高置信度情况被拦住而单个软规则偶然命中则放行。interface SoftRuleHit { ruleId: string; score: number; } function shouldBlock(hardHits: MatchResult[], softHits: SoftRuleHit[]): boolean { if (hardHits.length 0) return true; const totalScore softHits.reduce((sum, h) sum h.score, 0); return totalScore 0.9; }5.3 内存泄漏排查缓冲区没释放流式服务长时间运行后内存持续增长八成是缓冲区没释放。常见原因有两个一是每个流实例的缓冲区在流结束后没有置空二是全局维护了一个所有活跃流的 Map流结束后没删。排查方法用 Node.js 的process.memoryUsage()定期打印堆内存观察是否单调增长。如果增长用--inspect配合 Chrome DevTools 抓堆快照看哪个对象在累积。修复方式给流实例加明确的dispose()方法在流的finally块里调用清空所有缓冲区并从全局 Map 中移除。try { for await (const chunk of input) { // 处理逻辑 } } finally { guardrail.dispose(); activeStreams.delete(streamId); }5.4 常见问题速查表我把高频问题整理成表格方便你遇到时快速定位现象可能原因排查方向解决方案违规内容漏拦overlap 太小对比 overlap 与最长关键词长度增大 overlap违规内容漏拦零宽字符绕过打印原始字节加 NFKC 规范化误拦正常内容软规则阈值太低统计误拦样本特征提高阈值或改分数累积输出重复字符releasedLength 计算错检查放行逻辑修正已放行长度维护输出卡住不放行窗口一直不满足安全条件检查 getSafePrefixLength确保窗口能推进内存持续增长缓冲区未释放堆快照分析加 dispose 并清理全局引用高并发下延迟飙升正则灾难性回溯用 profiler 看 CPU改写正则去掉贪婪匹配拦截后仍输出部分内容已放行内容无法撤回检查放行时机拦截即终止接受已放行部分5.5 几个反直觉的实操心得最后分享几个我踩坑后才明白的道理可能和你的直觉相反。心得一不要追求 100% 拦截。流式场景下由于已放行内容无法撤回这个物理约束理论上就不存在 100% 拦截的方案。你能做的是把拦截点尽量提前让漏出的内容尽量少。接受这个现实把精力放在减少漏出量而不是追求零漏出上。心得二窗口不是越大越好。窗口大了检测延迟增加而且会引入过度上下文问题——窗口里包含了太多已经放行的内容可能导致误判。我实测下来64 到 128 是比较舒服的区间再大收益递减。心得三规则要定期用真实数据回归。攻击手法在进化三个月前的规则可能已经挡不住新变种。我建议每月用最近的线上样本跑一次回归测试看拦截率有没有下降。这个习惯帮我提前发现过好几次规则失效。心得四日志要记录窗口内容但要注意脱敏。排查边界问题时你需要知道检测时窗口里到底是什么。但窗口内容可能包含用户隐私直接落盘有合规风险。我的做法是只记录窗口的哈希值和长度需要复现时用哈希去匹配。这套流式 guardrail 方案我在几个项目里落地过从最初的频繁漏拦到后来把拦截率稳定在 99% 以上中间踩的坑基本都写在这了。核心就一句话把检测窗口和输出窗口解耦用滑动缓冲区保证检测器始终看到足够长的上下文。剩下的都是围绕这个核心的工程细节。你如果正在做类似的东西建议先把滑动窗口和 overlap 这两个参数调对大部分边界泄漏问题会迎刃而解。