Resumen Técnico: SimpleWikiSearch

Declaración del Problema

Las evaluaciones actuales de los sistemas de búsqueda agéntica basados en Modelos de Lenguaje de Gran Escala (LLM) a menudo tratan el entorno de búsqueda subyacente como un detalle secundario, centrándose principalmente en las puntuaciones de la respuesta final del modelo. Sin embargo, el rendimiento medido de estos agentes depende fuertemente de la configuración específica del entorno de búsqueda, incluyendo la versión del snapshot de Wikipedia, los procesos de preprocesamiento de documentos, las políticas de fragmentación (chunking), los backends de recuperación, los esquemas de herramientas, los formatos de observación y las reglas de envío de respuestas.

El artículo destaca que estos detalles suelen estar insuficientemente especificados en trabajos previos. Por ejemplo, configuraciones ampliamente reutilizadas como KILT y DPR dependen de snapshots históricos específicos (p. ej., 2018/2019) y divisiones de pasajes fijos de 100 palabras. Estas convenciones heredadas, diseñadas para lectores de contexto corto y recuperadores de nivel de pasaje, pueden no ser valores por defecto neutrales para los agentes modernos que utilizan herramientas basadas en LLM. Además, las unidades de recuperación cortas pueden ocultar información a nivel de documento y obligar a los agentes a encontrar "agujas en pajares" sin completitud semántica. La falta de especificaciones ambientales explícitas dificulta la comparación de resultados entre estudios o la reproducción de las líneas base reportadas.

Metodología

Se propone SimpleWikiSearch como un entorno de Wikipedia offline, limpio, explícito y ejecutable para la búsqueda agéntica. Funciona como un arnés de agente de dominio específico en lugar de un nuevo algoritmo de agente. La metodología se define mediante los siguientes componentes:

1. Construcción del Corpus y Recuperación

• Snapshot: El sistema utiliza el volcado oficial de la Wikipedia en inglés enwiki-20260601.
• Preprocesamiento: El Wikitext se convierte en una representación de texto plano limpia (Markdown ligero) preservando los encabezados de sección y tablas, pero eliminando el marcado de enlaces explícito.
• Estrategia de Fragmentación (Chunking): A diferencia de las divisiones fijas de 100 palabras, los fragmentos se definen por longitud de tokens utilizando el tokenizador Qwen3-Embedding-0.6B. Las secciones se fusionan hacia un objetivo de 1536 tokens con una banda de tolerancia del 20%, preservando los límites de las oraciones. Esto resulta en 10,837,506 fragmentos que cubren 7,189,602 artículos.
• Stack de Recuperación:
  • Índice de Palabras Clave: Construido usando Tantivy sobre el texto y títulos de los fragmentos.
  • Índice Denso: Construido usando FAISS HNSW con vectores de 1024 dimensiones provenientes de Qwen3-Embedding-0.6B.
  • Fusión: El método de búsqueda por defecto es la Fusión de Clasificación Recíproca (RRF) que combina candidatos de palabras clave y densos. Los modos de solo palabras clave y solo vectores están disponibles para ablación.
  • Resolución: La búsqueda densa devuelve IDs de fragmentos, que se resuelven contra el almacén de Tantivy para recuperar el texto completo.

2. Interfaz de Herramientas

El agente interactúa con el entorno a través de tres herramientas mínimas de estilo OpenAI:

• search: Recupera resultados clasificados (título, URL, fragmento/snippet). Soporta métodos: rrf (por defecto), keywords y vector.
• open_url: Abre una URL de Wikipedia devuelta. Si la URL contiene un sufijo #chunk-N, devuelve ese fragmento específico; de lo contrario, devuelve el artículo completo.
• submit_answer: Termina el episodio con una cadena exacta corta o una tabla en Markdown.

3. Protocolo del Agente

El agente de línea base opera en un servidor de chat-completion compatible con OpenAI.

