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, reindexarlo o migrarlo de estrategia (hoy sparse por tokens, mañana embeddings densos) sin tocar el modelo relacional que ya funciona.
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
Hoy es Búsqueda por Tokens. Los Embeddings Densos son el Siguiente Paso.
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 hoy convierte la consulta en lenguaje natural a tokens (palabra + slug, hash FNV-1a) y hace kNN sobre un vector disperso ("sparse") en Qdrant, no sobre embeddings densos todavía. Es semántica en el sentido de que entiende variantes de lenguaje (sinónimos, correlaciones tipo "dieta → sueldo de diputados"), pero no es aún el matching semántico profundo de un embedding denso entrenado.
Es exactamente el criterio de ingeniería que aplicamos en cualquier contrato I+D: dimensionar la arquitectura al caso de uso real, y escalar a embeddings densos cuando el caso de uso lo exija, no adoptar la solución más compleja por defecto solo para impresionar en el paper.
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 densa de esta serie: