Hay un fallo muy repetido en sistemas RAG para agentes: el stack encuentra la idea general, pero falla justo cuando la respuesta depende de un SKU, un error exacto, una cláusula, un nombre propio o una línea de código.

Por eso la preview pública de Full Text Search que Pinecone abrió el 7 de mayo de 2026 sí merece atención aunque no venga con una tabla de benchmarks ruidosa. La novedad no es “Pinecone ahora también hace keyword search”. La novedad es otra: Pinecone quiere que el retrieval exacto viva en el mismo índice donde ya guardas vectores y metadata.

Qué cambia exactamente

Según el anuncio oficial, la feature trae:

BM25;
Lucene query syntax;
tokenización multiidioma;
y varios campos de texto por índice.

La documentación de release notes baja eso a tierra con un detalle importante: el índice usa un document schema tipado donde puedes declarar campos string con full_text_search, además de dense_vector y sparse_vector.

Eso cambia bastante la arquitectura típica porque te evita una de estas dos rutas incómodas:

mantener un motor separado para keyword search;
o forzar preguntas exactas dentro de una capa pensada para similitud semántica.

La señal útil para builders: exact match y semantic ya no tienen que vivir divorciados

Pinecone lo explica bien en su post: cuando el retrieval semántico escala, amplía cobertura, pero también pierde precisión para ciertos casos. Un agente puede entender el tema general y aun así fallar al buscar:

un error code 4092;
un nombre de persona;
un identificador;
o una frase jurídica literal.

Ese tipo de consulta no necesita “más inteligencia”; necesita coincidencia estricta donde toca y semantic ranking donde conviene.

La parte práctica es que ahora el mismo índice puede:

guardar texto;
guardar vectores;
filtrar metadata;
y elegir el método de ranking por query con score_by.

Eso reduce bastante la costumbre de sobrecomplicar RAG con demasiadas piezas antes de demostrar que la app realmente las necesita.

Cuándo sí se nota en un agente

La docs de Pinecone son bastante claras en su árbol de decisión: si tu consulta comparte tokens específicos con los datos, full-text search debería ser la primera opción.

Yo lo traduciría así para agentes:

usa retrieval semántico cuando el problema es intención o parecido conceptual;
usa full-text cuando el problema es precisión literal;
y mezcla ambos solo cuando el flujo de verdad lo pida.

Ese matiz importa porque demasiados equipos meten embeddings a todo, y luego compensan la pérdida de precisión con loops más largos, más reranking y más tokens.

Lo que más me interesa no es BM25; es el ahorro de infraestructura torpe

Hay equipos que pueden vivir perfectamente con dos motores distintos. Pero muchos otros terminan pagando complejidad de más:

un índice vectorial por un lado;
una capa keyword aparte;
reconciliación de resultados;
y lógica custom para decidir qué consulta va a cada sitio.

Si el mismo índice ya soporta texto, vectores y filtros, tienes una ruta más limpia para preguntas como:

soporte técnico sobre códigos de error;
búsqueda de cláusulas o citas;
code search con identificadores exactos;
o recuperación de nombres, SKUs y entidades delicadas.

Eso abre búsquedas bastante cualificadas:

pinecone full text search
bm25 pinecone
rag exact match
lucene pinecone

No es tráfico de curiosidad general. Es gente que ya se golpeó con los límites de retrieval puramente semántico.

Los límites también importan

La feature sigue en public preview y la docs pone varias restricciones que conviene no barrer debajo de la alfombra:

usa una versión de API nueva;
el schema queda fijo al crear el índice;
y para mezclar señales de forma más compleja todavía puede tocar hacer composición desde cliente.

O sea: esto no te da automáticamente “hybrid retrieval perfecto”. Te da algo más útil y más honesto: una base menos fragmentada para decidir mejor qué señal usar en cada query.

Cómo lo aterrizaría en una decisión

Si tu agente falla en preguntas exactas y la respuesta actual ha sido “metamos otro reranker” o “hagamos más vueltas”, yo revisaría primero si el problema real es de señal de búsqueda.

Full-text search en Pinecone merece piloto cuando:

tus usuarios preguntan por códigos, nombres, cláusulas o términos exactos;
quieres menos infraestructura paralela para lexical y semantic;
o necesitas un baseline más barato antes de meter otro modelo al loop.

Si todavía estás ordenando la base de retrieval y contexto antes de sofisticar el stack, empieza por el curso gratis. Y si quieres una pieza hermana donde Pinecone ataca el costo del loop desde otro ángulo, conversa muy bien con Pinecone AskData y su recorte de tokens para agentes.

Mi lectura corta es esta: Pinecone no lanzó “otra búsqueda”. Lanzó una forma más sensata de dejar que exact match y RAG dejen de estorbarse entre sí.