Most teams build their first retrieval system the same way: slice every document into fixed 512-token chunks, push them into a vector database, and hope the embedding model does the hard work. That hope gets you through a demo. It does not survive contact with real users.
In production, a legal contract falls apart when you sever a liability clause from its exceptions. API documentation turns useless when a code sample gets detached from its function signature. A customer support thread becomes noise when you rip a single complaint out of its conversational history. The problem is rarely the language model sitting at the end of the pipeline. The problem is what you feed it.
We learned this the hard way. Our initial retrieval layer looked standard but behaved inconsistently. So we rebuilt it around a simple idea: treat retrieval as measured infrastructure, not magic. Here is exactly what changed, and how we pushed recall to 95 percent while cutting the 95th-percentile latency from 850 ms to 320 ms.
The Fixed-Chunk Trap
Uniform token counts are easy to code and easy to explain. That convenience masks a basic truth: documents have structure. When you ignore that structure, you destroy signal.
Consider a ten-page master service agreement. A fixed 512-token slice will land mid-obligation, splitting a clause from the very cap table that limits it. The retrieval step then returns half a thought. The generator hallucinates the rest. In API documentation, a chunk that is too large dilutes the embedding with boilerplate headers, burying the specific method a developer needs. In support tickets, a fixed window treats a conversation as a bag of sentences, stripping away the back-and-forth that reveals what actually failed.
We stopped treating chunk size as a hyperparameter we guessed. We started treating it as a mapping exercise between the document type and the information architecture inside it.
Match Your Chunking to the Data
The fix is not one perfect chunk size. The fix is three distinct strategies tuned to three distinct data shapes.
Legal documents now go through recursive splitting. The algorithm first looks for the largest natural boundaries—sections, then subsections, then numbered clauses—and only falls back to smaller splits when necessary. This keeps a termination clause attached to its survival conditions. The retrieval step sees complete logical units, which sharply reduces the model’s temptation to invent missing exceptions.
API and code documentation get structure-aware chunking. Markdown headers, code fences, and parameter tables are parsed as atomic units. We do not split inside a code block. We keep docstrings adjacent to their signatures. The result is that a query for a specific class method retrieves the full context a developer needs: the description, the typed parameters, and the working example.
Support and conversational data use semantic chunking. Instead of counting tokens, we look for shifts in topic or intent. If a customer describes a bug in message three and pastes a stack trace in message seven, we chunk by meaning, not by message index. The retrieval layer then returns the full arc of the problem rather than a orphaned sentence.
Why Vector Search Alone Fails
Even perfect chunks die in a pure vector search. Dense embeddings excel at capturing meaning and synonymy, but they are notoriously fuzzy on exact strings. If an engineer searches for the precise error code ERR_CONNECTION_REFUSED, vector similarity might return a dozen conceptual neighbors and miss the exact match buried at rank fourteen.
Keyword search with BM25 has the opposite problem. It finds exact tokens but misses semantic intent. A user asking “why is my database down” will never match a document that says “troubleshooting connection timeouts.”
We now run both. Vector and keyword results are fed into Reciprocal Rank Fusion, which blends the two ranked lists without requiring calibrated scores. The fused list is then passed through a cross-encoder reranker. The reranker is slower than the initial retrieval, but it is far more precise because it judges query-document relevance directly rather than through compressed embeddings. That hybrid pipeline alone lifted our recall by 15 percent.
Fixing Bad Queries Before They Hit the Index
Los usuarios no escriben consultas de búsqueda ideales. Pegan líneas de registro truncadas. Escriben “está roto”. Usan jerga que su documentación nunca adoptó. Si confía en la consulta original, está confiando en el ruido.
Ahora expandimos cada consulta entrante en tres a cinco variaciones antes de enviarlas a la capa de recuperación. Una variación puede ser una paráfrasis directa. Otra puede ser el título hipotético de un documento ideal. Una tercera elimina el relleno conversacional e aísla las palabras clave técnicas. Cada variante se convierte en un embedding y se busca. Luego, eliminamos duplicados y fusionamos los conjuntos de candidatos.
Esto no es gratis. Esas llamadas de embedding adicionales cuestan dinero y añaden unos milisegundos. Pero el efecto en el recall fue dramático: pasamos del 78 por ciento al 96 por ciento al expandir las consultas antes de la recuperación. Debido a que una mejor recuperación reduce la ventana de generación y fundamenta al modelo en el contexto correcto, terminamos ahorrando dinero en las etapas posteriores. Un paso de recuperación ligeramente más costoso es más barato que un paso de generación largo y con alucinaciones.
Deje de adivinar. Empiece a buscar.
Una vez que tuvimos implementados el chunking adecuado, la recuperación híbrida y la expansión de consultas, aún nos enfrentamos a un caos combinatorio. El tamaño del chunk, el solapamiento (overlap), la profundidad de recuperación top-k, los límites del reranker y los pesos de fusión interactúan entre sí. Una búsqueda de cuadrícula (grid search) manual habría tomado semanas y aún nos habría dejado en un máximo local.
Cambiamos a la optimización bayesiana para explorar el espacio. En lugar de probar exhaustivamente cada combinación, el algoritmo de búsqueda mantiene una creencia sobre qué configuraciones es probable que funcionen bien y se estrecha progresivamente en las regiones prometedoras.
El resultado no es una única configuración perfecta. Es una frontera de Pareto de opciones. En un extremo, tenemos una configuración ligera optimizada para nuestro endpoint de soporte de API de alto rendimiento: inferencia rápida, recall moderado y la latencia más baja posible. En el otro extremo, tenemos una configuración agresiva para revisión legal: recuperación más profunda, reranking más pesado y un solapamiento más estricto, intercambiando milisegundos por exhaustividad. Como la frontera es explícita, podemos elegir el punto adecuado para el producto en lugar de pretender que una única solución sirve para todos.
Cómo se ven realmente los números
Estos cambios llevaron el sistema de un prototipo frágil a un pipeline de producción medido.
El recall a diez mejoró del 78 por ciento al 95 por ciento. Eso significa que cuando la respuesta correcta existe en nuestro corpus, la encontramos diecinueve de cada veinte veces.
La latencia en el percentil 95 cayó de 850 ms a 320 ms. El stack híbrido suena más pesado sobre el papel, pero un indexado más inteligente, rerankers más pequeños y la capacidad de servir chunks agresivos solo cuando es necesario hicieron que todo el sistema fuera más rápido.
La tasa de alucinación —rastreada por anotadores humanos en un golden dataset reservado— cayó del 12 por ciento al 3 por ciento. Cuando el modelo recibe un contexto completo y relevante, deja de inventar hechos.
El costo por consulta bajó de $0.008 a $0.005. Una mejor recuperación significa prompts de LLM más cortos y enfocados, y menos intentos de recuperación. El gasto extra en embeddings para la expansión de consultas se ve eclipsado por el ahorro en la generación.
Construya un Golden Dataset y trate la recuperación como código
Si se lleva algo de esto, que sea la disciplina de la medición. Construimos un pequeño golden dataset de preguntas reales y ubicaciones de respuestas verificadas. Antes de que cualquier cambio llegue a producción, se ejecuta contra ese conjunto de datos. El recall y la latencia se monitorean en tiempo real, no se estiman a ojo en un notebook.
La recuperación no es una demo de investigación. Es infraestructura. Merece pruebas unitarias, benchmarks de regresión y optimización automatizada, al igual que el resto de su stack. Divida en chunks por estructura de documento, no por superstición de tokens. Combine la búsqueda vectorial y por palabras clave con un reranker. Expanda las consultas que sus usuarios escriben realmente. Luego, deje que un algoritmo de búsqueda ajuste los controles en lugar de su intuición.
El pipeline que describimos no es teórico. Puede leer el artículo original aquí, y si desea discutir la ingeniería de recuperación con una comunidad que se preocupa por estos temas, el grupo de GyaanSetu AI está abierto.