Por qué actualizamos la búsqueda de código a voyage-4-large

Las cifras de benchmark en esta publicación reflejan las tablas de RTEB al momento de la publicación (junio de 2026). Las tablas cambian; trata las clasificaciones como una instantánea, no como un hecho permanente.

La búsqueda semántica es tan buena como los embeddings que hay detrás.

Cuando un agente le pregunta a Maguyva «dónde manejamos los reintentos», no está haciendo grep de la palabra «retry». Está pidiendo el significado — el bucle de backoff, el circuit breaker, la cosa que envuelve una llamada inestable. Esa pregunta la responde un modelo vectorial que convierte el código en un punto en el espacio y encuentra a sus vecinos. Elige un mejor modelo y cada consulta semántica del producto se vuelve silenciosamente más aguda.

Así que cambiamos el nuestro. Desde junio de 2026, los embeddings de código de Maguyva corren sobre voyage-4-large, en reemplazo de voyage-code-3.

El benchmark

No tomamos esta decisión por intuición. El Retrieval Embedding Benchmark (RTEB) público clasifica modelos de embeddings en tareas reales de recuperación, y en su tabla de Code, voyage-4-large ocupa el #1 general (90.86) — por delante de gemini-embedding-2-preview (90.26) y, notablemente, por delante del modelo que ya estábamos usando, voyage-code-3 (89.73, #3).

Esa es una brecha absoluta pequeña. Pero es una brecha en la dirección correcta, en un benchmark público, en la tarea exacta que nos importa: recuperar código por significado.

El compromiso que aceptamos: cuantización binaria

Aquí está la parte que la mayoría de las publicaciones de «actualizamos nuestro modelo» se saltan.

Maguyva no almacena vectores de precisión completa. Almacenamos embeddings cuantizados en binario: cada vector de 2048 dimensiones se colapsa a una firma de 2048 bits — 256 bytes por vector. Esas firmas se buscan con distancia de Hamming, indexadas y particionadas por tenant.

Ese es un compromiso deliberado. La cuantización binaria cede algo de precisión de recuperación a cambio de un almacenamiento dramáticamente más pequeño y un cálculo de distancia rápido y barato, sin necesidad de operar una base de datos vectorial separada. Para un producto que indexa repositorios completos por espacio de trabajo, esa economía importa más que exprimir la última fracción de un punto de benchmark.

voyage-4-large encaja en este diseño sin forzar una migración de la capa de almacenamiento: produce una salida de 2048 dimensiones, igual que voyage-code-3, así que nuestras columnas bit(2048) y la ruta de búsqueda por Hamming no cambiaron. El modelo mejoró; el esquema se quedó igual.

El código fue solo el comienzo

Maguyva es una herramienta de inteligencia de código. Pero también somos el cliente cero, y lo apuntamos a otra cosa: el markdown que vive en nuestros repositorios junto al código. Registros de decisiones de arquitectura, runbooks, contratos, documentos de finanzas y políticas — todo bajo control de versiones en Git, todo detrás del mismo servidor MCP, un índice semántico sobre los documentos, no solo sobre el código fuente.

Por eso importa exactamente la amplitud de voyage-4-large. En la misma familia de tablas de RTEB es #1 en finanzas, #1 en salud y #1 en recuperación general de texto — por delante de Gemini Embedding de Google, Embed v4 de Cohere y text-embedding-3-large de OpenAI. (Voyage es cocreador de RTEB, así que lo leemos como una señal pública fuerte más que como un árbitro perfectamente neutral, pero se compara cabeza a cabeza contra todos los modelos comerciales importantes, en conjuntos de reserva privados). El mismo índice que encuentra la función correcta para un agente encuentra la cláusula correcta en un contrato o la línea correcta en una política — y en esos dominios, voyage-4-large no es un compromiso, es el líder.

Por qué pagamos por embeddings premium

Hay una forma más barata de hacer búsqueda, y gran parte de ella es gratis. La búsqueda léxica — BM25 y sus parientes — coincide palabras clave, corre localmente y no cuesta nada. Los modelos de embeddings de código abierto como BGE, Nomic y embeddinggemma dan una recuperación semántica genuinamente decente, y puedes alojarlos tú mismo por el precio de una GPU. Maguyva también usa el lado gratuito: cada consulta fusiona búsqueda de texto, AST, grafo y semántica. En lo que no escatimamos es en la capa semántica.

Pagamos por token por embeddings premium — voyage-4-large — en lugar de autoalojar un modelo gratuito, por dos razones. Primero, la búsqueda por palabras clave sola no puede responder «dónde manejamos los reintentos» cuando el código dice backoff y circuit breaker y nunca dice la palabra «retry» — el significado es todo el punto del embedding, y en los dominios a los que servimos los modelos abiertos van a la zaga de los premium: un par de puntos por detrás en texto general, y más atrás todavía en nichos como código, contratos y finanzas. Segundo, en nuestra experiencia la calidad de la recuperación moldea la respuesta final más que el modelo del otro lado — un agente fuerte al que le dan el contexto equivocado de todas formas responde mal, y nunca ve el documento que nunca le dieron.

Así que los embeddings premium son una factura por token que escala con cada repositorio y documento que indexamos — y la pagamos a propósito. Por el resultado que obtienen nuestros usuarios, la función correcta o la cláusula correcta, creemos que ese compromiso vale la pena.

La parte honesta

La propia documentación de Voyage todavía etiqueta a voyage-code-3 como el modelo optimizado para código. Entonces, ¿por qué cambiar?

Porque leímos el benchmark público, no solo la tabla de modelos del proveedor, y el benchmark puso a voyage-4-large en la cima para recuperación de código. Esta fue una decisión con visión de futuro: tomar el modelo más nuevo y generalmente más fuerte y validarlo contra una tabla pública en las tareas que importan. Nos sentimos cómodos haciendo esa apuesta porque la evidencia es amplia — voyage-4-large no solo gana en código, también lidera en finanzas, salud y recuperación general.

El piso silencioso

Cada herramienta que exponemos — búsqueda semántica, recopilación de contexto de tareas, preguntas y respuestas fundamentadas — termina apoyándose en la recuperación. Cuando el recuperador mejora, el agente del otro lado obtiene mejor evidencia, comete menos giros equivocados, y fundamenta sus respuestas en el código correcto — o en la cláusula correcta, o en la política correcta. Un modelo de embeddings más agudo no es una función vistosa. Es el piso debajo de todo lo demás, y acabamos de elevarlo. No lo vas a notar. Ese es el punto.