PaperlayerView exact revision on arXiv

Source-linked AI summary

Self-Evolving Search Index

Sangam Lee, Wonjae Lee, Sunghwan Kim, Deogyong Kim, Jaehoon Kim, Daye Nam, SeongKu Kang, Dongha Lee

arXiv:2609.19656v1cs.IRcs.AI

TL;DR

Index representations must fit diverse retrieval environments, yet adapting them to retrieval failures has largely required human diagnosis and strategy refinement. SELF-INDEX automates selective index revision and validation while exploring additional query demands, and consistently improves retrieval across corpora and retrievers, with benefits extending to downstream applications.

  • Problem

    Index keys must expose document knowledge, but effective representations vary across corpora and retrievers, while evolving them in response to failures remains human-driven.

    Source: §1 · pp. 1–2

  • Method

    SELF-INDEX autonomously diagnoses retrieval shortfalls, selectively revises and validates affected keys, and uses a Query Simulator to explore additional retrieval demands.

    Source: §1 · p. 2

  • Results

    SELF-INDEX consistently achieves the highest average score for every corpus type under every retriever, outperforming the strongest competing method, with gains extending to downstream applications.

    Source: §1 · p. 2

  • Takeaways & Limitations

    Search agents using SELF-INDEX-evolved indexes achieve higher answer accuracy with lower online cost, and agent memory systems retrieve useful information from past interactions.

    Source: §1 · p. 2

Abstract

from arXiv · show

Information retrieval is increasingly important as LLM agents tackle complex tasks involving diverse information needs. Because retrieval relies on an index that represents each document through index keys, retrieval quality depends heavily on how effectively these keys expose the knowledge contained in each document. However, effective index representations vary across retrieval environments, making it difficult for any fixed optimization strategy to perform consistently. Yet evolving an index to its retrieval environment remains largely human-driven, requiring humans to diagnose retrieval failures, refine the optimization strategy, and reprocess the index accordingly. We propose SELF-INDEX, a framework that enables an index to self-evolve without human intervention. Its Optimizer autonomously diagnoses retrieval shortfalls, selectively revises the responsible index keys, and validates each revision before updating the index. Beyond reacting to observed retrieval demands, SELF-INDEX proactively explores additional demands through a Query Simulator, allowing the index to evolve beyond the queries already available for optimization. Across diverse corpora and retrievers, SELF-INDEX consistently improves retrieval performance while outperforming existing index optimization methods. We further show that these benefits extend to downstream applications, improving the effectiveness and efficiency of search agents and helping agent memory systems retrieve useful past interactions.

1 INTRODUCTION

Retrieval quality depends on index keys that expose document knowledge, but effective representations vary by corpus and retriever. SELF-INDEX automates index evolution, including proactive exploration, and improves retrieval and downstream applications.

1 INTRODUCTION

  • Retrieval effectiveness depends heavily on whether index keys expose document knowledge, motivating optimization of those representations.Index keys represent documents for retrievers to match and rank against queries.Source: §1 · p. 1
  • Corpus and retriever differences favor different index representations, so no single optimization strategy is expected to perform consistently across retrieval environments.The examples include natural-language, code, and table corpora, and sparse or dense retrievers.Source: §1 · p. 1
  • Index evolution remains human-driven: people diagnose failures and refine strategies, while applying a revised strategy requires reprocessing all index keys.These repeated steps impose substantial human effort and computational cost.Source: §1 · pp. 1–2
  • SELF-INDEX automates diagnosis, selective revision of responsible keys, and validation, updating the index only with accepted revisions.Validated revisions accumulate as the loop repeats, without requiring human intervention.Source: §1 · p. 2
  • A Query Simulator explores plausible retrieval demands beyond received queries and supplies them to the Optimizer for proactive index evolution.This extends optimization beyond the queries already available for it.Source: §1 · p. 2
  • SELF-INDEX achieves the highest average score for every corpus type under every retriever, outperforming the strongest competing method and extending gains to search agents and agent memory.Search agents achieve higher answer accuracy while reducing online cost; agent memory systems retrieve useful past information.Source: §1 · p. 2

2 RELATED WORK

Prior index optimization methods use predefined or learned strategies, but still leave adaptations to retrieval failures and broad index reprocessing to human effort. SELF-INDEX applies self-evolution to index keys, autonomously refining them from retrieval outcomes.

2 RELATED WORK

  • Earlier index optimization expands or restructures document representations with predefined strategies, while learned strategies still require additional relevance annotations and reruns when demands remain unsupported.SELF-INDEX instead evolves keys from retrieval outcomes and selectively refines those linked to observed shortfalls.Source: §2 · p. 2
  • SELF-INDEX’s Optimizer diagnoses retrieval shortfalls, selectively revises affected key sets, and validates changes, while a Query Simulator can supply additional queries.Only accepted revisions update the index as the exploration and optimization loop repeats.Source: Figure 1 · p. 3
  • Existing self-evolving work has focused on models or agents, leaving self-evolution for index optimization underexplored.SELF-INDEX extends the paradigm to index representations without manual strategy redesign or relevance annotations.Source: §2 · pp. 2–3

3 SELF-INDEX

SELF-INDEX revises document-level index keys while leaving the corpus unchanged. Its Optimizer diagnoses and selectively revises shortfalls, validates proposed keys, and can use simulated queries to explore additional retrieval demands.

3 SELF-INDEX

  • SELF-INDEX revises document-level key sets K(d) while leaving the underlying corpus unchanged; retrieval scores each document by its most relevant key.For query q, the document score is the maximum relevance rel(q, k) over keys k in K(d).Source: §3 · p. 3

3.1 OVERVIEW

  • The Optimizer iterates through Self-Diagnosis, Self-Revision, and Self-Validation, accepting valid revisions into the index for later iterations.Because it responds only to queries it receives, the Optimizer’s evolution is reactive without additional exploration.Source: §3.1 · p. 3

3.2 OPTIMIZER

  • Self-Diagnosis uses retrieval outcomes and co-retrieval profiles to identify shortfalls in keys and describe their causes without relevance annotations.Each profile records which keys from other documents are retrieved alongside a key and how frequently.Source: §3.2 · pp. 3–4
  • Self-Revision targets document key sets with diagnosed shortfalls, revising each set as a whole to account for interactions among its keys.Joint revision avoids introducing information already represented by another key in the same set.Source: §3.2 · p. 4
  • Self-Validation checks generated keys for faithfulness, document specificity, and separation from competing keys before accepting revisions.The original-text key is fixed, and failing generated keys are removed from proposals.Source: §3.2 · p. 4

3.3 QUERY SIMULATOR

  • Self-Exploration samples corpus documents to generate plausible unmet-demand queries, then filters lexical overlap before supplying retained queries to the Optimizer.The Dissimilarity filter uses Jaccard similarity against optimization queries and queries already accepted in the simulation step.Source: §3.3 · p. 4

4 EXPERIMENTS

The experiments evaluate SELF-INDEX across retrieval environments and downstream agent tasks. They report consistent retrieval gains, alongside improvements in search-agent performance and memory retrieval.

4.1 EXPERIMENTAL SETTINGS

  • The evaluation spans natural-language, code, mathematics, and table corpora, using BRIGHT, three table-retrieval datasets, BrowseComp-Plus, and LongMemEval-V2.Retrieval performance is measured with nDCG@10; comparisons include multiple retrievers and index-optimization baselines.Source: §4.1 · p. 5

4.2 SELF-INDEX IMPROVES RETRIEVAL ACROSS DIVERSE ENVIRONMENTS

  • SELF-INDEX achieves the highest average nDCG@10 for every retriever on BRIGHT and the table-retrieval benchmarks, outperforming competing methods across corpus types.Other methods sometimes improve or degrade performance depending on the retrieval environment.Source: Table 1 · p. 5, Table 2 · p. 5, §4.2 · p. 6

4.3 SELF-INDEX IMPROVES THE DOWNSTREAM PERFORMANCE OF SEARCH AGENTS

  • Across evaluated agent backbones and retrievers, SELF-INDEX improves answer accuracy and evidence recall, outperforms SPIKE in answer accuracy, and reduces search calls versus the base index.It also improves accuracy while reducing online cost; as BrowseComp-Plus expands from 100K to 400K documents, its accuracy remains stable and online cost per query slightly decreases relative to its 100K baseline.Source: §4.3 · pp. 6–7, Table 3 · p. 6, Figure 2 · p. 7

4.4 SELF-INDEX IMPROVES THE MEMORY UTILIZATION OF AGENTS

  • SELF-INDEX improves answer accuracy across the evaluated memory systems while leaving their stored memory contents unchanged.The reported improvements span static, dynamic, and workflow abilities and memory designs ranging from raw trajectory slices to consolidated notes and AgentRunbook-R.Source: §4.4 · p. 8, Table 4 · p. 8

5 ANALYSIS

The analysis tests the Optimizer’s validation and diagnosis components, the Query Simulator’s query generation, and how index representations change over successive iterations.

Ablation on the Optimizer

  • Removing co-retrieval profiles or any Self-Validation criterion lowers average nDCG@10; removing validation altogether drops scores below the base index in every corpus type.The authors conclude that co-retrieval profiles and each validation criterion contribute to retrieval gains.Source: §5 · p. 8, Table 5 · p. 8

Ablation on the Query Simulator

  • Removing the Query Simulator’s Dissimilarity filter consistently lowers average nDCG@10 across all three corpus types.The experiment keeps the number of optimization queries fixed.Source: §5 · pp. 8–9, Table 5 · p. 8

Effect of the query source

  • ReasonIR queries improve average nDCG@10 over the base index, but Query Simulator queries yield larger gains in every corpus type.The authors attribute the broader demand coverage to Self-Exploration seeking retrieval demands not covered by optimization queries.Source: §5 · p. 9, Figure 5 · p. 9

Dynamics of index evolution

  • Across corpus types, SELF-INDEX continues gaining after surpassing SPIKE in early iterations, progressively revising keys to make query-relevant knowledge more explicit.In the Biology example, revised keys highlight tendon connections and their relevance to finger movement.Source: §5 · p. 9, Figure 6 · p. 9, Figure 4 · p. 9

6 CONCLUSION

SELF-INDEX selectively revises index keys to address retrieval shortfalls and proactively explores additional retrieval demands. The paper reports retrieval improvements across corpora and retrievers, with benefits for search agents and agent memory retrieval.

6 CONCLUSION

  • SELF-INDEX selectively revises index keys to address retrieval shortfalls and explores additional demands to guide further evolution.Source: §6 · p. 10
  • The experiments show consistent retrieval improvements across diverse corpora and retrievers.Source: §6 · p. 10
  • Reported downstream benefits include improved search-agent effectiveness and efficiency and help retrieving useful information from agent memory.Source: §6 · p. 10

A METHOD DETAILS

SELF-INDEX iteratively diagnoses retrieval shortfalls, selectively revises index keys, and validates proposed changes before updating the index. A Query Simulator adds plausible, previously uncovered retrieval demands to this process.

A.1.1 OPTIMIZATION PROCEDURE

  • The Optimizer runs Self-Diagnosis, Self-Revision, and Self-Validation in each iteration, updating the index only when revisions pass validation.The next iteration starts from the index incorporating accepted revisions.Source: §A.1.1 · p. 17, §A.1.4 · p. 20

A.1.2 SELF-DIAGNOSIS

  • Retrieval feedback combines query results and co-retrieval profiles with each retrieved document’s current keys; the LLM diagnoses representational shortfalls and gives revision guidance.Optimization uses neither manually annotated relevance judgments nor evaluation queries or labels.Source: §A.1.2 · pp. 17–18

A.1.3 SELF-REVISION

  • For a diagnosed shortfall, the competing-key set draws on other-document keys co-retrieved with implicated keys; a whole-set coverage shortfall implicates every current key.Revision proposes one new version of the targeted key set, with no predefined strategy and a budget of at most 10 keys including the fixed original-text key.Source: §A.1.3 · p. 19

A.1.4 SELF-VALIDATION

  • Self-Validation checks generated keys for Faithfulness, Specificity, and Separation, removing any key that fails a criterion before deciding whether to update the index.Faithfulness uses an LLM judge; Specificity tests retrieval of the source document, and Separation compares relevance to competing keys.Source: §A.1.4 · p. 20

A.2.1 SELF-EXPLORATION

  • The Query Simulator samples corpus documents, abstracts each underlying information need, then generates candidate queries without supplying the original document to the query-writing call.It checks candidates against the sampled document and sends accepted queries to the Optimizer.Source: §A.2.1 · p. 21

A.2.2 QUERY VALIDATION

  • Simulated queries must be answerable from their sampled document and have Jaccard similarity below 0.8 to previously used or accepted queries.The dissimilarity check also limits overlap among queries generated in the same simulation step.Source: §A.2.2 · p. 22

B.1.1 RETRIEVAL EVALUATION

Retrieval evaluation covers BRIGHT and table-retrieval datasets, with document and table rankings assessed using nDCG@10. Search-agent evaluation uses BrowseComp-Plus and measures answer accuracy alongside retrieval and calibration behavior.

