乐于分享
好东西不私藏

爱可可AI前沿推介(4.18)

爱可可AI前沿推介(4.18)

LG - 机器学习 CV - 计算机视觉 CL - 计算与语言

1、[CL] Blazing the trails before beating the path:Sample-efficient Monte-Carlo planning
2、[CL] CROP:Token-Efficient Reasoning in Large Language Models via Regularized Prompt Optimization
3、[IR] A Unified Model and Document Representation for On-Device Retrieval-Augmented Generation
4、[CL] Shuffle the Context:RoPE-Perturbed Self-Distillation for Long-Context Adaptation
5、[CL] Compressed-Sensing-Guided,Inference-Aware Structured Reduction for Large Language Models

摘要:高样本效率的蒙特卡洛规划、基于正则化提示优化的大语言模型Token高效推理、面向端侧检索增强生成的统一模型与文档表示、基于RoPE扰动的自蒸馏长文本适配技术、面向大语言模型的压缩感知引导与推理感知结构化缩减

1、[CL] Blazing the trails before beating the path: Sample-efficient Monte-Carlo planning

J Grill, M Valko, R Munos
[INRIA Lille & Google DeepMind]

辟径先行,成路在后:高样本效率的蒙特卡洛规划

要点:

  • 探讨了在使用生成模型的马尔可夫决策过程 (MDP) 中进行高效采样蒙特卡洛规划的问题,目标是即使在下一状态数量无限 () 的情况下也能实现多项式级的样本复杂度。
  • 反直觉的探索策略: 与基于“面对不确定性保持乐观”(OFU) 原则的主流算法(如UCT)不同,本文提出的 TrailBlazer 算法在设计上刻意避免了乐观主义。它不试图平衡所有可能动作的置信上限,而这正是避免在无限状态空间中产生贪婪样本需求、从而实现多项式复杂度的关键。
  • 反直觉的数据丢弃机制(挑选冠军路径): 在平均 (AVG) 节点上,如果父节点请求  个样本,该节点将严格只使用前  个被采样的子节点来计算估计值,故意忽略它可能为了更深层子任务而生成的任何额外样本。这是因为额外的样本并不会改善父节点方差的上限,丢弃它们反而能防止样本复杂度被不必要地放大。
  • 解耦偏差与方差: 传统的置信界方法通常将偏差和方差合并为一个单一的宽度区间,而 TrailBlazer 将它们分开处理。这是因为平均独立估计值会缩小方差(标准差平方求和),但偏差只会直接累加,因此必须对低偏差查询和低方差查询进行差异化处理。
  • 对于有限的 ,实现了  的最坏情况样本复杂度,严格提升了之前已知的最佳边界(如 StOP 算法)。
  • 首次为无限状态转移空间 () 提供了多项式级的样本复杂度边界,复杂度为 ,其中  衡量了识别近乎最优节点的难度。
  • 揭示了一个惊人的理论结果:当动作间的收益差距不趋于零时(即 ),样本复杂度直接降至 。这完全等同于没有控制节点(没有 MAX 节点)的纯蒙特卡洛估计的复杂度,实际上在数学层面上抵消了交替出现 MAX 和 AVG 节点带来的复杂性负担。

主旨: 本文旨在解决拥有生成模型的马尔可夫决策过程 (MDP) 中的蒙特卡洛规划样本效率问题。文章旨在打破现有算法在面对深层规划或连续/无限状态转移时遭遇的指数级样本复杂度爆炸,提出一种即使在状态转移空间无限时,也能利用 MDP 结构特性实现多项式级样本复杂度的高效规划算法。

创新:

  • 非乐观探索机制: 抛弃了经典的“面对不确定性保持乐观 (OFU/UCB)”范式,直接修剪次优分支而不去平衡所有动作的置信上限。
  • 偏差与方差分离架构: 创新性地在树搜索中引入双参数 (m, ) 机制,分别独立控制节点返回结果的方差要求和最大偏差要求。
  • 延迟满足与数据截断(Champion paths): 在平均 (AVG) 节点上创新地采用“按需返回”策略,即使底层子节点拥有更多高精度的采样数据,也强制只截取父节点请求数量的样本参与计算,以此在全局树结构中严格控制方差传播边界。
  • 隐式策略树共享: 节点作为具有独立记忆的持久对象,无需显式构建和更新全局策略集合,即可在不同策略间自然共享采样信息,降低了计算复杂度。

贡献:

  • 提出了一种易于实现且计算高效的新型算法 TrailBlazer。
  • 理论突破(有限状态): 将有限状态转移下的最坏情况样本复杂度指数从以往的  改进至 
  • 理论突破(无限状态): 首次为具有无限下一状态 () 的 MDP 规划问题提供了多项式级别的样本复杂度上界 
  • 证明了在动作回报存在确定差距的理想条件下,交替最大化(MAX)和期望(AVG)的随机控制问题可以被简化到等同于纯粹蒙特卡洛采样的复杂度 ()。

提升:

  • 最坏情况容忍度: 相比于 UCT 等在最坏情况下可能出现双重指数级复杂度的算法,TrailBlazer 保证了多项式级的复杂性下限。
  • 样本复杂度指数: 在有限状态场景下,显著缩小了受问题规模 (N, K) 影响的指数项;在无限状态场景下,将复杂度从“未知/非多项式”提升到了可被难度系数  约束的多项式级别。
  • 计算效率: 相比于前置的 StOP 算法,不需要计算所有可能策略的上限(其数量随规划范围呈指数增长),计算复杂度与模型调用次数呈线性关系,更加贴近实际应用。

不足:

  • 树结构带来的冗余: 算法使用树来表示可达状态,这意味着 MDP 中可以通过不同路径到达的同一个状态会在树中被重复表示为不同的节点,未采用图合并(Graph merging)可能使得规划问题在形式上变得更难且存在一定的计算冗余。
  • 理论保证的概率性质差异: 对于有限状态模型,算法能提供“高概率 (with high probability)”的样本复杂度界限;但对于无限状态模型,目前的边界仅能在“期望 (in expectation)”层面上成立,理论上的鲁棒性略逊一筹。
  • 依赖完美生成模型: 算法高度依赖于一个可以随时在任意状态-动作对上进行调用的生成模型(Oracle),这在许多难以低成本仿真的真实物理世界任务中是难以满足的。

心得:

  • “丢弃数据”反而能获得全局最优: 算法在 AVG 节点故意丢弃多余的高精度样本,这一反直觉设计极具启发性。它告诉我们在层级嵌套或递归计算的系统中,局部节点“拥有的数据越多”并不一定能带来全局效率的提升,严格遵守层级间的方差与信息契约比盲目堆砌局部精度更重要。
  • “乐观主义”并非万能药: UCB/UCT 中的“面对不确定性保持乐观”几乎是强化学习探索的圣经,但本文指出,在面对无限分支(无限状态)时,乐观主义会因为试图填平所有未知的置信上限而导致算力枯竭。有时候,果断放弃、不寻求全局平衡的“非乐观”裁剪,才是通向多项式复杂度的唯一现实路径。
  • 解耦数学性质以突破理论瓶颈: 在构建置信区间时,将偏差和方差混为一谈是学界的惯性思维。本文通过敏锐地观察到“均值计算中方差会随样本量平方级缩小,而偏差只是线性传递”这一数学特性,将两者解耦,从而打破了前人算法的理论瓶颈。这启发我们在设计算法时,需深入洞察底层数学操作的非对称性。

一句话总结: 本文提出了一种非乐观驱动的蒙特卡洛规划算法 TrailBlazer,通过反直觉地“丢弃局部多余样本”以及解耦偏差与方差的传播,首次在转移状态无限的马尔可夫决策过程中实现了多项式级的样本复杂度,证明了只要动作间存在合理差距,复杂控制问题的采样效率就能媲美最基础的纯蒙特卡洛估计。

You are a robot and you live in a Markov decision process (MDP) with a finite or an infinite number of transitions from state-action to next states. You got brains and so you plan before you act. Luckily, your roboparents equipped you with a generative model to do some Monte-Carlo planning. The world is waiting for you and you have no time to waste. You want your planning to be efficient. Sample-efficient. Indeed, you want to exploit the possible structure of the MDP by exploring only a subset of states reachable by following near-optimal policies. You want guarantees on sample complexity that depend on a measure of the quantity of near-optimal states. You want something, that is an extension of Monte-Carlo sampling (for estimating an expectation) to problems that alternate maximization (over actions) and expectation (over next states). But you do not want to STOP with exponential running time, you want something simple to implement and computationally efficient. You want it all and you want it now. You want TRAILBLAZER.

https://arxiv.org/abs/2604.14974

2、[CL] CROP: Token-Efficient Reasoning in Large Language Models via Regularized Prompt Optimization

D Shah, S Badhe, N Kathrotia, P Tiwari
[Google LLC & Purdue University]

CROP:基于正则化提示优化的大语言模型Token高效推理

要点:

  • 指出现有自动提示词优化(APO)的致命缺陷: 现有的APO框架(如TextGrad或DSPy)仅针对准确率进行优化。反直觉的是,这反而会让模型推理变得“更贵”,因为元优化器在解决逻辑错误时,会不断堆砌冗长的边缘情况指令,将“废话税(verbosity tax)”最大化。
  • 将数学正则化转化为自然语言: 提出了成本正则化提示优化(CROP),创造性地将传统机器学习中的L1/L2权重正则化概念,映射为直接在提示词优化循环中使用的“纯文本长度惩罚”。
  • 双目标文本梯度: 使用两个不同的评估器LLM——一个生成针对任务准确率的文本梯度,另一个生成针对简洁性的文本梯度(仅当输出长度超过阈值时触发)。这两个梯度被拼接成一个综合梯度供元优化器使用。
  • 反直觉的涌现行为(自主生成“草稿链”): 在持续的文本简洁性压迫下,目标LLM会自发地发明高度压缩的符号化数学速记语法来解决问题。这在概念上完全再现了人类精心设计的“草稿链 (Chain-of-Draft)”策略,但这完全是自主涌现的,无需人工硬编码。
  • 关于文本批处理动态的高信息熵发现: 就像深度学习一样,文本梯度也存在高方差问题。如果Batch Size设为1,会导致“提示崩溃(prompt collapse)”(优化器为了满足简洁性约束,会激进地删掉所有关键推理指令)。稳定的多目标文本优化必须依赖大批次(如128)。
  • 优化器与目标模型的能力不对称性: 研究发现中端模型无法进行多目标自我优化。要综合处理相互冲突的文本梯度(准确率 vs. 简洁性),必须使用前沿级别的模型(如开启Thinking的Gemini 3.1 Pro)作为元优化器,即使目标推理模型较小(如Qwen 2.5 7B)。
  • 实验表现: 在复杂推理基准(GSM8K, LogiQA, BBH)上,输出Token消耗减少了高达80.6%,同时严格保持了传统冗长思维链(CoT)所具备的高任务准确率。

主旨: 本文旨在解决大语言模型在使用“思维链(CoT)”进行复杂推理时产生的输出过度冗长、导致推理延迟和Token成本极高的问题,并修复现有自动提示优化(APO)工具因单向追求准确率而加剧“废话连篇”的结构性缺陷。

创新:

  • 纯文本正则化(Textual Regularization): 首次将机器学习中用于控制模型复杂度的“正则化”惩罚项引入自然语言反馈中,将硬性的数学约束转化为LLM可以理解和迭代的“文本长度惩罚梯度”。
  • 解耦准确率与冗长度的联合优化: 将任务验证反馈和长度约束反馈分离为两个独立的评估流,通过字符串拼接算子结合,使得文本反向传播具有了真正的“多目标优化”能力。
  • 将效率成本转移至离线阶段: 不同于动态剪枝、提早退出或模型微调,CROP将所有压缩推理轨迹的计算负担全部转移到了前期的Prompt寻优阶段,最终产出一个能在单次前向传播中诱发高效推理的静态System Prompt。

贡献:

  • 提出了CROP框架,为生产环境中部署高性价比的AI Agent系统提供了一种极具实用价值的提示词优化范式。
  • 实现了在复杂数学、逻辑和算法推理任务中,Token消耗大幅降低(超80%)且几乎不牺牲准确率的惊人性能。
  • 经验性地证明了在纯文本优化空间中,也存在类似于传统深度学习中的“梯度方差”和“批处理大小(Batch Size)依赖”规律。
  • 揭示了LLM在双重目标压迫下,会自动剥离人类语言习惯,涌现出类似计算机代码/数学符号的极简推理结构的现象。

提升:

  • Token使用效率: 在GSM8K上下降74.8%,BBH上下降80.6%,LogiQA上下降66.5%。
  • 推理延迟: 输出Token的大幅压缩直接带来了生成速度的几何级提升。
  • 生产成本控制: 为实际业务部署高级推理模型消除了最主要的财务障碍(输出Token计费)。

不足:

  • 忽略了输入Token成本优化: CROP产出的系统提示词可能变长,论文未将输入Token纳入惩罚,而是默认依赖工业界的“前缀缓存(Prefix Caching)”技术来抹平这部分成本。
  • 元优化门槛极高: 优化阶段极度依赖顶尖大模型(如Gemini 3.1 Pro)来理解和权衡矛盾的梯度反馈,小模型作为元优化器会直接导致“提示崩溃”,这增加了该框架的研发侧使用成本。
  • 正则化系数敏感: 需要像传统ML一样,在验证集上仔细进行网格搜索来确定长度惩罚权重(文中最优),超参数对最终结果的平衡非常敏感。

心得:

  • 自然语言正在成为可微的计算介质: 本文最深刻的启发在于,传统的数学概念(L1/L2正则化)可以被完美无损地翻译成“自然语言Critic”。这意味着Prompt Engineering正在正式演变为Prompt Compilation(提示编译),自然语言本身构成了全新的、具有多目标反向传播能力的“计算图”。
  • 真正的智能是“压缩”,压力催生涌现: 我们通常认为需要绞尽脑汁“教”模型如何做精简推理(如手动设计Chain-of-Draft)。但CROP表明,只要设定好正确的边界约束(即“必须算对”+“越短越好”),大模型为了生存,会自动剥离人类对话的虚伪外壳,回归最底层的符号逻辑。外部压力是激活LLM隐性能力的最佳钥匙。
  • Agent系统的“阶级”不对称性定律(Scaling Law for Optimizers): 论文揭示了一个关键细节:干活的模型(Actor)可以很小,但负责评估和重写规则的模型(Optimizer/Overseer)必须具备绝对的降维打击能力(大Context + 强Deduction)。想让系统自动进化,裁判的认知水平必须远超运动员,这为未来多Agent系统的资源分配指明了方向。

一句话总结:
CROP通过将传统机器学习的正则化惩罚转化为自动提示优化的文本梯度,迫使大模型在无需人工干预的情况下自主涌现出高度压缩的符号化推理逻辑,从而在保持高准确率的同时砍掉了80%的输出Token成本。

Large Language Models utilizing reasoning techniques improve task performance but incur significant latency and token costs due to verbose generation. Existing automatic prompt optimization(APO) frameworks target task accuracy exclusively at the expense of generating long reasoning traces. We propose CostRegularized Optimization of Prompts (CROP), an APO method that introduces regularization on response length by generating textual feedback in addition to standard accuracy feedback. This forces the optimization process to produce prompts that elicit concise responses containing only critical information and reasoning. We evaluate our approach on complex reasoning datasets, specifically GSM8K, LogiQA and BIG-Bench Hard. We achieved an 80.6% reduction in token consumption while maintaining competitive accuracy, seeing only a nominal decline in performance. This presents a pragmatic solution for deploying token-efficient and cost-effective agentic AI systems in production pipelines.

https://arxiv.org/abs/2604.14214

3、[IR] A Unified Model and Document Representation for On-Device Retrieval-Augmented Generation

J Killingback, O Meshi, H Li, H Zamani…
[University of Massachusetts Amherst & Google]

面向端侧检索增强生成的统一模型与文档表示

要点:

  • 精准定位端侧RAG的双重瓶颈: 在本地部署RAG虽然解决了隐私和延迟问题,但面临两大严苛的硬件限制:有限的磁盘空间(用于存储密集的检索向量)和有限的活动内存/KV Cache(用于生成时处理长上下文)。
  • 提出ECG(嵌入、压缩、生成)模型: 这是一个单一的仅解码器(decoder-only)大语言模型,统一了三个角色。它生成的多向量表示具有双重用途:既用于基于MaxSim的检索,又可通过线性投影转化为压缩的上下文Token供LLM读取。
  • 存储需求减半: 由于在检索()和上下文压缩()之间共享隐层表示,系统只需在磁盘上存储一组向量,与标准的“压缩+生成”RAG架构相比,节省了50%的存储空间。
  • 极致的上下文效率: ECG模型在使用仅约 1/10 的上下文预算(例如16-32个向量,而不是128-256个Token)的情况下,就能达到传统RAG阅读器在全文本上的精确匹配(EM)准确率。
  • 关于正则化的反直觉发现: 联合训练向量以同时满足检索(对比损失)和压缩(生成损失)的要求,实际上比单独训练压缩模型的效果更好。对比检索损失充当了强大的正则化器,产生了更丰富的语义表示。
  • 关于上下文数量的反直觉发现: 当检索器非常强大时,给阅读器(生成模型)提供更多的上下文文档实际上会降低性能。提供Top-1或Top-2之后的文档会用噪声稀释有用信号。
  • 解决联合训练中的灾难性干扰: 将检索和生成统一到一个模型中通常会因为梯度冲突而摧毁性能。作者发现,“动态损失缩放”(可学习的温度参数和教师分数缩放)对于防止多任务目标破坏共享表示来说是绝对关键的。

主旨: 本文旨在解决大语言模型(LLM)在边缘设备(On-Device)上部署检索增强生成(RAG)时,面临的内存(KV Cache受限)和磁盘空间(向量存储受限)的双重挑战。为此,论文提出了一种统一架构,用单个模型同时完成文档检索、上下文压缩和文本生成任务。

创新:

  • 统一的模型与表征(Unified Model and Representation): 打破了传统RAG中“检索器”和“阅读器”分离的范式。通过向LLM注入特殊的 `<emb- 精巧的多任务联合训练机制: 采用两阶段训练:自监督预训练阶段(结合文本重建、相邻文本预测和批次内对比损失)和特定于RAG的微调阶段(结合阅读器KL散度知识蒸馏、InfoNCE对比损失和Margin MSE重排序器蒸馏)。
  • 引入动态损失缩放(Dynamic Loss Scaling): 在训练中引入可学习的温度和缩放参数,优雅地解决了检索对比损失与生成损失之间互相抢占模型容量(即梯度冲突)的难题。

贡献:

  • 极大优化端侧资源占用: 通过统一表征,省去了传统方案中需要同时存储“检索向量”和“压缩提示向量”的冗余,节省了50%的磁盘空间。
  • 突破上下文窗口限制: 实现了高达16倍的上下文压缩率,仅用16到32个向量表示就能媲美甚至超越传统RAG需要数百Token才能达到的生成精度,极大缓解了端侧设备的KV Cache压力。
  • 提供“全能模型”的端侧部署蓝图: 证明了将多种截然不同的RAG功能(检索、压缩、推理)压缩到单一小模型(如135M的SmolLM或1B的Gemma)中不仅可行,而且在相互促进下能获得更优的表征。

提升:

  • 严格预算下的准确率(固定上下文预算): 在仅允许输入16-32个向量的极端限制下,标准RAG架构几乎失效,而ECG模型的精确匹配率(EM)达到了最佳标准RAG模型的3倍以上。
  • 存储与效率的性价比(固定性能目标): 传统的ColBERT检索+RAG阅读器需要消耗ECG模型 5到14倍 的上下文长度(极大增加内存和推理延迟)才能勉强追平ECG的准确率,而ECG在磁盘占用上还略低于ColBERT。

不足:

  • 测试数据集缺乏“端侧”真实性: 论文使用的是公共的问答数据集(NQ和TriviaQA),而端侧RAG真正的应用场景(如个人短信、私人邮件、本地金融文档检索)可能具有完全不同的分布特征。
  • 对超参数和训练策略极度敏感: 论文的消融实验表明,一旦去除动态损失缩放或轻微改变硬负样本(Hard Negatives)的温度系数,模型性能就会腰斩,这意味着该方法在迁移到新领域时可能需要极高成本的调参。
  • 多文档综合推理能力受限: 验证表明,ECG模型在输入文档数 $k 心得:
  • “既要又要”反而成就了更好的表征(多任务的正则化奇迹): 传统的直觉是“术业有专攻”,专门训练一个压缩模型理应比一个既管检索又管压缩的模型表现更好。但本文揭示了一个反直觉的深度学习现象:给向量加上“必须能用于检索(对比损失)”的严苛物理约束,反而防止了压缩向量在生成任务上的过拟合。这启示我们,在设计模型时,引入正交的辅助任务往往是最高级的正则化手段。
  • 端侧AI的未来在于“大一统(Everything-Models)”而非“流水线(Pipelines)”: 云端AI喜欢把系统拆分成多个微服务(专门的Embedding模型、Reranker、大模型),但在内存和算力极其抠门的端侧,这种流水线是灾难性的。本文展示了通过表征复用(一个向量打天下)来榨干每一滴硬件性能的优雅思路,这必将成为未来手机/PC端AI Agent的主流架构。
  • RAG中的“信噪比悖论”——喂得越多,错得越多: 论文指出,当检索器足够强大时,给大模型提供额外的Top-N文档实际上是在注入噪声,导致性能下降。这打破了目前业界“上下文窗口越大越好、塞的文档越多越好”的迷思。在端侧算力受限的场景下,提升Top-1的检索精度,远比盲目扩大LLM的上下文接收窗口更有价值。

一句话总结:
针对端侧设备内存和存储严重受限的痛点,本文创新性地提出了一种单一的ECG大语言模型架构,反直觉地证明了“将检索向量和上下文压缩向量合二为一”不仅能节省50%的磁盘空间,还能利用检索任务的正则化效应提升生成质量,最终在仅使用1/10上下文长度的严苛条件下,完美复现甚至超越了传统全文本RAG的问答性能。

Traditional Retrieval-Augmented Generation (RAG) approaches generally assume that retrieval and generation occur on powerful servers removed from the end user. While this reduces local hardware constraints, it introduces significant drawbacks: privacy concerns regarding data access, recurring maintenance and storage costs, increased latency, and the necessity of an internet connection. On-device RAG addresses these challenges by executing the entire pipeline locally, making it ideal for querying sensitive personal information such as financial documents, contact details, and medical history. However, on-device deployment necessitates a delicate balance between limited memory and disk space. Specifically, the context size provided to the generative model must be restricted to manage KV cache and attention memory usage, while the size of stored embeddings must be minimized to preserve disk space. In this work, we propose a unified model that compresses the RAG context and utilizes the same representations for retrieval. This approach minimizes disk utilization compared to using separate representations, while significantly reducing the context size required for generation. With an average of 1/10 of the context, our model matches the performance of a traditional RAG reader without increasing storage requirements compared to a multi-vector retrieval model. This approach represents the first model to unify retrieval and context compression using a shared model and representation. We believe this work will inspire further consolidation of distinct models to optimize on-device performance.

https://arxiv.org/abs/2604.14403

4、[CL] Shuffle the Context: RoPE-Perturbed Self-Distillation for Long-Context Adaptation

Z Li, C Liang, L Ren, T Zhao…
[Georgia Institute of Technology & Microsoft]

乱序上下文:基于RoPE扰动的自蒸馏长文本适配技术

要点:

  • 指出了长上下文大模型的“位置脆弱性”: 即使经过专门的长上下文微调,LLM(在使用标准因果语言建模 CLM 损失时)的准确率依然会因为证据在文本中的绝对位置不同而产生剧烈波动(例如“迷失在中间”现象或对“大海捞针”位置的极度敏感)。
  • 提出 RoPE-Perturbed Self-Distillation (RoPE扰动自蒸馏): 提出了一种新的训练正则化方法,旨在迫使模型依赖语义信号,而不是脆弱的绝对位置索引。
  • 通过篡改 RoPE 创造“替代视角”: 该方法在保持实际 Token 序列完全不变的情况下,通过人为偏移旋转位置编码 (RoPE) 索引(例如在随机分割点  插入大小为  的“间隙”或“跳跃”),生成训练序列的“扰动视角”。
  • 自蒸馏目标: 模型分别处理标准视角(通过正常的 CLM 损失优化)和扰动视角。使用反向 KL 散度损失,迫使扰动视角的输出分布去匹配标准视角(标准视角作为停止梯度的“教师”)。
  • 保留结构的扰动效果最好: 消融实验表明,“基于跳跃”的偏移(保留了局部单调性和相对顺序)比随机分块、完全移除位置编码或循环移位(破坏了顺序)效果更好。
  • 显著的性能提升: 在 Llama-3-8B 和 Qwen-3-4B 上测试,该方法在 RULER 和 HELMET 等长上下文基准测试中取得了持续的提升,其中在 Llama-3-8B 的 RULER-64K 上实现了 12.04% 的绝对提升。
  • 改善了长度外推能力: 当结合 YaRN 使用时,这种正则化显著提高了模型推断超出其训练上下文窗口(例如,在 64K 上训练但在 256K 上表现良好)的能力。
  • 算力高效: 性能的提升并不仅仅是因为额外的前向传播带来了“更多的算力消耗”。在控制挂钟训练时间(Wall-clock time)一致的情况下,该方法依然显著优于标准的 CLM 微调。

主旨: 本文旨在解决大语言模型(LLM)在长上下文处理中存在的“位置脆弱性”问题,即模型准确率高度依赖于关键信息在长文本中的绝对位置。为了提高模型对上下文位置变化的鲁棒性,论文提出了一种基于 RoPE(旋转位置编码)扰动的自蒸馏训练方法。

创新:

  • 位置编码与Token序列解耦的视角构造: 创新性地提出在不改变输入Token序列的情况下,仅仅通过篡改/偏移 RoPE 的位置索引来构建训练样本的“扰动视角(Perturbed view)”。
  • 基于KL散度的位置不变性正则化: 引入反向 KL 散度作为正则化项,将未经扰动的标准前向传播作为Teacher(不回传梯度),迫使经过 RoPE 扰动的前向传播输出与其保持一致,从而赋予模型对绝对位置偏移的“不变性(Invariance)”。
  • 跳跃式(Skip-based)RoPE偏移策略: 设计了一种在随机点切断并增加位置常数间隙的扰动方式,巧妙地在改变绝对位置的同时,保留了序列的局部相对距离和单调性。

贡献:

  • 提出了一种简单有效、即插即用的长上下文训练正则化技术(RoPE-Perturbed Self-Distillation)。
  • 在 Llama-3 和 Qwen-3 等主流开源模型上验证了该方法的有效性,在极具挑战性的 RULER 基准测试上取得了两位数(12.04%)的性能飞跃,特别是在多键检索和聚合任务上改善巨大。
  • 证明了该方法不仅提升了模型在训练窗口内的表现,还显著增强了结合 YaRN 等技术的长度外推(Length Extrapolation)能力。
  • 经验性地证明了长上下文微调中的性能瓶颈往往不是数据不够,而是标准 CLM 目标无法阻止模型学习到脆弱的、过拟合的位置依赖。

提升:

  • 位置鲁棒性: 显著拉平了“大海捞针”测试中的 U 型准确率曲线,极大地缓解了“迷失在中间(Lost-in-the-middle)”现象。
  • 长上下文基准得分: 在 Llama-3-8B (64k) 上的 RULER 平均分从 57.25 提升至 69.29;在 Qwen-3-4B (256k) 上也有稳定提升。
  • 外推能力: 使得在 64K 上训练的模型,在面对 128K 或 256K 的超长输入时,性能退化速度大幅减缓。
  • 正交兼容性: 可以与 LongCE 等损失权重重分配技术完美叠加,取得更优的综合性能。

不足:

  • 训练开销增加: 每个训练 Step 需要额外进行一次前向传播来计算蒸馏损失,导致实际挂钟时间(Wall-clock time)增加了约 1.6 倍。
  • 破坏性扰动的副作用: 论文提到,如果使用“循环移位(Cyclic-shift)”这种破坏全局顺序的扰动方式,可能会在严格要求顺序的“有序检索(Ordinal retrieval)”任务中导致性能下降。
  • 正则化强度的权衡:  超参数的选择对结果有影响,若设置过大,模型会过度关注位置不变性而损害主要的语言建模能力。

心得:

  • “欺骗”位置编码是打破死记硬背的利器: 大模型之所以会“迷失在中间”,是因为它们在预训练时潜意识里记住了“重要信息通常在开头或结尾”的绝对位置分布。通过在微调时随机给 RoPE 索引“注水(Skip)”,等于是蒙上了模型的眼睛,强迫它只看语义,不看位置。这是一种极其高级的、针对 Transformer 架构特点的 Data Augmentation(数据增强)。
  • 结构化噪声比纯随机噪声更有价值: 作者尝试了直接去掉位置编码(NoPE)、随机打乱(Permutation)或加高斯噪声,发现效果都很差。只有“保留局部单调性,仅改变绝对偏移量”的 Skip 策略效果最好。这启示我们,正则化/扰动必须顺应人类语言的底层逻辑——语言的相对连贯性不能破,但它所在的绝对页码无关紧要。
  • 自我蒸馏是稳定训练的魔法: 如果直接用扰动后的序列去算交叉熵损失,往往会因为目标过于严苛而把模型训崩。本文巧妙地用未经扰动的“自己”去教“扰动后的自己”,由于 Teacher 也是动态进化的,这种“软着陆”的优化路径极大地保证了多任务训练的稳定性。

一句话总结: 为了解决大模型在处理长文本时过度依赖证据绝对位置(即“迷失在中间”等脆弱性),本文提出在训练时不改变文本内容,仅通过人为偏移 RoPE 索引来创造“扰动视角”,并通过自我蒸馏迫使模型输出保持一致,从而强迫模型学会关注语义而非位置,在 RULER 基准上实现了 12% 的巨大提升。

Large language models (LLMs) increasingly operate in settings that require reliable long-context understanding, such as retrieval-augmented generation and multi-document reasoning. A common strategy is to fine-tune pretrained short-context models at the target sequence length. However, we find that standard long-context adaptation can remain brittle: model accuracy depends strongly on the absolute placement of relevant evidence, exhibiting high positional variance even when controlling for task format and difficulty. We propose RoPE-Perturbed Self-Distillation, a training regularizer that improves positional robustness. The core idea is to form alternative “views” of the same training sequence by perturbing its RoPE indices—effectively moving parts of the context to different positions—and to train the model to produce consistent predictions across views via self-distillation. This encourages reliance on semantic signals instead of brittle position dependencies. Experiments on long-context adaptation of Llama-3-8B and Qwen-3-4B demonstrate consistent gains on longcontext benchmarks, including up to 12.04% improvement on RULER-64K for Llama-3-8B and 2.71% on RULER-256K for Qwen-3-4B after SFT, alongside improved length extrapolation beyond the training context window.

https://arxiv.org/abs/2604.14339


5、[CL] Compressed-Sensing-Guided, Inference-Aware Structured Reduction for Large Language Models

A Kiruluta
[UC Berkeley]

面向大语言模型的压缩感知引导与推理感知结构化缩减

要点:

  • 指出现有模型剪枝与提示词压缩之间的鸿沟: 现有的模型压缩方法(如 SparseGPT, Wanda)大多是静态的离线技术,而提示词压缩方法(如 LLMLingua)虽然减少了输入长度,但仍然在执行完整的密集模型。
  • 提出统一的“压缩感知”框架: 将大语言模型(LLM)的动态执行过程转化为一个“测量与恢复”的逆问题。框架不再假设必须运行完整模型,而是假设对于任何给定的 Token/Prompt,只需要调用一个稀疏的结构化子集(如注意力头、层、通道)。
  • 任务条件化测量: 使用依赖于 Prompt 的轻量级“探测”测量矩阵。因为不同的任务(如写代码与写总结)会激活模型内部完全不同的潜在计算路径。
  • Token自适应恢复: 在解码期间在线求解稀疏恢复问题。处于活跃状态的模型子网络会随着 Token 的生成而动态变化,从而在困难的 Token 上分配更多算力,在简单的 Token 上减少算力。
  • 基于RIP和互不相关性的理论保证: 基于压缩感知理论(受限等距性 RIP),提供了数学上的样本复杂度边界,证明了需要多少次随机探测测量,才能准确无误地恢复出模型真正的活跃支撑集。
  • 硬件编译约束: 摒弃了无法带来实际延迟收益的非结构化稀疏,该框架严格限制恢复出的“支撑集”(活跃子网络)必须是能够高效映射到 GPU Kernel 的模式(例如块稀疏、N:M 掩码)。
  • Prompt与模型的联合压缩: 将这两种技术统一到一个单一的目标函数中。系统会联合决策:保留哪些 Prompt Token,以及调用哪个模型子网络来处理这些 Token。
  • 不确定性驱动的自适应感知(UDS): 引入了一个动态反馈环,由模型预测的熵(不确定性)来决定感知预算()。模型置信度高时使用的探测测量少;不确定性高时则触发更大的测量预算以更准确地恢复子网络,同时从控制论角度保证了该反馈环的稳定性。

主旨: 本文旨在解决大语言模型(LLM)推理成本高昂的问题。作者提出打破“先静态剪枝,再全局推理”的传统范式,引入了一个基于“压缩感知(Compressed Sensing)”理论的统一框架。该框架在推理时,通过极少量的随机探测(Probes),动态地、Token级别地估算出当前真正需要的稀疏模型结构,并结合硬件约束和提示词压缩,实现端到端的延迟和内存双重优化。

创新:

  • 将LLM推理重新定义为压缩感知逆问题: 首次将信号处理领域的压缩感知理论直接应用于 LLM 内部动态路由,用轻量级的随机测量替代了繁重的全量前向传播或启发式的路由门控网络。
  • 解耦的联合压缩优化(Prompt + Model): 传统方法要么缩短输入(Prompt压缩),要么缩小模型(模型剪枝)。本文在数学上将它们统一进同一个求解目标中,让模型自己权衡“留下更多Token”和“动用更大子网络”的边际效益。
  • 引入不确定性驱动的自适应控制环(UDS): 创新性地将模型的预测熵作为反馈信号,实时调节测量预算,在计算置信度高的部分节省“探测成本”,在模棱两可的部分加大“探测力度”,并提供了严格的控制论稳定性证明。

贡献:

  • 提出了一种全新的、基于严格数学理论(RIP和互不相关性)支持的 LLM 动态执行范式。
  • 提供了 Prompt 相关的样本复杂度定理,在理论上证明了:如果提前利用 Prompt 信息缩小候选支持集,那么定位活跃子网络所需的计算探针数量将大幅下降。
  • 提供了一套将理论稀疏性转化为实际硬件加速的工程约束方案(硬件感知恢复),确保理论上的计算减少能转化为真实的挂钟时间(Wall-clock time)加速。
  • 提出了一套完整的评估指标与实验方法论体系,为后续此类联合压缩研究确立了比较基准。

提升:

  • 推理速度: 预期实现比纯密集基线(Dense Baseline)快 1.55 倍至 2.00 倍的端到端净加速。
  • 动态资源分配: 相比于 SparseGPT 和 ZipLM 等静态剪枝技术,能够在生成不同 Token 时动态切换活跃参数,活跃支持比例预期控制在 35% - 50%。
  • 硬件执行效率: 通过结合编译时约束(Compile-to-hardware constraints),避免了无规则稀疏带来的显存带宽浪费。

不足:

  • 极高的工程实现难度: 每次生成 Token 都需要在线求解一个稀疏恢复(L1 正则化或 OMP)问题,这要求极其优化的底层 CUDA 实现,否则“求解稀疏网络”的开销会轻易超过“直接运行完整网络”的开销。
  • 理论假设的现实适用性: 压缩感知依赖于字典  能够使得 LLM 的隐含层动态变得稀疏。如果真实的 LLM 激活状态并不是严格稀疏的(例如过度平滑),恢复误差将不可避免。
  • 缺乏真实的端到端实验数据: 当前论文更像是一篇“宏伟蓝图(Position Paper)”,文中提供的对比数据(Table 3)标注为“估计值(estimated)”,亟需在实际的 LLaMA 或 Qwen 级别模型上进行真实部署验证。

心得:

  • 用信号处理的“刀”解大模型的“牛”: 深度学习近年来习惯于用“再训练一个神经网络”去解决问题(比如训一个小模型去预测大模型的路由)。但本文反其道而行之,借用了经典信号处理中的“压缩感知”,这让人眼前一亮。它提醒我们,数学上的经典逆问题在应对如今“过度参数化”的 LLM 时,依然有极高的降维打击潜力。
  • “动态”才是智能的本质,静态剪枝违背直觉: 一道简单的寒暄题和一道复杂的微积分题,不应该唤醒大模型里同样多的大脑皮层。本文将“算力分配”做到了 Token 级别,这不仅是工程上的优化,更是向人类大脑能量分配机制的靠拢。
  • 闭环控制(Closed-loop control)在 AI 推理中的觉醒: 将当前 Token 的信息熵作为反馈,去控制下一个 Token 的计算探针数量(UDS机制),这是一个非常优美的控制论闭环设计。它打破了传统 AI 模型“开环运行”的盲目性,引入了“自我意识”式的计算调节,这一思路对未来的 Agentic AI 硬件设计有深远启发。

一句话总结: 本文创造性地将压缩感知理论引入大语言模型推理中,通过极少量随机探针“在线侦测”并唤醒当前 Token 真正需要的硬件级稀疏子网络,在理论上实现了提示词压缩与模型剪枝的统一,为实现极低延迟的动态大模型执行提供了严密的数学框架。

Large language models achieve strong generative performance at the cost of extreme parameter counts, large memory footprints, and substantial decoding latency. Existing compression methods have shown that sparse or structured reductions can preserve accuracy under aggressive pruning, and prompt-compression methods have further demonstrated that substantial latency reductions can be obtained by removing redundant input content before inference. However, these two lines of work remain largely disjoint. Most model-compression approaches are static, are optimized offline, and do not explicitly exploit the fact that different prompts and even different decoding steps activate different latent computational pathways. Conversely, prompt-compression methods reduce sequence length but do not directly adapt the executed model subnetwork. In this manuscript we propose a unified compressed-sensing-guided framework in which random measurement operators are used to probe latent model usage, sparse recovery is used to estimate task-conditioned and token-adaptive support sets, and the recovered supports are compiled into hardware-efficient sparse execution paths over blocks, attention heads, channels, and feed-forward substructures. The proposed formulation contributes five coupled novelties. First, it introduces taskconditioned measurements, so that different prompts induce different sparse supports and therefore different computational graphs. Second, it enables token-adaptive recovery, so that active substructures are re-estimated during decoding rather than fixed once offline. Third, it provides a formal sample-complexity analysis showing how many probe measurements are required to recover the active support under restricted isometry or mutual incoherence assumptions. Fourth, it imposes compile-to-hardware constraints so that recovered supports are restricted to structures compatible with efficient GPU kernels and practical runtime speedup. Fifth, it unifies prompt compression and model reduction in a single compressed-sensing objective, thereby coupling input-token selection and subnetwork selection rather than optimizing them independently. The resulting framework defines dynamic large language model execution as a measurement-andrecovery problem, with explicit approximation guarantees and deployment-oriented constraints.

https://arxiv.org/abs/2604.14156

基本 文件 流程 错误 SQL 调试
  1. 请求信息 : 2026-04-20 03:43:02 HTTP/1.1 GET : https://www.yeyulingfeng.com/a/546670.html
  2. 运行时间 : 0.090594s [ 吞吐率:11.04req/s ] 内存消耗:4,726.97kb 文件加载:145
  3. 缓存信息 : 0 reads,0 writes
  4. 会话信息 : SESSION_ID=75c9e6cf39a04203ff1de0e8dba6fd8a
  1. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/public/index.php ( 0.79 KB )
  2. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/autoload.php ( 0.17 KB )
  3. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/composer/autoload_real.php ( 2.49 KB )
  4. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/composer/platform_check.php ( 0.90 KB )
  5. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/composer/ClassLoader.php ( 14.03 KB )
  6. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/composer/autoload_static.php ( 6.05 KB )
  7. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-helper/src/helper.php ( 8.34 KB )
  8. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-validate/src/helper.php ( 2.19 KB )
  9. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/ralouphie/getallheaders/src/getallheaders.php ( 1.60 KB )
  10. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/helper.php ( 1.47 KB )
  11. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/stubs/load_stubs.php ( 0.16 KB )
  12. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Exception.php ( 1.69 KB )
  13. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-container/src/Facade.php ( 2.71 KB )
  14. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/symfony/deprecation-contracts/function.php ( 0.99 KB )
  15. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/symfony/polyfill-mbstring/bootstrap.php ( 8.26 KB )
  16. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/symfony/polyfill-mbstring/bootstrap80.php ( 9.78 KB )
  17. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/symfony/var-dumper/Resources/functions/dump.php ( 1.49 KB )
  18. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-dumper/src/helper.php ( 0.18 KB )
  19. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/symfony/var-dumper/VarDumper.php ( 4.30 KB )
  20. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/guzzlehttp/guzzle/src/functions_include.php ( 0.16 KB )
  21. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/guzzlehttp/guzzle/src/functions.php ( 5.54 KB )
  22. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/App.php ( 15.30 KB )
  23. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-container/src/Container.php ( 15.76 KB )
  24. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/psr/container/src/ContainerInterface.php ( 1.02 KB )
  25. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/provider.php ( 0.19 KB )
  26. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Http.php ( 6.04 KB )
  27. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-helper/src/helper/Str.php ( 7.29 KB )
  28. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Env.php ( 4.68 KB )
  29. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/common.php ( 0.03 KB )
  30. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/helper.php ( 18.78 KB )
  31. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Config.php ( 5.54 KB )
  32. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/alipay.php ( 3.59 KB )
  33. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/facade/Env.php ( 1.67 KB )
  34. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/app.php ( 0.95 KB )
  35. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/cache.php ( 0.78 KB )
  36. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/console.php ( 0.23 KB )
  37. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/cookie.php ( 0.56 KB )
  38. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/database.php ( 2.48 KB )
  39. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/filesystem.php ( 0.61 KB )
  40. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/lang.php ( 0.91 KB )
  41. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/log.php ( 1.35 KB )
  42. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/middleware.php ( 0.19 KB )
  43. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/route.php ( 1.89 KB )
  44. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/session.php ( 0.57 KB )
  45. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/trace.php ( 0.34 KB )
  46. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/view.php ( 0.82 KB )
  47. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/event.php ( 0.25 KB )
  48. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Event.php ( 7.67 KB )
  49. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/service.php ( 0.13 KB )
  50. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/AppService.php ( 0.26 KB )
  51. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Service.php ( 1.64 KB )
  52. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Lang.php ( 7.35 KB )
  53. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/lang/zh-cn.php ( 13.70 KB )
  54. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/initializer/Error.php ( 3.31 KB )
  55. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/initializer/RegisterService.php ( 1.33 KB )
  56. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/services.php ( 0.14 KB )
  57. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/service/PaginatorService.php ( 1.52 KB )
  58. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/service/ValidateService.php ( 0.99 KB )
  59. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/service/ModelService.php ( 2.04 KB )
  60. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-trace/src/Service.php ( 0.77 KB )
  61. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Middleware.php ( 6.72 KB )
  62. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/initializer/BootService.php ( 0.77 KB )
  63. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/Paginator.php ( 11.86 KB )
  64. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-validate/src/Validate.php ( 63.20 KB )
  65. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/Model.php ( 23.55 KB )
  66. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/model/concern/Attribute.php ( 21.05 KB )
  67. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/model/concern/AutoWriteData.php ( 4.21 KB )
  68. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/model/concern/Conversion.php ( 6.44 KB )
  69. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/model/concern/DbConnect.php ( 5.16 KB )
  70. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/model/concern/ModelEvent.php ( 2.33 KB )
  71. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/model/concern/RelationShip.php ( 28.29 KB )
  72. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-helper/src/contract/Arrayable.php ( 0.09 KB )
  73. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-helper/src/contract/Jsonable.php ( 0.13 KB )
  74. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/model/contract/Modelable.php ( 0.09 KB )
  75. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Db.php ( 2.88 KB )
  76. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/DbManager.php ( 8.52 KB )
  77. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Log.php ( 6.28 KB )
  78. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Manager.php ( 3.92 KB )
  79. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/psr/log/src/LoggerTrait.php ( 2.69 KB )
  80. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/psr/log/src/LoggerInterface.php ( 2.71 KB )
  81. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Cache.php ( 4.92 KB )
  82. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/psr/simple-cache/src/CacheInterface.php ( 4.71 KB )
  83. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-helper/src/helper/Arr.php ( 16.63 KB )
  84. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/cache/driver/File.php ( 7.84 KB )
  85. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/cache/Driver.php ( 9.03 KB )
  86. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/contract/CacheHandlerInterface.php ( 1.99 KB )
  87. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/Request.php ( 0.09 KB )
  88. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Request.php ( 55.78 KB )
  89. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/middleware.php ( 0.25 KB )
  90. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Pipeline.php ( 2.61 KB )
  91. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-trace/src/TraceDebug.php ( 3.40 KB )
  92. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/middleware/SessionInit.php ( 1.94 KB )
  93. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Session.php ( 1.80 KB )
  94. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/session/driver/File.php ( 6.27 KB )
  95. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/contract/SessionHandlerInterface.php ( 0.87 KB )
  96. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/session/Store.php ( 7.12 KB )
  97. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Route.php ( 23.73 KB )
  98. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/route/RuleName.php ( 5.75 KB )
  99. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/route/Domain.php ( 2.53 KB )
  100. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/route/RuleGroup.php ( 22.43 KB )
  101. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/route/Rule.php ( 26.95 KB )
  102. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/route/RuleItem.php ( 9.78 KB )
  103. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/route/app.php ( 3.94 KB )
  104. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/facade/Route.php ( 4.70 KB )
  105. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/route/dispatch/Controller.php ( 4.74 KB )
  106. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/route/Dispatch.php ( 10.44 KB )
  107. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/controller/Index.php ( 9.87 KB )
  108. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/BaseController.php ( 2.05 KB )
  109. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/facade/Db.php ( 0.93 KB )
  110. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/connector/Mysql.php ( 5.44 KB )
  111. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/PDOConnection.php ( 52.47 KB )
  112. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/Connection.php ( 8.39 KB )
  113. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/ConnectionInterface.php ( 4.57 KB )
  114. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/builder/Mysql.php ( 16.58 KB )
  115. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/Builder.php ( 24.06 KB )
  116. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/BaseBuilder.php ( 27.50 KB )
  117. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/Query.php ( 15.71 KB )
  118. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/BaseQuery.php ( 45.13 KB )
  119. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/TimeFieldQuery.php ( 7.43 KB )
  120. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/AggregateQuery.php ( 3.26 KB )
  121. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/ModelRelationQuery.php ( 20.07 KB )
  122. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/ParamsBind.php ( 3.66 KB )
  123. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/ResultOperation.php ( 7.01 KB )
  124. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/WhereQuery.php ( 19.37 KB )
  125. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/JoinAndViewQuery.php ( 7.11 KB )
  126. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/TableFieldInfo.php ( 2.63 KB )
  127. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/Transaction.php ( 2.77 KB )
  128. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/log/driver/File.php ( 5.96 KB )
  129. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/contract/LogHandlerInterface.php ( 0.86 KB )
  130. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/log/Channel.php ( 3.89 KB )
  131. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/event/LogRecord.php ( 1.02 KB )
  132. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-helper/src/Collection.php ( 16.47 KB )
  133. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/facade/View.php ( 1.70 KB )
  134. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/View.php ( 4.39 KB )
  135. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/controller/Es.php ( 3.30 KB )
  136. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Response.php ( 8.81 KB )
  137. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/response/View.php ( 3.29 KB )
  138. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Cookie.php ( 6.06 KB )
  139. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-view/src/Think.php ( 8.38 KB )
  140. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/contract/TemplateHandlerInterface.php ( 1.60 KB )
  141. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-template/src/Template.php ( 46.61 KB )
  142. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-template/src/template/driver/File.php ( 2.41 KB )
  143. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-template/src/template/contract/DriverInterface.php ( 0.86 KB )
  144. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/runtime/temp/c935550e3e8a3a4c27dd94e439343fdf.php ( 31.80 KB )
  145. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-trace/src/Html.php ( 4.42 KB )
  1. CONNECT:[ UseTime:0.000575s ] mysql:host=127.0.0.1;port=3306;dbname=wenku;charset=utf8mb4
  2. SHOW FULL COLUMNS FROM `fenlei` [ RunTime:0.000762s ]
  3. SELECT * FROM `fenlei` WHERE `fid` = 0 [ RunTime:0.000281s ]
  4. SELECT * FROM `fenlei` WHERE `fid` = 63 [ RunTime:0.000278s ]
  5. SHOW FULL COLUMNS FROM `set` [ RunTime:0.000451s ]
  6. SELECT * FROM `set` [ RunTime:0.000205s ]
  7. SHOW FULL COLUMNS FROM `article` [ RunTime:0.000546s ]
  8. SELECT * FROM `article` WHERE `id` = 546670 LIMIT 1 [ RunTime:0.001378s ]
  9. UPDATE `article` SET `lasttime` = 1776627782 WHERE `id` = 546670 [ RunTime:0.005101s ]
  10. SELECT * FROM `fenlei` WHERE `id` = 64 LIMIT 1 [ RunTime:0.000404s ]
  11. SELECT * FROM `article` WHERE `id` < 546670 ORDER BY `id` DESC LIMIT 1 [ RunTime:0.000478s ]
  12. SELECT * FROM `article` WHERE `id` > 546670 ORDER BY `id` ASC LIMIT 1 [ RunTime:0.000368s ]
  13. SELECT * FROM `article` WHERE `id` < 546670 ORDER BY `id` DESC LIMIT 10 [ RunTime:0.000727s ]
  14. SELECT * FROM `article` WHERE `id` < 546670 ORDER BY `id` DESC LIMIT 10,10 [ RunTime:0.001383s ]
  15. SELECT * FROM `article` WHERE `id` < 546670 ORDER BY `id` DESC LIMIT 20,10 [ RunTime:0.003354s ]
0.092482s