• Interacción: El modelo recibe el historial de la conversación y los esquemas de herramientas, puede solicitar llamadas a herramientas y puede llamar a múltiples herramientas independientes en un solo paso.
• Restricciones: Los episodios están limitados a 20 rondas del modelo. Los pasos del asistente se truncan a un máximo de cinco llamadas a herramientas. Si no se emite ninguna llamada a herramienta, el sistema insta al agente a continuar o enviar.

4. Configuración de Evaluación

• Datasets: Los experimentos cubren seis conjuntos de datos de QA: 2WikiMultiHopQA, HotpotQA, MuSiQue, FRAMES, PopQA y Bamboogle.
• Modelos: Las líneas base incluyen modelos de código abierto (Qwen3.5-4B, Qwen3.5-9B) y modelos comerciales de código cerrado (deepseek-v4-pro, gpt-5.4-2026-03-05) en un subconjunto aleatorio-300.
• Métricas: Se reportan dos métricas complementarias:
  1. F1 a nivel de Token: Normalización estándar (minúsculas, eliminación de puntuación) tomando el máximo sobre las respuestas de oro (gold answers) y alias.
  2. Precisión juzgada por LLM: Computada usando gpt-5.4-mini-2026-03-17 con un prompt fijo para dar crédito a respuestas fácticamente equivalentes, paráfrasis y respuestas embebidas.

Resultados Clave

• Rendimiento del Modelo: En los resultados de prueba completa, el modelo de código abierto de 9B generalmente supera al de 4B en la mayoría de los datasets, con ganancias significativas en MuSiQue, FRAMES y Bamboogle. Sin embargo, en HotpotQA, el modelo de 9B mostró un rendimiento ligeramente inferior.
• Divergencia de Métricas: El estudio observa una discrepancia frecuente entre el F1 y la Precisión del Juez. Por ejemplo, los modelos comerciales suelen lograr un F1 léxico más bajo pero una mayor precisión del juez en comparación con los modelos de código abierto, lo que sugiere que sus respuestas son más largas o están más parafraseadas, algo que las métricas léxicas penalizan.
• Estadísticas de Interacción: El análisis del uso de herramientas revela que los datasets multi-hop más difíciles (MuSiQue, FRAMES) requieren aproximadamente el doble de rondas y llamadas de búsqueda que los datasets más simples (2Wiki, PopQA). Las tasas de envío exitosas caen al rango del 66–73% para estos datasets difíciles, lo que indica que muchos episodios terminan debido al agotamiento del presupuesto de rondas en lugar de encontrar una respuesta.

Significancia y Contribuciones

El artículo establece explícitamente que su contribución principal no es un nuevo algoritmo de agente, sino una configuración de referencia especificada que permite la evaluación reproducible de la búsqueda agéntica.

Los autores reclaman las siguientes contribuciones:

1. Contrato de Entorno Explícito: Una especificación completa del diseño del corpus, los servicios de recuperación, las definiciones de herramientas y el protocolo de interacción del agente para la búsqueda en Wikipedia offline.
2. Líneas Base Reproducibles: Resultados de benchmark de prueba completa y aleatorio-300 utilizando tanto modelos de código abierto como de código cerrado, acompañados de scripts de análisis vinculados a código ejecutable en lugar de números mantenidos manualmente.
3. Transparencia: La liberación de todos los archivos de resultados de inferencia, incluyendo trayectorias de mensajes, observaciones de herramientas y predicciones, para facilitar el análisis de la comunidad.
4. Estandarización: Al hacer explícito el contrato del entorno, SimpleWikiSearch busca que los resultados de la búsqueda agéntica sean más fáciles de reproducir y comparar, abordando la falta de especificación que actualmente plaga al campo.

Los autores mantienen una postura modesta, enfatizando que el valor reside en la "configuración de referencia especificada" misma, la cual permite a la comunidad aislar el impacto de las capacidades del modelo de las variables ambientales.