# Pre-registro Entrega 2: el radar de licitaciones por perfil de empresa

> **Documento SELLADO el 15-07-2026** con las decisiones resueltas por Alfonso ese
> mismo día. En el momento del sellado no se ha corrido ningún modelo, no se ha
> calculado ni un embedding y NO se ha mirado el periodo de evaluación
> (2024) para nada de esta entrega. Las cifras de justificación de este documento
> se han medido SOLO con el periodo de entrenamiento (adjudicaciones resueltas
> hasta 2023-12-31), para poder afirmar honestamente que las decisiones se toman
> sin haber visto el examen. El sellado (commit + OpenTimestamps) se hará cuando
> Decisiones resueltas por Alfonso el 15-07-2026 ("adelante con lo propuesto"), igual que en la
> Entrega 1.
>
> Regla de oro del pre-registro: lo que aquí se fije NO se recalcula ni se ajusta
> después de ver resultados. Si una elección sale mal, se publica igual con su
> pero. Complementa `pre-registro-entrega-1.md` (mismo protocolo, verdad distinta),
> `bd-diseno.md` (el esquema y la identidad estable de empresa y órgano),
> `pipeline-v0-informe.md` (los números del dato) y `sondeo-datos.md` (origen,
> prior art y trampas). El objeto del contrato, la materia prima de los embeddings,
> lo está extrayendo un agente en paralelo y se da por hecho que existirá la
> columna `expediente.objeto_contrato` (migración 006 ya aplicada).

## 1. La pregunta, en una frase

Dado el historial de licitación de una empresa hasta una fecha de corte (a qué se
presentó y ganó antes), y viendo solo lo que se sabía cuando se publicó cada
licitación nueva, ¿el sistema pone en la bandeja de esa empresa las licitaciones
a las que de verdad acabó presentándose y ganando después del corte? Y lo más
importante, la vara honesta: ¿lo hace mejor que una regla simple de "más de lo
mismo" (mismo sector y mismo comprador habitual), y sabe decir cuándo no tiene
suficiente historial para opinar?

Dicho para un no técnico: si esta empresa fuera cliente el 1 de enero de 2024,
¿le habríamos enseñado a tiempo las licitaciones que efectivamente ganó ese año,
o se le habrían escapado?

## 2. El universo: qué empresas entran en el examen

La unidad de esta entrega no es el lote (esa era la Entrega 1), es la **empresa**.
La base tiene 72.510 empresas adjudicatarias distintas por NIF normalizado
(`bd-diseno.md`), 3.035 de ellas UTE. Pero la mayoría aparecen una sola vez: no
se le puede construir un perfil a quien solo ha ganado un contrato en su vida.

**El problema del historial mínimo, con la distribución real medida.** Contando,
por empresa, cuántas licitaciones ganó con fecha de adjudicación saneada anterior
o igual a 2023-12-31 (solo periodo de entrenamiento), la distribución es muy
sesgada:

| Historial previo al corte | Empresas | % de las que tienen 1 o más |
|---|---|---|
| 1 o más adjudicaciones | 53.315 | 100 % |
| 2 o más | 25.948 | 48,7 % |
| 3 o más | 17.740 | 33,3 % |
| 5 o más | 11.123 | 20,9 % |
| 10 o más | 5.576 | 10,5 % |
| 20 o más | 2.461 | 4,6 % |

Mediana 1, percentil 90 igual a 10, máximo 886. La mitad de las empresas con
algún historial han ganado exactamente una vez. Un perfil estable (sector típico,
comprador típico, rango de importe) necesita más de un caso, o el perfil es el
propio caso y no se puede backtestar con honestidad.

**Regla del examen que se propone:** entran en el examen las empresas con al menos
**N adjudicaciones ganadas** antes del corte (fecha de adjudicación saneada hasta
2023-12-31). Las que no llegan a N quedan fuera y se cuentan (ver abstención,
punto 7). **N = 5, decidido por Alfonso el 15-07-2026** ("adelante con lo propuesto"):
deja 11.123 empresas (el 20,9 % de las que tienen algún historial), suficiente
para un perfil y suficiente masa para un examen creíble. Se valoraron N = 3
(17.740 empresas) y N = 10 (5.576); cuanto más alto N, perfil más rico pero
examen menos representativo del tejido
real (donde dominan las pymes de pocos contratos). El número se congela aquí.

**Un pero honesto de esta medición, declarado ya:** el filtro por fecha de
adjudicación deja fuera 76.201 adjudicaciones con empresa pero sin fecha de
adjudicación (el 15,6 % de las adjudicaciones con ganador), porque sin fecha no se
puede ubicar antes o después del corte sin arriesgar fuga temporal. Eso significa
que estos recuentos de historial **subestiman** el historial real de algunas
empresas. Es la política de la casa: no se imputa una fecha que no está. Al
construir el perfil de cada empresa se podrá recuperar parte de ese historial
usando la fecha del snapshot (`fecha_aviso`, siempre presente) como sello de
"conocido antes de", pero para fijar el umbral N se usa la medición conservadora
de arriba.

## 3. La verdad proxy, con su sesgo declarado sin adornos

Aquí está el problema honesto de esta entrega, y se dice el primero: **"licitación
interesante para una empresa" no tiene una verdad limpia.** Nadie etiquetó qué le
interesaba a cada empresa. Lo único observable y verificable es el comportamiento
real: a qué se presentó y ganó de verdad después del corte.

**El proxy exacto:** para cada empresa del examen, sus **positivos observables**
son las licitaciones publicadas en 2024 donde esa empresa aparece como
adjudicataria (misma identidad de NIF normalizado). Si el sistema, mirando solo el
pasado, le habría enseñado esas licitaciones, acierta. Si no, falla. Es el mismo
principio de "trampa con el futuro" de la Entrega 1: se sella la predicción y se
compara contra lo que de verdad pasó.

**El sesgo del proxy, declarado tal cual, sin esconderlo:** solo vemos las
licitaciones que la empresa **ganó**, no todas a las que **se presentó**. El dato
de PLACSP trae el adjudicatario (quién ganó) y el número de licitadores (cuántos
se presentaron), pero **no trae la identidad de los perdedores** (limitación
conocida, `bd-diseno.md` y `sondeo-datos.md`). Por eso "a lo que se presentó" no
es observable y usamos "lo que ganó" como sustituto.

Las consecuencias, dichas de antemano:

- Es un proxy **conservador y sesgado a la baja**. Una licitación que la empresa
  vio, le interesó, se presentó y perdió, cuenta como negativo en nuestro examen
  aunque para un radar habría sido un acierto legítimo (se la enseñamos y ella la
  consideró). El recall que midamos es por tanto un **suelo**, no el techo: el
  sistema real acertaría más de lo que este examen le reconoce.
- No mide "interés", mide "encaje ganador". Son parientes pero no lo mismo, y se
  dice con esa palabra.
- En un no técnico: "solo sabemos las que ganó, no a todas las que se presentó,
  así que le estamos poniendo el examen más difícil de lo justo, y aun así lo
  medimos así de duro a propósito."

## 4. El corte temporal y la regla anti-fuga

Mismo corazón de credibilidad que la Entrega 1, adaptado a que aquí hay dos cosas
con fecha: el historial que forma el perfil y la licitación que se evalúa.

**Entrenamiento (lo que forma el perfil de cada empresa):** todo lo resuelto el
31-12-2023 o antes, con la misma regla de fecha de desenlace de la Entrega 1
(fecha de adjudicación para las adjudicadas, saneada al rango plausible; nunca el
año del fichero, que es acumulativo y mete futuro).

**Examen (los positivos observables):** licitaciones **publicadas en 2024** cuyo
desenlace se conoce en 2024 y cuya adjudicataria es una empresa del examen. Misma
acotación por fecha de publicación real que la Entrega 1, por limpieza.

**La regla anti-fuga, en una frase que un no técnico entiende:** cuando el sistema
decide si enseñarle a una empresa una licitación concreta, solo puede usar lo que
se sabía el día en que esa licitación se publicó. En concreto:

- El **perfil de la empresa** (su historial de sectores CPV, importes típicos,
  órganos habituales, y el embedding agregado de los objetos de contrato que ya
  ganó) se construye SOLO con adjudicaciones resueltas **antes de la fecha de
  publicación** de la licitación que se está evaluando. No al corte fijo de
  2023-12-31 y ya, sino móvil: para una licitación publicada en julio de 2024, el
  perfil puede incluir lo que la empresa ganó hasta junio de 2024; para una de
  enero, solo hasta diciembre de 2023. Ningún agregado del perfil puede contener
  la propia licitación que se evalúa ni ninguna posterior.
- El **embedding de la licitación evaluada** se calcula solo con su objeto de
  contrato y datos publicados el día de su publicación (presupuesto, CPV, órgano,
  procedimiento). Nada del resultado.
- Ningún agregado, ni del perfil ni del entorno, puede incluir el futuro.

Este punto móvil es más estricto que un corte único y es deliberado: un radar real
no congela el conocimiento de la empresa a 31 de diciembre, lo actualiza según va
ganando. Medimos como funcionaría de verdad.

## 5. Las métricas, con su definición exacta de acierto

El examen es mensual, como funcionaría un radar: cada mes de 2024, para cada
empresa del examen, el sistema ordena las licitaciones publicadas ese mes de más a
menos encaje con el perfil de la empresa y le "enseña" las K primeras.

**Métrica principal, recall@K:** de las licitaciones que la empresa realmente ganó
entre las publicadas en un mes, qué fracción aparecían entre las K que el sistema
le habría enseñado ese mes. Se agrega sobre todas las empresas y meses de 2024.

- **K = 10 como principal, decidido por Alfonso el 15-07-2026**, y se reporta **también K = 20**
  para enseñar la curva. Un radar que enseña 10 licitaciones al mes por perfil es
  una bandeja razonable de revisar por una persona; 20 es el límite alto antes de
  volverse ruido. La banda 10 a 20 es la del enunciado; se fija 10 como número que
  se enseña y 20 como contexto.
- En un no técnico: "de las licitaciones que esta empresa acabó ganando en marzo,
  ¿cuántas estaban entre las 10 que le habríamos puesto delante en marzo?"

**Cobertura de empresas:** cuántas empresas del examen tienen al menos un positivo
observable en 2024 (si una empresa del examen no ganó nada en 2024, no aporta al
recall y se cuenta aparte). Se publica cuántas empresas entran realmente en el
cómputo del recall y cuántas quedaron sin positivos.

**Recall@K por tamaño de historial:** el recall se parte por tramos de historial
previo (por ejemplo 5 a 9, 10 a 19, 20 o más adjudicaciones), porque es de esperar
que un perfil más rico prediga mejor y esconder eso sería vender humo. Se publica
la tabla por tramos.

**Qué significa acertar una empresa concreta:** para las fichas de ejemplo, una
empresa está "bien servida" si su recall@10 individual supera 0 (le enseñamos al
menos una de las que ganó); se enseñarán casos buenos y casos donde el radar no
vio venir nada, con su lectura.

## 6. El baseline honesto (la vara de medir)

Ganar aquí es la condición de éxito, igual que en la Entrega 1. La vara no es un
hombre de paja: es una regla simple de "más de lo mismo" que cualquiera aplicaría
sin embeddings, y que además los datos dicen que es fuerte.

**Baseline "sector y comprador habitual", sin embeddings:** para cada empresa,
ordenar las licitaciones del mes por afinidad con su historial estructurado, así:

1. Coincidencia de **división CPV a 2 dígitos** con las divisiones donde la
   empresa ya ganó (ponderada por su frecuencia en el historial).
2. Coincidencia de **órgano de contratación** con los órganos donde la empresa ya
   ganó (su comprador habitual).
3. Cercanía del **presupuesto del lote** al rango de importes que la empresa suele
   ganar.

Se combinan en una puntuación simple y se toman las K primeras. Sin ningún texto,
sin ningún embedding, solo el historial estructurado que ya está en la base.

**Por qué esta vara es honesta y no floja, medido en entrenamiento:** en las
empresas con 5 o más adjudicaciones previas al corte, su división CPV principal
concentra de media el **77,8 %** de sus victorias, y su órgano principal el
**44,8 %**. Es decir, las empresas son muy monotemáticas de sector y bastante
fieles a sus compradores. Una regla que diga "más del mismo sector y del mismo
comprador" ya captura mucho. Batir eso es difícil y por eso es la vara buena.

**Nota de geografía:** el enunciado pedía "misma provincia u órgano habitual". La
provincia NO está resuelta de forma limpia en la base (el DIR3 no da provincia sin
un registro externo, `bd-diseno.md`), así que el componente geográfico del
baseline es el **órgano habitual**, no la provincia. Se declara el hueco: si más
adelante se mapea DIR3 a provincia, se puede añadir; hoy no se inventa.

**Qué significa batir el baseline, fijado de antemano:** el método con embeddings
gana si su **recall@10 supera el recall@10 del baseline** sobre exactamente el
mismo universo de empresas y el mismo examen mensual, y ese margen se publica gane
o pierda. Margen mínimo para cantar victoria sin ambigüedad, **decidido por Alfonso el
15-07-2026: 5 puntos de recall** (por ejemplo, pasar de un recall@10 del 30 % a 35 % o más).
Por debajo de ese margen se declara "empate técnico" y se dice que los embeddings
no aportaron sobre el historial estructurado, que también sería un resultado
honesto y publicable.

## 7. Abstención (cuándo el sistema dice "no lo sé")

Un sistema que sabe cuándo no sabe transmite más confianza (misma filosofía que la
Entrega 1). El sistema se **abstiene** con una empresa cuando su historial previo
al corte no llega al mínimo N del punto 2. Esas empresas quedan fuera del examen y
**se cuentan**: se publica cuántas empresas del total quedaron sin radar por falta
de historial (con N = 5, quedarían fuera unas 42.000 de las 53.315 con algún
historial, más las que no tienen ninguna). Abstenerse de la mayoría para lucir un
recall bonito sobre las fáciles sería trampa, así que el porcentaje de abstención
se publica como cifra de cabecera, no en letra pequeña.

En un no técnico: "el radar solo opina de empresas de las que sabe bastante; de
las demás dice claramente que no tiene datos para opinar, y contamos cuántas son."

## 8. El método previsto (sin comprometer la técnica concreta)

Lo que se va a construir, a grandes rasgos y sin cerrar detalles que no toca cerrar
en un pre-registro:

- **Perfil de empresa:** un vector que combina (a) el **embedding agregado** de los
  objetos de contrato que la empresa ya ganó antes de la fecha de publicación
  evaluada, y (b) su **historial estructurado** (divisiones CPV, órganos, rango de
  importes), lo mismo que usa el baseline pero como entrada del modelo, no como
  regla.
- **Representación de la licitación:** el **embedding de su objeto de contrato**
  (`expediente.objeto_contrato`) más sus datos publicados (CPV, órgano,
  presupuesto, procedimiento).
- **Encaje:** similitud entre el perfil de la empresa y la licitación (distancia
  coseno sobre los vectores, más las señales estructuradas), para ordenar las
  licitaciones del mes por empresa. La base ya tiene la tabla `expediente_embedding`
  con índice HNSW y operador coseno preparada (`bd-diseno.md`).
- El **modelo de embeddings**: un modelo ABIERTO multilingüe ejecutado en local
  (sin API de pago, coste cero por expediente y reproducible). El modelo concreto y
  su versión exacta se verifican online en el momento de ejecutar, se comunican a
  Alfonso por correo y quedan registrados en el informe ANTES de mirar el examen.
  La elección del modelo no altera la verdad, el universo ni las métricas selladas
  aquí. La dimensión del vector se ajusta al modelo (la tabla está montada a 1536
  y se reajusta si hace falta).

Lo que importa del pre-registro no es qué modelo de embeddings, es que **el perfil
y todos los agregados se construyen solo con el pasado** (punto 4) y que la vara y
las métricas están fijadas antes de mirar 2024.

## 9. Prior art citado y qué añadimos

Igual que en la Entrega 1, esto no es terreno virgen y decirlo es parte de la
credibilidad (`sondeo-datos.md`, apartado f):

- **Manuel J. García Rodríguez et al., Universidad de Oviedo**: *"Bidders
  Recommender for Public Procurement Auctions Using Machine Learning"*. Es
  **exactamente esta entrega**, un recomendador de licitadores sobre datos abiertos
  españoles. Se cita como lo que es: el problema ya está publicado y demostrado
  viable.
- El mismo grupo tiene el estimador de precio de adjudicación (nuestra Entrega 1) y
  trabajo de detección de colusión. El hallazgo citable relevante: más licitadores,
  más baja (más competencia).

**Qué añadimos nosotros (el ángulo diferencial), sin reivindicar un modelo nuevo:**

1. El **proxy declarado con su sesgo a la vista**: usar "lo que ganó" como
   sustituto honesto de "lo que le interesó", diciendo en voz alta que solo vemos
   ganadores y que eso pone el examen más difícil de lo justo.
2. El **corte temporal móvil con regla anti-fuga explícita**: el perfil se
   actualiza al día de cada licitación evaluada, no a un corte fijo, y se sella la
   predicción contra lo que de verdad pasó en 2024.
3. La **abstención contada** como parte del sistema: se dice de cuántas empresas
   no se puede opinar.
4. La visión de producto: **el radar sellado hacia delante**. Lo que aquí se
   backtestea contra 2024 es, mirado hacia el futuro, un radar que a una empresa le
   pondría cada mes las licitaciones nuevas que mejor encajan con lo que ya hace.
   El backtest es la prueba de que el radar habría funcionado; el radar es el
   producto.

## 10. Qué se publica pase lo que pase

- **Todas** las métricas definidas arriba, salgan como salgan, incluido el recall
  por debajo del baseline si ocurre.
- La **comparación explícita contra el baseline**, con su margen, gane o pierda el
  método de embeddings.
- El **porcentaje de abstención** como cifra de cabecera.
- Los **casos con su historia**: 3 a 5 empresas donde el radar acertó de lleno
  (le enseñó lo que ganó) y 3 a 5 donde falló (no vio venir lo que ganó), con su
  ficha y una lectura honesta de por qué.
- Todos los **peros** del punto 11 y el sesgo del proxy del punto 3.

## 11. Los peros, declarados de antemano

- **El proxy no es "interés", es "encaje ganador".** Solo vemos ganadores, no
  presentados. El recall medido es un suelo (punto 3). Es la limitación grande y va
  la primera.
- **Historial mínimo subestimado:** el 15,6 % de las adjudicaciones con ganador no
  tienen fecha de adjudicación y no cuentan para fijar N; algunos perfiles reales
  son más ricos de lo que la tabla del punto 2 refleja.
- **Cobertura del universo:** solo perfiles del contratante sin menores, como en
  toda la demo. No es el 100 % del gasto público.
- **Geografía no resuelta:** el baseline usa órgano habitual, no provincia, porque
  el DIR3 no da provincia limpia. Declarado, no inventado.
- **UTEs:** una Unión Temporal de Empresas tiene NIF propio y se trata como entidad
  aparte; el historial de cada empresa miembro por separado no siempre es
  recuperable (el parser tomó el identificador de la UTE). Puede partir historial
  de grandes constructoras que concurren a veces solas y a veces en UTE.
- **Identidad de empresa por NIF:** robusta, pero un grupo empresarial con varias
  filiales de NIF distinto se ve como empresas distintas. No se consolidan grupos.
- **No prometemos causalidad ni "lo que le conviene".** Es encaje con su
  comportamiento pasado y antecedentes, no un consejo de negocio.
- **Prior art:** el recomendador de licitadores ya lo publicó Oviedo; lo nuestro es
  el protocolo verificable y el proxy declarado, no un algoritmo nuevo.

## 12. Cómo se sella (cuando deje de ser borrador)

Idéntico a la Entrega 1:

- Con las decisiones ya congeladas, se hace **commit** y el **hash del
  commit** es el sello.
- **OpenTimestamps (OTS)** además del hash: prueba criptográfica anclada en Bitcoin
  de que el documento existía en esta fecha, sin depender de que nos crean.
- El orden es sagrado: **primero se sella, después se corre el modelo sobre 2024.**
  Ni una métrica del examen antes del sello.

---

### Decisiones que necesita resolver Alfonso antes de sellar

Resueltas por Alfonso el 15-07-2026: **N = 5** de historial mínimo, **K = 10**
principal (con K = 20 como contexto), **5 puntos de recall** como margen de
victoria, y **modelo de embeddings abierto en local** (versión exacta registrada
en el informe antes de mirar el examen). Congeladas para esta entrega.