B.1.1 RETRIEVAL EVALUATION

  • BRIGHT covers 1,384 real-world queries across 12 datasets; results are grouped by natural-language, code, and mathematics corpus type, with equal dataset weighting in the averages.Table retrieval uses Spider 2.0, FIBEN, and BEAVER; rankings are evaluated with nDCG@10 on a 0–100 scale.Source: §B.1.1 · p. 24

B.1.2 SEARCH AGENT EVALUATION

  • BrowseComp-Plus evaluates search agents on 830 complex questions over a fixed corpus of 100,195 documents, reporting answer accuracy, evidence recall, search calls, and calibration error.Answer accuracy is judged against reference answers; evidence recall measures annotated evidence documents retrieved across the agent trajectory.Source: §B.1.2 · p. 24

B.1.3 AGENT MEMORY EVALUATION

LongMemEval-V2 Small tests whether agents can answer questions using knowledge from past web interactions, and reports accuracy overall and across four question categories.

B.1.3 AGENT MEMORY EVALUATION

  • LongMemEval-V2 Small comprises 451 questions based on multimodal histories from WebArena and ServiceNow, with each source’s questions sharing 100 web-agent trajectories.Accuracy is reported for Static, Dynamic, Workflow, and Gotchas, as well as Overall with equal weight per question.Source: §B.1.3 · p. 24

B.2 BASELINE METHODS AND REPRODUCTION

The experiments compare SELF-INDEX with established index-optimization baselines under shared retrieval and index-evolution settings. Separate protocols hold agent and memory-system components fixed, and cost accounting distinguishes offline index work from online agent calls.

B.2 BASELINE METHODS AND REPRODUCTION

  • Baselines include Doc2Query and SPIKE on BRIGHT and table datasets, RL-Index on BRIGHT, and EnrichIndex on table datasets; comparisons use three retrievers.For BrowseComp-Plus, the compared indexes are the base index, SPIKE, and SELF-INDEX.Source: §B.2 · p. 25

B.3 SHARED INDEX EVOLUTION AND RETRIEVAL SETTINGS

  • Main runs use Qwen3.6-35B-A3B for the Optimizer, Query Simulator, and judges, with 2,560 simulated queries over 20 iterations and a 10-key budget per document.Evaluation queries remain unobserved during optimization; each iteration processes 128 queries and retrieves the top 30 keys per query.Source: §B.3 · p. 25

B.4 AGENT SETTINGS ON BROWSECOMP-PLUS

  • BrowseComp-Plus comparisons hold the agent, prompt, retriever, and judge fixed while comparing base, SPIKE, and SELF-INDEX indexes.The search tool returns five documents per call and previews each document’s first 512 tokens.Source: §B.4 · pp. 25–26

B.5 MEMORY SETTINGS ON LONGMEMEVAL-V2

  • LongMemEval-V2 compares three retrieval-based memory designs while SELF-INDEX evolves their retrieval keys and leaves stored memory contents unchanged.The fixed reader receives retrieved memory as text and images, with a 200,000-token context limit.Source: §B.5 · p. 26

B.6 COST ACCOUNTING

  • Offline cost estimates use recorded input and output token usage for index construction and evolution, while online estimates cover agent LLM calls.The online accounting excludes offline optimization, retriever serving, and answer evaluation; offline estimates exclude local GPU ownership and hosting costs.Source: §B.6 · p. 26

C.1 DETAILED RESULTS ON BRIGHT

Across the three retrievers, SELF-INDEX has the highest overall nDCG@10 in the additional BRIGHT results. Backbone size affects retrieval performance, but larger models do not guarantee better results; the section also reports online token usage and costs for BrowseComp-Plus.

C.1 DETAILED RESULTS ON BRIGHT

  • SELF-INDEX achieves the highest overall nDCG@10 across all three retrievers in the additional BRIGHT results, with standard deviations small relative to competing-method gains.The reported results average three runs.Source: §C.1 · p. 27

C.2.1 RETRIEVAL PERFORMANCE ON BRIGHT

  • 22.4 average nDCG@10 is reached with Qwen3.6-35B-A3B, compared with 13.9 for the 0.8B backbone and 19.2 for the 9B backbone.These scores average over five BRIGHT datasets and three retrievers.Source: §C.2.1 · p. 27
  • The 304B backbone reaches 19.9 average nDCG@10, so increasing model size beyond 35B does not yield further average-performance gains.Source: §C.2.1 · p. 27
  • The 0.8B backbone improves Biology and Pony but falls below the base index on Economics, Psychology, and TheoremQA-Theorem; backbones of at least 9B improve every dataset.Source: §C.2.1 · p. 27

C.3 ONLINE SEARCH COSTS ON BROWSECOMP-PLUS

  • Table 15 reports token usage and USD costs for the base, SPIKE, and SELF-INDEX indices over all 830 BrowseComp-Plus questions under the same agent and retriever settings.Search calls alone do not determine cost; context length, output length, and cached input-token share also vary.Source: §C.3 · p. 27

C.4 CORPUS-SCALE EVALUATION ON BROWSECOMP-PLUS

The corpus-scale evaluation compares SELF-INDEX and SPIKE on expanded BrowseComp-Plus corpora, while the published DCI reference uses a different agent configuration and question set. Results are expressed as relative changes from each method’s own 100K-document baseline, not as absolute cross-method comparisons.

C.4 CORPUS-SCALE EVALUATION ON BROWSECOMP-PLUS

  • SELF-INDEX is evaluated against SPIKE on 100K-, 200K-, and 400K-document BrowseComp-Plus variants using a GPT-5.4-nano agent, BM25, and all 830 questions.Each corpus variant starts SELF-INDEX from the initial index.Source: §C.4 · p. 27
  • The published DCI reference uses DCI-Agent-CC and 100 questions, unlike the index-based runs; comparisons therefore concern changes from each method’s own 100K baseline, not absolute accuracy or cost.Source: §C.4 · p. 27
  • Figure 3 reports relative percentage changes in answer accuracy and average online cost per question against each method’s own 100K-document result, not percentage-point changes.Source: §C.4 · p. 28
  • Table 16 gives the numerical changes plotted in Figure 3, describing each method’s sensitivity to corpus growth.Source: §C.4 · p. 28

C.5.1 COMPONENT ABLATIONS

This section examines how SELF-INDEX’s query supply, validation, and scoring affect retrieval, and traces how evolving keys support evidence retrieval across biology, robotics, mathematics, and structured data. Its cases show keys linking mathematical principles to concrete questions and tables to user-related queries.

C.5.1 COMPONENT ABLATIONS

  • Component ablations use the same base index and optimization budget, independently disabling co-retrieval context or validation checks against the full framework’s three-criteria validator.The co-retrieval ablation retains the profiles needed for Separation; other variants disable all checks or individual checks, while retaining the remaining validation procedure.Source: §C.5.1 · pp. 29–30

C.5.2 EFFECT OF THE QUERY SOURCE

  • Query Simulator queries yield higher scores than ReasonIR HQ queries in every domain for each retriever, while ReasonIR HQ still improves overall nDCG@10 over the base index under all three retrievers.The comparison retains the full Optimizer and all three Self-Validation criteria; ReasonIR HQ queries are corpus-grounded and generated independently of the Query Simulator.Source: §C.5.2 · p. 30, Table 18 · p. 31

C.5.3 SCORE AGGREGATION

  • SELF-INDEX has higher average nDCG@10 than SPIKE across all three retrievers even when both use the same max score aggregation.This comparison tests whether SELF-INDEX’s advantage is explained simply by differing score aggregation rules.Source: §C.5.3 · p. 32, Table 19 · p. 32

C.6 INDEX EVOLUTION AND OFFLINE EFFICIENCY ON BRIGHT

  • At iteration 20, SELF-INDEX outperforms SPIKE on all three BRIGHT datasets while incurring lower cumulative optimization cost.The comparison pairs checkpoints with cumulative LLM cost; SELF-INDEX selectively revises document key sets identified with retrieval shortfalls, whereas SPIKE generates scenarios for every document.Source: Table 20 · p. 32, §C.6 · p. 33

D.1 BRIGHT: BIOLOGY (NATURAL LANGUAGE)

  • In biology cases, revised index keys align tendon anatomy with independent-finger movement, improving rank from 40 to 2, and connect fainting with slowed heart rate, improving rank from 140 to 3.Source: §D.1.1 · p. 34, §D.1.2 · p. 35

D.2 BRIGHT: ROBOTICS (CODE)

  • In robotics cases, revised keys raise a Gazebo ArUco-marker tutorial to rank 1 and a ROS 2 callback-code example from outside the top 200 to rank 1.The marker key makes the tutorial’s application explicit; the callback example offers a semantic route through lambda-capture context but does not explicitly implement the requested additional argument.Source: §D.2.1 · p. 36, §D.2.2 · p. 37

