Decomposing Complex Queries for Tip-of-the-tongue Retrieval (arXiv 2305.15053)

Forum topic · 小凯 · 2026-07-05

Summary

This forum post indexes the arXiv paper 'Decomposing Complex Queries for Tip-of-the-tongue Retrieval' (arXiv:2305.15053) by Kevin Lin, Kyle Lo, Joseph E. Gonzalez, and Dan Klein. Tip-of-the-tongue (ToT) retrieval addresses queries where users only vaguely remember a document—e.g., recalling plot fragments of a story but not its title. The paper proposes using large language models to decompose such complex, underspecified queries into simpler sub-queries, which can be answered independently and then combined for document retrieval. The post contextualizes the work within modern information retrieval: dense vs. sparse retrieval, rerankers, RAG, and agentic search, and discusses how query decomposition fits into the retrieve-rerank-generate pipeline. It also includes engineering checklists covering latency budgets, index versioning, evaluation practices (nDCG, MRR, Recall@k, human audits), and safety concerns such as corpus poisoning. The original entry is largely a template-based summary, so readers should consult the arXiv PDF for exact experimental results, datasets, and quantitative comparisons before citing numbers.

Decomposing Complex Queries for Tip-of-the-tongue Retrieval (arXiv:2305.15053)

Overview

This entry indexes the paper "Decomposing Complex Queries for Tip-of-the-tongue Retrieval" (May 2023).

Authors: Kevin Lin, Kyle Lo, Joseph E. Gonzalez, Dan Klein
Link: https://arxiv.org/abs/2305.15053
Category: Query Understanding / Information Retrieval

Key points

Problem: Tip-of-the-tongue (ToT) retrieval — a user only vaguely remembers a document (e.g., partial plot details of a story) without knowing its title or exact identifiers. Standard keyword or single-query retrieval often fails on such underspecified queries.
Approach: Use large language models (LLMs) to decompose complex ToT queries into simpler sub-queries that can be answered independently, then aggregate evidence across sub-queries to retrieve the target document.
Positioning in the IR stack: The work sits within the query-understanding stage of the classical retrieve → rerank → generate pipeline, complementing query expansion, conversational query rewriting, and retrieval-augmented generation (RAG).

Context from the forum entry

The original post frames the paper within broader trends in search and recommendation:

The evolution from BM25 and dense bi-encoders to cross-encoder rerankers, generative retrieval, and LLM-based agentic search.
The new design variables in the LLM era: inference budget and action space (whether to retrieve, how many times, which tools to call).
Engineering considerations for deploying such methods: p99 latency budgets, cascade retrieval with early stopping, embedding index versioning, offline-vs-online metric gaps, and safety (corpus poisoning, output filtering).

> Note: The forum entry is largely template-based; its experimental details are generic placeholders. For datasets, baselines, and quantitative results, refer directly to the arXiv abstract/PDF.

Related entries in the same collection

Aligned Query Expansion: Efficient Query Expansion for Information Retrieval
Beyond the Limitation of a Single Query: Train Your LLM for Query Expansion
Few-Shot Generative Conversational Query Rewriting (SIGIR 2020)
Hierarchical Query Classification in E-commerce Search (WWW 2024)
Hypothetical Documents or Knowledge Leakage? Rethinking LLM-based Query Expansion

Glossary

| Term | Meaning | |------|---------| | IR | Information Retrieval | | RAG | Retrieval-Augmented Generation | | ToT | Tip-of-the-tongue retrieval from vague memory cues | | nDCG | Normalized Discounted Cumulative Gain, a ranking metric | | Agentic Search | Modeling search as sequential decisions and tool calls |

Takeaways

1. Researchers: Reproduce the decomposition pipeline and check whether significance and compute costs are reported. 2. Engineers: Treat query decomposition as a pluggable module in front of existing retrievers/rerankers; watch added latency from multiple sub-queries. 3. Product teams: Evaluate user-perceivable gains (finding the remembered item, answer trustworthiness) rather than offline nDCG alone.