¿Qué es un Point? Un point en Qdrant es la entidad básica de almacenamiento que contiene:

• ID único: Identificador del punto (puede ser entero o UUID)
• Vectors: Uno o más embeddings (vectores numéricos)
• Payload: Metadatos opcionales en formato JSON

Relación con Embeddings: Los embeddings NO se generan en Qdrant. Se generan externamente usando modelos como:

• OpenAI embeddings (text-embedding-ada-002, text-embedding-3-small)
• Sentence Transformers (all-MiniLM-L6-v2, multilingual-e5)
• Modelos propios

Qdrant solo almacena y busca estos embeddings. La calidad de la búsqueda depende completamente del modelo de embedding utilizado.

2. Parent Chunks vs Child Chunks

Patrón de RAG Avanzado: Este es un patrón de arquitectura que se orquesta fuera de Qdrant, típicamente usando frameworks como LangChain:

Child Chunks:

• Fragmentos pequeños del documento original (ej: párrafos de 200-500 tokens)
• Se convierten en embeddings y se almacenan como points individuales en Qdrant
• Payload contiene el texto del fragmento + metadatos

Parent Chunks:

• Unidades más grandes que agrupan varios child chunks (ej: secciones completas)
• Pueden o no almacenarse como embeddings separados
• Su función principal es proporcionar contexto ampliado durante la generación

Ejemplo de Payload para Child Chunk:

{
  "text": "Qdrant supports multiple vectors per point...",
  "document_id": "doc_123",
  "parent_chunk_id": "parent_456",
  "chunk_index": 3,
  "total_chunks": 10,
  "source": "documentation.pdf"
}

3. Record Manager

RAG_REFERENCES:

• (RAG: standard-rag-pattern) Patrón descrito en arquitecturas RAG — «El Record Manager es un componente externo que rastrea las relaciones entre documentos originales, parent chunks y child chunks.»

¿Qué es? El Record Manager es un componente de orquestación que:

• NO es parte de Qdrant
• Gestiona relaciones jerárquicas entre documentos
• Mantiene el mapeo: Documento → Parent Chunks → Child Chunks
• Usualmente implementado con bases de datos relacionales (SQLite, PostgreSQL)

Funciones principales:

1. Versionado: Rastrea qué versiones de documentos están indexadas
2. Deduplicación: Evita re-indexar contenido no modificado
3. Relaciones: Mantiene referencias entre puntos en Qdrant

Ejemplo de esquema de Record Manager:

-- Tabla de documentos
documents (id, source, hash, last_updated)

-- Tabla de parent chunks  
parent_chunks (id, document_id, content, metadata)

-- Tabla de child chunks
child_chunks (id, parent_id, qdrant_point_id, content_hash)

4. MultivectorRetriever

RAG_REFERENCES:

• (RAG: storing-multiple-vectors) Storing multiple vectors per object in Qdrant — «Storing several vectors per object in a single collection avoids having to create multiple collections and reuses the payload.»

Dos enfoques complementarios:

1. MultivectorRetriever (Patrón LangChain):

• Genera múltiples embeddings para el mismo documento
• Usa diferentes modelos o preguntas hipotéticas
• Puede almacenarlos como points separados en Qdrant

2. Múltiples Vectores por Point (Nativo Qdrant):

• Característica nativa de Qdrant
• Un solo point puede contener múltiples vectores con nombres diferentes
• Ideal para:
  • Modelos ColBERT: Un documento representado por muchos vectores
  • Búsqueda híbrida: Embeddings densos + dispersos en el mismo point
  • Embeddings Matryoshka: Diferentes dimensiones del mismo contenido

Ejemplo de creación de colección con múltiples vectores:

from qdrant_client import QdrantClient
from qdrant_client.http import models

client = QdrantClient("localhost", port=6333)

client.create_collection(
    collection_name="multivector_collection",
    vectors_config={
        "dense_vector": models.VectorParams(
            size=768,
            distance=models.Distance.COSINE
        ),
        "sparse_vector": models.SparseVectorParams(
            index=models.SparseIndexParams()
        )
    }
)

5. Relación Completa: Flujo de Trabajo

SCHEMA_PLAN:

Documento Original
    ↓ (chunking)
Parent Chunks (secciones grandes)
    ↓ (sub-chunking)  
Child Chunks (fragmentos pequeños)
    ↓ (embedding)
Embeddings (vectores)
    ↓ (almacenamiento)
Points en Qdrant (con payloads)
    ↑ (gestión de relaciones)
Record Manager (SQL database)

Flujo de Indexación:

1. Documento → Parent Chunks → Child Chunks (procesamiento externo)
2. Child Chunks → Embeddings (modelos externos)
3. Embeddings → Points en Qdrant (almacenamiento vectorial)
4. Relaciones → Record Manager (gestión de metadatos)

Flujo de Búsqueda:

1. Consulta → Embedding → Búsqueda en Qdrant
2. Recuperar child chunks más relevantes
3. Usar Record Manager para encontrar parent chunks asociados
4. Proporcionar contexto ampliado al LLM

6. Ventajas del Enfoque Integrado

INDEX_PLAN:

collection_name: "document_chunks"
vectors_config:
  dense_embedding:
    size: 384
    distance: Cosine
  sparse_embedding:
    type: SparseVector
    index: SparseIndex
payload_schema:
  - name: text
    type: text
  - name: document_id
    type: keyword  
  - name: parent_id
    type: keyword
  - name: chunk_type
    type: keyword
  - name: metadata
    type: json
optimization:
  quantization: Scalar
  hnsw_ef: 128

7. Referencias y Enlaces Oficiales

Documentación Qdrant:

• Multiple Vectors per Point
• Hybrid Search with Prefetch API
• Vector Quantization

Patrones RAG (fuentes externas):

• LangChain Parent Document Retriever
• LangChain Multi Vector Retriever

CONFIG_SNIPPET para Parent-Child RAG:

# Ejemplo simplificado de integración
from langchain.vectorstores import Qdrant
from langchain.retrievers import ParentDocumentRetriever
from langchain.storage import SQLRecordManager

# 1. Record Manager para relaciones
record_manager = SQLRecordManager(
    namespace="documents",
    db_url="sqlite:///record_manager.db"
)

# 2. Vector store para child chunks
vectorstore = Qdrant(
    client=qdrant_client,
    collection_name="child_chunks",
    embeddings=embedding_model
)

# 3. Retriever integrado
retriever = ParentDocumentRetriever(
    vectorstore=vectorstore,
    docstore=document_store,
    record_manager=record_manager,
    child_splitter=child_splitter,
    parent_splitter=parent_splitter
)

RESULT_PREVIEW:

Búsqueda típica:
1. Query: "¿Qué es multiple vectors per point?"
2. Embedding de la consulta
3. Búsqueda en Qdrant → top 5 child chunks
4. Record Manager → parent chunks asociados
5. Contexto final: parent chunks + child chunks relevantes
6. Respuesta LLM con contexto ampliado

Conclusión: Los points son el contenedor fundamental en Qdrant que almacena embeddings generados externamente. Las relaciones parent-child y la gestión del Record Manager son patrones de aplicación que utilizan Qdrant como almacén vectorial, mientras que el MultivectorRetriever aprovecha la capacidad nativa de Qdrant para múltiples vectores por point, optimizando la recuperación semántica en sistemas RAG avanzados.

RAG_REFERENCES:

• (RAG: multiple-vectors-per-point) Support for multiple vectors per point — «Qdrant supports storing multiple vectors per point. This is useful for models like ColBERT, where each document is represented by multiple vectors.»
• (RAG: hybrid-search) Creando un sistema de búsqueda híbrido en Qdrant — «Qdrant’s Prefetch API allows building complex search pipelines that can use multiple vectors stored in points for prefetch and reranking.»

generado con

Modelo del agente Qdrant: arquitectura, propósito y funcionamiento