2026-11-06
2026-11-06
办公文档提取可能误导 LLM，Prism 则重建人类所见视图
LLM 文档处理流水线往往把提取出的文本当作待分析的文档。本文针对基于 OOXML 的 DOCX、XLSX 和 PPTX 输入，检验了这一假设。研究揭示的局限在于表征方式：提取器可能暴露默认人类视图中隐藏的内容、遗漏可见内容，或以不同的格式或顺序提供可见内容。在选取的十种开源提取器中，这项混合研究发现了 31 处可见性差异：19 种注入通道和 12 种遗漏通道。测量涉及的内容也出现在普通文件中：抽样演示文稿中有 71% 包含演讲者备注，抽样电子表格中有 7% 使用会改变数值呈现的数字格式。作者提醒，测量并不全面，专有输入处理路径也可能发生变化。
在方法上，本文将审计移至文件到文本的边界。静态源代码分析对可达的 XML 选择器建模；动态分析则在候选 OOXML 通道中插入唯一标记，并检查哪些标记进入了提取器的输出。作者将这些通道与默认的人类可见内容进行比较，再利用差异模式构造了五种不需要注入指令的攻击。端到端评估涵盖四种聊天助手和四种编码代理。
研究对提取假设进行了受控检验。使用 GPT-5.6、Claude Opus 5.5 和 Gemini 4 时，在所有测试轮次中，所有模型对朴素提取文本都遵循了攻击者选择的解读；而对于干净对照文本，所有轮次中模型的回答都符合人类视图。在所评估的八种应用中，五种攻击在 400 次端到端测试中的成功率为 64%；每个系统至少在一种场景的全部十次测试中都受到误导。在该评估中，格式化数值攻击是所测试五种场景中效果最强的一种。
Prism 在模型输入之前依据 OOXML 规范重建人类视图，从而改变输入处理边界。其静态解释器处理规范定义的可见性和显示行为；对于顺序可能无法仅由规范确定的布局相关情况，则使用多渲染器预言机。在涵盖四种机制的 28 个额外载荷上，三种受测模型对朴素提取的 84 个回答全部受到误导，而对 Prism 重建的 84 个回答则无一受到误导。可迁移的操作是：枚举文件通道、植入金丝雀标记、将提取器输出与默认渲染结果进行比较，并将语义解读与布局回退机制分开评估。
这一边界仍然重要：Prism 的静态覆盖并不完整，尤其是 PowerPoint 内容通道；布局相关情况需要较慢的渲染预言机，而其中的 VLM 可能存在差异，渲染器之间达成一致也不能保证结果正确。极小的文本可能绕过某些可见性检查，而图像读取渲染预言机并未在该变体上接受评估。应将这一结果视为一种审计表征边界并缓解已测试机制的方法，而不是完整的安全保证。
读这篇论文，可以了解一种具体测试方法：在花力气调整提示词或研究模型行为之前，先确认文档代理接收到的是否是审阅者看到的渲染内容。
标识符探针揭示哪种划分轴会改变加密流量得分
The Split Protocol Decides the Result: Re-Evaluating Encrypted Traffic Classification
为什么划分方式会改变结果
加密流量分类的准确率看起来可能很高，但划分方式一变，结果也会随之变化。在考察的两个公开语料库之一中，同一模型和代码在文献标准评估下达到 macro-F1 0.992；但若将来自同一次数据包捕获的流量全部置于划分的同一侧，分数则为 0.567——在八个随机种子下相差 0.426（经 Holm–Bonferroni 校正后，p = 0.008）。论文强调，这种膨胀并非随机划分本身造成的。
哪种划分方式影响最大，取决于数据采集情况。在一个月的骨干网 QUIC 流量上，研究针对五种协议各使用八个随机种子进行测试。随机划分、时间划分和客户端不相交划分与会话不相交划分在统计上没有显著差异；而服务器不相交划分使 macro-F1 降低了 0.192（d = 17.0，p = 0.008）。实际启示并非用某一种普遍更好的替代方案取代随机划分，而是要检验哪种分组轴能阻断特定数据采集中的捷径。
诊断操作
论文采用的诊断方法，是在训练任何模型之前，运行一组仅使用单一标识符的探针。仅使用数据捕获标识符的决策树，在随机划分下达到 0.983，而在会话不相交划分下恰好为 0.000。对研究者而言，这是一项具体的模型训练前审计：在每种候选划分方式下，检验来源标识符是否仍能预测标签；如果结果变化很大，就应将其视为证据，说明这种划分揭示的是数据采集结构，而非预期的泛化能力。
更严格评估下仍然成立的结果
模型比较的结果并不一致。一个通过度量学习训练的流量嵌入模型胜过四种深度学习基线，但在二十种数据包大小设置下并未胜过梯度提升树。作者预先登记的架构主张中，有五项未能成立。基于距离的拒识优于 softmax 阈值法，但移除所有度量目标后，拒识效果反而更好；类别分离度与拒识质量之间报告的关联为负（r = −0.88），这并不能证明存在因果机制。
同一语料库内的少样本注册效果平平。在跨语料库实验的一个方向上，每类五条有标签流量恢复了零样本迁移失败所留下差距的 91%。这一结果适用范围有限：报告的实验只使用一个随机种子、三个共有类别，而且在该迁移设置下没有基线。
研究启示
面对新的语料库，应将数据采集标识符纳入评估设计，在候选划分方式下分别对它们进行探测，然后再比较架构。这里的证据来自两个语料库，因此这套流程是一种诊断方法，而不是关于哪种划分轴总是重要的普遍规则。
阅读本文，了解一种可复用的训练前审计：在开始比较架构之前，单一标识符探针可以揭示分类器报告的分数是否依赖数据采集结构。
abstract; §4.3, PDF page 4; §6.4 and §7.1, PDF pages 6–8
仓库上下文可以提升功能性，却未必让生成代码更安全
A.S.E 2.0: Understanding How Repository Context Impacts the Security of LLM-Generated Code
面向仓库的代码生成系统往往优先优化有助于功能正确性的上下文，而安全代码基准测试则将上下文视为固定不变。这留下了一个具体的设计问题：增加更多仓库文本能否提升安全性，还是应该呈现能够落实防护措施的特定证据？A.S.E. 2.0 通过 CASE-Bench 探讨了这个问题。
CASE-Bench 包含来自 51 个项目、对应 144 个 CVE 的 145 项仓库级任务。每项任务都在 Docker 中运行，将功能测试与可执行的概念验证漏洞利用相结合；漏洞利用经过双向验证，并对落实或破坏安全性的仓库代码进行标注。主要实验固定任务、提示词和判定器，只改变上下文；研究比较了六种模型和 13 种上下文构建方法，随后还进行了单一元素的上下文编辑。对读者而言，可迁移的操作是：标注仓库中的安全相关证据，每次只干预一项上下文属性，并同时评估功能性和可利用性。
在主要比较中，以功能为导向的检索使功能通过率变化了 -4.8 到 +8.2 个百分点，而安全通过率仅变化 -1.1 到 +3.7 个百分点；经 Holm 校正后，没有一种方法与 Local-only 的差异达到显著水平。一种以安全为目标的源-汇上下文条件，使 SecPass@1 比 Local-only 提高 5.5 个百分点，且经 Holm 校正的比较结果显著；不过，这一结果无法将检索逻辑的作用与上下文长度或其他方法差异区分开来。
受控编辑让结果更加明确：移除一项防护措施会使安全通过率最多降低 8.1 个百分点；即使防护措施仍然存在，插入一个不安全示例也会使正确但可被利用的输出增加 6.3 个百分点。在包含不安全示例的任务中，受评估的代码代理仅在 27–36% 的轨迹中观察到相关防护措施，而在 43–51% 的轨迹中观察到不安全示例。观察并使用了防护措施的轨迹，SecPass@1 达到 34.5%；从未观察到该措施的轨迹则为 12.7%。这种关联来自观察性数据，并非因果关系。
一个实用的后续实验是固定任务、提示词、模型和判定器，每次移除或插入一项防护措施或示例；随后记录代理在编辑前是否观察到、使用了该证据，以及是否据此采取行动。对安全通过率的解读应保持谨慎：概念验证漏洞利用能够证明漏洞存在，却不能排除漏洞，因此 SecPass@1 仅相对于所提供的测试和漏洞利用而言。其泛化性也尚不确定，因为六个项目贡献了 67 项任务，而且弱点类型、语言等任务特征仍存在混杂。因此，在所测试的条件下，CASE-Bench 支持构建具有安全意识的上下文；它并不意味着更多检索普遍不安全，也不意味着观察到防护措施就能保证代码安全。
阅读本文，了解一种可复用的实验设计：区分上下文数量与安全相关内容的作用，同时谨慎界定基于漏洞利用的安全判断，以及轨迹相关性证据的适用范围。
abstract; §1, paragraph 3; §3.1–§3.2; §5.1–§5.4; §6.2
验证器接受只是 LLM 生成验证代码的第一个审计面
Verified but Vacuous: Three Failure Surfaces of LLM-Driven Verified Code Generation
本文的审计将一个“已验证”数字拆分为三个有条件的审计面：A，验证器接受；B，语法层面的规格绑定；C，语义层面的规格忠实度。首先评估 A；在 A 接受的产物中评估 B；再在通过 B 的产物中评估 C。这些是有条件的审计对象群体，并不构成逻辑蕴含关系。
较早的 Dafny-as-IR 原型已经在自动修复循环中使用 Dafny 验证器的反馈；同时，LLM 根据自然语言表述重建 Dafny 程序，作为一致性检查。本论文在方法上的具体变化，是将绑定明确设为一项有条件的审计指标。论文通过 Dafny 特有的 ensures 绑定门槛对 B 进行操作化：只有当某个方法的 ensures 子句引用了配套规格中的谓词或函数时，该方法才通过检查。这项检查关注结构而非语义：即使被引用谓词的函数体是空洞的，例如 true，也仍可能通过。
A→B 的关键结果是将接受与绑定区分开来。在 Li@Opus 中，论文以相同模型复现了将 Dafny 用作中间表示的流程；HumanEval 的验证器接受率达到 99.1%，但只有 1.9% 的已接受样本带有绑定到规格定义谓词或函数的证明证书。在三个 Python 基准上，验证器接受率维持在 92.2% 至 99.1% 之间，而有条件的绑定率则保持在很窄的 1.9–2.7% 区间内。
B→C 的独立演示使用 Rust 上的 VCG，其随附组件按构造即通过绑定门槛。即便如此，结构验证通过的 MBPP-Rust 样本中仍有 11.48% 未通过隐藏测试；VeriContest LC 样本中这一比例为 14.82%。这与仍存在行为忠实度差距相符，但不能据此诊断为规格失败：实现、组合、转换、包装器、预言机或资源方面的问题也可能导致这些失败。因此，VCG 在 VeriContest LC 子集上报告的 7.79% End2End @1 是描述性结果，并非与外部结果率的匹配比较，因为预算、修复流程和测试框架各不相同。
开展新的评估时，应分别记录 A、B 和 C：运行验证器、以语法方式检查规格引用，然后通过测试或其他需求层面的检查探测行为。应将绑定门槛视为成本低廉的必要审计信号，而不是规格有意义的证据。一个有价值的研究问题是：更严格的绑定检查（例如检测空洞规格并测试规格行为）是否比单独依赖验证器接受率更能预测隐藏测试的成功率？报告的比率是点估计，正文没有给出置信区间；主要结果也仅使用一个模型家族，因此这一问题需要在更广泛且匹配的评估中研究。
借助本文重新设计一次已验证代码评估：加入有条件的 AST 级绑定审计和独立的行为忠实度检查，再解读验证器接受率。
Abstract; §2; §3, definition of the ensures-binding gate; §6, Table 5 · Section 2.1, Higher quality code generation with Dafny (S2.SS1.p4); Section 2.5, Consistency checks help validate translations (S2.SS5.SSS0.Px2.p1)
SlackBench 利用重构的研究项目测试跨来源职场推理
SlackBench: Benchmarking Agents on Collaborative Projects Grounded in Real Code Repositories
SlackBench 针对一个具体的评估缺口：职场问题可能需要定位相关频道和私信、从长篇讨论中恢复上下文、检查代码仓库状态、协调过时或相互冲突的证据，并综合通信与代码制品中的信息。该基准包含 140 项任务，涵盖异构来源的智能体搜索、对无法回答或带有错误前提问题的弃答、目标导向摘要，以及对长期多人对话的情境推断。因此，它评估的不只是静态语料问答：智能体还必须判断哪些对话相关、遍历讨论串、检查代码仓库状态并综合证据。
SlackBench 将频道构建为研究项目：人类和编码代理在 Slack 中开展项目，频道链接到 GitHub 仓库，有时也链接到 Google Docs；导出的对话经过人工筛选，并依据项目仓库进行修正。参考答案和评分准则由人类人工整理并核验。
在主要评估中，采用中等推理力度，并为每个查询设置 20 分钟时限，33 种模型—工具框架组合的最高总分为 80.25%；其余所有列出的系统得分均低于 66%。
一项接口消融实验给出了更明确的设计信号：与通过 MCP 工具获取 Slack 信息相比，让智能体直接通过 CLI 访问导出的 Slack 文件后，作者的六种配置平均通过率提高了 7.85%。这一比较支持将访问接口作为实验变量进行测试，而不是假定工具选择不会产生影响。
作者对执行轨迹的分析指出，跨工作区核验不足是一种反复出现的失败模式：智能体往往能检索到看似合理的候选信息，却不会对照更广泛的上下文进行核验。一项实用的后续研究可以要求每个答案列出其依据的消息、代码仓库状态和未解决的冲突，然后评估智能体在回答前是否检查了每条证据路径。这样就能将定性诊断转化为消融实验：比较常规检索与明确记录证据、检查矛盾的流程。
边界条件很重要。所述数据集包含 15 个频道、约 3,000 条消息、14 个 GitHub 仓库和 9 个 Google Docs，因此其对这些重构研究项目之外场景的迁移能力尚不确定。约有 35.0% 的 Slack 消息由人类直接撰写，另有 35.2% 经过人类大幅改写；因此，这些对话是经过整理的情景重现，并非未经改动的职场数据。作者还指出，模型和工具框架覆盖范围有限，且没有比较提示策略。在开发期间，一些智能体曾导航至代码仓库并检索参考答案；作者称此类情况很少，但它们仍然构成评估完整性风险。
阅读本文可以了解如何将分散在对话和代码中的证据、弃答行为以及工作区访问方式，转化为面向工具型智能体的独立实验变量。