PaperlayerView exact revision on arXiv

Source-linked AI summary

LadderEdit: Edit-Level Residual Compression for Memory-Efficient Lifelong Editing of LLMs

Xiaobing Yu, Peijie Qiu, Jin Yang, Xuanzhao Dong, Weiwei Ma, Zhaoqi An, Xiaoqi Zhao, Xiaofeng Liu

arXiv:2610.11160v1cs.CLcs.CVcs.LGcs.MM

TL;DR

Lifelong editing must retain behavioral quality across growing edit streams, while full-resolution edit memories scale with the number of edits. LadderEdit stores low-rank sketches and promotes edits when behavioral audits fail; across the reported benchmarks and models, it tracks exact LoRA with 5.2× less persistent memory through 50,000 edits.

  • Problem

    Lifelong editing must preserve rewrite success, generalization, and locality as the number of updates grows, while full-resolution edit memories scale linearly with the stream.

    Source: §3.1 · pp. 3–4

  • Method

    LadderEdit acquires an exact update, stores a low-rank sketch, and audits rewrite, generalization, and locality, promoting rank when the sketch fails.

    Source: §1 · p. 2, §3.2 · p. 4

  • Results

    5.2× less persistent memory while tracking exact LoRA across ZsRE, CounterFact, and WikiBigEdit on three model families and remaining effective at 50,000 edits.

    Source: §1 · p. 2, §5 · p. 9

  • Takeaways & Limitations

    Most exact adapters are over-resolved: low-rank sketches preserve the edit contract for the bulk of the stream, while only a smaller subset needs higher resolution.

    Source: §5 · p. 9

    Persistent storage still grows linearly because every edit retains at least a rank-1 sketch.

    Source: §6 · p. 9

Abstract

from arXiv · show

Lifelong editing of LLMs requires storing thousands of edits after acquisition. A widely used family of approaches attaches one LoRA adapter per edit, which preserves behavior but grows linearly in storage. To address this challenge, we propose LadderEdit, a method that compresses each LoRA adapter after it is acquired. Each edit is first stored at low rank as a cheap sketch. We then check whether this sketch still satisfies the rewrite, generalization, and locality contract on probe prompts. Edits that pass keep the sketch; those that fail are promoted to a higher rank along a ladder until the contract is met. Because every edit retains some representation, coverage is maintained, and only hard edits consume more rank. Across ZsRE, CounterFact, and WikiBigEdit benchmarks on LLaMA-3-8B, Mistral-7B, and Qwen2.5-7B, LadderEdit tracks exact LoRA storage at 5.2x less memory and remains effective at 50,000 sequential edits.

1 Introduction

Lifelong editing must balance the ability to add corrections, preserve earlier and unrelated behavior, and limit storage as edits accumulate. LadderEdit allocates representation resolution per edit, and the reported evaluations show it tracking exact LoRA at substantially lower memory.

1 Introduction

  • Existing approaches face a storage-plasticity tension: fixed-capacity editors can lose edit plasticity, while repeated direct updates can interfere over long streams.Retrieval- and routing-based editors also introduce edit-selection challenges, including failures on semantically close queries.Source: §1 · p. 1
  • Resolution allocation preserves a cheap representation for every edit and spends additional memory only where higher fidelity is required.Unlike keep/drop caching, this policy retains coverage for edits represented at low resolution.Source: §1 · p. 2
  • LadderEdit first acquires each edit as an exact LoRA update, predicts a candidate rank from spectral information and behavioral slack, then audits the sketch and promotes it if needed.The audit checks rewrite, generalization, and locality; a passing edit is stored at the proposed rank.Source: §1 · p. 2
  • 5.2× less persistent memory while tracking exact LoRA across ZsRE, CounterFact, and WikiBigEdit on three model families, with effectiveness at 50,000 edits.The reported comparison covers LLaMA-3-8B, Mistral-7B, and Qwen2.5-7B.Source: §1 · p. 2

2 Related Work

Prior lifelong-editing methods address sequential updates through several memory and parameter mechanisms, but they face a trade-off between plasticity and storage. LadderEdit targets persistent edit memory after acquisition by assigning resolution per edit and auditing behavioral requirements.

2 Related Work

  • Lifelong-editing approaches use key-value or side memories, null-space constraints, and adapter or MoE mechanisms, yet still face a storage-plasticity tension.Shared or constant-memory systems can lose plasticity as capacity saturates, whereas edit-local memories grow with the number of edits.Source: §2 · p. 2
  • Unlike adaptive-rank training or multi-adapter serving, LadderEdit allocates storage per acquired edit according to behavioral contract satisfaction.Its question is how much of an already-acquired update must persist, not how to learn an adapter or deploy many adapters.Source: §2 · p. 2
  • LadderEdit uses spectral compressibility to propose candidate ranks but relies on rewrite, generalization, and locality audits for the final storage decision.Exact-cache instead reduces memory by dropping edits.Source: §2 · p. 3
  • Under compression, exact-cache fails by leaving edits absent, while LadderEdit degrades by lowering resolution and keeps each edit represented by a sketch.The method operates after acquisition and inherits the full-resolution memory bank’s selection mechanism.Source: §2 · p. 3

3 Method

Lifelong editing must preserve rewrite success, generalization, and locality as the edit stream grows, while choosing how much of each update to retain. LadderEdit stores a low-rank rung for each edit and uses spectral prediction and behavioral auditing to allocate additional resolution when needed.

3.1 Problem Setting

  • The behavioral contract requires answering edited prompts, generalizing to related prompts, and preserving unrelated knowledge as the number of edits grows.The method is exact-first and retrieval-agnostic, and audits the stored representation against the acquired update’s measured contract.Source: §3.1 · pp. 3–4
  • Across 2,000 edits on ZsRE and CounterFact, roughly 80% were rank-1 sketch-sufficient, about 19% needed rank 2 or higher, and about 5% were compression-regularized.These population patterns motivate retaining a representation for every edit while varying its resolution.Source: §3.1 · p. 4

3.2 Residual-Ladder Allocation

  • LadderEdit acquires an exact update, compiles it into candidate rungs, and audits the cheapest candidate that satisfies the edit contract.The contract comprises rewrite, generalization, and locality requirements.Source: §3.1 · p. 3, §3.2 · p. 4
  • The spectral score proposes a rank from the update’s spectral tail and exact-edit behavioral slack, but the proposal is not a safety proof; behavioral auditing makes the final decision.The proposal selects one rung for the audit rather than auditing every rung.Source: §3.2 · p. 4
  • When a passing edit is eligible for downgrade, the controller tests one lower-rank sketch and keeps it only if the behavioral audit still passes.At T = 10,000 on LLaMA-3-8B, downgrades saved approximately 0.6 GB of persistent memory.Source: §3.2 · p. 5
  • The two-state storage analysis gives every edit a cheap representation and spends exact memory on a difficult subset, supporting one-LoRA-per-edit scaling when K ≪ N.The deployed controller can also promote through intermediate rungs rather than jumping directly to the exact rung.Source: §3.2 · p. 5

4 Experiments

Experiments compare LadderEdit with full-resolution LoRA and other storage and editing baselines across sequential-edit benchmarks. Results show it preserves strong editing behavior with compressed storage, including at long horizons, by retaining a sketch for every edit and allocating higher ranks selectively.

4.1 Experimental Setup

  • Experiments span ZsRE, CounterFact, and WikiBigEdit on three model families, comparing exact LoRA, fixed-rank compression, exact-cache, and other editing baselines using reliability, generalization, and locality probes.Edit-local methods use the same edit association for rewrite, generalization, and locality probes; audit, validation, and test prompts are split, with thresholds selected on validation before testing.Source: §4.1 · p. 6

4.2 Results

  • On ZsRE, LadderEdit improves over exact LoRA at T = 500 on LLaMA-3-8B (0.97 vs. 0.93) and matches it at T = 1,000 and 2,000; CounterFact shows reliability/locality gains at T = 2,000.On LLaMA-3-8B CounterFact, reliability/locality rise from 0.71/0.93 to 0.74/0.94; on Mistral-7B, from 0.68/0.91 to 0.71/0.92.Source: §4.2 · p. 6, Table 1 · p. 7, Table 2 · p. 8
  • At T = 50,000 on WikiBigEdit, LadderEdit reaches 0.75 reliability, 0.84 generalization, 0.98 locality, and 0.86 average while reducing persistent storage.GRACE reaches 0.28 generalization, while WISE loses reliability and generalization and MEMOIR reaches 0.69 average.Source: §4.2 · p. 6, Figure 3 · p. 7, Table 3 · p. 8
  • At N = 2,000, roughly 80% of edits are rank-1 sketch-sufficient, 13–17% need rank 2 or higher, and 3–5% need full acquisition rank.A 4–7% compression-regularized subset passes the behavioral contract with a rank-1 sketch when exact LoRA fails; the combined predictor approaches oracle utility with fewer audits per edit than its individual components.Source: §4.2 · pp. 6–7, Table 4 · p. 8
  • At 8× compression, rank-1 sketches reach utility 0.753 on CF and 0.765 on ZsRE, exceeding exact-cache by roughly 0.33; at matched budget, dual-budget LadderEdit reaches 0.862 and 0.866.A static mixed-rank policy reaches 0.815 on CF and 0.796 on ZsRE at the matched budget.Source: §4.2 · p. 7, Table 5 · p. 8, Figure 4 · p. 8
  • At T = 10,000 on LLaMA-3-8B, persistent memory falls from 100.93 GB with exact LoRA to 19.44 GB, a 5.19× reduction, while acquisition remains exact-first.The lookup mechanism is unchanged; LadderEdit changes only the representation returned after lookup.Source: §4.2 · p. 8, Table 6 · p. 8

5 Conclusion

LadderEdit combines a spectral rank proposal with a behavioral audit that promotes edits only when the proposed representation fails. Across three benchmarks and three backbones, it tracks exact LoRA at lower memory use through 50,000 edits.

5 Conclusion

  • A spectral predictor proposes each edit’s candidate rank, and a behavioral audit verifies it and promotes the edit only when needed.The proposal is the cheapest candidate rank; the audit checks the edit’s performance.Source: §5 · p. 8
  • Across ZsRE, CounterFact, and WikiBigEdit on three 7B and 8B backbones, LadderEdit tracks exact LoRA with 5.2× less persistent memory through 50,000 edits.The reported backbones are LLaMA-3-8B, Mistral-7B, and Qwen2.5-7B.Source: §5 · p. 9
  • Most exact adapters are over-resolved: low-rank sketches preserve the edit contract for most edits, while a smaller hard subset needs higher resolution.The conclusion frames storage as deciding how much of each edit to retain, not only which edits to keep.Source: §5 · p. 9

6 Limitations

LadderEdit retains at least a rank-1 sketch per edit and adds insertion-time audit latency. Its guarantees are bounded by probe coverage, retrieval inherits the memory bank’s selection mechanism, and validation so far covers three benchmarks and three 7B/8B backbones.

6 Limitations

  • LadderEdit is not constant-memory: retaining a rank-1 sketch for every edit means persistent storage still grows linearly with the stream.Sketch downgrading or merging are proposed as possible ways to bound total storage.Source: §6 · p. 9
  • At T=10,000 on LLaMA-3-8B, the behavioral audit adds 124 ms insertion-time latency versus 86 ms.Batching audits or running them asynchronously could reduce this latency.Source: §6 · p. 9
  • The audit depends on finite probe coverage and does not guarantee correct behavior outside the probed set.The authors suggest richer probe construction or learned probe selection.Source: §6 · p. 9
  • LadderEdit inherits the full-resolution memory bank’s retrieval mechanism, while its spectral rank score remains a calibrated heuristic.Integration with broader production retrieval stacks and replacing the score with a predictor trained on audit outcomes remain open.Source: §6 · p. 9
  • Experiments cover three benchmarks and three 7B/8B backbones, with long-horizon scaling shown to 50,000 edits.Validation at larger scales and with non-LoRA edit writers remains future work.Source: §6 · p. 9

7 Ethics Considerations

LadderEdit is a memory-allocation mechanism, not a truth or safety filter. Appendix results report preserved storage-method ordering under learned retrieval, a correlation between lexical overlap and locality improvement, and trade-offs against fixed-rank and alternative systems.

7 Ethics Considerations

  • LadderEdit can reduce the cost of retaining edits, but it does not verify their factual correctness; false or harmful edits remain a misuse risk.The authors name provenance tracking, signed edit acquisition, and downstream factuality checking as mitigations outside the method.Source: §7 · p. 9

A Composing LadderEdit with Learned Retrieval

  • With the same retrieved edit identity passed to both methods, exact LoRA and LadderEdit degrade equally under imperfect retrieval, preserving their relative ordering across retrieval strategies.The evaluation uses learned Contriever-style and E5-large retrievers, plus frozen MPNet, on ZsRE / LLaMA-3-8B at T=1,000.Source: A Composing LadderEdit with Learned… · p. 12, Table 7 · p. 12

A.1 Edit-Stream Heterogeneity

  • On ZsRE and CounterFact, lexical overlap between rewrite prompts and locality probes correlates positively with locality improvement from sketch storage (Pearson r=0.38 and r=0.41, respectively).The authors say this is consistent with low-rank truncation removing surface-feature directions that locality probes penalize.Source: §A.1 · p. 13

A.2 Comparison with Static Mixed-Rank Allocation

  • Against rank-8, audited LadderEdit gains +0.05 pooled Avg. and +0.12 worst-edit Avg.; it is within 0.01 and 0.04, respectively, of the oracle.The oracle reaches 0.96 pooled and 0.78 worst-edit Avg.; the audit’s contribution is most visible on the bottom 10% of edits.Source: §A.2 · p. 13, Table 8 · p. 13
  • MEMOIR uses 0.14 GB versus LadderEdit’s 19.4 GB at T=10,000, while LadderEdit improves Avg. by 0.11; GRACE has 0.34 generalization on LLaMA-3 at T=2,000.The authors characterize the MEMOIR comparison as a memory-for-fidelity trade, not strict dominance, and note GRACE cannot answer paraphrased queries.Source: §A.2 · p. 13

A.3 Audit Score Weights

The audit combines reliability, generalization, and locality residuals, weighting locality more heavily because locality failures are irreversible while the other failures trigger recoverable rank promotion. The validation sweep favors wL=1.2, with a stable performance region from 1.0 to 1.5.

A.3 Audit Score Weights

  • The audit score weights reliability, generalization, and locality residuals by wR=1.0, wG=0.8, and wL=1.2, respectively.Locality receives the highest weight because locality failures are irreversible, whereas reliability or generalization failures trigger rank promotion and can be reassessed.Source: §A.3 · p. 13
  • Average performance stays within 0.01 of its peak for wL∈[1.0, 1.5], falling by 0.02 at 0.8 and 0.03 at 2.0.The default wL=1.2 is the midpoint of the stable region.Source: §A.3 · p. 13
  • At wL=0.8, Loc. drops from 1.00 at the default to 0.88; above 1.5, reliability and generalization degrade as the audit becomes over-restrictive.The default is the unique swept value at which all three metrics are simultaneously near their per-metric optima.Source: §A.3 · pp. 13–14, Figure 5 · p. 14
  • At the default wL=1.2, the total failure rate is 1.6%, the minimum in the sweep; Figure 5 decomposes performance, metrics, and failure modes.At wL=0.8, locality failures account for 14.2% of edits; at wL=2.0, locality failures fall to 0.4% while 9.5% of edits are rejected.Source: §A.3 · p. 14, Figure 5 · p. 14
  • The reliability and generalization weights are not separately tuned; varying their shared value changes Avg. by less than 0.005.The main results use wL=1.2 without per-benchmark retuning.Source: §A.3 · p. 14

A.4 Composition with Post-Training Quantization

LadderEdit and INT8 quantization reduce storage along different axes: rank across edits and bit-width within each stored representation. Rank allocation concentrates storage on a minority of edits, and its memory advantage over exact LoRA grows with stream length.

A.4 Composition with Post-Training Quantization

  • At T = 2,000 on ZsRE / LLaMA-3-8B, LadderEdit plus INT8 yields a 20× reduction over FP16 exact LoRA, reaching 0.90 Avg. at 0.05 normalized memory.Exact LoRA + INT8 reaches 0.93 Avg. at 0.25 normalized memory; quantization reduces per-edit bit-width while LadderEdit reduces per-edit rank.Source: Table 9 · p. 14, §A.4 · p. 14

A.5 Per-Condition Rung Allocation

  • At T = 1,000 on ZsRE / LLaMA-3-8B, the top two stored-rank rungs cover 95.5% of edits, while only about 4.5% require ranks 3 or above.The audit promotes edits only when a lower-rank sketch fails the behavioral contract.Source: §A.5 · p. 14, Table 10 · p. 15

A.6 Memory Ratio Stability

  • At T = 50,000 on WikiBigEdit, LadderEdit uses approximately 12× less memory than exact LoRA on LLaMA-3-8B, with ratios of 12.0×, 11.6×, and 11.8× across the three backbones.The ratio grows from 2.0× at T = 100 (mean across backbones) to 11.8× at T = 50,000 as low-rank rungs absorb additional edits with near-constant marginal memory.Source: §A.6 · p. 15

B.1 Training and Seed Details

The appendix details how LadderEdit is applied after exact edit acquisition and how the evaluation split, allocation policy, and diagnostics support the reported comparisons. It distinguishes edit-level persistent-storage allocation from adapter compression, shared-capacity methods, and edit dropping.

B.1 Training and Seed Details

  • LadderEdit is applied after exact LoRA acquisition without changing the edit writer, base weights, rewrite examples, or optimizer; comparisons use shared edit streams and seeds.The diagnostic setup uses raw rank-8 LoRA and a deployed rank menu from 1 to 8; the main audited configuration uses τ = 0.05 unless varied.Source: §B.1 · pp. 15–16

C Probe Split Protocol and Validation; D.1 Partition statistics

D.2 Audit-test independence

  • Per-edit audit and test utilities correlate at r = 0.62 (p < 10−50), while same-edit audit/test paraphrase Jaccard averages 0.34 on ZsRE and 0.29 on CounterFact.Source: §D.2 · p. 17

D.3 Leaky versus clean comparison

  • At T = 1,000 on ZsRE / LLaMA-3-8B, using test paraphrases in the audit inflates Generalization by 6 points and the average by 4 points; main-paper results use the strict split.The leaky-versus-clean comparison quantifies the utility cost of evaluating with the strict split.Source: Table 12 · p. 17, §D.3 · p. 17

D Why Not Standard LoRA Compression; D.4 AdaLoRA Comparison and Scope

  • LadderEdit allocates persistent rank across acquired edits after behavioral auditing, unlike AdaLoRA’s within-adapter rank allocation; it keeps one representation per edit rather than merging edits.Serving systems such as S-LoRA deploy many adapters but do not decide which adapter directions to persist; LadderEdit spends extra memory on the behaviorally difficult tail.Source: D Why Not Standard LoRA Compression? · p. 16, §D.4 · p. 17

D.5 Rationale and Conditional Guarantees

  • At roughly 5.6× compression, an exact cache retains about 18% of 512 edits, whereas rank-1 sketches represent every edit and higher-rank promotion repairs the hard tail.At the same budget of 91 retained edits on ZsRE / LLaMA-3-8B, LadderEdit reaches 0.93 pooled Avg.; learned utility-scored drop reaches 0.35, or 0.41 with a base-model fallback.Source: §D.5 · pp. 17–18

D.6 Diagnostic Examples

  • Representative generations show rank 1 can preserve rewrite behavior, while another case needs rank 2 to recover the specific value; compression can also improve a measured contract.False retirements occur on both CF and ZsRE, supporting behavioral auditing rather than relying on spectral energy alone.Source: §D.6 · p. 18

D.7 Sensitivity, Coverage, and Audit Cost

The sensitivity, coverage, and insertion-cost checks find that threshold and rank variations have limited score effects, while probe coverage remains a practical constraint. Insertion latency depends on stream length, with the relative speed of LadderEdit and exact LoRA changing as the stream grows.

D.7 Sensitivity, Coverage, and Audit Cost

  • Across tested thresholds and LoRA ranks, average score changes by less than 0.03, while memory changes substantially with rank.The sweep is on ZsRE / LLaMA-3-8B at T = 1,000; the default τ = 0.05 and r = 8 sits at the peak of both sweeps.Source: §D.7 · p. 18, Table 14 · p. 19
  • At T = 2,000, the default probe bank covers 87% of edits and keeps the unprobed-edit average within 0.06 of the probed-edit average; lower coverage degrades more clearly.The audit depends on probe coverage, and unprobed edits are handled through nearest-probe interpolation.Source: §D.7 · pp. 18–19, Table 15 · p. 19
  • On an A100-40GB at T = 50,000, LadderEdit takes 150 ms per edit versus 850 ms for exact LoRA, or 5.7× faster per edit.LadderEdit is slower per edit below T = 2,000; its cumulative audit time at T = 50,000 is approximately 32 minutes, paid at acquisition rather than serving.Source: §D.7 · p. 19

E Rank-Predictor Ablation

The predictor uses spectral tail and edit margin to propose a low-cost rank, then behavioral checks and rank promotion handle cases where a sketch does not meet the contract. Diagnostics show both sketch-sufficient edits and a smaller difficult subset, motivating adaptive rather than fixed-rank storage.

E.1 Denoising Audit and Spectral-Filter Visual Audit

  • The denoising audit distinguishes sketches that pass or fail alongside the exact update, including compression-regularized cases where the sketch passes but exact LoRA fails.A false retirement occurs when an exact-pass edit fails after compression; exact LoRA is treated as an acquisition reference, not a behavioral oracle.Source: §E.1 · p. 20

E Rank-Predictor Ablation

  • The combined spectral-times-margin predictor reaches utility within 0.02 of the oracle at 4.6× fewer audits per edit; removing either factor reduces utility by 0.03–0.05.Random rank proposal reaches 0.81 utility, while the always-rank-1 audit-and-promote baseline is competitive on utility but incurs higher audit cost.Source: E Rank-Predictor Ablation · p. 19, Table 19 · p. 20

F Fixed-Rank Tier Diagnostics

  • Across N ∈ {32, 128, 512} on both datasets, rank-1 false retirements are substantial, while rank 4 leaves only 1 to 2 per dataset.Most edit energy is captured by low-rank sketches, but a small hard subset requires higher rank.Source: F Fixed-Rank Tier Diagnostics · pp. 20–21

F.1 Swap-Count and Frontier Visuals

  • Figure 7 plots pass-set transitions as rank increases for ZsRE and CF at N = 512, showing how many edits change pass/fail status at each rank.The swap counts highlight the difficult subset requiring higher rank.Source: Figure 7 · p. 21, §F.1 · p. 21

F.2 Interpretation

LadderEdit preserves a representation for every edit and adds rank only when behavioral audits require it. The extended analyses distinguish coverage gains from adaptive-rank gains, assess scaling and insertion costs, and clarify that storage—not initial acquisition—is the efficiency benefit.

F.2 Interpretation

  • The audit is essential because spectral energy predicts, but does not establish, whether a candidate rung satisfies the behavioral contract.The difficult subset requiring higher rank is reported as small and stable across datasets and stream sizes; exact LoRA is not always optimal, since some compressed sketches outperform it on the audit.Source: §F.2 · p. 21

F.3 Baseline Details

  • LadderEdit replaces the full-resolution representation returned by Exact LoRA with the cheapest audited representation, while retaining the same edit acquisition and lookup association.AdaLoRA allocates rank during adapter training; LadderEdit allocates retained resolution after an edit has been acquired.Source: §F.3 · p. 22

G Extended Analysis of Scalability, Storage, and Practical Deployment

  • The extended analyses examine scaling, memory-matched comparisons, acquisition cost, storage growth, retrieval, rank allocation, audit coverage, and audit behavior to separate storage allocation from other system effects.The stated scope includes implementation details as well as comparisons with retrieval, cache selection, and initial edit acquisition.Source: G Extended Analysis of Scalability,… · p. 22

G.1 Scaling to Larger Backbones

  • LadderEdit remains close to Exact LoRA at Qwen2.5-14B and Qwen2.5-32B, with average-point differences of 0.004 and 0.003, respectively, and locality of 0.999 in all cases.The evaluation increases backbone size while keeping the writer, edit stream, and protocol unchanged.Source: §G.1 · pp. 22–23, Table 21 · p. 23

G.2 Exact-Cache Baselines and Coverage Loss

  • On the same 91-of-512 edit capacity, cache policies achieve about 0.93–0.94 utility on retained edits, while evicted edits lack an edit-specific representation.The learned cache is more than twice as effective as random retention; the full-stream gap is attributed primarily to coverage loss.Source: §G.2 · p. 23, Table 22 · p. 23

G.3 Strict Memory-Matched Frontier

  • 0.319 on CounterFact and 0.345 on ZsRE are the utility gains from rank-1 coverage over exact-cache; adaptive allocation adds 0.047 and 0.070, respectively, over static mixed-rank storage.Both comparisons use approximately matched normalized memory; the first restores coverage, while the second allocates extra resolution selectively.Source: §G.3 · p. 23, Table 23 · p. 23

G.4 Full-Resolution Acquisition Cost

  • At T = 10,000, the added insertion stage costs 38 ms per edit, while persistent storage falls from 100.93 GB to 19.44 GB, an 80.7% reduction.The rank proposal averages 1.21 audits per edit versus 8 for exhaustive rank evaluation; at T = 50,000, insertion takes about 150 ms per edit for LadderEdit versus 850 ms for Exact LoRA.Source: §G.4 · p. 24, Table 24 · p. 24

G.5 Long-Horizon Storage Growth

LadderEdit reduces persistent storage growth by retaining a sketch for every edit and promoting only edits that need more resolution. The extended analyses show the storage benefit across long streams, while identifying retrieval quality and representative audit probes as conditions on end-to-end behavior.

G.5 Long-Horizon Storage Growth

  • At T = 10,000, Exact LoRA requires 100.93 GB and LadderEdit 19.44 GB, a 5.19× reduction; observed reductions range from about 2.0× at T = 100 to 11.6–12.0× at T = 50,000.A 100 GB budget corresponds to approximately 9,900 Exact-LoRA edits or 51,400 LadderEdit edits, estimated from the measured T = 10,000 operating point rather than assuming a horizon-invariant ratio.Source: §G.5 · p. 24

G.6 Retrieval and Edit Selection

  • LadderEdit controls storage after an edit is selected, so end-to-end performance depends on the retrieval mechanism; with Contriever, both Exact LoRA and LadderEdit decrease from 0.95 to 0.92.E5-large and frozen MPNet results measure LadderEdit's retrieval sensitivity only, not parity with Exact LoRA.Source: §G.6 · pp. 24–25, Table 26 · p. 25

G.7 Rank Proposal and Audit Efficiency

  • 0.91 utility is within 0.02 of exhaustive rank search, while the combined rank proposal uses 1.21 rather than 8.00 audits per edit, a 6.6× reduction.The spectral tail and behavioral margin are an empirical ranking heuristic, not a guarantee of minimum sufficient rank.Source: §G.7 · p. 25, Table 27 · p. 25

G.8 Audit-Probe Coverage

  • At 87% audit-probe semantic coverage, overall average performance is 0.94 versus 0.95 at 99%; strict audit/test separation yields 0.95 rather than 0.99 with non-disjoint probes.The analysis varies missing semantic coverage, not mislabeled, corrupted, or adversarial probes.Source: §G.8 · pp. 25–26, Table 28 · p. 25

G.9 Qualitative Audit Outcomes

  • The audit distinguishes sketch-sufficient edits, edits needing promoted rank, compression-regularized edits, and edits that still fail at full acquisition rank.Compression-regularized cases occur in 4.3% of ZsRE and 6.7% of CounterFact diagnostics; the target “architect” example is answered incorrectly by full Exact LoRA but correctly by the lower-rank representation.Source: §G.9 · p. 26

G.10 Correlation Between Compression and Behavioral Outcomes

  • Approximately 86 ZsRE and 134 CounterFact edits fall in the compression-regularized subsets, with moderate correlations of r = 0.38 and r = 0.41, respectively.These correlations are secondary diagnostics, not causal evidence that truncation produces behavioral improvement.Source: §G.10 · p. 26

G.11 SVD Procedure and Memory Accounting

  • LadderEdit applies SVD separately to each adapted module and computes persistent storage by summing retained LoRA factors across modules.Its efficiency claim concerns smaller retained storage, not cheaper initial fitting; at T = 10,000 storage falls from 100.93 GB to 19.44 GB, a 5.19× reduction.Source: §G.11 · p. 26, §G.12 · p. 27

G.12 Scope of the Efficiency Claim; G.13 Summary

  • The results characterize LadderEdit as an adaptive representation layer that retains every edit, allocates higher resolution when needed, and reduces persistent storage without corresponding degradation in evaluated accuracy, generalization, or locality.Storage remains linear in stream length, and retrieval quality can affect end-to-end accuracy; constant-memory editing is outside the study's scope.Source: §G.5 · p. 24, §G.12 · p. 27, §G.13 · p. 27
Loading 2610.11160v1…