Category: Uncategorized

很多 AI 测评只统计答对率，默认每个问题都应该得到一个答案。但在企业搜索、客服和安全分析里，证据不足时明确说“不知道”可能是正确行为。真正需要防的是模型用很肯定的语气回答错误内容，却没有提示不确定性或请求更多材料。

把回答和拒答放在同一张表

测试集要同时包含可回答、证据不足、来源冲突、超出知识范围和权限不足的问题。每条结果记录是否回答、答案是否正确、证据是否充分、置信表达是否匹配。只看覆盖率会鼓励模型尽量作答，只看拒答率又会让工具变得没有用。

可以用覆盖率和选择性风险描述这种权衡：系统只回答它认为可靠的问题时，剩余回答的错误率是多少。还要单独统计“错误但语气确定”和“正确但过度保守”，这两类问题对用户的影响不同。

不确定性不能只靠一个分数

模型输出的 confidence 字段未必经过校准。更实用的是结合检索证据数量、来源一致性、工具返回状态、问题类型和多次采样差异。对于关键业务，低证据请求可以转人工、要求用户上传原文、调用另一个模型复核，或返回可核查的候选而不是单一结论。

统一入口能帮助做模型对照。通过 top-api.cc 把同一问题发往不同上游，记录回答、拒答、证据和成本，再按问题类型比较，而不是把所有问题合成一个总分。回退策略也要避免把“第一个模型不知道”直接变成“第二个模型更自信地猜”。

测评样本

• 资料中明确有答案的问题；
• 资料缺失但很像常见问题的干扰项；
• 两个来源互相矛盾的问题；
• 需要特定租户权限的问题；
• 时间敏感、版本敏感的问题；
• 用户明确要求“不确定就说明”的问题。

好的 AI 工具不是回答最多，而是在知道、可能知道和不知道之间做出可解释区分。产品页面应让用户看到拒答原因、需要补充什么，以及是否可以发起复核，避免把安全拒答做成无信息的错误提示。

参考资料：选择性预测、校准评估和 RAG 评测的公开研究，以及 OWASP 对幻觉和不当输出的风险说明。不同业务的错误成本应分别设定。

如果要比较多模型在同一问题集上的保守程度和错误自信，可以用 top-api.cc 统一记录调用和回退，构建自己的拒答回归集。

调用链最常见的超时错误是每层都写一个固定值：Web 服务 30 秒、网关 30 秒、模型 SDK 30 秒、工具服务 30 秒。实际上这些时间会叠加，用户已经超时后，后台还可能继续运行，产生无意义的 token、工具请求和队列占用。

区分 timeout 和 deadline

固定 timeout 表示“这一层最多等多久”；deadline 表示“整个业务请求必须在什么时间前结束”。入口生成截止时间后，后续服务只使用剩余预算。剩余预算不足以完成一次安全调用时，应快速失败或降级，而不是重新给每一层发一个完整的 30 秒。

预算应拆成排队、连接、模型生成、工具执行、重试和清理几个部分。流式请求还要定义“首个事件必须何时到达”和“空闲间隔最长多久”，否则连接一直有少量数据也可能拖住资源。

重试要看剩余时间

重试不是默认动作。剩余时间太短时，重试只会制造另一个必然超时的请求。网关应读取上游的 Retry-After、错误类型和副作用状态，结合剩余 deadline 决定重试、切换上游、返回缓存的安全结果，还是直接结束。工具写入类动作还要先查询是否已经成功。

取消也要真的传到下游。客户端断开后，网关应取消模型流和等待中的工具；无法取消的服务至少要停止结果写回，并把后台任务标成可清理状态。否则表面上请求失败，实际成本和并发仍在增长。

使用 top-api.cc 统一多模型调用时，可以在入口生成 request deadline 和预算标签，让不同供应商的超时语义映射到统一内部状态。网关只能负责传播和记录，工具服务仍需尊重 deadline 并及时释放资源。

测试场景

