- 博客(406)
- 收藏
- 关注
RSS订阅
15原创 无限 token 也绕不过 review 带宽：遗留模块批量重写的分片、差分测试与按批回滚闸门
无限 token 改变的是生产队列的吞吐，它不改变审查队列的吞吐，而系统吞吐由两者中较小的那个决定。所以流水线的设计中心不是 agent，是 reviewer 的队列长度：在审批次数到了N × k就停派，批次大小按审查时长反推而不是按代码行数。每批配两层验收。第一层是 golden master 差分，它证明新旧实现在给定输入集合上不可区分；第二层是预期差异白名单，它把“哪些行为允许改变”变成事前签字。两层缺一不可——只有差分，你没法修 bug；只有白名单，你不知道改动波及了什么。门禁要分两级。
2026-11-06 09:51:51
175
原创 重建索引的那两个小时线上不能停：双写窗口、别名原子切换与新旧索引答案一致性抽样
对账差值为空，且连续若干分钟没有新的差异产生——说明双写和对账把增量对齐了；固定问题集的 Wilson 上界低于阈值，且单向丢失条数为零——说明新索引的检索行为可接受；双写仍在运行，旧索引完整——说明回滚窗口还开着。三个条件里，第三条最容易被提前放弃。它不产生任何指标，看起来只是“多跑一倍的写入”，但它是唯一能在切换出问题时把损失控制在秒级的机制。观察期结束之前，旧索引的价值不是“备份”，是“退路”。
2026-11-06 09:50:24
121
原创 示例库越加越多效果反而变差：动态 few-shot 的选择、去重与污染清洗，用任务成功率与选择一致率验收
把「加了示例效果变差」当成一个笼统的现象，就永远调不动。它至少是三条互相独立的链路，每条有自己的度量。通道一：冗余。库容量增长快于语义覆盖增长。同一条业务规则被不同人写成五个版本，检索器无法区分，Top-K 全部落在这一簇里。后果不是「少了信息」，而是多样性被挤掉：K 个位置本该覆盖 K 种不同情况，实际只覆盖 1 种。通道二：抖动。动态选择的输入是当前 query 的向量，输出是示例 ID 列表。这个映射不稳定时，同一条 query 在不同时刻可能拿到不同示例集；
2026-11-05 09:02:20
206
原创 刚上传的文档第一问检索不到：用写入水位、请求级直查与状态回执补齐 RAG 的读己之写，以首问命中率和可见延迟 P95 验收
回到开头那个工单。运营的问题不是知识库坏了，是系统没有告诉她「你刚传的文档还在处理」，也没有在处理的这 41 秒里做任何补救。三个部件各管一段：写入水位把「索引做到了哪」从隐性假设变成一个可查询的量，请求级直查在未可见的那一小部分文档上提供一条不依赖索引的临时路径，状态回执把前两者的判断结果翻译成调用方能理解的信息。三者缺一不可——只有水位没有旁路，用户还是检不到；只有旁路没有水位，旁路会一直开着，成本和延迟都失控；两者都有但没有回执，用户仍然不知道发生了什么。
2026-11-05 09:01:48
267
原创 人工标注不一致不是噪声：双标、仲裁与分歧聚类怎么把评测集做稳，用 κ 一致性、争议样本复用率和门禁波动验收
分歧不是要被清理的脏数据，它是三种不同信号的混合体：随机错误要返工，定义差异要改指南，不可约模糊要保留并标记。把三类混在一起删掉，得到的是一个高分、干净、和生产无关的评测集。工程上有四个决定值得记住。一致性报告必须同时给Poκ和边际校正版本，只报 κ 会在稀有类上系统性误导。门禁建在 bootstrap 置信下界而不是点估计，否则门禁在批次大小变化时自己就会抖。争议样本要按比例回流并同时看复用率和复发率，只换新样本的评测集无法观测指南补丁的效果。
2026-11-04 08:41:37
626
原创 中文提问检索英文手册：语言识别、查询翻译与双语索引怎么选，用跨语言召回率和答案语言错配率验收
跨语言检索的核心不是选一条路线，而是把两件事分开管：证据的跨语言召回，和答案的语言对齐。它们可以独立失败，也必须分开验收。先统计数据，再设计路由。查询语言和文档语言是两个独立的分布，决策发生在它们的笛卡尔积上。矩阵里没有量的格子不值得为它建索引，矩阵里没有目标语言文档的格子是知识覆盖问题，翻译解决不了。三条路线的差别在于失真发生在哪里：多语言向量把失真留在模型对齐里，查询翻译把失真放在检索之前，双语并列索引把失真挪到离线阶段，并让它变成可校对、可抽检的产物。术语密度高、文档更新慢，往离线挪；
2026-11-04 08:41:03
401
原创 检索慢在召回还是重排：把请求剩余 deadline 逐段下传，按降级档位测 P99 与答案可用率
回到标题那个问题。"检索慢在召回还是重排"在尾部分布上没有稳定答案，因为瓶颈随并发度移动。能稳定回答的是另一个问题：哪一段吃掉了后面所有段的预算——而这个问题的答案要靠和段耗时的比值，不是靠一次 profile。四段共享一份 deadline，比四段各有超时重要得多。前者的失效模式是"降级按计划发生"，后者的失效模式是"超时在最外层落下，归因丢失，重试放大负载"。降级顺序不是教条。先跳重排，是因为它的延迟形状是整批同步、没有中间状态可退，而且它是最容易变成僵尸计算的一段；
2026-11-03 08:50:21
232
原创 关键证据被埋在中段就答错：上下文装配的顺序策略、分段锚点与位置敏感度验收
位置敏感度不是"模型不够强"，而是一个可以被输入结构影响的倾向。既然可影响，就可以工程化：把装配从 Prompt 模板里拆出来，做成一个有明确不变量、有降级路径、有验收指标的独立一层。三个动作的优先级：分段锚点和结论前置几乎零成本，先做；首尾交替分配在"单条关键证据"场景收益最大，其次；分级降级和句柄回读是预算紧张时的必需品，但它改变的是成本结构，不是准确率。验收比实现更重要。没有排列扰动的验收，你无法区分"策略生效了"和"这批数据恰好不难"。
2026-11-03 08:49:49
210
原创 “除了 A 其他都要”这种查询怎么检索：把否定与排除条件解析成结构化过滤，再用误包含率与漏召率验收
否定查询的失败不是因为模型不够聪明，是因为它被交给了错误的组件。相似度函数优化的是话题接近度，否定翻转的是命题真值，两者正交。把“除了 A”翻译成“和 A 更接近”，方向从一开始就反了。可执行的路径是把排除条件外化成约束，按可执行性分成两档：能映射到白名单 metadata 字段的，下推成 pre-filter；映射不上的、置信度不够的、明确声明为语义条件的，降级成 post-filter 逐条判定。降级是默认动作，丢弃不是——丢弃一条排除条件等于保证它失效，而且不留任何信号。验收必须同时看两个比率。
2026-11-03 08:49:15
328
原创 服务刚上线那两分钟最慢：模型权重加载、向量索引映射与连接池的预热顺序，用冷启动窗口 P95 与就绪误判率验收
回到开头那条误判链。它的根因不是探针写错了，而是探针被要求回答一个它回答不了的问题。可操作的结论有四条。把启动阶段先分类再排序，分类依据是资源读写关系而不是直觉，排序依据是本机实测耗时而不是文档。伪并行比伪串行更贵，因为它多付了上下文切换还拖慢了关键路径。预热流量必须走与真实请求相同的中间件链，覆盖 shape 分布的两端，并且在接近稳态显存占用的条件下执行；验证焐热程度用 Rss、显存池、连接池、autotune cache 这些可观测证据，不用请求计数。
2026-11-02 08:59:57
209
原创 同一个请求在德州排碳是瑞典的 8.5 倍：把电网碳强度接进路由与批处理调度，用 gCO2e/请求与 P95 延迟的帕累托验收
做碳感知调度，先做漂移门禁，再做可等待任务时移，最后做实时请求区域偏好。顺序不能反，因为漂移是碳路由引入的新风险，必须先把新风险控制住，再追求碳收益。反过来做，碳账好看了，质量掉了，团队会在两周内失去对碳路由的信任。可等待任务时移的收益最确定，因为它不影响用户感知的延迟；实时区域偏好的收益受 RTT 和合规约束，能做的空间小；漂移门禁是两者的前置条件，不做门禁就没有资格做切流。验收用帕累托前沿，不用加权和。前沿上的每个点都是一个可选策略，选哪个取决于业务约束。
2026-11-01 10:25:10
351
原创 当所有模型对同一件事说法一致：先测跨模型分歧矩阵，再决定多模型投票和 LLM 陪审团值不值
多模型投票和 LLM 陪审团不是坏技术，它们是被默认假设拖着走的技术。默认假设是「不同模型的错误独立」，而这个假设在公共语料、相似偏好数据、同一批榜单驱动的选型环境下，越来越难成立。判据可以压缩成三句话：先算两两分歧率和独立基线的比值 h。h 低于 0.5，等权投票基本等于重复多数派的选择，不值得付钱。再把 maj 的错误拆成「全错」和「多数错 ∧ 少数对」。全错率高，钱该投给检索和工具；第二项高但缺在线验证器，钱该投给验证器，而不是加模型。
2026-11-01 10:25:06
351
原创 CT 筛查检出 42.9% 之后：把阈值从 AUC 挪到复核产能上，用每千次扫描的复核队列长度与阳性捕获率定 operating point
AUC 是把所有可能的阈值遍历一遍、对真阳性率和假阳性率做积分得到的单个标量。它的语义是"随机取一个阳性和一个阴性，模型给阳性打更高分的概率"。这个定义里根本没有"阈值"这个变量——它是排序质量，不是工作点质量。后果很直接：两个模型 AUC 都是 0.91，一个在假阳性率 2% 处敏感度 0.80，另一个在同一点只有 0.62。前者可以支撑一个每天复核 30 例的分诊台，后者不行。AUC 相等，部署价值差一倍以上。
2026-10-31 17:29:31
379
原创 4.5 万封邮件写成一本每条都有出处的 wiki：抽取式写作、引用回链与冲突事实合并，用可回链率和未标注冲突率验收
这套系统做的事情可以压缩成三句话。写作方式从生成换成抽取，代价是覆盖率和可读性，收益是每条断言都能用一个的字符串比较验证，不需要模型参与验证。这个交换是否值得，取决于读者是想要一段好读的总结，还是想要一条能拿去对质的证据。后者的话，没有第二条路。回链的正确性建立在「正文规范化只做一次、之后不再改动」这条不变量上。MIME 解码、换行统一、NFC 归一化，每一步漏掉或者重复做一次，偏移都会漂，而且漂移量随位置增长，测试集里看不出来。引用掩码必须保守，因为把正文误判成引用的代价远小于反过来。
2026-10-31 17:29:25
119
原创 离线批处理和在线请求抢同一张卡：优先级队列、抢占点与批窗口，用在线 P95 与批吞吐的帕累托曲线验收
离线批处理和在线请求共享一张卡，干扰的根源不是"并发太多"，是"每步被塞进去的预填充 token 太多"。限制并发数踩不到这个点，限制每步的 token 预算才踩得到。dp95是在线 P95 相对基线的增量，tloss是批样本完成数相对基线的损失。窗口策略和优先级队列都在这条前沿上，独立副本也在，区别在于后者的隔离是结构性的，不依赖调度器。如果要做共享，优先级的三个不变量必须守住：抢占点只落在步边界、在线请求进入解码后不可驱逐、驱逐代价按已投入 token 数计算。
2026-10-30 08:56:32
277
原创 工具报错信息其实是写给模型看的：错误分类、可重试标记与自愈提示，用自愈成功率和无效重试次数验收
工具错误体的设计分歧不在"写不写清楚"，在"承认不承认它有两个消费者"。code进指标，class决定分支，retryable和idempotent归执行器且必须分开，hint和归模型，归运维。分类的判据是"谁有能力让下一次调用成功"，不是异常类名也不是 HTTP 状态码。四类各自绑定一个不同的下一步动作，合并或拆分都以此为准。分类不确定时默认不可重试，因为错标的代价不对称。验收必须用联合指标：无效率重试下降了但自愈率没降，才算契约真的变好；只有自愈率涨而无效重试也涨，那是模型在暴力搜索。
2026-10-30 08:55:49
248
原创 上线后人工抽检抽多少条才够：分层抽样、置信区间与停止规则，用区间宽度和漏检代价反推样本量
回到开头那份报告。正确的写法不是"抽了 200 条未发现错误，建议放行"，而是"一般层抽 200 条零缺陷，单侧 95% 上界 1.49%，高于该层 1% 容差，未达到认证条件；高风险层预算不足，标记为未认证"。两句话的差别不在措辞，在于第二句可以被反驳，因此也可以被改进。三个可以直接拿去用的判断：容差决定的是下界，不是答案。零缺陷公式给出的是"只有完美产品才能通过"的门槛，它的检出率通常只有 20% 上下。如果抽检的目的是发现问题而不是开证明，样本量要按检出率算，量级是它的 5 到 7 倍。
2026-10-29 08:45:00
190
原创 JSON 约束解码的隐性代价：把 Schema 编译成 token 掩码，用任务正确率、退化重复率与首字延迟决定哪些字段该约束
约束解码是一个把"语法不确定性"换成"分布不确定性"的工具。它把格式错误压到接近零，代价是把概率质量挤到更小的集合里，于是长出另一种失败：复读、截断、格式完美但内容空洞。这三种失败在只看格式合规率的看板上是隐形的。判断哪些字段该约束，不靠 schema 的复杂度，靠三件事：这个字段的合法集合有多小（决定收益上界）、它的语义有多开放（决定退化风险）、它贡献多少状态（决定延迟成本）。落到规则就是：下游按结构消费的、值域封闭且基数小的，约束；语义开放的自由文本和高基数开放值，放开但给长度上界；
2026-10-29 08:44:30
305
原创 小块负责命中、大块负责作答：父子块双粒度索引怎么建，用证据完整率与每答 token 成本两条曲线定回填窗口
父子双粒度索引解决的不是“切多大”的问题，是“命中和作答用同一个尺寸”的问题。它把 chunk size 这一个参数拆成三个：子块尺寸决定召回区分度，父块上限决定单次证据量的天花板，回填窗口 k 决定实际花多少 token。三者可以独立调，也就可以独立评测。定 k 的方法不是拍脑袋，是两条曲线：证据完整率按 gold span 的字符覆盖率算，每答 token 成本按实际送进模型的上下文算，找饱和点或边际比跌破阈值的位置。扫描时先不设预算看纯曲线，再设预算看裁剪损失，两次的差值是扩容决策的依据。
2026-10-28 08:39:20
302
原创 Agent 刚写完就查不到：用会话级覆盖层与索引版本水位补齐写后读一致性，以陈旧读窗口和不一致率验收
写完查不到”不是一个组件故障，是架构里两条路径（写路径和索引路径）的解耦带来的必然窗口。把它当 bug 修，会走向“同步建索引”或者“sleep 等一会儿”这两条代价高昂的路。把它当窗口管理，才有覆盖层加水位这条中间路线。这套机制的核心只有三个不变量：提交序号在全系统单调；索引水位只能按连续消费推进、不能跳跃；覆盖层里的条目在水位追平之前一直参与读路径。三个不变量任何一个被打破，整个机制就失效，而且失效得非常安静——没有报错，只有偶尔查不到。
2026-10-28 08:38:46
209
原创 同一个名字七种写法就搜不到一起：NFKC、简繁与零宽字符的归一化该放在入库侧还是查询侧，用归一对召回增益和引用偏移误差两组指标验收
回到开头那个客诉。七种写法搜不到一起，根因不是检索算法，是整条链路上没有统一的规范形，而每一段又各自做了局部最优的清洗决定。规范形必须在入库侧建立并持久化。去重、倒排索引、向量编码、缓存键都需要它。单做查询侧在去重和缓存上无解。原文和偏移映射必须保留。归一化视图是索引层的表示，原文是展示层的表示，映射表是两者之间的桥。丢掉映射表，引用精度就得用模糊匹配去换，代价更高。规则层要可组合、可开关、带版本。L0 到 L3 四层各自有明确的长度影响和可逆性，逐层可测。
2026-10-27 08:48:21
235
原创 同一个问题用中文问和英文问，检索出的文档不一样：定位分词器、嵌入模型与融合权重的语言偏置，并用分语言召回率与跨语言召回率两组指标验收
中文问和英文问结果不一样」这句话本身没法验收，因为它没有说清楚哪里不一样。工程上至少要把它拆成三个互不替代的量，而这三个量经常被混成一句话。第一个是分语言召回率：中文查询在中文 gold 文档上的召回、英文查询在英文 gold 文档上的召回。它衡量的是每条单语路径本身好不好用。第二个是跨语言召回率：中文查询在英文 gold 文档上的召回。它衡量的不是「中文检索做得好不好」，而是「中文查询有没有能力触达另一种语言的证据」。
2026-10-27 08:47:50
236
原创 文档删了，RAG 还在回答：墓碑标记、索引压实与缓存版本化的可验证删除
一次文档删除要在四个地方生效，每个地方有自己的机制和时间窗口：向量索引用墓碑保证检索不可达，用压实兑现物理回收；缓存用 epoch 让旧条目失去地址，ANN 缓存必须把 epoch 作为过滤条件而不是 key 前缀；引用快照按失效，靠一张反向索引表找到它；原文存储的删除要等存储层的版本清理走完。三个决定成败的细节：墓碑带版本上界，否则删了旧版会挡住新版；epoch 推进要按 request_id 去重，否则重试会把缓存反复击穿；压实要有墓碑年龄这个触发条件，否则存活率刚好卡在阈值上的段永远不会被物理回收。
2026-10-27 08:47:15
395
原创 Kimi K3.1 Pro 普通版与 Highspeed 怎么选：质量、延迟与成本的配对评测
Kimi K3.1 Pro Highspeed 的官方定位是同等智能下的输出加速。业务接入要检验这项承诺在自己的请求、推理强度和负载下能否成立，不预设高速版降质，也不把输出速率倍数当成整条任务的提速倍数。决策要落在三个数上：每类请求的质量差及其区间、迁移后仍然成立的延迟收益、以及把延迟折算成钱之后的净收益。三个都过线才走快档，任何一个不过线就留在稳档。容差和等待成本必须按类别设，因为「合同条款抽错一个字」和「闲聊慢两秒」本来就不该用同一个标准。最后一条边界：这套测量有保质期。
2026-10-26 09:25:09
1635
原创 Trace 采样别把故障现场采掉：头部采样与尾部采样的取舍、错误与慢请求的保留策略，用可复现故障占比和存储成本验收
回到凌晨 2 点那三条 trace。问题不是「采样率调低了」，而是团队用一把按 trace_id 哈希的尺子去执行一条「按错误保留」的策略，而尺子在策略所依赖的信息产生之前就已经落下。头部采样是一种概率，不是一种策略；凡是「当 X 发生时保留」的规则，都不能在 X 发生之前执行。尾部采样把决定挪到 trace 结束之后，代价是一层缓冲、一次跨服务装配、一个自己也会宕机的组件，以及一次必须提前算清楚的成本预算。
2026-10-26 08:50:06
144
原创 用户点踩后怎么变成回归用例：请求快照、反馈聚类与复现率验收
回到开头那个会议室。真正的问题不是“点踩没被转成用例”，而是“点踩被当成了缺陷”。从反馈到回归用例，中间隔着归因、快照、复现三道关，跳过任何一道，得到的都是一个看起来很大、实际拦不住东西的回归集。如果只记三件事：第一，快照的完整性决定了后面一切。少存一份检索原文，半年后这条用例就废了。schema 版本和模型 revision 必须在第一版就设计进去，事后补不回来。第二，复现率是准入条件，不是排序依据。跑不够次数就不给分，这条纪律比任何调参都重要。第三，误报率和回归捕获率要一起看。
2026-10-25 09:15:13
352
原创 用户点了停止之后：取消信号如何贯穿流式生成与工具调用，用残留副作用和「取消后 token 增量」验收
取消这件事，难点不在「怎么停下来」，而在「停下来之后账怎么算清楚」。把结论压成几句可执行的：把取消建模成带 reason 和时间戳的不可变数据，而不是异常。异常只负责打断阻塞调用，事实由 ticket 承载。第一次请求赢，后面的丢掉，因为事后审计需要唯一的原因。检查点的粒度决定了的上界，这个上界是设计出来的常量，可以直接当门禁用。别指望它是 0，批处理的语义不允许。prefill 的浪费要单独计量，token 增量看不见它。工具按「能不能撤」三分，而不是按「快不快」分。
2026-10-25 09:14:59
254
原创 【元宝搜索开发者征文大赛】用元宝搜索做权益雷达：把政策变成办事清单
查到一项补贴，距离真正把事情办成，往往还有很长一段路。毕业生需要确认自己是否属于支持对象，灵活就业者需要分清缴费要求与申领周期，来一座城市生活的人需要弄明白居住登记、居住证申领与积分落户有什么区别。搜索结果能够告诉人们“存在这项政策”，但下一步要补充什么条件、准备哪些材料、到哪里提交、是否错过期限，仍然需要自己逐页核对。。它把政策发现、条件核对、材料准备、官方入口和后续跟进放进同一个工作区，让一次查询能够留下可以继续使用的办事清单。页面里的“天津”就是当前实际支持范围。
2026-10-24 22:58:38
497
原创 RAG 入库前的解析质检：文本覆盖率、乱码率与阅读顺序怎么量化，用坏文档拦截率和下游答对率验收
覆盖率想回答的问题是：这一页上肉眼可见的文字，有多少比例进入了输出？分母不可知。要精确知道一页有多少字，你得先正确地把它读出来。这是一个循环。所以工程上不存在"精确覆盖率"，只存在一组代理信号。诚实的做法是把代理信号拆开，各自说明它能测到什么、测不到什么。信号一：文本层存在性。这是唯一一个二元的、无歧义的信号。对一页 PDF 调用文本抽取，返回空或只返回空白，同时这一页的渲染结果明显有内容，那这页就是"无文本层"。它测不到"抽出来了一半"，但它能干净地覆盖扫描件和纯图页这一大类。
2026-10-24 09:34:14
197
原创 AI 审查报出的 bug 比人能修的多：从 Postgres 19 延期看缺陷分诊、近重复合并与可复现证据，用有效缺陷率与积压斜率验收
回到开头那个团队。到第八周他们的真实问题不是"审查器不准"，而是"把缺陷生产当成免费资源"。生产侧的边际成本接近零，消费侧的成本一点没降，两条曲线一交叉队列就爆了。分层门把进入人眼的速率压下来，并且用校准过的确认率而不是模型分数来定阈值；近重复合并把同一根因的多个 occurrence 压成一个簇，用"一个补丁能否关掉"来验证合并粒度；证据分级把每条 finding 的可信度变成外部事实，syntax不入队、reproduced才进 P1、confirmed才进 P0。
2026-10-24 09:33:59
347
原创 Anthropic Console 的 100 倍扣款报告：金额 i18n 解析、整数最小单位与扣款上限熔断，用多语言输入用例集和账实差异条数验收
一条未经官方确认的 100 倍扣款报告，能提供的确定性其实很少。它不能证明谁对谁错，也不能告诉我们根因在哪。但它能提供一个很好的压力测试题：把“100 倍”当成一个待解释的现象，你的系统里有多少地方能让同一个字符串读出两个数？解析层：Unicode 规范化 + 显式 locale + 顺序正确的分隔符剥离，超精度拒绝而非舍入。存储层：整数最小货币单位，金额和币种成对出现，聚合必须按币种分组。扣款层：绝对上限与相对上限取或，触发即熔断，转人工而不是自动放行。对账层。
2026-10-23 08:00:53
322
原创 九成工时落在 benchmark 覆盖之外：用任务—工时覆盖矩阵重配内部评测采样，以覆盖率与排序一致性验收
回到开头那 3.2 分。它本身不是错的，只是回答了一个没人问的问题：在这个按题量采样的池子里，B 比 A 高多少。而评审真正需要回答的是：在我们实际花工时的那些任务上，B 比 A 好吗。覆盖矩阵做的事，是把这两个问题之间的桥搭起来。它不提高模型的任何能力，也不增加评测的题目数量，它只是把有限的评测预算重新分配到工时所在的地方。三条边界要记住。第一，覆盖率是分布层面的指标，别拿单类别的好坏去代替整体判断，也别拿整体达标去掩盖头部缺口。第二，加权提升代表性，同时降低有效样本量。n_eff。
2026-10-23 08:00:33
289
原创 本地 Agent 把用户磁盘写满：Crashpad dump 的采样配额、落盘前脱敏与磁盘水位熔断，用写放大比和去重后崩溃覆盖率验收
去重失败通常不是因为哈希碰撞，而是因为输入没有规范化。绝对地址、模块加载顺序、线程调度顺序、崩溃发生的实际时间，都不属于崩溃身份。如果把它们放进指纹，同一个 bug 每次崩溃都会得到新值，去重率会虚高，覆盖率会虚低。可用的指纹至少应包含：异常码、出错线程调用栈的前 N 帧、每帧的模块标识和模块内偏移。模块标识应使用名称加调试 ID（或时间戳加镜像大小），不要使用完整路径，因为路径会随安装目录变化。帧之间用长度前缀分隔，避免a|b与a加|b这类拼接歧义。
2026-10-22 08:02:46
206
原创 AI 生成的代码合并前先考作者：按 diff 自动出题、答案防泄漏与豁免规则，用返工率和漏答率验收
定义模糊的指标一定会被解释成对自己有利的样子。所以两个率都要写到没有解释空间。返工率的定义是：在窗口内，一个通过了 quiz 并合并的ChangeUnit，满足以下任一条件，记为一次返工。其一，包含它的 commit 被git revert。其二，同一文件的同一符号被非作者修改，且增删行数之和不少于五行。其三，关联到一次 P1 或 P2 事故（通过 incident 表里的 commit sha 关联）。返工率等于返工单元数除以通过 quiz 并合并的单元总数。三个条件都要写进代码，不能靠人肉判断。
2026-10-22 08:02:03
221
原创 政策与合同文档年年改版：按生效区间建索引、解决冲突版本与 as-of 检索，并用过期引用率和时点召回率验收
判断要不要做时态索引，有一个简单的问题：你的知识库里，过去两年发生过版本更替的文档占比有多少？如果超过两成，或者回答会被用于合同审查、合规判断、审计留痕，那就需要。如果只是稳定不变的技术手册，在引用里带上文档版本号就够了，不必引入区间和裁决的复杂度。如果决定做，落地顺序是：先改 chunk 元数据，加上valid_fromvalid_toslotsupersedes四个字段并回填历史数据；再把入库时的后向闭合写成事务约束；然后把检索改成“先过滤、再裁决、后打分”；最后补固定时点评测集和三个指标。
2026-10-21 08:38:25
222
原创 Agent 并行工具调用怎么做才不炸：依赖分组、幂等键与并发上限，用重复副作用计数和端到端延迟分位验收
并行工具调用的核心不是并发本身，而是在并发之前把依赖和副作用语义先算清楚。三个必须先做完的动作：给每个工具标一个语义标签（读、幂等写、非幂等写），从参数引用重建依赖并做拓扑分层，算出关键路径的预算看看并行到底能省多少。这三件事都不写代码，但决定了后面所有代码有没有意义。三条兜底机制：幂等键由task_id + call_id + 工具名 + 规范化参数构成且必须持久化；并发上限至少覆盖全局、每工具、每资源三层，并且要关掉 SDK 的自动重试以免绕过闸门；
2026-10-21 08:37:49
178
原创 把学校通知变成可执行清单，我用TextIn xParse做了一个通知行动台(附源码)
下一步更值得做的不是立刻扩大概念，而是积累更多经过标注的通知样例，把日期、地点、物资、条件事项和取消语义做成稳定的回归集，再决定哪些规则值得配置化。演示中，系统找出 5 项版本变化：活动日期从 10 月 23 日改为 10 月 26 日，集合时间从 07:30 改为 08:00，地点从学校东门改为体育馆北门，加厚垃圾袋从“每组 2 只”变为“不用准备”，并新增“不能参加改期活动时在指定时间前联系班主任”的条件事项。确认完成后，系统把结果分成四组：现在要做、符合条件才做、已经完成、已经取消。
2026-10-20 21:33:58
1587
原创 流式输出 JSON 怎么边生成边校验：增量解析、Schema 前置约束与局部回滚，用首片延迟和重试成本验收
先把成功判据说清楚，否则后面所有优化都没有靶子。一个流式结构化输出方案，只有在下面三件事同时成立时才算成立：第一，消费侧永远看不到半成品。下游要么拿到一个已经通过校验的完整字段，要么什么都没拿到，不存在"先渲染再撤回"的中间态。这条决定了你要在解析器里维护一个"已提交"集合，而不是每收到一个分片就无条件json.loads一次然后吞掉异常。第二，失败被局部化。当某个字段校验不过，方案能给出"最少需要重新生成哪些字段"的清单，并且这个清单通常远小于整个文档。
2026-10-20 08:45:08
289
【数据库建模】Dify平台PostgreSQL表结构解析：基于SQLAlchemy模型的132张业务表用途与字段映射分析
2026-07-07
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人