Habr AI mostró cómo crear tu propio RAG retriever en LangChain para nombres y términos

Habr AI publicó una guía práctica para ingenieros de RAG que no obtienen la precisión requerida en búsquedas vectoriales estándar en nombres, títulos y términos raros. El artículo muestra cómo construir un recuperador TF-IDF personalizado, integrarlo en LangChain y probarlo contra soluciones típicas en un benchmark.

Dónde fallan los embeddings

La idea principal del artículo es simple: no toda tarea de búsqueda necesita resolverse con el mismo esquema vectorial. Los embeddings funcionan bien en preguntas generales, pero a menudo fracasan con entidades nombradas. Para RAG esto es particularmente doloroso, porque el modelo puede formular una respuesta con confianza mientras se basa en contexto incorrecto. El error no ocurre en la etapa de generación, sino antes — cuando el sistema recupera el fragmento equivocado del documento.

El punto débil de la búsqueda estándar aparece donde las diferencias literales importan. Los nombres de personas, nombres de productos, empresas, sistemas internos, abreviaciones técnicas y términos raros pueden ser demasiado similares en contexto semántico pero críticamente diferentes en una tarea práctica. Si tales entidades están mal separadas en el espacio de embeddings, la calidad de los resultados cae incluso con una buena capa LLM. Entonces la idea de un recuperador personalizado aquí no parece un adorno para el stack, sino una forma de cerrar una clase específica de errores.

"Y para eso tengo mi propio recuperador."

Esquema del recuperador personalizado

La parte práctica comienza con la capa más comprensible — preparación de datos. Los documentos deben dividirse en fragmentos o chunks, para que la búsqueda devuelva no todo el texto, sino una pieza específica relevante. Después de esto, se construye una representación TF-IDF para el conjunto de chunks. Ayuda a clasificar fragmentos por importancia de palabras y encontrar coincidencias más rápidamente donde la precisión literal importa más que la similitud semántica. Luego, encima del índice, se agrega lógica de búsqueda personalizada y todo esto se empaqueta en una interfaz LangChain. En el artículo, este pipeline se ve maximalmente práctico:

• el corpus se limpia y se lleva a forma operativa
• los documentos se dividen en chunks para devolución precisa de contexto
• un modelo TF-IDF se construye a partir de los chunks
• los resultados de búsqueda se envuelven en un recuperador personalizado para LangChain
• las preguntas de prueba se preparan por separado para comparación con opciones estándar

La fortaleza de este enfoque es la previsibilidad. El ingeniero entiende mejor por qué el sistema seleccionó tal o cual fragmento, y puede depurar los resultados sin infraestructura compleja alrededor de una base de datos vectorial. Además, tal recuperador es más barato de operar y más rápido de configurar para experimentos locales. Esto no es un reemplazo universal para soluciones modernas, pero una buena herramienta para dominios donde importan las coincidencias exactas de entidades y formulaciones, no el "significado similar."

Cómo se validan los resultados

Se pone un énfasis separado en la comparación, no solo en el ensamblaje. Después de crear un recuperador personalizado, el autor propone ejecutarlo contra dos o tres soluciones estándar y observar la calidad y velocidad de los resultados. Este paso es importante porque una implementación personalizada puede fácilmente parecer mejor en algunos ejemplos manuales pero perder en un conjunto más amplio de consultas. El benchmark aquí actúa como un filtro contra el autoengaño y ayuda a entender exactamente dónde la búsqueda especializada proporciona ganancias reales.

Para la preparación de preguntas, el artículo usa Ollama. Esta es una forma conveniente de ensamblar rápidamente un conjunto de prueba para su corpus sin vincularse a una API externa y sin gastar tiempo en marcado completamente manual. Como resultado, el material demuestra un enfoque de ingeniería maduro: primero identifique un error típico, luego seleccione un mecanismo de búsqueda más apropiado para él, y solo después compare resultados en un conjunto controlado de consultas. Para equipos que construyen servicios RAG internos, tal disciplina usualmente es más importante que promesas sonoras sobre un stack "mágico."

Qué significa esto

El análisis de Habr AI muestra un cambio en la madurez de la práctica RAG: el mercado se aleja de la creencia en un recuperador universal hacia un ajuste más estrecho de la búsqueda a los datos y tipos de error. Para equipos con bases de conocimiento, catálogos, textos legales o directorios internos esta es una buena señal: a veces una ganancia notable en calidad proviene no de un nuevo modelo, sino de una capa de búsqueda adecuadamente construida.