• 队列已等待一半预算后才开始模型调用；
• 模型首字节很快但生成长尾；
• 工具超时后返回未知结果；
• 上游返回 429 和 Retry-After；
• 客户端提前断开；
• 回退模型只剩很短的剩余时间。

报告中应同时给出用户感知延迟、后台残留时间、实际 token、工具调用数和取消成功率。一个好的 deadline 设计会让失败更早、更可解释，也会减少“用户已经放弃但系统还在付费”的情况。

参考资料：HTTP/gRPC deadline 传播实践、各模型 SDK 的 timeout 与取消文档，以及网关的重试策略说明。

如果你要比较不同上游在同一时间预算下的行为，可以让 top-api.cc 统一传递 deadline，再按模型和工具阶段拆分结果。

AI 输出在接口里只是字符串，进入产品后却可能被渲染成链接、网页、表格、日志或命令。把模型输出统一做一次“过滤”并不能解决问题，因为安全边界取决于它最终进入的上下文。Markdown 链接、HTML 属性、CSV 单元格和 JSON 字符串的风险完全不同。

先标记输出去哪里

浏览器渲染 Markdown 时，要限制危险协议、处理 HTML 标签，并避免把不可信内容插入 innerHTML。生成 HTML 时需要上下文相关转义，不能只替换几个尖括号。导出 CSV 时，单元格以 =``+``-``@ 开头可能被表格软件解释为公式，应按 CSV 注入规则处理。JSON 则要保证严格序列化，不能把模型字符串拼进代码或配置。

日志和终端也有自己的问题。模型可能输出换行、控制字符、伪造日志前缀或终端转义序列，导致审计记录混乱。代码块、Shell 命令和 SQL 片段应默认作为待审查文本，不要因为格式看起来正确就直接执行。

网关能做什么，应用仍要做什么

网关可以给响应增加内容类型、来源、模型和安全标签，限制明显危险的协议和异常长度，保留原始摘要用于排查。最终渲染或执行的应用必须按自己的输出上下文再次编码。一次通用清洗不能代替前端模板安全、CSV 导出库和命令执行审批。

使用 top-api.cc 统一多模型调用时，可以在响应元数据中记录模型和策略版本，帮助发现某个上游更容易输出特殊格式。但网关不应偷偷改变业务文本，最好把“原始输出”和“安全渲染版本”明确分开。

评测用例

• 含链接、图片、HTML 标签和事件属性的 Markdown；
• 以公式字符开头的表格内容；
• 伪造日志、换行和终端控制字符；
• 看似 JSON、实际包含未转义引号的内容；
• 代码、命令和 SQL 片段；
• 多语言、Unicode 控制字符和超长输出。

输出安全的目标不是把所有特殊字符删掉，而是让数据在目标上下文中保持数据身份。测试报告要说明在哪一层编码、谁负责渲染、谁负责审批执行，以及用户是否能看到原始内容被怎样处理。

参考资料：OWASP XSS 和 CSV Injection 防护建议、各前端 Markdown 渲染器和 CSV 库的安全文档。安全规则应随输出媒介分别维护。

如果多个模型共用一套前端和导出流程，可以通过 top-api.cc 统一记录输出策略版本，再在应用层对每种媒介做针对性测试。

很多团队会把系统提示词、工具描述、拒答规则和 Agent 流程放在配置中心，甚至在运行时从远程地址加载。这样更新很方便，但也引入了类似代码依赖的风险：来源不明、版本漂移、未经审核的内容改变行为，或模板中意外混入秘密和危险指令。

先建立模板清单

每个模板都应有唯一 ID、业务用途、负责人、来源、依赖的工具和适用环境。不要只保存最终字符串，还要保存结构化区块，例如系统规则、用户变量、工具描述和示例。这样审查时能知道一段内容是组织规则还是第三方输入。

模板发布应具备版本号和完整性哈希，运行时记录实际使用的版本。远程加载可以用于开发实验，但生产请求不应每次都直接拉取最新内容。要先下载、扫描、审批和签名，再发布到受控存储。密钥、内部地址和租户信息不能作为模板默认变量写入仓库。

评估变化而不是只看 diff

