Manticore agrega chunking nativo para búsquedas vectoriales largas

Por qué el chunking se volvió el cuello de botella invisible del RAG

Cualquier founder que haya montado un buscador semántico sobre documentación interna ha vivido esta escena: el insert funciona, la búsqueda responde, y aun así el documento de 5.000 tokens nunca aparece cuando la respuesta está en la página 4. No es un bug, es el comportamiento por defecto de la mayoría de motores vectoriales: tu modelo de embeddings tiene una ventana de entrada (por ejemplo, 512 tokens en all-MiniLM-L6-v2, según datos de Manticore Search) y todo lo que pase de ahí simplemente se descarta sin avisarte. El embedding resultante representa, en el mejor de los casos, la primera mitad del documento.

Manticore Search, el motor de búsqueda open source derivado del código de Sphinx, acaba de mover ese problema del lado de tu pipeline al motor. En lugar de pedirte que partas cada documento en pedazos, crees una tabla auxiliar para los chunks y luego escribas un GROUP BY para reconstruir los resultados a nivel de documento, ahora declaras la estrategia directamente en la columna vector y el motor hace el resto.

Qué lanzó exactamente Manticore: cinco estrategias declarativas

El cambio aparece como un nuevo parámetro chunk_strategy en la definición de la columna, con cinco valores posibles según explica Manticore en su blog oficial:

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

truncate (el antiguo default): un vector por documento, recorta al tamaño de la ventana del modelo. Sirve para títulos, descripciones cortas y queries, no para prosa larga.
mean: trocea el documento completo, embebe cada parte y promedia los vectores en uno solo normalizado. Cuesta igual que truncate en RAM pero no tira contenido.
fixed: ventanas de tamaño fijo en tokens, predecibles, pensadas para OCR, HTML sin estructura o logs.
recursive: misma ventana que fixed pero los cortes se hacen en fronteras naturales (párrafo, línea, oración, espacio). El equivalente del RecursiveCharacterTextSplitter de LangChain pero ejecutándose dentro del motor sobre los tokens reales del modelo.
sentence: detecta fronteras de oración con Unicode UAX #29 y las empaqueta hasta llenar el presupuesto. Es la opción cuando los chunks se van a inyectar luego en el prompt de un LLM.

Las tres últimas producen varios vectores por documento y requieren cambiar la columna de float_vector a float_vector_array. El chunk individual gana la búsqueda y el documento sigue apareciendo una sola vez en el resultado, con knn_dist() reportando la distancia al chunk más cercano.

Qué pasa cuando se compara contra truncate, según los números de Manticore

El equipo de Manticore anunció las pruebas que hizo sobre su propio manual en inglés: 189 páginas, alrededor de 298.000 palabras, con 419 consultas de «contenido profundo» (la respuesta vive más allá de los primeros ~1.200 caracteres, fuera del alcance de la ventana de 512 tokens del modelo usado) y 88 consultas de control.

Sobre contenido profundo, los números de la tabla publicada por Manticore son los siguientes:

truncate: hit@5 del 55.1%, MRR 0.44, 4.2 MB de RAM, 21 segundos de ingest.
mean: hit@5 del 65.2%, MRR 0.54, 4.2 MB.
fixed: hit@5 del 81.1%, MRR 0.68, 9.5 MB.
recursive: hit@5 del 83.3%, MRR 0.70, 11.7 MB.
sentence: hit@5 del 83.5%, MRR 0.68, 10.6 MB.

En el grupo de control (consultas cuya respuesta está en los primeros 1.200 caracteres, donde truncate sí la ve), truncate gana en precisión top-1 (65.9% contra 58.0% de recursive), pero a partir del top-5 la diferencia se diluye. El trade real, según el propio análisis del equipo, es perder unos puntos de precisión en el primer resultado para ganar 28 puntos de recall en todo lo demás.

