Construir un RAG que no miente no es cuestión del modelo. Es cuestión de lo que instrumentas antes de que el modelo siquiera entre en juego.
1. Schema de citación, no retroajustado
Cada chunk lleva identificador estable del documento fuente, rango de páginas, tipo de contenido, hash. Si esto lo diseñas en la versión 1.2, la versión 1.1 del corpus es basura. Se decide una vez y se convive con ello.
2. Versión del embedding
El día que se cambie de modelo — y lo haré — los vectores antiguos dejan de tener sentido. Si no se marca cada vector con el modelo y versión con el que se generó, no se puede filtrar al hacer retrieval y acabas mezclando espacios vectoriales incompatibles. Yo lo codifico directamente dentro del `vector_id` para que no haya forma de meter la pata.
3. Parser que preserva estructura
Aplanar una tabla a texto lineal pierde relaciones entre columnas. "2.500 / 15 / 2025-04-30" sin saber que son precio unitario, cantidad y fecha de entrega no sirve para nada. Tablas son tablas: `chunk_kind='table'`, filas preservadas, markdown si hace falta.
4. Filtros post-retrieval
El vector store solo indexa lo que cabe en su metadata. Todo lo demás se filtra después del hit, con un JOIN contra la base de datos. Si no tienes esa capa, acabas devolviendo chunks correctos del documento equivocado.
5. Idempotencia del chunking
Un mismo documento indexado hoy y dentro de un mes tiene que producir exactamente los mismos chunk_ids. Si no, el reproceso duplica vectores, rompe citas y envenena el corpus. Tests que lo verifican desde el primer día.
Ninguna de estas cinco cosas es un "nice to have". Son la línea que separa un sistema que se puede auditar de uno que no.
El modelo vino después.
# RAG #Python #VectorSearch #DataEngineering #SoftwareEngineering