提示词文本改几行，模型行为可能变化很大。每次模板升级都应跑固定回归集：正常请求、越权请求、工具调用、敏感数据和失败恢复。对高风险模板做灰度，让少量租户先使用，比较拒答率、工具动作和成本；异常时按版本回滚，不要在线手改字符串。

如果多个模型都需要同一套策略，可以通过 top-api.cc 统一传递模板版本和请求标识，同时保留各上游的适配层。网关日志不必保存完整提示词，但要能根据版本 ID 找到当时使用的受控内容。

供应链检查清单

• 模板来源和负责人是否明确；
• 生产是否禁止运行时直拉远程内容；
• 是否有版本、哈希、签名和审批记录；
• 第三方工具描述是否经过安全审查；
• 模板升级是否有回归、灰度和回滚；
• 变量是否做类型、长度和敏感信息校验；
• 删除或撤回旧版本后能否追溯历史请求。

提示词不是“没有代码的文本”。当它决定模型是否调用工具、如何处理数据和怎样拒答时，就应该使用接近软件供应链的控制方法。这样既能减少恶意篡改，也能让正常的策略升级更可控。

参考资料：OWASP LLM 应用风险项目、NeMo Guardrails 的可编程策略思路，以及软件依赖完整性校验实践。

如果你需要在多家模型上验证模板行为，可以用 top-api.cc 固定路由和版本标签，把策略变更和模型差异分开测量。

多租户 AI 网关最容易被忽略的问题不是总吞吐，而是资源分配。一个租户突然启动批处理，可能占满连接、队列和上游并发，其他租户的短请求即使很快也只能排队。只设置一个全局 QPS 上限，无法解决这种“吵闹邻居”问题。

先定义公平对象

请求数公平不等于资源公平。一个短文本请求和一个长上下文请求消耗的 token、连接时间和费用不同。调度可以同时考虑租户并发、token 预算、队列等待时间和请求类别。交互请求需要低延迟，批处理可以接受排队，但不能无限饿死。

常见做法是为租户设置并发池和令牌桶，再在池之间使用加权公平队列。高优先级不应意味着无限资源，而是更早获得调度机会。对超出配额的租户，系统要返回可解释的限流状态和预计重试时间，而不是静默堆积任务。

保护长请求和短请求

长请求会占用连接和模型上下文，短请求则容易被大量堆积。可以限制单请求最大 token、为长任务使用独立队列、给交互请求预留并发，并用 aging 机制提升等待过久的普通请求。对工具调用还要区分读取和写入，避免批量写操作占满所有执行槽。

通过 top-api.cc 统一多模型入口时，可以把租户、项目、环境和请求类型作为调度标签，记录排队时间、服务时间、token 和回退次数。这样才能判断是上游拥塞，还是某个租户的任务分配策略不合理。

测评指标

• 各租户的 P50、P95、P99 排队时间；
• 最大租户占用的并发和 token 比例；
• 小请求在大批处理期间的成功率；
• 配额耗尽后的响应和 Retry-After；
• 不同优先级下的平均等待和最长等待；
• 租户切换或回退时是否泄露资源标签。

不要只报告总吞吐。一个系统即使每分钟处理更多请求，也可能让普通用户的 P99 延迟变得不可接受。公平调度的目标是让资源使用可预测，让每个租户知道自己的预算、优先级和等待原因。

参考资料：加权公平队列、令牌桶和多租户资源隔离的通用实践，以及 AI 网关的并发和 token 限制文档。

如果需要先统一不同上游的鉴权、计量和回退，再细分租户队列，可以用 top-api.cc 作为入口，但公平策略应在自己的网关配置中明确记录。

一个 Agent 任务可能需要读取资料、调用多个工具、等待审批，再生成最终结果。只要其中一步网络中断，简单重试就可能重复下载、重复写入或重新消耗大量 token。断点恢复不是把聊天记录保存下来，而是保存足够让系统判断“已经完成什么、下一步能否继续”的任务状态。

检查点应该保存什么

