Datos-Llm on lo0 — Blog Técnico

Data versioning para LLMOps: DVC, lakeFS y el reto del golden dataset reproducible

Fri, 22 May 2026 11:00:00 +0200

TL;DR

La etapa Data del pipeline LLMOps de seis etapas tiene un eslabón silencioso del que depende todo lo demás: versionar los datasets con la misma disciplina que se versiona el código. No es opcional. Un sistema LLM en producción consume al menos cuatro tipos de dataset diferenciados —training/fine-tuning, corpus RAG, golden eval set, dataset enriquecido del bucle Retrain— y cada uno tiene exigencias propias. Git resuelve el código pero falla en datos por dos razones técnicas (tamaño y diff binario inútil) y una operativa (no propaga lineage hasta el bucket de pesos del modelo entrenado). Las dos herramientas OSS dominantes —DVC y lakeFS— se unificaron en noviembre de 2025 bajo una sola organización con hoja de ruta orientada a LLM training y RAG datalakes; siguen siendo proyectos complementarios (file-level vs branching de bucket completo) pero ya bajo gobierno común. El patrón productivo que el mercado ha consolidado: identificar cada artefacto con (dataset_id, version) inmutable, propagar el par hasta el experiment tracking (MLflow / W&B), versionar también el schema del dataset (no solo el contenido), aplicar holdout estricto al golden eval set para no medir memorización, y mantener trazabilidad bidireccional dataset_version ↔ model_version ↔ deployment ↔ trace_id. Sin esto, la promesa de “podemos auditar qué modelo respondió qué” se cae en el primer incidente serio.

Estás aquí: Data (con efecto transversal sobre Tune, Eval y Retrain)

Este post entra al detalle del eslabón de versionado dentro de la etapa 1 · Data. El versionado pertenece operativamente a Data, pero los artefactos que produce viajan a Tune (training set), Eval (golden set) y Retrain (dataset enriquecido). Por eso el diagrama marca Data como activa y una banda transversal indicando el lineage end-to-end.

La analogía maestra: trazabilidad de lote en una fábrica seria

Una fábrica farmacéutica seria no produce sin trazabilidad de lote. Cada caja de pastillas lleva un número de lote impreso; ese lote se asocia a fechas de fabricación, a los lotes concretos de cada materia prima que se usó, a las pruebas de calidad que pasó, y a los técnicos que firmaron cada paso. Si un paciente reporta un efecto adverso, la fábrica puede rebobinar en horas: este envase → este lote → estas materias primas → este turno → esta línea de producción → este resultado de control de calidad. Sin esa cadena, el incidente es un misterio permanente.

Un sistema LLM serio funciona igual. El “envase” es la respuesta que un usuario vio en producción. El “lote” es la combinación de modelo, adapter, prompt, contexto y configuración que la generó. Y las “materias primas” son los datasets: el training set sobre el que se entrenó el modelo base, el dataset del fine-tuning del adapter, el corpus RAG que alimenta el retrieval, el golden eval set que valida la promotion. Si un cliente dice "¿con qué datos se entrenó el modelo que el 14 de marzo respondió X a mi pregunta Y?", sin trazabilidad de lote la respuesta es “no lo sabemos”. Y eso, en un cliente con compliance encima, mata el contrato.

Git versiona la receta (el código). Data versioning versiona los ingredientes. Sin las dos cosas, no hay fábrica auditable.

Los cuatro artefactos que conviene versionar (con exigencias diferenciadas)

No todos los datasets se versionan igual ni con la misma frecuencia. El sistema LLM en producción típico maneja cuatro artefactos que conviene gobernar por separado.

Artefacto	Qué es	Tamaño típico	Frecuencia de versión nueva	Quién la consume
Training / fine-tuning dataset	Pares input/output (o conversaciones) que entrenan el adapter o el modelo.	10⁴ – 10⁷ ejemplos · 1 – 100 GB	Por experimento de Tune	Trainer (Axolotl, TRL, Unsloth)
RAG corpus	Documentos indexados que alimentan retrieval.	10⁵ – 10⁹ chunks · 10 GB – 10 TB	Casi continuo (ingest streaming)	Indexer + vector store
Golden eval set	Ejemplos curados con respuesta esperada para medir calidad.	10² – 10⁴ ejemplos · MB	Por release del producto	Eval gates en CI
Enriched retrain dataset	Casos donde el sistema falló + corrección humana.	Cientos a miles por trimestre	Por ciclo de retrain	Siguiente Tune

Los cuatro tienen requisitos comunes (identidad inmutable, lineage, schema) y diferencias relevantes:

El training set suele ser grande, estable por experimento, y el coste de un error es un experimento perdido (caro pero acotado).
El RAG corpus es enorme, en continuo cambio, y el versionado se gestiona por snapshots periódicos del índice (no del raw text). Usualmente lakeFS o branches del bucket; DVC no es la mejor encaja.
El golden eval set es pequeño pero crítico: errores aquí contaminan toda la cadena de promotion. Aquí la rigidez del versionado importa más que en ningún otro.
El enriched retrain dataset es incremental por naturaleza: cada ciclo de Retrain aporta un delta sobre el anterior. La versión nueva no sobrescribe; hereda y añade.

Confundirlos —tratar el RAG corpus como si fuera el training set, o el golden eval como si fuera un dataset más— es el origen de la mitad de los problemas operacionales en data versioning.

Por qué Git no basta

La pregunta evidente: si Git ya resuelve el código, ¿por qué no resuelve también los datos? Tres razones, dos técnicas y una operacional.

Razón 1: tamaño. Un repositorio Git con un dataset de 50 GB se vuelve inmanejable. git clone baja todo el histórico; git status recorre todos los archivos; el pack file en .git/objects infla hasta el doble del dataset. Git LFS resuelve la primera parte (el binario sale del pack) pero introduce su propia complejidad sin abordar las otras dos razones.

Razón 2: diff binario inútil. Git asume que los diffs de texto son útiles. Cuando cambia una columna en un parquet de 8 GB, el diff es opaco —el archivo es binario, comprimido, columnar—. No puedes hacer code review sobre un cambio de dataset igual que sobre un cambio de función. Necesitas diff semántico: cuántas filas cambiaron, qué columnas cambiaron, qué distribución se movió. Ningún Git nativo te da eso.

Razón 3: lineage que cruza fronteras de repositorio. Esta es la más importante y la más sutil. El dataset de training vive en un bucket. El código del trainer vive en un repo Git. El modelo entrenado se publica a un model registry. La inferencia en producción genera traces en un sistema de observability. Conectar dataset_v3 → adapter_v7 → deployment_d2 → trace t_x9 requiere propagar identificadores a través de cuatro sistemas distintos, no dentro de un repo. Git no tiene opinión sobre esto.

Las herramientas de data versioning (DVC, lakeFS, Pachyderm, Quilt) existen porque resuelven los tres problemas a la vez: cuelgan los datos fuera del repo Git, ofrecen alguna forma de diff semántico, y exponen identidades estables propagables hacia experiment tracking y model registry.

DVC vs lakeFS antes de la unificación

Hasta noviembre de 2025, las dos herramientas dominantes OSS coexistían como aproximaciones complementarias.

Eje	DVC	lakeFS
Modelo mental	“Git para datos”	“Branching para el data lake”
Granularidad	Archivo individual	Bucket entero (con namespacing por branch)
Storage	Remote-agnóstico (S3, GCS, Azure, MinIO, SSH)	S3-compatible (S3, MinIO, Ceph)
Workflow	`dvc add` + `dvc push` + `dvc.yaml` pipelines	`lakectl commit` + branches/merges sobre el bucket
Diff	Hash del archivo + metadata externa	Diff a nivel de objeto + commit log
Casos fuertes	Training datasets discretos, model files, pipelines reproducibles	RAG corpora grandes, branching de un data lake compartido, experimentos en paralelo sin duplicar datos
Integración con Git	Profunda (los `.dvc` files se commitean a Git)	Tangencial (lakeFS vive en paralelo)
Quién lo opera	Equipo MLE	Equipo data engineering

En la práctica, muchos equipos los usaban a la vez: DVC para los datasets discretos que alimentaban un experimento (cabe en un repo Git por la indirección de los .dvc pointers), y lakeFS para el bucket grande del corpus RAG sobre el que querían branching sin duplicar terabytes.

Qué cambió con la adquisición de noviembre 2025

lakeFS adquirió DVC en noviembre de 2025. La consecuencia operacional a mayo de 2026 es modesta pero relevante:

No hay (todavía) fusión técnica de los proyectos. DVC sigue siendo DVC y lakeFS sigue siendo lakeFS. Las CLIs, los formatos y los workflows actuales no han cambiado.
Hoja de ruta combinada explícita hacia LLM training y RAG datalakes. La organización fusionada ha enunciado prioridades específicas: branching consistente entre el dataset y el modelo entrenado, integraciones nativas con MLflow / W&B / Langfuse, soporte para los formatos típicos de LLM (jsonl, parquet con tokenización embebida), e indexación vectorial branch-aware.
Convergencia esperada en 2026-2027. El mercado anticipa un único registry con dos modos operativos (file-level + bucket-branching) bajo CLI unificada. A día de hoy, los equipos siguen combinando ambos.

La lectura práctica para 2026: adopta DVC para training/eval datasets discretos y lakeFS para el RAG corpus, pero diseña el lineage para que un futuro registry unificado pueda absorber ambos sin re-versionar todo. En concreto: usa identificadores estables (dataset_id, version, commit_hash) que sean propagables independientemente de la herramienta.

El patrón operativo: lineage de cuatro saltos

Una vez aceptado que hay que versionar datasets, la pregunta no es “qué herramienta” sino “qué cadena de identificadores conecta producción con el dato origen”. El patrón que ha consolidado el mercado tiene cuatro saltos:

(dataset_id, dataset_version)
│ versiona en DVC o lakeFS
▼
(model_id, model_version)
│ registra en MLflow / W&B con dataset como input
▼
(deployment_id, prompt_version)
│ registra en model registry + prompt registry
▼
(trace_id)
│ emite el motor de inferencia con OTel
▼
respuesta visible al usuario

Cada flecha es un escritura de metadata que cruza el límite entre dos sistemas. Si una sola flecha falta, el lineage se rompe y la promesa de auditabilidad se evapora.

Ejemplo concreto del flujo, usando DVC + MLflow:

# Etapa Data: versionar el dataset
dvc add data/finetune_v3.jsonl
git add data/finetune_v3.jsonl.dvc data/.gitignore
git commit -m "data: finetune dataset v3"
dvc push # sube el binario al remote (MinIO/S3)

# Etapa Tune: entrenar registrando lineage
mlflow run train.py \
 -P dataset_id=finetune \
 -P dataset_version=v3 \
 -P dataset_hash=$(dvc get-url data/finetune_v3.jsonl | sha256sum)
# El run registra: input dataset + model output

# Etapa Eval: validar registrando lineage
mlflow run eval.py \
 -P model_id=adapter_customer_v7 \
 -P golden_set_id=customer_support \
 -P golden_set_version=v12

# Etapa Deploy: el deployment hereda dataset + golden ids
# Cada trace en Observe lleva model_version + prompt_version
# que rebobinan hasta dataset_version

Versión equivalente con lakeFS sobre el RAG corpus:

# Branch para los embeddings del nuevo corpus
lakectl branch create lakefs://corpus/embed-2026q2 --source main

# Indexar el corpus en ese branch
python index_corpus.py --branch embed-2026q2

# Validar antes de mergear a main
python eval_retrieval.py --branch embed-2026q2 \
 --metric recall@10 --threshold 0.78

# Si pasa, mergear (cambia el corpus que sirve producción)
lakectl commit lakefs://corpus/embed-2026q2 -m "embed: corpus 2026q2"
lakectl merge lakefs://corpus/embed-2026q2 lakefs://corpus/main

La virtud del segundo flujo: durante la validación del nuevo corpus, el sistema de producción sigue sirviendo desde main sin interferencia. La rama paralela funciona como un staging real sobre el bucket completo.

Schema contracts: data versioning sin esto es ilusión

Versionar el contenido de un dataset sin versionar su schema es un error frecuente. El problema: un dataset versionado pero con schema implícito sigue rompiendo silenciosamente cuando un productor (el equipo de ingestión, el equipo de annotation, un script ad-hoc) cambia un campo.

Caso concreto: golden eval set de soporte al cliente, 1000 ejemplos, campo expected_output originalmente string. Alguien decide que necesita capturar varias respuestas válidas y cambia el campo a list[string]. El loader del eval acepta ambos formatos por casualidad (Python es laxa) pero el judge LLM downstream recibe un objeto diferente. El eval sigue pasando pero ahora mide otra cosa.

Patrón productivo: el dataset se versiona con DVC/lakeFS y su schema se versiona con Schema Registry (Confluent o Apicurio) o, en sistemas menos maduros, con un JSON Schema embebido junto al dataset. CI bloquea cualquier PR que rompa el contract sin bump de versión.

Schema mínimo de un golden eval entry (ilustrativo):

$schema: https://json-schema.org/draft/2020-12/schema
$id: https://example.org/schemas/golden_eval_entry/v3.json
type: object
required: [example_id, input, expected_outputs, rubric, segment]
properties:
 example_id: {type: string, format: uuid}
 input:
 type: object
 required: [user_query, retrieved_context]
 properties:
 user_query: {type: string}
 retrieved_context: {type: array, items: {type: string}}
 expected_outputs:
 type: array
 minItems: 1
 items: {type: string}
 rubric:
 type: object
 required: [must_include, must_not_include, format]
 properties:
 must_include: {type: array, items: {type: string}}
 must_not_include: {type: array, items: {type: string}}
 format: {enum: [text, json, markdown]}
 segment: {type: string}
 difficulty: {enum: [easy, medium, hard]}
 added_at: {type: string, format: date-time}
 curated_by: {type: string}

Reglas operativas:

Compatibility forward/backward explícita: añadir un campo opcional es backward-compatible; quitar uno requerido es breaking. La política se enforza con un compatibility check en CI.
Versión del schema embebida en cada fila del dataset (un campo _schema_version). El loader valida que la versión coincide con lo que espera el código que lo consume.
Schema registry como única fuente de verdad, no como copia opcional del JSON Schema en cuatro repos.

Sin este nivel de disciplina, “tenemos data versioning” significa “guardamos los bytes pero no controlamos qué significan”.

Golden eval set: la versión más crítica

De los cuatro artefactos, el golden eval set es el que más rigor exige. Un fallo aquí contamina toda la cadena de promotion: si el eval miente, los gates aprueban modelos que no deberían.

Tres disciplinas extra sobre el golden set:

Anotación con calidad medida. Cada ejemplo lo etiqueta un humano, y un porcentaje (10-20 %) se anota por dos personas independientes. El acuerdo inter-anotador (Cohen’s kappa o F1 pairwise) se mide y se publica; un golden set con kappa < 0.7 está midiendo ruido humano, no comportamiento del modelo. Argilla y Label Studio dan la mecánica; lo importante es la disciplina, no la herramienta.

Holdout estricto contra contaminación. El golden set nunca debe entrar al training set. Mecanismo concreto: hash de cada input del golden set (sha256 normalizado por lowercasing + stripping de puntuación trivial) → check en CI contra todos los hashes del training set. Si hay intersección, el CI bloquea hasta resolución. Sin este check, el modelo aprueba el eval por memorización, no por capacidad. La consecuencia es desastrosa en producción: el modelo “validado” falla en casos análogos al golden set que no estaban memorizados.

Versionado aditivo, nunca destructivo. Cuando el golden set crece (cada ciclo de retrain añade casos), golden_v3 = golden_v2 ∪ new_examples. Nunca golden_v3 = nuevo set distinto. Sólo así puedes comparar dos modelos entrenados a meses de distancia sobre la misma base + el delta nuevo. Si reescribes el golden set, no puedes decir si el modelo de marzo era peor que el de mayo o si simplemente medías cosas distintas.

Tabla resumen de la disciplina por artefacto:

Práctica	Training set	RAG corpus	Golden eval set	Enriched retrain
Versionado inmutable	Sí	Sí (snapshots)	Sí, crítico	Sí
Schema con contract	Sí	Recomendado	Sí, crítico	Sí
Doble anotación	No	No aplica	Sí (10-20 %)	Sí (10-20 %)
Holdout vs otros datasets	N/A	N/A	Sí, hash check	Sí (vs golden)
Drift check vs versión anterior	Recomendado	Sí	Recomendado	Sí
Lineage hasta deployment	Sí	Sí	Sí	Sí

Promotion gates: el dataset es promovido como el modelo

Un dataset candidato (un golden_v13 recién enriquecido, un enriched_retrain_2026_q2 resultado del ciclo de Retrain) no entra a producción por estar en el bucket. Pasa por gates equivalentes a los del modelo o del prompt:

Schema validation — el contract se cumple. Bloqueo en CI si no.
Quality validation — muestra aleatoria del 5-10 % revisada por humano con quality score ≥ 4/5. Bloqueo si la muestra falla.
Holdout segregation check — para golden sets y enriched datasets, hash check contra todos los demás datasets activos. Bloqueo si hay solapamiento.
Drift check vs versión anterior — KS test sobre distribución de embeddings de los inputs, o métricas más simples (longitud media, distribución de segmentos, ratio de cada label). Aviso si el drift es alto sin causa documentada; bloqueo si es muy alto.
Lineage check — el dataset declara explícitamente de qué versión hereda y qué cambió. Sin esa metadata, no entra.

Sólo cuando los cinco gates pasan, el dataset se etiqueta como production-ready y se desbloquean los pipelines downstream que dependen de él (el siguiente Tune, el siguiente release del producto, el siguiente ciclo de eval).

El stack on-premise aplicado

En una infraestructura genérica con RTX 4090 (24 GB VRAM, perfil de desarrollo / batch chico) y un cluster 4×H100 SXM (80 GB VRAM cada una, NVLink, entrenamientos y inferencia productiva), el data versioning encaja sin GPU dedicado para el versionado en sí —el versionado vive en CPU + storage— pero sí toca la GPU para los drift checks que requieren embeddings.

Topología típica:

┌────────────────────────────────────────────────────────────┐
│ Object store (MinIO o Ceph) │
│ buckets: /training-sets /corpus-rag │
│ /golden-evals /enriched-retrain │
└────────────────────────┬───────────────────────────────────┘
│
┌─────────────────┼──────────────────┐
│ │ │
┌───▼────┐ ┌────▼────┐ ┌────▼─────┐
│ DVC │ │ lakeFS │ │ MLflow │
│ remote │ │ branches│ │ Tracking │
└───┬────┘ └────┬────┘ └────┬─────┘
│ │ │
└─────────────────┴──────────────────┘
│
┌──────▼──────┐
│ CI/CD gates │
│ (Forgejo / │
│ GitLab) │
└──────┬──────┘
│
┌──────────┴───────────┐
│ │
┌─────▼──────┐ ┌─────▼─────┐
│ RTX 4090 │ │ 4×H100 │
│ (drift │ │ (training │
│ embeds, │ │ + │
│ validates)│ │ serving) │
└────────────┘ └───────────┘

Notas operativas:

El object store (MinIO o Ceph) sirve a la vez como DVC remote y como storage de lakeFS. Un solo plano de almacenamiento, dos vistas.
Los schema checks y hash de holdout son tareas CPU-bound rápidas; el CI runner las ejecuta sin GPU.
El drift check por embeddings requiere encoder; la RTX 4090 sirve para esto sin tocar el cluster productivo. Un encoder pequeño (BGE-small, E5-small, ~100M parámetros) procesa 10⁴ ejemplos en pocos minutos.
El cluster H100 queda libre para training y serving, sin contaminación por jobs de versionado.

¿Cuándo NO hace falta DVC/lakeFS?

Hay una posición opuesta defendida con datos en el post de fine-tuning continuo: para sistemas pequeños con un único equipo, datasets < 1 GB y un puñado de adapters, Postgres + pgvector + un bucket S3 + filenames con hash son suficientes. La complejidad operativa de DVC/lakeFS no se amortiza.

La línea divisoria es razonable:

No hace falta DVC/lakeFS: un solo equipo, datasets pequeños, pocos adapters, sin múltiples productos compartiendo datos.
Sí hace falta: múltiples equipos, datasets > 10 GB, varios productos que comparten golden eval set, compliance externo que exige trazabilidad de lote, o un ciclo de retrain trimestral institucionalizado.

Adoptar DVC + lakeFS antes de necesitarlos es overhead. Adoptarlos seis meses tarde es perder seis meses de lineage de manera irrecuperable.

Siete pitfalls que convierten data versioning en teatro

Versionar los datos pero no los schemas. El contenido se versiona, el contrato cambia silenciosamente, el sistema rompe sin que el versionado lo capture. Schema Registry no es opcional; es la mitad del problema.
Mismo S3 path sobrescrito. “Sube training.jsonl al bucket” y el siguiente experimento reescribe el archivo. El versionado de S3 (si está habilitado) salva la lana, pero sin un identificador inmutable propagado a MLflow no se puede rebobinar. Patrón correcto: training_v3.jsonl o training/2026q2/<sha>.jsonl, nunca el mismo nombre.
Golden eval set sin holdout estricto. Sin hash check contra training, el modelo memoriza el eval y aprueba sin haber aprendido. Es el equivalente LLM de un examen que el profesor anuncia: aprueba todo el mundo, no se ha medido nada.
No registrar lineage dataset → modelo. Cuando un incidente requiere saber con qué datos se entrenó cierto modelo, la respuesta correcta es un query a MLflow / W&B. Si la respuesta es “preguntemos a quien lo entrenó” (suponiendo que siga en el equipo), el lineage no existe.
DVC añadido seis meses tarde. Adoptar versionado en mes 1 = molestia. Adoptarlo en mes 6 = pérdida irrecuperable de seis meses de datasets que ya no se pueden reconstruir. La maldición del “lo metemos después”.
lakeFS con branches que nunca se mergean. Branches paralelos sobre el corpus son útiles para experimentar; mantenidos indefinidamente sin merge, el operativo se vuelve un cementerio de branches medio actualizados. Política explícita: merge o destruir en N semanas.
Validación de schema solo en producción. El contract se valida cuando el dataset ya está en producción y el modelo entrenado. Para entonces, el incidente ya pasó. La validación tiene que ser en CI, antes del merge, sobre el delta que el PR introduce.

El ciclo de un dataset en una pantalla

┌─────────────────────────────────────────────────────────────┐
│ Productor (ingest / annotation / retrain bucle) │
└────────────────┬────────────────────────────────────────────┘
│
▼ (commit a candidate version)
┌─────────────────────────┐
│ CI gates │
│ - Schema validation │
│ - Quality sampled │
│ - Holdout hash check │ ── falla → PR bloqueado
│ - Drift vs anterior │
│ - Lineage declarado │
└────────────┬────────────┘
│ pasa
▼
┌─────────────────────────┐
│ DVC tag o lakeFS commit│
│ + MLflow registry │ ← versión inmutable
│ + Schema Registry │
└────────────┬────────────┘
│
▼
┌─────────────────────────┐
│ Pipeline downstream │
│ Tune / Eval / Deploy │
└────────────┬────────────┘
│
▼
┌─────────────────────────┐
│ Trace de producción │
│ → rebobina hasta dataset│
└─────────────────────────┘

Lo que no hemos cubierto

A primer nivel queda fuera de este post:

Vector store versioning propiamente dicho: un índice de embeddings no se versiona como un dataset crudo porque depende del modelo de embedding. Cambiar el embedder reescribe todo el índice. Es otro animal y merece tratamiento aparte (recall, ANN parameters, branching del índice vs reembedding completo).
Tooling de lineage estandarizado (OpenLineage, Marquez): cómo emitir y consumir lineage events de manera interoperable entre sistemas.
Data quality frameworks (Great Expectations, Soda, Deequ): cómo escribir suites de “expectations” sobre un dataset y enforzarlas en cada versión.
Privacy-preserving versioning: federated learning sin centralizar el dataset, differential privacy aplicada a la versión que se distribuye.
Contaminación entre golden sets de proveedores externos (HumanEval, MMLU, etc.) y datasets de training de modelos open: el problema de “el modelo aprueba HumanEval porque HumanEval está en su pretraining”.

Cada uno da para un post propio cuando el campo lo justifique.

Ver también

Pipeline LLMOps de seis etapas — el mapa maestro donde encaja esta pieza, sección Data.
Retrain: cerrar el bucle — cómo el enriched dataset producido por Retrain vuelve a Data; este post detalla cómo versionarlo bien.
Prompt versioning con Langfuse y MLflow — la otra pieza transversal del lineage; el prompt_version viaja junto al dataset_version en cada trace.
Fine-tuning continuo en producción — defiende un stack minimalista (Postgres + pgvector + S3) sin DVC/lakeFS para sistemas pequeños; este post explica cuándo se cruza la línea hacia el otro lado.
Evals para LLMs: la capa después del tracing — el consumidor principal del golden eval set.
MLOps específico para LLMs en 2026 — contexto de mercado del stack LLMOps completo.
PostgreSQL + Qdrant para ingestión — cómo se materializa la ingestión que precede al versionado.

Referencias

DVC documentation — workflows de versionado, pipelines y remotes.
lakeFS documentation — branching, merging y commits sobre el bucket.
lakeFS adquiere DVC, noviembre 2025 — anuncio y hoja de ruta combinada.
Confluent Schema Registry y Apicurio — schema contracts para datos en streaming.
OpenLineage y Marquez — estándar abierto de eventos de lineage.
Great Expectations — data quality expectations en CI.
MLflow Tracking — input datasets como artefactos de primera clase desde MLflow 2.4.
Pachyderm y Quilt — alternativas históricas a DVC/lakeFS.
Sobre contaminación de eval sets: “Stop Uploading Test Data in Plain Text” (Magar & Schwartz, 2022) y trabajo posterior sobre detección de contaminación en pretraining corpora.

PostgreSQL + Qdrant en la etapa de ingestión: patrones de sincronización, microservicios y cómo encaja todo sin romperse

Thu, 21 May 2026 06:50:00 +0200

TL;DR

PostgreSQL es la fuente de verdad transaccional de la mayoría de las empresas; Qdrant es el motor de búsqueda vectorial que más equipos eligen cuando pgvector se queda corto. Combinarlos no es trivial: tu modelo de dominio vive en Postgres con ACID, las relaciones, las constraints, los triggers; los embeddings viven en Qdrant con HNSW filterable, quantization escalar, multivectors, sparse-dense hybrid search. Mantener los dos sincronizados es el problema operacional número uno que el campo LLMOps ha codificado en 2026 con tres patrones canónicos: dual-write (simple, frágil, válido para prototipos), transactional outbox + CDC con Debezium (la opción “correcta” para producción seria) y event-driven directo a Kafka (cuando el evento es el ciudadano de primera y la DB es proyección). La elección de Qdrant sobre pgvector se justifica con números concretos —filtered search 6ms vs 29ms en 500K vectores, 65% menos memoria con scalar quantization, HNSW filterable que no se hunde con metadata, escalabilidad horizontal—. El precio es operacional: un servicio stateful adicional que mantener, snapshots que gestionar, gRPC que asegurar. Este post entra en detalle en cómo se sitúa PostgreSQL + Qdrant en la etapa Data del pipeline LLMOps que dibujamos en el post anterior, qué microservicios participan, cómo se sincronizan, cómo se observan y dónde están las trampas que se ven una y otra vez en producción.

Este es el cuarto post de la serie MLOps para LLMs y el primero que aplica el patrón “estás aquí” sobre el mini-mapa que definimos en el post anterior sobre el pipeline de seis etapas. Aquí estamos plenamente en la primera etapa: Data.

Estás aquí: etapa Data del pipeline

La pregunta que define la arquitectura: ¿una DB o dos?

Antes de hablar de patrones, vamos a la decisión que marca el resto del diseño. Tienes datos transaccionales en PostgreSQL —usuarios, productos, documentos, conversaciones— y necesitas búsqueda vectorial sobre ellos para RAG. Dos respuestas razonables:

Opción A — pgvector dentro de Postgres: añades la extensión vector, una columna embedding vector(1536), un índice HNSW. Cero arquitectura nueva, cero servicio nuevo. Tu DBA sigue siendo el DBA. Una sola DB, ACID con tus tablas relacionales, JOINs entre embedding y metadata. Una sola fuente de verdad.

Opción B — Qdrant separado: dejas Postgres como está y montas Qdrant como servicio stateful aparte. Tu microservicio escribe a las dos. Dos fuentes parciales que mantener en sync.

La elección depende de números. Vamos a ellos.

Cuándo pgvector basta y cuándo no

Los benchmarks 2026 son consistentes. La regla del pulgar:

Hasta ~1M vectores: pgvector es excelente. Setup en minutos, cero overhead operacional, queries ACID con JOINs naturales.
1-10M vectores: pgvector funciona pero ya empiezas a sufrir. Index builds tardan, recall baja bajo carga, memoria sube linealmente.
>10M vectores: pgvector se hunde a no ser que tunes mucho. Index build pasa de horas; query p95 deriva por encima de 200ms.
>50M vectores: pgvector deja de ser opción razonable en single-node.

Qdrant escala a billones con sharding. Numéricamente, en 500K vectores con 3 condiciones de payload:

Qdrant: 6 ms p95 (filtered HNSW).
pgvector: 29 ms p95 (heap scans rompen la localidad del índice).

Y en memoria: Qdrant con scalar quantization usa 65% menos RAM que pgvector con IVFFlat sobre el mismo dataset. Para 50M vectores de 1024 dimensiones eso son decenas de GB de diferencia. Multiplicado por tres réplicas para HA, es un nodo entero menos.

Pero pgvector tiene una ventaja decisiva en proyectos pequeños y medianos: es gratis, embebido, y lo opera tu DBA. La fricción de adoptar Qdrant —un servicio stateful nuevo, gRPC, snapshots, observabilidad propia— solo se justifica cuando el dolor de pgvector es real, no anticipado.

El veredicto operativo 2026

Empieza con pgvector si tu corpus es <5M vectores y tu equipo es pequeño.
Migra a Qdrant cuando uno de los tres siguientes signos aparezca: latencia p95 inaceptable, presión de memoria sobre el cluster Postgres principal, necesidad de hybrid search (sparse + dense) avanzada.
No migres anticipadamente: el coste operacional de Qdrant es real; sufre cuando lo necesitas, no por si acaso.

Lo importante: diseña la capa de acceso a embeddings con una abstracción (un VectorStore interface en tu código) para que cambiar de pgvector a Qdrant sea cambiar la implementación, no reescribir la app.

Qdrant en detalle: lo que ofrece sobre pgvector

Si decides que Qdrant es la opción, vale la pena entender qué te da más allá del rendimiento bruto. Cinco features dominantes:

1. Filterable HNSW

El HNSW filterable es lo que más se nota en producción. En pgvector, filtrar por metadata (WHERE category = 'tech' AND date > '2026-01-01') hace que el índice HNSW pierda eficiencia: la búsqueda tiene que recorrer más nodos para encontrar los que cumplen el filtro. En Qdrant, el HNSW está construido para podar la búsqueda con filtros dentro del propio recorrido del grafo, sin escapar a heap scans externos. Para queries con filtros densos (lo normal en RAG con permisos multi-tenant), la diferencia es brutal.

2. Multivector y late-interaction (ColBERT)

Qdrant permite almacenar una matriz de vectores por punto, no solo un vector. Esto soporta nativamente modelos late-interaction como ColBERT, que codifican un vector por token y comparan con MaxSim. La calidad de retrieval con ColBERT-style multivectors es típicamente 5-15% mejor que single-vector en cargas semánticas complejas.

3. Sparse + dense hybrid search

Hybrid search combina un vector denso (semántico, eg embeddings de SentenceTransformers) con un vector disperso (lexical, eg SPLADE, BM25 reproducido como sparse). El denso captura “esto es semánticamente similar”; el disperso captura “esta palabra concreta aparece”. Combinados —tipicamente con reciprocal rank fusion o weighted combination— recuperan tanto la similitud semántica como los matches exactos de keyword. Es el patrón de retrieval que más calidad da en 2026 y Qdrant lo trae nativo desde la versión 1.10.

4. Quantization escalar y binaria

Para cargas grandes, Qdrant ofrece scalar quantization (int8 en lugar de float32, 4× menos memoria con pérdida marginal de recall) y binary quantization (1 bit por dimensión, 32× menos memoria con pérdida moderada que se recupera con rescoring de los top-K). En el roadmap 2026 está la 4-bit quantization, que será un punto medio.

5. Named vectors

Una colección Qdrant puede tener múltiples espacios vectoriales por punto, llamados named vectors. Caso típico: el mismo documento se indexa con un vector denso (text-embedding-3-small) y un vector sparse (SPLADE), bajo el mismo point_id. Las queries pueden buscar en el vector concreto que les interesa.

A esto se suma el roadmap 2026: 4-bit quantization, read-write segregation, expanded inference capabilities (Qdrant puede embeddar texto él mismo, sin un servicio externo).

La arquitectura de microservicios: dónde encaja cada pieza

Aquí está lo que el usuario que monta esto en producción tiene que diseñar. La arquitectura típica que se ha estabilizado tiene cinco microservicios que tocan estas piezas, cada uno con su responsabilidad clara:

Vamos a cada microservicio.

1. Domain Service

Responsabilidad: la lógica de negocio. CRUD de documentos, productos, conversaciones. Endpoints REST/gRPC para el front-end o para otros servicios. Solo conoce PostgreSQL como sistema de persistencia; no sabe nada de Qdrant.

Esto es importante por diseño: el domain service no debería tener nunca una referencia directa a Qdrant. Si la tiene, ya estás en el antipattern del dual-write. El domain service escribe a Postgres en una transacción ACID; el resto del pipeline se entera vía eventos.

2. PostgreSQL

Responsabilidad: source of truth transaccional. Schemas relacionales, constraints, triggers, ACID. Y la outbox table que veremos en breve, que es lo que va a permitir la sincronización fiable.

Patrón típico de despliegue: HA con Patroni + repmgr + PgBouncer para connection pooling, replicas de lectura para offloading.

3. Kafka

Responsabilidad: el bus de eventos. Recibe los cambios capturados por CDC (Debezium leyendo el WAL de Postgres o leyendo la outbox table) y los pone disponibles para los consumidores. Cubierto en profundidad en RAG sobre Kafka.

Topics típicos:

documents.changes: eventos crudos de cambio (insert/update/delete).
documents.embedded: eventos con embedding ya calculado.

4. Embedding Service

Responsabilidad: consumir eventos de cambio, calcular embeddings, publicar al topic embedded. Esta es la pieza que más coste consume si usas embeddings vía API (OpenAI, Cohere, Voyage AI).

Estructura típica:

Consumer Kafka con consumer group propio.
Batching de eventos para llamadas embedding (mucho más eficiente que uno a uno).
Llamadas paralelas con concurrency control.
Retry con exponential backoff ante rate limits.
Métricas exportadas (latencia, throughput, errores, coste).
Idempotencia (key del topic = doc_id, mismo doc no se re-embedea sin necesidad).

Patrón de optimización clave: deduplicate por hash de contenido. Si el documento se actualiza pero el texto no cambió (solo metadata), no merece la pena re-embedear. Hash + cache de embeddings ahorra 30-70% del coste en cargas reales.

5. Indexing Worker

Responsabilidad: consumir el topic embedded y hacer upsert a Qdrant. Es la pieza más simple de toda la arquitectura: lee del topic, escribe al vector store. Pero importante para la fiabilidad: tiene que ser idempotente (el mismo doc_id puede llegar varias veces si el consumer reinicia) y resiliente (si Qdrant está caído, reintentar sin perder eventos).

Estructura: Consumer Kafka con commit manual de offset solo después de confirmación del upsert. Si Qdrant falla, el offset no se commitea y el evento se reprocesa.

6. Retrieval Service

Responsabilidad: la cara que el LLM Service ve. Recibe una query del usuario, hace búsqueda en Qdrant (vector + filtros + reranker), enriquece los resultados con metadata fresca de PostgreSQL si hace falta, y devuelve top-K documentos con su contenido para que el LLM construya su prompt.

Es el único servicio que consulta Qdrant. Esto centraliza la lógica de retrieval: cuando quieras añadir reranking, hybrid search, query rewriting, lo haces aquí sin tocar el resto.

7. LLM Service

Responsabilidad: la generación. Recibe del Retrieval Service el contexto + query, construye el prompt, llama al LLM (self-hosted vLLM o API externa vía LiteLLM), devuelve la respuesta. Lo cubrimos en posts anteriores; no es el foco aquí.

El problema del dual-write y los tres patrones de solución

Aquí está la pieza arquitectónica más importante del post. El problema: tu Domain Service necesita escribir a dos lugares: PostgreSQL (el documento) y, indirectamente vía pipeline, Qdrant (el embedding del documento). Si lo haces ingenuamente —escribir a uno y luego al otro— tienes el problema del dual-write:

La escritura a Postgres tiene éxito, pero la publicación del evento a Kafka falla → el embedding no se calcula, Qdrant nunca se entera.
La publicación a Kafka tiene éxito, pero el commit a Postgres falla → evento fantasma, el embedding se calcula sobre algo que no existe.
El servicio crashea entre las dos operaciones → estado parcial, no sabes qué pasó.

Distributed transactions (two-phase commit) son la solución teórica pero nadie las quiere en producción: requieren coordinator XA, latencia alta, locking distribuido. La solución práctica son los patrones modernos. Tres opciones:

Patrón 1 — Dual-write naïve (prototipos)

El Domain Service escribe a Postgres, luego publica a Kafka:

async def create_document(doc):
 async with db.transaction():
 doc_id = await db.execute("INSERT INTO documents ...")
 await kafka.publish("documents.changes", {...})
 return doc_id

Funciona en happy path. Falla cuando algo entre las dos operaciones se rompe. Para prototipos donde la inconsistencia es aceptable, vale; para producción seria, no.

Patrón 2 — Transactional outbox + CDC con Debezium (la opción correcta)

Solución elegante: el Domain Service escribe a Postgres en una sola transacción que incluye tanto la tabla principal como una outbox table. La outbox no es consumida directamente; Debezium lee el WAL de Postgres y produce a Kafka los eventos de la outbox.

Schema típico:

CREATE TABLE outbox (
 id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
 aggregate TEXT NOT NULL, -- 'document', 'user', 'product'
 aggregate_id TEXT NOT NULL, -- el doc_id que cambió
 event_type TEXT NOT NULL, -- 'created', 'updated', 'deleted'
 payload JSONB NOT NULL,
 created_at TIMESTAMPTZ DEFAULT NOW()
);

Cuando el Domain Service crea un documento:

async def create_document(doc):
 async with db.transaction():
 doc_id = await db.execute("INSERT INTO documents (id, body) VALUES (...)", ...)
 await db.execute(
 "INSERT INTO outbox (aggregate, aggregate_id, event_type, payload) VALUES (...)",
 "document", doc_id, "created", json.dumps(doc)
 )
 # transacción committed; Debezium leerá el WAL y publicará a Kafka
 return doc_id

Lo crucial: las dos inserciones están en la misma transacción ACID de Postgres. O las dos van, o ninguna va. Garantía absoluta de consistencia local.

Configuración Debezium para leer la outbox:

{
 "name": "outbox-debezium-connector",
 "config": {
 "connector.class": "io.debezium.connector.postgresql.PostgresConnector",
 "database.hostname": "postgres",
 "database.dbname": "app",
 "table.include.list": "public.outbox",
 "transforms": "outbox",
 "transforms.outbox.type": "io.debezium.transforms.outbox.EventRouter",
 "transforms.outbox.route.by.field": "aggregate",
 "transforms.outbox.table.field.event.id": "id",
 "transforms.outbox.table.field.event.key": "aggregate_id",
 "transforms.outbox.table.field.event.type": "event_type",
 "transforms.outbox.table.field.event.payload": "payload",
 "transforms.outbox.route.topic.replacement": "${routedByValue}.changes",
 "key.converter": "org.apache.kafka.connect.storage.StringConverter",
 "value.converter": "org.apache.kafka.connect.json.JsonConverter"
 }
}

EventRouter enruta a topics distintos según el valor de aggregate: eventos de document van a document.changes, los de user a user.changes, etc.

Ventajas: garantía “exactly-once” desde el punto de vista de la aplicación; eventos en orden del commit; sin polling.

Coste: una tabla extra, una configuración Debezium, ~5-10 ms extra de latencia en la escritura.

Patrón 3 — Event-driven directo (event sourcing puro)

Variante más radical: el evento es el primer ciudadano; PostgreSQL es solo una proyección. El Domain Service publica el evento a Kafka, y un consumer lo escribe a Postgres y otro lo procesa para embedding. No hay tabla principal, no hay outbox; el log Kafka es la fuente de verdad.

Más limpio conceptualmente pero requiere repensar el modelo de dominio (eventos como source of truth, queries reconstruidas de la proyección). Más adecuado para greenfield con equipo que entiende event sourcing.

Comparativa

Patrón	Setup	Consistencia	Cuando
Dual-write naïve	Trivial	Frágil	Prototipos, PoC
Outbox + CDC	Medio	Sólido	Producción seria (default)
Event-driven directo	Alto	Sólido	Greenfield con event sourcing

El default en 2026 para producción es outbox + CDC con Debezium. Es lo suficientemente simple para mantenerse, lo suficientemente robusto para no preocupar de noche.

Manifest completo: despliegue Qdrant en Kubernetes

Ya cubrimos cómo se monta el resto del pipeline (Kafka, Debezium, Flink) en el post anterior de Kafka. La pieza que añadimos aquí es Qdrant. Despliegue típico vía Helm chart oficial:

# values.yaml para qdrant/qdrant chart
replicaCount: 3 # cluster con 3 réplicas

image:
 repository: qdrant/qdrant
 tag: "v1.14.0"

persistence:
 enabled: true
 storageClassName: "fast-ssd"
 size: 200Gi

resources:
 requests:
 cpu: 2
 memory: 8Gi
 limits:
 cpu: 8
 memory: 16Gi

# clustering: cada réplica conoce a las otras
cluster:
 enabled: true
 consensus:
 tickPeriodMs: 100

# auth via API key
apiKey:
 enabled: true
 secretKeyRef:
 name: qdrant-auth
 key: api-key

# observability
metrics:
 enabled: true
 serviceMonitor:
 enabled: true # scrapping desde kube-prometheus

# snapshots periódicos
snapshots:
 enabled: true
 schedule: "0 3 * * *" # diario a las 3 AM
 retention: 7
 storage: "s3"
 s3:
 bucket: "qdrant-snapshots-prod"

config:
 storage:
 performance:
 max_search_threads: 8
 quantization:
 always_ram: true # quantized vectors en RAM
 service:
 enable_tls: true

Y la creación de la colección con configuración para hybrid search:

from qdrant_client import QdrantClient
from qdrant_client.models import (
 VectorParams, SparseVectorParams, Distance,
 HnswConfigDiff, ScalarQuantization, ScalarType
)

client = QdrantClient(url="https://qdrant.internal:6333", api_key=API_KEY)

client.create_collection(
 collection_name="documents",
 vectors_config={
 "dense": VectorParams(
 size=1536,
 distance=Distance.COSINE,
 on_disk=False, # en RAM para latencia
 )
 },
 sparse_vectors_config={
 "sparse": SparseVectorParams() # para BM25-style lexical
 },
 hnsw_config=HnswConfigDiff(
 m=16,
 ef_construct=128,
 on_disk=False
 ),
 quantization_config=ScalarQuantization(
 scalar=ScalarType.INT8 # 65% menos memoria
 ),
 on_disk_payload=True, # payload en disco
 shard_number=6, # particionado para escala
 replication_factor=2, # cada shard replicado
 write_consistency_factor=1
)

Con esta config, una colección de 50M vectores de 1536 dimensiones ocupa ~150-200 GB en RAM (vs ~600 GB con float32 puro), con queries p95 sub-10ms en cargas típicas.

Observabilidad: ver qué está pasando

Cuatro métricas que cualquier dashboard mínimo de la etapa Data debería tener:

1. Lag del outbox

debezium_lag_seconds: cuánto tarda Debezium en leer un evento desde que se commitea. Objetivo: <1 segundo. Si sube, indica WAL retention insuficiente o consumer rate menor que producer.

2. Lag del embedding service

embedding_service_consumer_lag_messages: cuántos eventos pendientes hay en el topic documents.changes. Objetivo: <100 sostenido. Si crece, indica que el rate de cambios supera la capacidad del embedding service. Soluciones: más consumers (paralelismo), batching más grande, modelo de embedding más rápido.

3. Tasa de upsert a Qdrant

qdrant_upsert_rate y qdrant_upsert_p95_latency. Objetivo: latencia <50 ms p95, tasa estable acorde al CDC rate. Si la latencia sube, Qdrant está degradado (memory pressure, disk slow, conn pool saturado).

4. Recall en producción (offline check)

Una vez al día, ejecutar un job que toma N queries reales, busca en Qdrant, busca en pgvector si lo mantienes en paralelo, compara recall@k. Si Qdrant deja de devolver lo que debería, lo detectas antes de que un usuario se queje.

Trampas operativas comunes

Sin outbox: el equipo aprende dual-write a base de incidentes

Lo más común. La primera versión hace dual-write directo “para empezar simple”; un día se cae Kafka durante 10 minutos y miles de embeddings quedan sin generar. Migrar a outbox después de tener tráfico es caro porque hay que backfill. Outbox desde el día 1.

Reembedding ignorante del coste

Cambias el modelo de embedding (text-embedding-3-small → text-embedding-3-large). Tu pipeline reemboda los 5M documentos. 17 horas y $1500 de coste que nadie anticipó. Calcular reembedding upfront: documentos × tokens promedio × coste/1k tokens × throughput limits.

Snapshot de Qdrant sin testear restore

Sacas snapshots diarios pero nunca pruebas restaurar. Un día Qdrant se corrompe y descubres que el snapshot está incompleto o que tu storage class no permite recuperarlo. Test trimestral de restore en entorno paralelo, obligatorio para producción.

Qdrant detrás de Service ClusterIP estándar sin gRPC affinity

Qdrant habla gRPC. Si el Service hace round-robin connection-level pero el cliente reusa connections, todo el tráfico va a un solo pod. Headless Service + client-side load balancing o gRPC-aware service mesh.

PG y Qdrant sin shared trace id

El Domain Service recibe un request, lo procesa, escribe a PG, dispara evento. Cuando un día algo va mal, no puedes correlar el span del Domain Service con el span del Indexing Worker porque no propagaste trace context. OTel context propagation por el topic Kafka (vía headers Kafka), igual que hicimos en el post de MCP observability.

Vector y metadata en sync nominal pero no real

PG dice “documento X tiene categoría tech”; Qdrant dice “documento X tiene categoría legal” (porque el cambio de categoría se actualizó en PG pero el evento de update no llegó a regenerar el payload en Qdrant). Filtras category=tech, no aparece. Tests periódicos de consistencia cross-store sobre muestreo aleatorio.

Dimensión del vector hardcodeada en mil sitios

1536 aparece en el código del Domain Service, del Embedding Service, del Indexing Worker, del Retrieval Service, en la creación de la colección Qdrant. Cuando cambias modelo (a uno de 768 dimensiones), olvidas uno y todo se rompe. Configuración centralizada del modelo + dimensión.

Sin rate limiting al embedding provider

Tu CDC procesa una migración masiva: 1M documentos cambian. El embedding service intenta procesar todo a la vez. OpenAI te rate-limita, el consumer queda atascado, los eventos se acumulan, tu cluster Kafka queda con horas de lag. Rate limiting en el consumer, no en el producer.

Cuándo NO usar Qdrant: el contrapunto honesto

Para no presentar Qdrant como bala de plata:

Tu corpus es <1M vectores y no esperas crecer. pgvector basta y te ahorra un servicio.
Tu equipo es pequeño y no tiene capacidad de operar un stateful service más. Qdrant añade snapshots, gRPC, mTLS, observabilidad propia. Cada uno de esos puntos es un día de trabajo de un SRE.
Tu retrieval es batch off-hours, no real-time. Si solo haces RAG para reportes nocturnos, la latencia de pgvector no duele.
Necesitas JOINs nativos entre embeddings y tablas relacionales en queries críticos. pgvector permite hacer JOIN documents d ON d.id = embedding.doc_id WHERE d.tenant_id = X. Qdrant lo simula con payload pero menos elegante.

Y al revés, cuando Qdrant gana claramente:

Corpus >10M vectores con queries con filtros densos.
Necesidad de hybrid search nativo (sparse + dense + multivector).
Multi-tenant con strict latency requirements por cliente.
Quantization agresiva para mantener todo en RAM en hardware limitado.
Cluster mode con sharding horizontal real.

Lo que no hemos cubierto

Migración pgvector → Qdrant en vivo: patrón con dual-read durante la transición.
Vector search federation: queries que cruzan múltiples Qdrant collections o múltiples vector stores. Tema propio.
Multi-tenancy en Qdrant: payload filters + namespace isolation + per-tenant rate limiting.
Cold storage para vectores antiguos: archivo de partitions a object storage con índice secundario.
Embedding model self-hosted con vLLM: alternativa a OpenAI API que reduce coste y mejora privacidad. Tema cruzado con la serie de inferencia.

Referencias

PostgreSQL y pgvector:

PostgreSQL pgvector extension (GitHub) — el de toda la vida.
Pgvector vs Qdrant (Tiger Data) — comparativa con números.
Start with pgvector: Why You’ll Outgrow It Faster Than You Think (Qdrant blog) — los tradeoffs honestos desde Qdrant.

Qdrant:

Qdrant — sitio oficial.
Qdrant changelog.
Sparse Vectors in Qdrant — hybrid search nativo.
Multivectors and Late Interaction — ColBERT-style.
Qdrant 2025 Recap: Powering the Agentic Era — estado del proyecto y roadmap.

Outbox y CDC:

Reliable Microservices Data Exchange With the Outbox Pattern (Debezium blog) — el post canónico.
The Outbox Pattern Explained (Streamkap).
Outbox Pattern with Debezium (Thorben Janssen).
Distributed Data for Microservices — Event Sourcing vs CDC (Debezium blog) — comparativa entre patrones.

Comparativas 2026:

Cross-references:

Post anterior: Pipeline LLMOps de 6 etapas — donde definimos el mini-mapa.
RAG sobre Kafka — arquitectura técnica — la pieza que precede a Qdrant en el pipeline.
Panorama MLOps LLMs 2026 — el marco general.
Series previas: post-tracing y eBPF.

RAG sobre Kafka: arquitectura técnica de referencia para datalakes en streaming, con embeddings frescos y vector stores siempre al día

Thu, 21 May 2026 06:00:00 +0200

TL;DR

La pieza que más bloquea proyectos GenAI empresariales en 2026 no es el modelo, ni siquiera los guardrails: es la ingestión de datos para RAG. Las empresas tienen información valiosa en bases de datos OLTP, en logs operacionales, en sistemas SaaS, y todo eso está silenciosamente cambiando cada segundo. Los RAG batch que se reindexan cada noche llegan tarde —la respuesta del modelo está respaldada en un snapshot de hace 18 horas— y dan paso a alucinaciones operacionales aunque el retriever sea perfecto. La respuesta dominante en producción en 2026 es montar la pieza RAG sobre Kafka como source-of-truth: log inmutable, throughput masivo, schema evolution gestionada, y un ecosistema de stream processing maduro (Flink, Kafka Streams, RisingWave) que permite transformar y embedder eventos a medida que ocurren, llevándolos en milisegundos a vector stores (Milvus, Qdrant, Weaviate, pgvector). El patrón canónico: origen → CDC con Debezium → topics Kafka → Flink SQL con embedding UDF → sink connector a vector store → serving con vLLM o equivalente. Las novedades 2026 que cambian el juego: Confluent Tableflow convierte topics Kafka en tablas Iceberg/Delta automáticamente (lectura desde Snowflake/Databricks/Trino sin ETL, 30-50% menos TCO); Flink SQL nativo trae openai_embedding() y vector search integrado con Cosmos DB y Amazon S3 Vectors; el MCP server oficial de Confluent permite a agentes IA consultar Kafka/Flink/Tableflow en lenguaje natural. Este post desarrolla la arquitectura end-to-end con manifests, código Flink SQL y números concretos.

Este es el segundo post de la serie MLOps específico para LLMs. El primero (Panorama 2026) estableció el marco. Aquí bajamos a la pieza más operacional del stack: cómo se conecta un sistema empresarial real a un agente LLM manteniendo el RAG fresco sin caer en complejidad explosiva.

La analogía: Kafka como el “single source of truth”

Quien lleva tiempo en sistemas distribuidos ha visto el patrón una y otra vez: un log inmutable, append-only, replicado, ordenado en el tiempo se ha vuelto la primitiva canónica para reconstruir sistemas complejos. Los DBAs lo conocen como write-ahead log (PostgreSQL WAL, MySQL binlog). Los desarrolladores de sistemas de eventos lo conocen como event sourcing. Los arquitectos de datos lo conocen como Kappa architecture. Kafka es la implementación masiva, distribuida y madura de esa primitiva: un log que vive en disco, particionado para escalar, replicado para durabilidad, retenido por tiempo o tamaño, legible desde cualquier punto histórico.

Cuando se piensa en RAG, esto es exactamente lo que se necesita. Un sistema RAG bien diseñado tiene dos preguntas críticas: ¿cómo se mantiene fresco el índice? y ¿cómo se reconstruye el índice cuando algo se rompe? Las dos las contesta Kafka de manera natural: fresco porque cada cambio en el origen se publica como evento al log y el pipeline lo procesa en milisegundos; reconstruible porque el log entero está ahí: borras el vector store, dispones del topic Kafka desde el offset 0 y vuelves a construir el índice tal como estaba.

Hay además una segunda capa de analogía. Kafka, para una arquitectura GenAI moderna, juega el papel del WAL del sistema entero. Igual que el WAL de Postgres es el evangelio del estado de la base de datos —si pierdes la DB pero conservas el WAL, puedes reconstruirla—, el log de Kafka es el evangelio del estado del conjunto del negocio: pedidos, usuarios, transacciones, documentos. Conectar tu agente IA a Kafka es conectarlo al pulso real del sistema, no a snapshots obsoletos.

El problema del RAG estático

Antes de presentar la arquitectura, vale la pena fijar qué problema concreto estamos resolviendo. El antipattern que tropieza a la mayoría de proyectos GenAI:

Equipo construye RAG sobre un dataset estático: vuelca documentos de Confluence, PDFs de productos, snapshots de base de datos.
Lo embedea con un cron nocturno que regenera el índice cada 24 horas.
Lanza el producto.
Día 2: usuario pregunta sobre un cambio que ocurrió hace dos horas. El RAG no lo tiene; el modelo responde sobre la versión vieja.
Equipo añade lógica frágil: “si la query menciona una fecha reciente, escalar a un agente humano”.
Día 30: el dataset se ha movido tanto que media RAG está desactualizado. El equipo decide refactor y migrar a streaming.

Es la historia repetida de tantos proyectos que el ecosistema ha aprendido la lección: streaming desde el día 1, aunque el volumen sea bajo. La complejidad operacional de un pipeline streaming bien diseñado es constante; la complejidad de migrar de batch a streaming en proyecto vivo es enorme.

Del Lambda al Kappa al Streaming RAG

Tres arquitecturas en orden histórico:

Lambda (clásica de big data 2014): dos pipelines paralelos, uno batch para precisión y uno streaming para freshness. La consulta combina ambos. Funciona pero exige mantener dos pipelines.

Kappa (Jay Kreps 2014, mainstream desde 2020): solo un pipeline streaming. El batch es un caso particular del streaming (reprocesar desde el principio). Simplifica mucho.

Streaming RAG (emergente 2025-2026): variante específica de Kappa donde el output del pipeline son embeddings indexados en un vector store que el LLM consulta en runtime. El log Kafka es la fuente de verdad, el vector store es un proyección consultable.

La conversión mental: piensa en el vector store como la vista materializada del log Kafka. Si la vista se corrompe, la reconstruyes desde el log. Si quieres una vista nueva (otro embedding model, otro chunking strategy), creas otro consumer del log y construyes una segunda vista en paralelo.

La arquitectura de referencia

Vamos al diagrama. Voy a presentar la arquitectura canónica que se ha estabilizado en 2026, mostrando dónde encaja cada componente:

[OLTP DB (Postgres)] [Otros origenes]
│ │
│ WAL via logical decoding │
▼ ▼
┌──────────────────────────────────────────────────────────┐
│ Debezium / Kafka Connect (Sources) │
└──────────────────────────────────────────────────────────┘
│
▼ produce eventos
┌──────────────────────────────────────────────────────────┐
│ Kafka cluster │
│ ┌───────────────────────────────────────────────────┐ │
│ │ topic: orders.raw (3 particiones, RF=3) │ │
│ │ topic: users.raw (3 particiones, RF=3) │ │
│ │ topic: documents.raw (6 particiones, RF=3) │ │
│ └───────────────────────────────────────────────────┘ │
│ + Schema Registry (Avro/Protobuf) │
└──────────────────────────────────────────────────────────┘
│
▼ consume y transforma
┌──────────────────────────────────────────────────────────┐
│ Flink SQL streaming jobs │
│ - chunking text │
│ - llamadas a embedding model (UDF) │
│ - enriquecimiento con metadata │
│ - sink a topic curado: documents.embedded │
└──────────────────────────────────────────────────────────┘
│
┌───────────┼────────────────────┐
▼ ▼ ▼
[Vector store] [Tableflow] [Iceberg/Delta]
Milvus/Qdrant auto-convert para analytics
/pgvector/ topics →
Weaviate tables
│
▼ consultado en runtime
┌──────────────────────────────────────────────────────────┐
│ LLM serving (vLLM / SGLang) + Retriever │
│ - recibe query del agente │
│ - busca top-K en vector store │
│ - construye prompt + contexto │
│ - genera respuesta con citas │
└──────────────────────────────────────────────────────────┘

Las cinco capas que ves —fuente, ingestión (CDC), transporte (Kafka), procesamiento (Flink), almacenamiento (vector + tablas)— son las que estructuran cualquier RAG sobre datalake serio en 2026. Vamos a cada una.

Capa 1 — Fuentes: tu OLTP como punto de partida

La fuente típica es una base de datos OLTP (Postgres, MySQL, SQL Server). Es donde vive el estado vivo del negocio. La técnica para extraer cambios en tiempo real es Change Data Capture (CDC): leer el log de transacciones de la base de datos (PostgreSQL WAL, MySQL binlog) y convertir cada commit en un evento Kafka.

El estándar OSS es Debezium. Soporta Postgres, MySQL, SQL Server, MongoDB, Oracle, Cassandra y otros. Despliegue típico como cluster Kafka Connect con conectores Debezium.

Ejemplo de configuración Debezium para PostgreSQL:

{
 "name": "postgres-orders-connector",
 "config": {
 "connector.class": "io.debezium.connector.postgresql.PostgresConnector",
 "tasks.max": "1",
 "database.hostname": "postgres.prod.internal",
 "database.port": "5432",
 "database.user": "debezium",
 "database.password": "${secret:postgres-creds}",
 "database.dbname": "ecommerce",
 "database.server.name": "ecommerce-prod",
 "table.include.list": "public.orders,public.users,public.products",
 "publication.autocreate.mode": "filtered",
 "slot.name": "debezium_slot",
 "plugin.name": "pgoutput",
 "topic.prefix": "ecommerce",
 "key.converter": "io.confluent.connect.avro.AvroConverter",
 "value.converter": "io.confluent.connect.avro.AvroConverter",
 "key.converter.schema.registry.url": "http://schema-registry:8081",
 "value.converter.schema.registry.url": "http://schema-registry:8081"
 }
}

Esto produce, por cada commit en la base de datos, un evento Avro al topic correspondiente (ecommerce.public.orders, ecommerce.public.users, etc.) con el cambio: tipo (INSERT/UPDATE/DELETE), valores antes y después, timestamp del commit, posición en el WAL.

Alternativa más simple para 2026: RisingWave puede leerse el WAL de Postgres directamente, sin Debezium ni Kafka Connect intermedio. Cuando el caso es solo CDC sin más fuentes, es operacionalmente más simple. Para arquitecturas con múltiples fuentes (CDC + APIs + scrapers + logs), Debezium sigue siendo la pieza estándar.

Capa 2 — Kafka como transporte y persistencia

El cluster Kafka es donde aterrizan todos los eventos. Decisiones operativas clave:

Topics: raw vs curated

Convención que se ha establecido en 2026:

*.raw: el evento crudo tal como llegó. CDC sin transformar, log de aplicación sin parsear.
*.cleaned: tras dedup, validación de schema, normalización de tipos.
*.enriched: tras añadir metadatos (geolocalización, identificadores cruzados, etc.).
*.embedded: el evento con su vector embedding ya calculado.

Multi-stage topics permite debug por capa y reprocesamiento parcial: si cambias el embedding model, descartar *.embedded y reconstruir desde *.enriched cuesta horas; reconstruir desde *.raw cuesta días.

Schema Registry

Sin schema registry, los topics se rompen silenciosamente cuando alguien cambia el schema en origen. Confluent Schema Registry o el OSS Apicurio son las opciones dominantes.

Formatos comunes:

Avro: schema versionado, evolution rules estrictas. El default histórico.
Protobuf: compatible con stacks gRPC, buena performance.
JSON Schema: textual, debuggable a ojo, menos eficiente.

Para RAG sobre Kafka recomendamos Avro por defecto. Schema evolution es importante porque las tablas origen cambian con el tiempo, y un esquema sin versión rompe consumidores aguas abajo.

Particiones, replicación y retención

Decisiones operativas para topics de RAG:

Particiones: típicamente 3-12. Más particiones = más paralelismo en consumer Flink, pero más overhead. La regla del pulgar: particiones = pico esperado de eventos/s ÷ 1000.
Replication factor: 3 mínimo en producción. La replicación protege contra fallo de broker; con RAG el coste de perder un topic puede ser semanas de re-embedding.
Retención: para topics que alimentan RAG, retención larga o compactada por key. Si el documento doc-42 cambia 100 veces, compactación solo guarda el último estado por key, dejando un log más pequeño y reconstruible. Para datos que no se actualizan (logs históricos), retención por tiempo (90 días, 1 año).

Replicación cross-cluster

Para deployments multi-región o multi-cloud, MirrorMaker 2 o Cluster Linking (Confluent) replican topics entre clusters Kafka. El RAG puede consultar el cluster local sin tener que cruzar región.

Capa 3 — Flink como procesador streaming

Apache Flink es la pieza dominante de stream processing en 2026. Apache 2.0, distribución mature, ecosistema amplio. La alternativa principal es Kafka Streams (más simple, Java-only); RisingWave es la opción emergente para casos SQL puros.

Lo que Flink añade a Kafka:

Stateful streaming: agregaciones temporales, joins entre streams, sesiones.
Exactly-once semantics: con checkpoint coordination.
Watermarks: handling correcto de eventos out-of-order.
UDFs en Python/Java: incluyendo llamadas a modelos LLM.

Flink SQL: la pieza más operacional

Flink SQL es la pieza más usable de Flink para data engineers que no son streaming experts. Veamos un ejemplo realista de pipeline RAG:

-- 1. Definir la fuente: topic Kafka con eventos CDC de documentos
CREATE TABLE documents_raw (
 doc_id STRING,
 title STRING,
 body STRING,
 category STRING,
 updated_at TIMESTAMP_LTZ(3),
 PRIMARY KEY (doc_id) NOT ENFORCED
) WITH (
 'connector' = 'upsert-kafka',
 'topic' = 'ecommerce.public.documents',
 'properties.bootstrap.servers' = 'kafka:9092',
 'key.format' = 'avro-confluent',
 'value.format' = 'avro-confluent',
 'value.fields-include' = 'EXCEPT_KEY'
);

-- 2. Definir el sink: vector store via Kafka topic intermedio
CREATE TABLE documents_embedded (
 doc_id STRING,
 chunk_id INT,
 title STRING,
 chunk_text STRING,
 category STRING,
 embedding ARRAY<FLOAT>,
 embedded_at TIMESTAMP_LTZ(3),
 PRIMARY KEY (doc_id, chunk_id) NOT ENFORCED
) WITH (
 'connector' = 'upsert-kafka',
 'topic' = 'rag.documents.embedded',
 'properties.bootstrap.servers' = 'kafka:9092',
 'key.format' = 'json',
 'value.format' = 'json'
);

-- 3. UDF para chunking (definida en Python o Java)
-- CREATE TEMPORARY FUNCTION chunk_text AS 'com.example.ChunkingUDF';

-- 4. Pipeline: chunkear, embedder, escribir al sink
INSERT INTO documents_embedded
SELECT
 doc_id,
 chunk_idx AS chunk_id,
 title,
 chunk AS chunk_text,
 category,
 OPENAI_EMBEDDING(chunk,
 'text-embedding-3-small') AS embedding,
 CURRENT_TIMESTAMP AS embedded_at
FROM documents_raw
CROSS JOIN UNNEST(chunk_text(body, 512, 64))
 WITH ORDINALITY AS t(chunk, chunk_idx);

Lo que pasa aquí, línea a línea:

La tabla documents_raw lee el topic CDC en modo upsert-kafka (cada nuevo evento por la misma key reemplaza el anterior). Esto refleja correctamente la semántica “esta es la última versión del doc 42”.
La tabla documents_embedded será el topic intermedio donde Flink escribe los chunks embedded.
La UDF chunk_text (definida en Python o Java) divide cada doc en chunks de 512 tokens con overlap de 64.
La consulta INSERT INTO se ejecuta continuamente: cada evento nuevo en documents_raw se chunkea, cada chunk se embedea con OPENAI_EMBEDDING (función built-in de Flink SQL en Confluent Cloud 2026), y se escribe al topic embedded.

OPENAI_EMBEDDING puede sustituirse por una función custom que llame a un modelo self-hosted (vLLM con un encoder), a SentenceTransformers, o a un servicio managed. La sintaxis es la misma; cambias el provider.

Watermarks y late events

Para casos donde un evento puede llegar tarde (eg el WAL de Postgres se retrasa porque hubo un network blip), Flink permite definir watermarks:

CREATE TABLE documents_raw (
 doc_id STRING,
 title STRING,
 body STRING,
 updated_at TIMESTAMP_LTZ(3),
 WATERMARK FOR updated_at AS updated_at - INTERVAL '5' MINUTE
) WITH (...)

Esto le dice a Flink “asume que ningún evento llega más de 5 minutos tarde respecto al timestamp del evento”. Para joins y agregaciones temporales, Flink usa el watermark para decidir cuándo “cerrar” una ventana.

Capa 4 — Sinks a vector stores

El último paso es indexar los embeddings en un vector store. Tres patrones en 2026:

Patrón A — Kafka Connect sink directo

Cada vector store tiene su connector oficial:

Milvus: sink connector oficial de Zilliz. Soporta named/unnamed dense/sparse vectors.
Qdrant: sink connector oficial. Soporta dense, sparse, multi-vector.
pgvector: no tiene connector dedicado, pero se usa el JDBC Sink Connector con SQL custom.
Weaviate: connector community.
LanceDB: connector community.

Ejemplo de configuración Milvus sink:

{
 "name": "milvus-rag-embeddings-sink",
 "config": {
 "connector.class": "com.milvus.io.kafka.MilvusSinkConnector",
 "tasks.max": "3",
 "topics": "rag.documents.embedded",
 "milvus.host": "milvus.prod.internal",
 "milvus.port": "19530",
 "milvus.collection.name": "documents",
 "milvus.collection.dim": "1536",
 "milvus.collection.partition": "default",
 "key.converter": "org.apache.kafka.connect.storage.StringConverter",
 "value.converter": "org.apache.kafka.connect.json.JsonConverter",
 "value.converter.schemas.enable": false
 }
}

Tres tasks en paralelo (tasks.max: 3) consumen el topic embedded y escriben a la colección Milvus. La latencia desde “evento en Kafka” hasta “vector indexable en Milvus” es típicamente <5 segundos.

Patrón B — pgvector con CDC pipe directo

Para equipos que ya viven en PostgreSQL, pgvector es la opción de menor fricción. Patrón: el mismo cluster Postgres origen tiene una segunda DB para embeddings con extensión pgvector activada; el pipeline Flink escribe directamente vía JDBC.

-- En el cluster Postgres con pgvector activado
CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE document_embeddings (
 doc_id TEXT,
 chunk_id INT,
 chunk_text TEXT,
 category TEXT,
 embedding vector(1536),
 embedded_at TIMESTAMP,
 PRIMARY KEY (doc_id, chunk_id)
);

CREATE INDEX ON document_embeddings
 USING hnsw (embedding vector_cosine_ops)
 WITH (m = 16, ef_construction = 64);

Ventajas: tu mismo DBA opera todo, transactionality cross-tables, joins con metadatos relacionales triviales. Limitación: a >10M vectores, el rendimiento de pgvector empieza a ceder respecto a sistemas dedicados.

Patrón C — Confluent Tableflow → Iceberg + vector search Flink SQL

Esta es la novedad 2026 que cambia la mecánica. Confluent Tableflow materializa automáticamente topics Kafka como tablas Apache Iceberg o Delta Lake. Características:

Sin pipeline ETL: no escribes Flink/Spark jobs para mover Kafka a tabla. Lo hace Tableflow.
Schema evolution automática: cambios en el schema del topic se reflejan en la tabla.
Catálogo unificado: la tabla aparece en Glue, Unity Catalog, Snowflake, Databricks. Cualquier motor analítico la consulta sin copiar datos.
CDC nativo: maneja inserts, updates, deletes correctamente.
30-50% menos TCO según las cifras que Confluent publica vs pipelines tradicionales.

Y desde 2026, Tableflow + Flink SQL ofrecen vector search nativo integrado con Cosmos DB y Amazon S3 Vectors. La consulta RAG se puede hacer directamente en Flink SQL:

SELECT doc_id, chunk_text, category
FROM documents_embedded
WHERE VECTOR_SEARCH(embedding,
 OPENAI_EMBEDDING('query del usuario', 'text-embedding-3-small'),
 top_k => 10) > 0.7
ORDER BY VECTOR_SEARCH_SCORE DESC;

Esto unifica capas que antes eran separadas (vector store + analytics). Para muchos casos, elimina la necesidad de mantener un vector store dedicado.

El MCP server oficial de Confluent

Una pieza añadida en 2026 que merece mención: Confluent ha publicado un MCP server oficial que expone Kafka, Flink y Tableflow como tools accesibles a agentes IA vía MCP. Cualquier MCP client (Claude Desktop, Cursor, agentes propios) puede:

Listar topics, leer mensajes recientes, publicar a topics.
Ejecutar queries Flink SQL en lenguaje natural (“dame las órdenes de las últimas 24 horas con valor > 1000€”).
Consultar tablas Tableflow Iceberg.
Gestionar conectores Kafka Connect.

Esto cierra el círculo: tu agente IA, además de leer datos del datalake vía RAG (con vector search), puede escribir datos al log (vía MCP) y disparar transformaciones (vía Flink SQL en natural language). Es el punto de fusión más profundo entre LLM ops y data ops del año.

Conexión con la serie anterior: este MCP server emite traces con las OpenTelemetry GenAI MCP semantic conventions que cubrimos en el post de MCP observability. Los spans aparecen en Langfuse, Phoenix o tu OTel backend con la cardinalidad correcta. Cero código de instrumentación.

Vector stores: comparativa 2026

Las cinco opciones dominantes:

Vector store	Licencia	Operación	Cuándo encaja
pgvector	Postgres ext, OSS	Tu DBA	<10M vectores, equipo Postgres-heavy
Qdrant	Apache 2.0	Self-host o managed	Mid-scale, foco performance
Milvus	Apache 2.0	Self-host o Zilliz Cloud	Large-scale, foco escalabilidad
Weaviate	BSD-3	Self-host o managed	Hybrid search nativo, semantic rich
LanceDB	Apache 2.0	Embedded o serverless	Small-medium, simplicidad

La selección depende de:

Escala: pgvector se queda corto >10M vectores. Milvus y Qdrant escalan a billones.
Hybrid search: Weaviate trae lexical + vector nativo. Otros lo soportan pero menos integrado.
Operación: pgvector si ya tienes Postgres operado. Qdrant si quieres simplicidad. Milvus si necesitas máxima escala.
Cloud managed: Zilliz Cloud para Milvus, Qdrant Cloud para Qdrant, Pinecone si quieres SaaS puro (sin OSS detrás).

Freshness vs accuracy: el trade-off operativo

Una decisión crítica que cualquier sistema RAG sobre Kafka debe responder: ¿cuándo se considera que un nuevo documento está “live” en el índice?

Tres opciones:

Streaming síncrono: el evento llega a Kafka, Flink lo embedea, el sink lo escribe al vector store, y solo entonces se considera live. Latencia típica: 1-5 segundos. La mejor freshness. Pero si el embedding model falla o el vector store es lento, los eventos se acumulan en el topic.

Streaming asíncrono con baseline: el evento se considera live inmediatamente; un proceso de fondo lo embedea cuando puede. Mientras tanto, queries que pidan ese documento no lo encuentran. Latencia típica: 5-60 segundos. Aceptable para la mayoría de aplicaciones.

Batch micro: se procesa en mini-batches cada 1-5 minutos. Menos eficiente que streaming continuo pero más estable bajo carga variable. Latencia: 1-5 minutos.

La decisión depende del SLA del producto. Para chatbots de soporte al cliente, 5-60 segundos es aceptable. Para sistemas que reaccionan a eventos críticos (precios financieros, alarmas), streaming síncrono es necesario.

Schema evolution y reembedding

Cuando el embedding model cambia (cambias de text-embedding-3-small a text-embedding-3-large, o pasas de OpenAI a Cohere), los vectores existentes en el índice son incompatibles: dimensiones distintas, espacios semánticos distintos. La distancia entre un vector viejo y uno nuevo no significa nada.

Patrón estándar para handle de esto: dual-index durante la migración.

T0: índice activo es V1 (embedding model A).
T1: empieza pipeline paralelo que escribe a un índice V2 (embedding model B), consumiendo el topic desde offset 0 (reprocesar todo el log).
T2: V2 ha caught-up al presente.
T3: cambias el retriever para que use V2.
T4: una semana después, descartas V1.

El log de Kafka hace este patrón factible porque es inmutable y reproducible. Sin el log, este patrón se vuelve un proyecto de migración de datos de semanas.

Trampas operativas

Topics sin retención adecuada

Configurar topics con retención de 7 días pensando “ya tengo el vector store” lleva a perder la capacidad de reconstruir si el vector store falla. Retención larga (90+ días) o compactada por key para topics que alimentan RAG.

CDC pesado en cargas pico

Debezium leyendo el WAL en horas pico puede impactar performance de la base de datos origen. Replica de lectura dedicada para Debezium, no la primaria de producción. O usar logical replication específica solo para las tablas necesarias.

Embedding cost run-away

OPENAI_EMBEDDING en cada evento de un topic con millones de mensajes/día son miles de USD/mes. Estrategias: filtrar antes de embedder (solo embedder lo que aporta valor); deduplicar por hash de contenido; usar embedding models open-source self-hosted (BGE, E5, GTE) cuando el coste cloud sea prohibitivo.

Reembedding lento por throughput limitado

Recalcular 10M embeddings con OpenAI API a 3000 req/min tarda 55 horas. Si esperas a un incidente para reembeder, son dos días sin servicio. Embedding throughput es un capacity planning explícito; reservar capacity o tener un job offline pre-arrancable.

Schema breaks aguas abajo

Un cambio en el schema del topic raw rompe Flink jobs aguas abajo. Schema Registry con compatibility BACKWARD obligatoria; nunca ALLOW_ALL. Y test schema evolution en CI.

Vector store sin backup

Tu vector store tiene 50M vectores. Es la única copia (los topics expiraron). Un fallo lo borra. Vector stores deben ser backed up igual que cualquier persistencia primaria. Para Milvus/Qdrant: snapshots periódicos. Para pgvector: el propio pg_dump.

Multi-region sin replicación cross-cluster

Tu RAG sirve a usuarios en US y EU. El vector store está en US-east. Latencia desde EU = 100ms+ por query. MirrorMaker o Cluster Linking para replicar topics y vector stores en ambas regiones.

Lo que no hemos cubierto

Hybrid search en producción: combinar BM25/lexical + vector + reranker. Tema de su propio post.
Multimodal RAG: indexar imágenes, audio, vídeo además de texto. Embeddings multimodales (CLIP, Imagebind), arquitectura específica.
GraphRAG: usar conocimiento estructurado (knowledge graphs) además de vector retrieval. Microsoft GraphRAG, LlamaIndex KnowledgeGraphQueryEngine.
RAG con ACL multi-tenant: filtrar por permisos en runtime. Patrón con metadatos en el vector store + filtros server-side.
Query rewriting con LLM: usar un primer LLM para expandir la query antes del retrieval (HyDE, multi-query, step-back prompting).

Referencias

Kafka y stream processing:

Apache Kafka y Debezium.
Confluent Schema Registry y Apicurio Registry.
Apache Flink y Flink SQL docs.
RisingWave — alternativa SQL streaming con embedding built-in.

Vector store connectors:

Tableflow y arquitectura 2026:

RAG streaming:

Cross-references:

Post anterior: MLOps específico para LLMs en 2026: el panorama.
Serie post-tracing: Evals, Guardrails, MCP observability, eBPF + drift.
Serie eBPF: eBPF de cero a Cilium, Tetragon, Hubble, AgentSight.