D.3 BRIGHT: THEOREMQA-THEOREM (MATHEMATICS)

  • At iteration 13, the document ranked 2 for the question of finding the minimum order of a complete graph whose edges, under any 2-coloring, guarantee a monochromatic complete subgraph of order 4.Rank 2 is maintained through iteration 20.Source: §D.3.1 · p. 38

D.3.1 CASE 5: CONNECTING A TOURNAMENT QUESTION TO RAMSEY NUMBERS

  • The index key for the rank-2 document adds constraints for the tournament query—teams, red or blue outcomes, and a group of four—beyond the general topic of Ramsey numbers.These constraints express the specific mathematical problem underlying the tournament scenario.Source: §D.3.1 · p. 38

D.3.2 CASE 6: RECOVERING A THEOREM AFTER AN EARLY RANK DECLINE

  • The document fell outside the top 200 during iterations 1–5, then ranked first from iterations 6–20 after an index key linked birthdays and months to 13 people.The unchanged document’s original tags named the theorem but did not mention birthdays or months; the account notes that retaining an original key did not preserve relative rank as other keys evolved.Source: §D.3.2 · p. 39

D.4 TABLE RETRIEVAL

  • For structured data, retrieval targets a table rather than an explanatory passage, connecting its schema to an analytical objective and its role in a user-related query.Source: §D.4 · p. 40

D.4.1 CASE 7: SPIDER 2.0: FROM EVENT FIELDS TO RETENTION ANALYSIS

Across schema lookup, search-agent, and memory examples, evolved index keys surface relevant sources or prior procedures that the original index missed. In several cases, retrieval supports a correct answer or a more focused follow-up.

D.4.1 CASE 7: SPIDER 2.0: FROM EVENT FIELDS TO RETENTION ANALYSIS

  • The original index missed the relevant Firebase partition, whereas the evolved index ranked it first for the September 2018 retention query.The revised key connects “user retention” and the requested period to first-touch acquisition dates; the full analysis still requires the requested date range.Source: §D.4.1 · p. 40

D.4.2 CASE 8: BEAVER: EXPOSING THE GROUP-DEFINITION TABLE

  • The revised key ranked the user-directory security-groups table first instead of the original group table, but a separate membership table is still needed to identify a user’s groups.Both representations retrieve the same underlying table, which provides group attributes.Source: §D.4.2 · p. 41

D.5 AGENTIC SEARCH ON BROWSECOMP-PLUS

  • The BrowseComp-Plus trajectory comparison pairs original-document excerpts and evolved keys with selected original-index calls and all SELF-INDEX calls; ranks denote positions within each result list.Source: §D.5 · p. 42

D.5.1 CASE 9: THE LIVES OF OTHERS: FROM CLUES TO AN IDENTIFIED ACTOR

  • The original index did not resolve the film question in 20 searches, while SELF-INDEX retrieved the actor’s obituary and produced the correct answer in two searches.The evolved key surfaces clues about Ulrich Mühe that support the follow-up search for The Lives of Others.Source: §D.5.1 · pp. 42–43

D.5.2 CASE 10: GUILDHALL: FINDING THE INTERVIEW BEFORE VERIFYING THE SCHOOL

  • Across 32 unsuccessful original-index searches, SELF-INDEX retrieved the interview on the first call and at rank 1 on both follow-ups, yielding the correct Guildhall answer.The evolved summary key brings the interview context, date, artist identity, and training background into a compact entry.Source: §D.5.2 · p. 44

D.6 MEMORY RETRIEVAL ON LONGMEMEVAL-V2

  • The memory examples use revised keys to describe shared operations across products or users; displayed records report trajectory metadata and retrieval outcomes, not full memory contents.Source: §D.6 · p. 46

D.6.1 CASE 11: WEB: RECOVERING A PRODUCT-CONFIGURATION EXPERIENCE

  • For the web task, SELF-INDEX retrieved a trajectory absent from the original-index results and corrected the answer; similarity was 0.648 versus 0.346 for the original slice.The reference answer is Image, Price, Quantity, Weight.Source: §D.6.1 · p. 46

D.6.2 CASE 12: ENTERPRISE: REUSING A PROCEDURE ACROSS EMPLOYEE NAMES

  • For the offboarding task across employee names, SELF-INDEX retrieved the earlier trajectory and accompanied correction from asset-list option C to profile-based workflow A; similarity was 0.637 versus 0.375.The revised key names offboarding and hardware unassignment without relying on the original employee’s name.Source: §D.6.2 · p. 47

Related papers

Loading 2609.19656v1…