Metodología y precisión

1. Qué hace el sistema con un pliego

El recorrido completo, sin cajas negras intermedias. Cada etapa deja rastro en la base de datos, así que un análisis siempre se puede volver a mirar: qué documentos entraron, qué fragmentos se recuperaron, qué modelo respondió y qué devolvió.

1. Sincronización. Se leen a diario las fuentes oficiales: el feed ATOM de la PLACSP (CODICE 2.07) y la API de TED. Son los datos abiertos que publica el propio órgano de contratación, no una copia de terceros.
2. Descarga del expediente. PCAP, PPT y anexos del propio anuncio.
3. Troceado con contexto. El PDF se parte respetando la unidad de la cláusula (parent-document chunking): un fragmento no corta un artículo por la mitad, y el fragmento recuperado se devuelve junto a su bloque padre, para que una condición no llegue al modelo separada de aquello a lo que condiciona.
4. Recuperación léxica (BM25) dentro del expediente. El modelo solo ve fragmentos de ese pliego. No hay generación a libro abierto sobre "lo que suele pedirse" en una licitación: si algo no está en el documento, no hay de dónde sacarlo.
5. Extracción de requisitos. Un LLM devuelve JSON con contrato estricto: solvencia técnica y económica, clasificación, garantías, criterios de adjudicación, plazos y exclusiones. Cada requisito viaja con los identificadores de los fragmentos de los que sale.
6. Go/No-Go. El perfil de la empresa se contrasta contra esos requisitos. Hay tres veredictos posibles, y el tercero importa tanto como los otros dos: go, no_go y needs_human_check. Cuando la respuesta del modelo no cumple el contrato, se degrada a needs_human_check: nunca se rellena con una suposición.
7. Borrador de propuesta. Redacción asistida sobre los requisitos ya extraídos y citados, siempre marcada como borrador sujeto a revisión.

2. Precisión medida, no prometida

La medición se hace sobre un conjunto de control de 7 pliegos reales anotados a mano: alguien leyó el expediente y escribió qué requisitos contiene y qué veredicto merece el perfil de prueba. Después se ejecuta el sistema completo —indexar, extraer, evaluar— y se comparan las dos cosas.

Esta ejecución usó el backend agy con el modelo gemini-3.7-flash-high, el 21/08/2026. Tardó 553 segundos y consumió 395.345 tokens de entrada.

Qué significa cada una, sin adornos. La precisión es cuántos de los requisitos que el sistema extrae están efectivamente en el pliego. El recall es cuántos de los requisitos que anotó el humano encuentra el sistema. Las anotaciones afirman la presencia de un requisito, no su redacción exacta, y la precisión se calcula solo sobre las categorías que el caso anota de forma exhaustiva: anotar a medias nunca cuenta como error del extractor.

Caso por caso

El agregado esconde la varianza, así que va también el detalle. Cada fila es un expediente real; el informe completo enumera, además, cada anotación que el sistema no encontró.

Cómo reproducirlo

El informe íntegro —incluida la lista de todo lo que el sistema no encontró en cada pliego— está versionado en el repositorio, en eval/reports/iter6-agy-flash.md. La medición se relanza con:

uv run python -m eval.run --backend agy

3. Cada requisito, con su cita

Ningún requisito extraído se muestra sin decir de dónde sale. Cada uno guarda los identificadores de los fragmentos del expediente que lo sostienen, y en la ficha de la licitación se puede abrir el texto citado y leerlo.

La evaluación no se conforma con que la cita exista: comprueba dos fallos distintos. Una cita colgante apunta a un fragmento que no existe. Una cita sin soporte apunta a un fragmento que sí existe pero cuyo texto no cubre lo que el requisito afirma. Solo cuenta como válida la cita en la que el texto citado sostiene la afirmación. En la última medición, la validez de citas fue de 100,0 %.

4. La revisión humana no es opcional

Todo lo que genera el sistema es un borrador. La responsabilidad de lo que se presenta es de la persona que lo firma, y el producto está construido para que esa frontera no se pueda cruzar por accidente:

• Nunca se envía nada a un portal oficial. No existe —ni existirá— un flujo que presente una oferta de forma automática en la PLACSP o en cualquier otra plataforma de contratación. La presentación la hace una persona.
• El contenido generado va etiquetado como tal, con su aviso de revisión, en pantalla y en el documento descargado.
• La incertidumbre se señala: needs_human_check es un veredicto de primera clase, no un error. Es lo que el sistema responde cuando no puede sostener una conclusión.
• Queda traza de cada análisis: qué etapa se ejecutó, con qué modelo, cuánto tardó y cómo terminó. Y los requisitos extraídos se versionan por ejecución en lugar de sobrescribirse, así que un análisis anterior sigue siendo consultable meses después.

5. El radar de recurrencia: un resultado negativo, publicado

El sistema detecta contratos que se repiten cada año y proyecta cuándo volverán a salir. Una función de predicción sin backtest es una suposición con interfaz, así que la medimos: se entrena el detector solo con adjudicaciones anteriores a una fecha de corte y se comprueba después qué se publicó de verdad.

Protocolo: las series se detectan solo con adjudicaciones anteriores al corte; cada adjudicación posterior se asigna a una serie ya entrenada con la misma regla de similitud. Un acierto es una serie que volvió a publicarse dentro de la ventana predicha. Una predicción anclada en el plazo de presentación se compara contra el plazo real, no contra la fecha de adjudicación: son dos relojes distintos separados por el tiempo de resolución.

9609 adjudicaciones con fecha, del 2018-04-05 a 2026-08-29 (3068 días).
Corte de referencia: 2026-06-01 · horizonte 90 días · tolerancia 0 días · mínimo 3 ediciones.
Medición del 30/08/2026.

• Ediciones de entrenamiento (antes del corte): 924
• Ediciones de evaluación (dentro del horizonte): 5387
• Series detectadas: 885, de las cuales 6 llegaban a 3 ediciones (0.7%)
• Predicciones vigentes en el periodo: 2 (descartadas por ventana ya cerrada al corte: 0)
• Falsos positivos: 1 · falsos negativos: 40

Publicamos esto tal cual porque es lo que mide la evidencia disponible hoy. El radar sigue en el producto, señalado como lo que es: una hipótesis con fecha, medible en cuanto el histórico de adjudicaciones tenga fondo suficiente. Se reproduce con uv run python -m ingestion.cli backtest-radar --cutoff 2026-06-01 --horizonte 90.

6. Posición regulatoria

Reglamento europeo de IA. Licia es un asistente privado que usa internamente la empresa que licita para entender documentación y estructurar su propio texto comercial. No es —ni se vende como— una herramienta de la Administración para evaluar, puntuar o descartar licitadores: ese uso sí entra en el Anexo III de alto riesgo. De esa posición salen tres líneas que el producto no cruza: nada orientado a que la Administración evalúe candidatos, ningún envío automático a portales oficiales, y revisión humana obligatoria del contenido generado antes de cualquier uso externo.

Protección de datos. El perfil de tu empresa y sus documentos son datos confidenciales del cliente, aislados por inquilino. No entrenamos modelos con datos de clientes. Los PDF descargados de un expediente se borran del disco en cuanto se han indexado: son un insumo de un solo uso, no un archivo que acumulamos. Los datos de licitación en sí son datos abiertos del sector público (Ley 37/2007), aunque los nombres de adjudicatarios que aparecen en ellos se tratan como datos personales incidentales — por eso las fichas de empresa están detrás de identificación y fuera de los buscadores. Detalle completo en la política de privacidad.

Derecho de contratos. El análisis se apoya en la Ley 9/2017 (LCSP): las categorías de solvencia, clasificación y garantías que el sistema extrae son las que la ley y los pliegos españoles usan, no una traducción de un marco de otro país.

7. Lo que no afirmamos

• Que 7 pliegos sean una muestra grande. Son pocos y están elegidos para cubrir tipos distintos de expediente; sirven para detectar regresiones y para dar un orden de magnitud, no para publicar un intervalo de confianza.
• Que el sistema encuentre todos los requisitos. El recall de la última medición (79,9 %) está por debajo del objetivo (≥ 80,0 %) y lo publicamos igual. El pliego sigue siendo la fuente; el análisis es un acelerador de la lectura, no un sustituto.
• Que el radar de recurrencia acierte. Hoy no es evaluable con el histórico disponible, y así consta arriba.
• Que un veredicto Go/No-Go sea una opinión jurídica. No lo es, y no sustituye al criterio de quien firma la oferta.

Si detectas un número de esta página que no cuadra con el informe del repositorio, es un error nuestro y queremos saberlo: pablomatheis@gmail.com.