El costo en infraestructura: ~2.5× RAM y ~4× tiempo de ingest (de 21 a 86 segundos en el benchmark). La latencia de query va de 6.3 ms a 8.5 ms en p50 según los datos publicados.

Por qué tu RAG probablemente está fallando más de lo que crees

El problema de fondo lo describe bien un análisis de Compare the Cloud sobre el mercado de bases de datos vectoriales: RAG es ahora el método default para hacer IA útil sobre datos privados, pero la retrieval es lo que decide si el modelo acierta o inventa. Si tu pipeline corta mal los documentos, no es que el LLM «alucine»: es que le estás pasando el contexto equivocado desde el principio.

El mismo análisis apunta que pgvector (la extensión de Postgres) ya soporta esta lógica «al lado del resto de tus datos», con transacciones ACID incluidas, lo que lo convierte en el default honesto para corpus medianos. Manticore ocupa el nicho de un motor de búsqueda completo (full-text + vector + JSON, derivado de Sphinx) que ahora también sabe trocear. Para una startup que ya corre MySQL o Postgres y no quiere sumar un servicio más, la diferencia práctica es dónde vive el chunking: en un pipeline externo, en pgvector, en Pinecone con su integrated embeddings, o dentro del motor como hace ahora Manticore.

Un punto que vale la pena mirar: Elastic anunció el 11 de septiembre su propio Elasticsearch Vector Database, serverless, con indexación, embeddings, chunking y retrieval híbrido preconfigurados, según reportó Crypto Briefing. La dirección de toda la categoría es la misma: que el chunking deje de ser código tuyo y pase a ser configuración del motor.

¿Qué significa esto para tu startup?

Si estás eligiendo dónde correr tu retrieval hoy, hay dos preguntas que importan más que el benchmark:

1. ¿Cuánto te cuesta cada token que embedding le pasas? En el test de Manticore el ingest pasó de 21 a 86 segundos. Si usas un modelo pagado (OpenAI, Voyage, Cohere), eso se traduce en factura. Los modelos locales ONNX son gratis por inferencia, y por eso Manticore los pone en primera persona en su benchmark. Antes de subir recursive, multiplica el tamaño de tu corpus por tu costo por millón de tokens y mira el número.

2. ¿Cuántas veces vas a re-indexar? El parámetro max_chunks existe específicamente para poner un techo: un PDF de 400 páginas pegado en una sola fila puede convertirse en miles de nodos HNSW. Trátalo como una guarda contra outliers, no como una forma de ahorrar RAM.

Acciones concretas

Si tu corpus es <50.000 documentos cortos (titulares, descripciones de producto, logs): quédate con truncate. El benchmark lo confirma y la opción default no te cuesta un centavo de complejidad.
Si indexas documentación, wikis, READMEs o bases de conocimiento: arranca con recursive y max_tokens=256. Es lo que mejor rindió en la prueba de Manticore para prosa estructurada.
Si los chunks van a un prompt de LLM (RAG clásico): usa sentence con max_tokens=384-512. Una oración cortada a la mitad distorsiona el contexto que le pasas al modelo.
Antes de elegir el motor: instrumenta tu propio recall sobre 50 consultas reales. Lo que cambia entre vendors no es tanto la matemática del HNSW como el chunking default y el costo de embedding.

Conclusión

El chunking dejó de ser una preocupación menor y se convirtió en el diferenciador real de los motores vectoriales. Lo que Manticore anunció el 17 de septiembre no es una revolución técnica (la idea del chunking existe desde LangChain), sino un cambio de ergonomía: pasa de un pipeline externo a un parámetro de la columna. Para una startup, eso significa menos código que mantener, menos tablas auxiliares que sincronizar, y menos «trucos de fin de semana» para que tu búsqueda deje de ignorar la mitad de tus documentos. Lo que sigue siendo responsabilidad tuya es medir el recall sobre tu propio corpus antes y después, porque ningún benchmark de vendor refleja tu distribución de datos real.