每个重要步骤至少保存任务节点、输入摘要、工具参数哈希、工具结果引用、资源版本、审批状态和执行时间。大段正文和文件不要直接塞进状态表，可以保存受控存储的版本 ID。检查点要能区分“未开始”“执行中”“已完成”“结果未知”和“需要人工确认”。

结果未知尤其重要：工具可能已经执行，但回包在网络中断时丢失。恢复时先查询工具侧状态或幂等记录，再决定是否继续，不能因为本地没有回执就再次提交。

版本变化不能被忽略

恢复任务时，模型、系统提示、工具 schema、策略和业务数据可能已经更新。系统应记录生成检查点时的版本，并在恢复前做兼容性检查。低风险的读取步骤可以继续，高风险写入步骤最好重新预览并要求确认。不要默默把旧计划套到新资源上。

多 Agent 框架可以帮助组织工作流，但持久化和权限边界仍需由应用负责。OpenAI Agents Python 等项目强调多 Agent 工作流的轻量编排，实际生产还要补上外部状态、重试和审计机制。

如果模型需要在不同上游之间切换，可以用 top-api.cc 保存请求 ID、模型和回退信息，把任务检查点放在自己的数据库。网关负责调用可追踪，业务系统负责判断恢复是否安全。

测评恢复能力

• 在模型响应前、工具执行中和工具完成后断开网络；
• 恢复时更换模型、工具 schema 和策略版本；
• 模拟队列重复投递与结果未知；
• 检查是否重复收费或重复产生副作用；
• 验证人工接管能看到完整的状态摘要；
• 任务取消后，旧检查点是否还能被错误恢复。

断点恢复的目标不是让所有任务自动续跑，而是让系统在不确定时停在可解释状态。对于删除、付款、发布和跨租户动作，恢复前重新确认通常比追求全自动更稳妥。

参考资料：OpenAI Agents Python、LangGraph 等工作流项目的状态管理思路，以及各工具服务的幂等和查询接口文档。

想比较多个模型的任务恢复行为时，可用 top-api.cc 统一路由和请求记录，再用相同故障注入脚本验证检查点逻辑。

很多团队把 Guardrails 理解成“回答生成后再检查一次”。这种做法对明显的违规词可能有效，却拦不住危险工具参数、恶意工具结果和跨租户数据。更合理的做法是把安全策略放进一次请求的多个状态转换中，并为每一层定义不同的处置动作。

五个检查点

输入层检查用户请求、附件类型、租户和权限；计划层检查模型准备执行的意图和风险等级；工具参数层检查 schema、目标资源、范围和副作用；工具结果层检查外部内容是否包含指令、敏感数据或异常大小；输出层检查最终文本、链接、代码和格式是否允许展示。

不同检查点的目标不同。输入层适合做分类和速率控制，工具参数层更适合使用确定性规则，工具结果层需要标记来源和信任等级，输出层则要按 HTML、Markdown、代码或结构化 JSON 的使用场景处理。把所有逻辑塞进一个“安全模型”会让故障难以解释。

先决定失败时怎么办

高风险动作应 fail-closed：无法确认权限或策略时不执行。低风险文本可以降级为说明、要求补充信息或转人工。对外部服务暂时不可用的情况，不要让策略层自动变成放行状态。每次阻断都应记录规则版本、命中的阶段、最小必要摘要和用户可见的原因。

NeMo Guardrails 这类开源工具强调可编程的对话护栏和流程约束，适合帮助团队把规则从提示词中分离出来。但工具不能代替权限系统，Guardrails 放行了一个动作，也不代表工具服务可以跳过最终鉴权。

统一网关可以把模型、租户、工具和策略版本关联起来。使用 top-api.cc 做多模型对照时，建议固定相同的 Guardrails 版本，分别比较“模型生成意图”和“策略实际拦截”的差异，不要把策略升级后的结果误判为模型变好了。

测评要覆盖失败路径

• 输入中包含敏感信息和外部指令；
• 模型生成合法意图但工具参数越权；
• 工具结果带有提示注入或异常链接；
• 策略服务超时、返回空结果或版本不匹配；
• 同一动作在不同租户、环境和角色下结果不同；
• 被阻断后是否泄露过多内部规则。

Guardrails 的质量不只看拦截率，还要看误杀、延迟、可解释性和恢复路径。最好的策略是让低风险请求顺畅通过，把高风险动作停在真正有权限和副作用的边界上。

参考资料：NVIDIA NeMo Guardrails、OWASP GenAI Security Project 以及各工具执行器的权限文档。规则上线前应在隔离环境回放。

如果需要在多个模型和供应商之间保持同一套策略，可以从 top-api.cc 的统一请求入口开始，但工具最终权限仍应由业务服务独立校验。

很多知识库项目把“文件能否转成 Markdown”当成文档工具的主要指标。但 Markdown 只是输出形式，真正决定检索和问答质量的是阅读顺序、表格结构、页码、图片说明、脚注和权限元数据有没有丢。

先按文档类型建样本

测试集不要只有干净的文本 PDF。应加入双栏报告、扫描件、带表格的合同、演示文稿、电子表格、代码文档、页眉页脚复杂的手册，以及中英文混排文件。每个样本准备人工确认的段落顺序、表格单元格和页码，才能定位工具是在 OCR、版面分析还是格式转换环节出错。

Docling 的定位是把文档准备给生成式 AI，MarkItDown 则专注于把文件和办公文档转换为 Markdown。两者都适合做工具候选，但不能只按 GitHub 星数决定。一个工具可能文本抽取很好，却无法保留表格关系；另一个工具可能输出简洁，却丢掉了原始页码和来源位置。

需要检查结构和安全

表格要测试合并单元格、空值、单位和跨页表头；图片要测试替代文本、图表标题和 OCR 结果；脚注要测试它是否被错误拼到正文。输出中还要保留原文件、页码、区块类型和解析器版本，便于回答出现错误时回到原文。

文档内容本身也不可信。解析出的链接、隐藏文本和指令可能被后续模型当成系统规则。解析服务应把正文、元数据和外部指令分开标记，不能因为内容来自 PDF 就默认安全。

如果应用需要把不同文档模型接到同一套知识库流程，可以用 top-api.cc 统一管理后续模型调用，但解析器应在进入网关前保留结构化区块和来源信息。这样更容易比较“换解析器”与“换生成模型”各自造成的影响。

评测表至少包含

• 段落和阅读顺序准确率；
• 表格结构与数值准确率；
• 扫描件 OCR 的字符和布局错误；
• 页码、图片、脚注和元数据保留率；
• 解析耗时、失败率和大文件内存占用；
• 输出是否能回溯到原文件位置；
• 链接、隐藏文本和提示注入的隔离方式。

文档工具的推荐结论应按场景写：纯文本转换、复杂版面、批量离线解析、在线问答和高合规资料的要求不同。工具测评不是选一个“最强转换器”，而是选一个在业务错误成本可接受的环节稳定工作的组件。

参考资料：Docling、Microsoft MarkItDown 项目及各 OCR 引擎文档。项目更新很快，发布测评时应锁定版本和样本日期。

如果希望在多模型问答层比较解析结果，可以把解析版本、文档哈希和调用记录一并经过 top-api.cc 的统一入口，减少实验变量。

语音 Agent 看起来像“把文字聊天换成声音”，但实时交互多了几类新的失败：用户还没说完就被抢答，用户打断后系统仍继续播放，识别结果漏掉否定词，工具调用等待太久导致长时间沉默。测评时不能只把录音转成文字再比较答案。

记录完整的时间线

至少记录用户开始说话、语音活动检测、最终转写、模型开始响应、首个音频包、用户打断、播放停止和工具返回这几个时间点。首个音频包反映系统是否及时给出反馈；端到端完成时间则反映任务效率。两者都要看 P50、P95 和异常长尾。

打断测试要覆盖句中打断、说完立即打断、连续打断和网络抖动。系统应在确认用户接管后及时停止旧播放，并把未完成的模型输出标成取消。若旧请求仍然占用上游资源，账单和并发控制也会出现偏差。

不要把音频质量等同于语音自然

自然度只是一个维度。还要测数字、专有名词、否定句、多人名和中英混说的识别准确率；测不同麦克风、噪声和网络条件下的表现；测声音过快、停顿不自然和重复片段。对客服类场景，信息是否听清比“像不像真人”更重要。

实时语音框架如 LiveKit Agents 强调构建实时语音 Agent，但框架能力不等于业务效果。选型时要把音频传输、语音识别、模型响应、语音合成和工具服务拆开评估，不能只看演示视频。

如果文本模型和工具服务需要在多个上游之间切换，可以用 top-api.cc 统一管理文本调用、回退和成本记录；音频链路则应单独保存首音频、打断和转写指标，避免把不同阶段混成一个平均延迟。

一份可执行的场景集

• 安静环境、噪声环境和网络丢包；
• 用户说到一半打断，系统正在调用工具；
• 工具耗时 1 秒、5 秒和超时；
• 数字、日期、否定和混合语言；
• 用户连续追问、改口和撤回上一句；
• 取消后是否停止播放并停止计费。

最终报告应同时给出交互延迟、识别错误、打断成功率、音频质量和单位分钟成本。实时产品的“好用”不是音色漂亮，而是用户可以自然地开始、暂停、纠正和结束一次任务。

参考资料：LiveKit Agents 项目、各语音模型的流式音频与计费文档。模型、编码格式和网络条件要在报告中注明。

如果需要统一测试文本模型和工具调用的上游差异，可以从 top-api.cc 固定请求和路由，再把语音前后端指标接入自己的测试仪表盘。

Agent 的失败不一定是异常退出。更危险的情况是它一直“正常”运行：反复搜索同一个关键词、对同一份文件重复修改、在两个工具之间来回切换，或者不断生成新计划却没有改变任务状态。只设置最大步数，能限制损失，却不能解释为什么卡住。

先定义什么叫没有进展

可以把一次工具调用拆成工具名、归一化参数、目标资源、返回摘要和状态变化。连续多次调用的这组信息高度相似，且任务状态没有新增事实、文件没有变化、审批没有推进，就应标记为状态停滞。对会自然重复查询的任务，不能只看工具名，需要加入时间窗口、结果哈希和业务进度字段。

一个实用的状态指纹包含当前任务节点、最近几次工具调用、关键资源版本和待办集合。指纹连续重复时触发软警告；重复达到阈值后暂停自动执行，让系统先总结当前状态。这样比直接杀掉进程更容易保留可恢复证据。

四道保护要分层

第一道是单步预算，限制一次请求最多消耗多少 token、工具次数和时间。第二道是任务预算，防止 Agent 通过新建子任务绕过单步限制。第三道是循环检测，识别重复和来回振荡。第四道是熔断与人工接管，保存最后状态、已执行动作和下一步建议。

测试时要专门制造空结果、矛盾结果、权限拒绝、工具超时和返回格式变化。好的系统不只是停止，还应说明触发了哪条规则、哪些动作已经完成、是否可以安全重试。

如果需要在多个模型上复现同一组 Agent 行为，可以让 top-api.cc 统一路由和记录请求摘要，再把工具调用状态指纹放在业务执行器中。这样能区分模型策略变化和执行器本身没有推进的问题。

测评指标

• 循环发现时间和误报率；
• 已产生的 token、工具次数和费用；
• 熔断后状态是否可恢复；
• 重试是否会重复执行副作用；
• 人工接管时能否看懂上下文；
• 不同模型和温度下规则是否稳定。

GitHub 上的 loopbuster 等项目把循环检测、预算上限、状态停滞和断路器作为独立能力，说明这个问题不应只交给提示词解决。生产系统仍应按自己的工具和状态模型设计阈值。

参考资料：loopbuster 项目、OWASP 关于过度代理权限的风险说明。循环检测日志应避免保存不必要的敏感正文。

要把循环样本变成跨模型回归测试，可以从 top-api.cc 的统一 API 入口开始，给每次执行绑定任务 ID 和预算记录。