{"id":125,"date":"2026-03-08T23:10:50","date_gmt":"2026-03-08T23:10:50","guid":{"rendered":"https:\/\/blog.rebalai.com\/es\/2026\/03\/08\/rag-profundo-estrategias-de-chunking-bases-de-dato\/"},"modified":"2026-03-18T22:00:22","modified_gmt":"2026-03-18T22:00:22","slug":"rag-profundo-estrategias-de-chunking-bases-de-dato","status":"publish","type":"post","link":"https:\/\/blog.rebalai.com\/es\/2026\/03\/08\/rag-profundo-estrategias-de-chunking-bases-de-dato\/","title":{"rendered":"RAG Profundo: Estrategias de Chunking, Bases de Datos Vectoriales y Optimizaci\u00f3n"},"content":{"rendered":"

Hace unos meses, un cliente me pidi\u00f3 construir un sistema de b\u00fasqueda sobre 40.000 documentos legales \u2014 contratos, acuerdos de confidencialidad, t\u00e9rminos de servicio. La primera versi\u00f3n que entregu\u00e9 era un desastre. Los usuarios hac\u00edan preguntas perfectamente razonables y el sistema les devolv\u00eda fragmentos de texto que no ten\u00edan ninguna relaci\u00f3n con lo que<\/a> ped\u00edan. Un abogado me escribi\u00f3 literalmente: “Esto es<\/a> peor que Ctrl+F.”<\/p>\n

Ten\u00eda raz\u00f3n.<\/p>\n

El problema no era el modelo. Era todo lo anterior al modelo: c\u00f3mo divid\u00eda los documentos, qu\u00e9 base de datos<\/a> vectorial usaba, y c\u00f3mo recuperaba la informaci\u00f3n. Pas\u00e9 las siguientes dos semanas<\/a> desmontando el pipeline completo y reconstruy\u00e9ndolo con criterio. Lo que<\/a> comparto aqu\u00ed es producto de ese proceso \u2014 incluyendo los errores que comet\u00ed y que t\u00fa puedes evitar.<\/p>\n

\n

Por qu\u00e9 el chunking de 512 tokens es una trampa<\/h2>\n

Cuando empec\u00e9 con RAG, hice lo que<\/a> hace todo el mundo: dividir documentos en chunks de tama\u00f1o fijo, t\u00edpicamente 512 tokens con un overlap de 50-100 tokens. Es la configuraci\u00f3n por defecto en casi todos los tutoriales. Y funciona… m\u00e1s o menos, para casos simples.<\/p>\n

El problema surge cuando los documentos tienen estructura real. Un contrato legal tiene cl\u00e1usulas, y una cl\u00e1usula puede durar tres p\u00e1rrafos. Con chunking de tama\u00f1o fijo, puedes cortar una cl\u00e1usula a la mitad, y ahora tienes dos fragmentos que por separado no tienen sentido completo. Cuando el sistema recupera uno de esos fragmentos, el modelo trabaja con informaci\u00f3n incompleta.<\/p>\n

Lo que me tom\u00f3 tiempo entender es que el chunking no es un problema de ingenier\u00eda de software \u2014 es un problema sem\u00e1ntico. La pregunta correcta no es “\u00bfcu\u00e1ntos tokens?” sino “\u00bfqu\u00e9 unidad de informaci\u00f3n tiene sentido<\/a> como respuesta aislada?”.<\/p>\n

Para documentos legales, la respuesta era: la cl\u00e1usula completa. Para c\u00f3digo fuente, la funci\u00f3n. Para art\u00edculos t\u00e9cnicos, el p\u00e1rrafo o la subsecci\u00f3n.<\/p>\n

\n

Tres estrategias de chunking que realmente<\/a> prob\u00e9<\/h2>\n

Chunking recursivo<\/strong> fue mi primer salto desde tama\u00f1o fijo, y fue una mejora inmediata. LangChain tiene una implementaci\u00f3n en RecursiveCharacterTextSplitter<\/code> que intenta dividir por p\u00e1rrafos primero, luego por oraciones, luego por palabras. Funciona bien para texto en prosa pero sigue siendo ciego a la sem\u00e1ntica.<\/p>\n

Chunking sem\u00e1ntico<\/strong> fue donde las cosas se pusieron interesantes. La idea: usar embeddings para medir la similitud entre oraciones consecutivas, y cuando la similitud cae por debajo de un umbral, ah\u00ed va el corte. Esto captura cambios de tema de forma natural.<\/p>\n

from langchain_experimental.text_splitter import SemanticChunker\nfrom langchain_openai import OpenAIEmbeddings\n\n# SemanticChunker de LangChain 0.3 \u2014 necesita langchain-experimental\nembeddings = OpenAIEmbeddings(model="text-embedding-3-small")\n\nchunker = SemanticChunker(\n    embeddings,\n    breakpoint_threshold_type="percentile",  # o "standard_deviation"\n    breakpoint_threshold_amount=85,  # corta cuando la disimilitud supera el percentil 85\n)\n\nchunks = chunker.create_documents([texto_del_contrato])\n# En mis pruebas: chunks m\u00e1s grandes pero m\u00e1s coherentes sem\u00e1nticamente\n# Desventaja: es lento \u2014 procesa todos los embeddings antes de cortar\n<\/code><\/pre>\n
Los chunks eran m\u00e1s grandes (300-800 tokens en promedio, vs. los 512 fijos) pero capturaban ideas completas. La recuperaci\u00f3n mejor\u00f3 de forma visible \u2014 no fue dram\u00e1tico al instante, pero s\u00ed consistente en las pruebas.<\/p>\n
Parent-document retrieval<\/strong> fue la t\u00e9cnica que m\u00e1s me sorprendi\u00f3. La idea es indexar chunks peque\u00f1os para la b\u00fasqueda (mejor precisi\u00f3n sem\u00e1ntica), pero recuperar el chunk “padre” m\u00e1s grande cuando encuentras un match. Es como tener dos granularidades simult\u00e1neamente.<\/p>\n
Lo implement\u00e9 con el ParentDocumentRetriever<\/code> de LangChain, guardando los documentos completos en un InMemoryStore<\/code> (o Redis para producci\u00f3n<\/a>). El resultado: recuperaci\u00f3n precisa sin perder contexto. Es mi configuraci\u00f3n favorita para documentos largos con estructura jer\u00e1rquica.<\/p>\n
Un error que comet\u00ed: olvid\u00e9 que los chunks peque\u00f1os para indexar deben ser lo suficientemente peque\u00f1os (50-100 tokens) para que el embedding capture una idea espec\u00edfica. Si son demasiado grandes, pierdes la ventaja de la precisi\u00f3n.<\/p>\n
\n
Bases de datos vectoriales<\/a>: mi opini\u00f3n honesta despu\u00e9s de<\/a> probar cinco<\/h2>\n
Aqu\u00ed es donde tengo opiniones fuertes, as\u00ed que voy directo.<\/p>\n
Chroma<\/strong> es excelente para prototipos. La configuraci\u00f3n toma cinco minutos, funciona en memoria o en disco, y tiene buena integraci\u00f3n con LangChain. Pero en cuanto quise hacer b\u00fasqueda h\u00edbrida (vectorial + keyword) o filtros complejos por metadata, empec\u00e9 a sentir las limitaciones. No lo usar\u00eda para producci\u00f3n<\/a> con m\u00e1s de un mill\u00f3n de documentos.<\/p>\n
Pinecone<\/strong> es el que m\u00e1s aparece en demos de Y Combinator. Lo us\u00e9 en la primera versi\u00f3n del proyecto legal y, honestamente, me decepcion\u00f3 un poco la migraci\u00f3n a su v3 API \u2014 cambi\u00f3 bastante y la documentaci\u00f3n tard\u00f3 en actualizarse. El managed service es conveniente, pero el pricing escala r\u00e1pido y el vendor lock-in es real.<\/p>\n
Weaviate<\/strong> tiene cosas interesantes \u2014 BM25 integrado, soporte para m\u00faltiples vectores por objeto \u2014 pero me pareci\u00f3 m\u00e1s complejo de configurar de lo que<\/a> el problema requer\u00eda. No lo descart\u00e9 por malo sino por innecesariamente dif\u00edcil para lo que<\/a> necesitaba.<\/p>\n
pgvector<\/strong> \u2014 opini\u00f3n impopular: para muchos casos de uso, pgvector en PostgreSQL es suficiente y mucho m\u00e1s simple operacionalmente. Si ya tienes Postgres, a\u00f1adir pgvector es trivial. La b\u00fasqueda vectorial es m\u00e1s lenta que soluciones dedicadas a escala, pero para menos de 500k vectores con \u00edndices HNSW, funciona perfectamente bien. El hecho de que puedas hacer JOINs con tu data relacional es una ventaja real que las soluciones dedicadas no pueden igualar.<\/p>\n
Qdrant<\/strong> fue la sorpresa agradable. Es open source, tiene una API<\/a> limpia, soporta b\u00fasqueda h\u00edbrida con sparse vectors (SPLADE) de forma nativa, filtros por payload muy eficientes, y puedes correrlo en Docker sin fricci\u00f3n. Termin\u00e9 migrando el proyecto legal a Qdrant y no me arrepiento. La colecci\u00f3n de 40k documentos (con embeddings de 1536 dimensiones) ocupa unos 2GB en disco y las queries retornan en ~30ms.<\/p>\n
from qdrant_client import QdrantClient\nfrom qdrant_client.models import Distance, VectorParams, PointStruct\nimport uuid\n\nclient = QdrantClient("localhost", port=6333)\n\n# Crear colecci\u00f3n con HNSW\nclient.create_collection(\n    collection_name="contratos",\n    vectors_config=VectorParams(size=1536, distance=Distance.COSINE),\n    # HNSW: m=16 es el default, ef_construct=100 mejora recall a costa de tiempo de indexado\n    hnsw_config={"m": 16, "ef_construct": 100},\n)\n\n# Insertar con metadata \u2014 los filtros por payload son muy eficientes en Qdrant\nclient.upsert(\n    collection_name="contratos",\n    points=[\n        PointStruct(\n            id=str(uuid.uuid4()),\n            vector=embedding,\n            payload={\n                "texto": chunk_texto,\n                "cliente": "Empresa ABC",\n                "tipo_doc": "NDA",\n                "fecha": "2025-11-01",\n            },\n        )\n        for chunk_texto, embedding in zip(chunks, embeddings)\n    ],\n)\n<\/code><\/pre>\n
\n
Reranking: el paso que la mayor\u00eda omite (y por qu\u00e9<\/a> es un error)<\/h2>\n
Aqu\u00ed comet\u00ed mi error m\u00e1s costoso en t\u00e9rminos de tiempo. Ten\u00eda un retriever que devolv\u00eda los 5 chunks m\u00e1s similares sem\u00e1nticamente, y asum\u00ed que “m\u00e1s similar seg\u00fan embeddings” equival\u00eda a “m\u00e1s relevante para la pregunta”. No es lo<\/a> mismo.<\/p>\n
Los embeddings capturan similitud sem\u00e1ntica general, pero son malos para capturar relevancia espec\u00edfica a una consulta. Un chunk sobre “penalidades contractuales” puede tener alta similitud coseno con una pregunta sobre “consecuencias por incumplimiento”, pero un chunk diferente puede ser m\u00e1s preciso para esa pregunta en particular.<\/p>\n
La soluci\u00f3n es reranking: recuperar m\u00e1s candidatos (digamos, top-20) y luego usar un modelo cross-encoder m\u00e1s potente para re-ordenarlos.<\/p>\n
Prob\u00e9 dos opciones:<\/p>\n
Cohere Rerank<\/strong> (API externa) \u2014 f\u00e1cil de integrar, resultados excelentes. Precio razonable para volumen moderado. Si no quieres gestionar infraestructura<\/a>, esta es la opci\u00f3n m\u00e1s r\u00e1pida.<\/p>\n
cross-encoder\/ms-marco-MiniLM-L-6-v2<\/strong> (local, de HuggingFace) \u2014 m\u00e1s lento pero gratuito y privado. Para el caso de documentos legales, donde el cliente no quer\u00eda datos saliendo a APIs externas, fue la elecci\u00f3n obvia.<\/p>\n
from sentence_transformers import CrossEncoder\n\nreranker = CrossEncoder("cross-encoder\/ms-marco-MiniLM-L-6-v2")\n\ndef recuperar_con_reranking(query: str, retriever, top_k: int = 5) -> list:\n    # Paso 1: recuperar m\u00e1s candidatos de los que necesitamos\n    candidatos = retriever.get_relevant_documents(query, k=20)\n\n    # Paso 2: crear pares (query, documento) para el cross-encoder\n    pares = [(query, doc.page_content) for doc in candidatos]\n\n    # Paso 3: reranking \u2014 devuelve scores, no indices\n    scores = reranker.predict(pares)\n\n    # Paso 4: ordenar por score y retornar top_k\n    candidatos_con_score = sorted(\n        zip(candidatos, scores),\n        key=lambda x: x[1],\n        reverse=True\n    )\n\n    return [doc for doc, _ in candidatos_con_score[:top_k]]\n<\/code><\/pre>\n
Cuando mostr\u00e9 los resultados al cliente legal, la diferencia era obvia. Pasamos de “respuestas vagamente relacionadas” a “respuestas que citan la cl\u00e1usula exacta”. El overhead de latencia del cross-encoder local es de ~200-400ms, que para una aplicaci\u00f3n de b\u00fasqueda legal es perfectamente aceptable.<\/p>\n
Lo otro que mejor\u00f3 bastante: la b\u00fasqueda h\u00edbrida (vectorial + BM25 keyword search). Para t\u00e9rminos legales muy espec\u00edficos \u2014 nombres de cl\u00e1usulas, art\u00edculos, referencias cruzadas \u2014 la b\u00fasqueda vectorial sola falla porque los embeddings tienden a capturar significado general. BM25 es mejor para coincidencias exactas de t\u00e9rminos raros. Combinar ambas con un peso ajustable fue la diferencia entre 70% y 88% de precisi\u00f3n en nuestro conjunto de evaluaci\u00f3n \u2014 en Qdrant esto se implementa con sparse vectors.<\/p>\n
\n
Lo que yo usar\u00eda hoy<\/h2>\n
No voy a darte “depende de tu caso de uso” porque eso no ayuda a nadie. Voy a decirte lo que<\/a> yo montar\u00eda si empezara un proyecto RAG ma\u00f1ana:<\/p>\n
Para el chunking<\/strong>: Parent-document retrieval con chunks peque\u00f1os (100 tokens) para indexar y recuperar el chunk padre (300-500 tokens) para el contexto. Si el documento tiene estructura clara \u2014 secciones, cl\u00e1usulas, funciones de c\u00f3digo<\/a> \u2014 extr\u00e1ela expl\u00edcitamente en lugar de cortar ciegamente.<\/p>\n
Para la base de datos<\/a> vectorial<\/strong>: Qdrant si necesitas control, features avanzadas y no quieres pagar por managed services. pgvector si ya tienes Postgres y el volumen es manejable. No elegir\u00eda Pinecone a menos que el cliente tenga una raz\u00f3n operacional espec\u00edfica para managed cloud.<\/p>\n
Para la recuperaci\u00f3n<\/strong>: siempre reranking. El costo computacional es m\u00ednimo comparado con la mejora en calidad. Si el presupuesto lo permite, Cohere Rerank. Si no, ms-marco-MiniLM<\/code> local funciona bien. Y a\u00f1adir BM25 h\u00edbrido para dominios con terminolog\u00eda especializada \u2014 derecho, medicina, c\u00f3digo fuente.<\/p>\n
Una cosa que no cubro en profundidad aqu\u00ed pero que merece una nota: la evaluaci\u00f3n. No sabr\u00e1s si tu pipeline mejor\u00f3 sin m\u00e9tricas. RAGAS es una librer\u00eda razonable para evaluar RAG sin anotaciones manuales, usando el propio LLM para juzgar relevancia y faithfulness. No es perfecta \u2014 sus m\u00e9tricas no siempre escalan bien en dominios muy espec\u00edficos \u2014 pero es mejor que confiar solo en la intuici\u00f3n.<\/p>\n
El abogado que me dijo que mi sistema era peor que Ctrl+F me escribi\u00f3 tres semanas despu\u00e9s: “Ahora encuentro en 10 segundos lo que<\/a> antes me llevaba una hora.” Eso no fue magia \u2014 fue chunking correcto, Qdrant, y un cross-encoder de 22MB corriendo en una<\/a> instancia EC2 modesta.<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Hace unos meses, un cliente me pidi\u00f3 construir un sistema de b\u00fasqueda sobre 40.000 documentos legales \u2014 contratos, acuerdos de confidencialidad, t\u00e9rminos d<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[1],"tags":[],"class_list":["post-125","post","type-post","status-publish","format-standard","hentry","category-general"],"_links":{"self":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/125","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/comments?post=125"}],"version-history":[{"count":15,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/125\/revisions"}],"predecessor-version":[{"id":547,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/125\/revisions\/547"}],"wp:attachment":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/media?parent=125"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/categories?post=125"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/tags?post=125"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}