Cívica: Búsqueda en Lenguaje Natural Sobre 2.613 Proyectos de Ley Reales
Sobre el corpus legislativo completo de Chile — Cámara, Senado y BCN Ley Chile — Cifrid diseñó y construyó la arquitectura de búsqueda en lenguaje natural (Postgres relacional + Qdrant como vector store) de Cívica, iniciativa de Fundación para el Cambio (Providencia). Documentamos acá la arquitectura real, con sus límites actuales — sin inflar lo que todavía es trabajo en curso.
El Problema Real
Los Datos Públicos Existen. Consultarlos, no.
Chile publica datos legislativos abiertos — Cámara de Diputados, Senado, BCN Ley Chile — pero en formatos pensados para máquinas (XML, web services WSDL, HTML con WAF anti-bot), no para que una persona pregunte algo simple como "¿qué votó mi diputado sobre pensiones este año?".
El dato está, pero disperso en decenas de endpoints distintos, con esquemas propios cada uno. Cruzar "qué se propuso → cómo se votó → en qué ley terminó → de qué trata" requiere trabajo de ingeniería real, no solo acceso a una API.
Arquitectura
Relacional para Estructura, Vectorial para Lenguaje
La misma separación que usamos en cualquier contrato I+D de datos: lo que tiene estructura fija (personas, votos, fechas) vive en un modelo relacional; lo que es texto libre para búsqueda en lenguaje natural vive en un vector store aparte.
Postgres Relacional
Diputados, senadores, proyectos, votaciones, leyes, comisiones — con boletín como clave universal que conecta todo el ciclo legislativo.
Qdrant Vector Store
Índice separado para búsqueda en lenguaje natural — la "Licuadora Semántica". Es un índice para encontrar el registro relevante, no la fuente de verdad del dato: el cruce con Postgres es por ID, nunca duplicando contenido.
Ingesta de Fuentes Oficiales
Cámara (WServices XML), Senado (WS público), BCN Ley Chile (XML articulado) — ingesta idempotente e incremental, no scraping frágil.
Por Qué Este Stack
Postgres Ya Tenía pgvector Disponible. No lo Usamos Ahí.
La ruta más simple para agregar búsqueda vectorial a un sistema que ya corre en Postgres es activar la extensión pgvector (CREATE EXTENSION vector;) y guardar los embeddings en la misma base. Estaba disponible en la infraestructura de Cívica. Decidimos no usarla ahí — los vectores viven en Qdrant, un motor separado, cruzado con Postgres solo por ID (boletín).
La razón es de escalabilidad, no de moda tecnológica: mezclar lo vectorial dentro del motor relacional acopla el rendimiento de la búsqueda semántica al de las consultas transaccionales — cuando una crece, castiga a la otra. Separar el motor vectorial permite escalarlo o reindexarlo sin tocar el modelo relacional que ya funciona — hoy corre un índice disperso por tokens y uno denso por embeddings en paralelo, ambos en Qdrant.
Conocemos bien el mercado chileno de RAG documental: Neuronet, RAGTech, Confirmer360, rexlabs, AIX — todos ofrecen la misma capa, "base vectorial" separada de la ingesta, con pgvector/Chroma/Pinecone como opciones más citadas. Hasta ahí, nada distinto.
La diferencia está en lo que publicamos: el porqué de cada decisión de arquitectura, con números de una implementación en producción (2.613 proyectos, 10.353 votaciones), no una plantilla de proyecto ni una demo con datos de prueba.
Un matiz que no siempre queda explícito en cómo se vende RAG: el vector store no es la fuente de verdad del dato, es el índice para encontrarlo. Qdrant responde "estos son los registros relevantes para tu consulta" — Postgres sigue siendo quien tiene el dato real, versionado y auditable. Es el mismo principio de diseño que aplicamos en cualquier arquitectura de datos propia: la búsqueda vectorial sirve para ubicar qué fuente o expediente conviene consultar, nunca para reemplazar el repositorio autoritativo del hallazgo.
Estado Real — Sin Inflar
Es Búsqueda Híbrida: Dos Índices, y Postgres Filtra lo que se Expone
Documentar el estado real de un sistema — no solo el ideal — es parte de cómo entregamos cualquier reporte técnico. La búsqueda de Cívica corre un doble índice en Qdrant: uno disperso ("sparse", tokens con hash FNV-1a) y uno denso (embeddings). En la práctica, el índice sparse gana la mayoría de las consultas — quien busca sobre datos legislativos suele escribir términos exactos, nombres o números de boletín, más que conceptos abstractos — pero el denso sigue corriendo en paralelo y aporta en las consultas más conceptuales (sinónimos, correlaciones tipo "dieta → sueldo de diputados").
Ningún índice vectorial expone el dato directamente: los resultados de ambos se filtran después contra Postgres, la fuente de verdad. El vector store responde qué es relevante; la base relacional confirma que lo mostrado es el dato real y vigente. Es el mismo criterio que aplicamos en cualquier contrato I+D: correr ambos motores donde el patrón real de consulta lo justifica, y dejar que la base relacional — no el índice — decida qué se expone.
Qué Prueba Esto
No es una Demo. Es Cómo Trabajamos.
Cívica es una iniciativa de Fundación para el Cambio (Providencia) — Cifrid diseñó y construyó su arquitectura de datos + búsqueda en lenguaje natural como contrato I+D, y es quien documenta acá las decisiones técnicas reales detrás. No son maquetas ni copy-paste de terceros: es la misma arquitectura, validada en producción, sobre datos públicos reales y a escala nacional. Si tu empresa necesita algo equivalente sobre tus propios datos (documentos internos, contratos, normativa), es la misma base técnica ya probada.
Contratos I+D en IA y Datos
Misma arquitectura relacional + vectorial, aplicada a tus documentos y datos propios. Presupuesto cerrado por fase.
Modelo de Lenguaje Propio (SLM)
El siguiente paso natural cuando la búsqueda sparse ya no alcanza: un modelo entrenado con tu información.
778K Transferencias del Estado, Analizadas
Otro dataset público a escala nacional que procesamos completo: $22,7 billones CLP en 6 períodos de gobierno.
Consumo de IA en Producción
Cívica ya corre en producción — esto cubre cómo optimizamos el costo de un sistema de IA una vez que está ahí.
Cívica es el caso real de búsqueda híbrida en producción de esta serie: