Refery.
ENES
Contratar

06. El volante de datos

La parte más defensible de cualquier sistema de IA son los datos de los que aprende. El volante de datos de Refery se construye en torno a un activo poco común: una red de más de 300 scouts operadores que aportan envíos de candidatos estructurados, y un libro mayor de resultados del pipeline que rastrea cada decisión de colocación hasta sus predicciones.

Este capítulo describe cómo la red de scouts funciona como una capa distribuida de etiquetado con humano en el bucle (HITL), cómo se estructura el esquema para capturar señal de entrenamiento en cada paso, y cómo los resultados retroalimentan al sistema para refinar la puntuación con el tiempo.

Por qué los scouts importan (técnicamente)

La mayoría de las plataformas de "reclutamiento con IA" tienen un problema de arranque en frío: necesitan datos etiquetados para entrenar un modelo de emparejamiento, pero no tienen forma de adquirir etiquetas salvo mediante costosas revisiones de expertos. Las etiquetas que sí tienen son ruidosas (texto libre generado por reclutadores) y unilaterales (sin ejemplos negativos; nadie documenta los candidatos que descartó).

La red de scouts de Refery resuelve esto estructuralmente. Cada envío de un scout es, por construcción, un ejemplo de entrenamiento etiquetado:

  • Etiqueta positiva: Un scout envía un candidato a Refery para un puesto específico. Esta es una señal positiva implícita de que el scout (un experto en el dominio) cree que este candidato encaja.
  • Grado de calidad: El panel de Refery evalúa al candidato y le asigna un tramo (Top 1%, Top 5%, etc.) y un grado de reclutador (A+, A, A-, B+, pass). Esto se convierte en la señal de calidad calibrada.
  • Etiqueta de resultado: La máquina de estados del pipeline produce con el tiempo una etapa terminal (hired, rejected, withdrawn). Este es el resultado de referencia (ground-truth).
  • Serie temporal: Las transiciones de etapa en pipeline_stage_history producen una serie temporal de señales intermedias (si se compartió el perfil del candidato, si respondió, si el cliente interactuó).

Cada candidato que fluye por el sistema genera, por tanto, entre ~5 y 10 señales etiquetadas a lo largo de múltiples horizontes temporales. Con más de 300 scouts enviando periódicamente, los datos etiquetados se acumulan más rápido de lo que cualquier reclutador individual podría generar manualmente.

El contrato de envío estructurado

Los scouts no envían currículums de formato libre. Los envíos se estructuran en la admisión: cada envío especifica la identidad del candidato, el contexto previo (cómo lo conoce el scout), las expectativas de compensación, la postura sobre ubicación, la preferencia de etapa, y uno o más puestos que el scout cree que este candidato encajaría.

Esta estructura obliga al scout a comprometerse con predicciones específicas ("esta persona encaja en este puesto con esta compensación") que después pueden validarse frente a los resultados reales.

CREATE TABLE scout_submissions (
  id                       uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  scout_id                 uuid NOT NULL REFERENCES scouts(id),
  candidate_id             uuid NOT NULL REFERENCES candidates(id),
  submitted_at             timestamptz NOT NULL DEFAULT now(),

  -- Predicción del scout en el momento del envío
  predicted_fit_companies  uuid[] NOT NULL,
  predicted_fit_roles      uuid[],
  scout_confidence         text CHECK (scout_confidence IN ('low', 'medium', 'high')),
  scout_relationship       text,  -- "ex compañero de trabajo", "organizamos un hackathon juntos", etc.

  -- Evaluación del panel de Refery
  panel_aggregate_bracket  text,
  panel_grade              text,
  panel_evaluated_at       timestamptz,

  -- Resultado (se rellena a medida que avanza el pipeline)
  outcome_pipeline_id      uuid REFERENCES job_candidate_pipeline(id),
  outcome_terminal_stage   text,  -- 'hired', 'rejected', 'withdrawn', o null mientras está en curso
  outcome_terminal_at      timestamptz
);

CREATE INDEX idx_scout_submissions_scout ON scout_submissions(scout_id);
CREATE INDEX idx_scout_submissions_outcome ON scout_submissions(outcome_terminal_stage);

Este esquema captura toda la cadena de predicción y resultado en una sola fila, lo que la hace directamente entrenable.

Puntuación de calidad de scouts

No todos los scouts son iguales. Algunos tienen alta precisión (sus envíos obtienen consistentemente grado A o A-); algunos tienen alta exhaustividad (recall) (envían mucho, con calidad variable); algunos son especialistas de dominio (sus envíos de fintech son excelentes, sus envíos de IA son débiles).

Refery puntúa a los scouts sobre ventanas móviles usando los resultados de sus envíos. La puntuación de un scout afecta a cómo se priorizan sus envíos futuros en la cola del operador e informa al sistema de reputación de la plataforma.

-- Precisión móvil de scouts a 90 días
SELECT
  s.id,
  s.name,
  COUNT(*) AS total_submissions,
  COUNT(*) FILTER (WHERE ss.panel_grade IN ('A+', 'A', 'A-')) AS high_grade_count,
  COUNT(*) FILTER (WHERE ss.panel_grade IN ('A+', 'A', 'A-'))::float
    / NULLIF(COUNT(*), 0) AS precision_score,
  COUNT(*) FILTER (WHERE ss.outcome_terminal_stage = 'hired') AS placements,
  COUNT(*) FILTER (WHERE ss.outcome_terminal_stage = 'hired')::float
    / NULLIF(COUNT(*), 0) AS hire_rate
FROM scouts s
LEFT JOIN scout_submissions ss ON ss.scout_id = s.id
WHERE ss.submitted_at > now() - interval '90 days'
GROUP BY s.id, s.name
ORDER BY precision_score DESC;

Esta misma consulta, ejecutada con distintos filtros, produce:

  • Puntuaciones de scouts por vertical (mejores scouts de fintech, mejores scouts de IA)
  • Puntuaciones de scouts por etapa (mejores scouts de Seed, mejores scouts de Series A)
  • Puntuaciones de scouts por función (mejores para envíos de ingeniería frente a envíos de ventas)

Estas se utilizan para ponderar los envíos al presentarlos al operador: un envío de ingeniería de Series A de un scout con sólida precisión en ingeniería de Series A se prioriza sobre el mismo envío de un scout sin historial en ese segmento.

El bucle de reentrenamiento del modelo de puntuación

El motor de señales y las puntuaciones de emparejamiento no son estáticos. Se recalibran periódicamente contra el corpus completo de resultados.

Ciclo de calibración

Cada trimestre:

  1. Extraer todas las filas del pipeline en estado terminal del trimestre anterior. Estas son las etiquetas.
  2. Para cada fila, recuperar las características de puntuación en el momento del envío. Se almacenan en pipeline_stage_history.notes y candidates.ai_analysis.
  3. Calcular tablas de calibración. ¿Cuál fue la tasa real de contratación para los candidatos que el panel calificó como Top 5%? ¿Top 10%? Si la calibración está desviada (p. ej., los candidatos Top 5% solo convierten a la tasa que debería tener Top 10%), se recalibran los umbrales de los tramos.
  4. Calcular la efectividad de los pesos por eje. ¿Fue el eje stage_fit un fuerte predictor de la colocación? ¿O estaba comp_signals ponderado demasiado alto? Los pesos de recuperación del capítulo 02 se ajustan frente a esto.
  5. Comparar los cambios de peso propuestos. Un operador humano revisa el diff y aprueba o rechaza la actualización propuesta.

Esto deliberadamente no está totalmente automatizado. El paso con el operador en el bucle previene la deriva desde óptimos locales y mantiene el comportamiento del sistema interpretable.

Atribución de resultados

Un punto sutil pero importante: no todo resultado "hired" es una señal positiva para el sistema de emparejamiento. Un candidato que fue contratado pero se marchó antes de 6 meses es un positivo débil. Un candidato que fue contratado y sigue en la empresa 18 meses después es un positivo fuerte.

Refery amplía el libro mayor de resultados con verificaciones de retención:

ALTER TABLE scout_submissions ADD COLUMN
  retention_check_6mo boolean DEFAULT null,
  retention_check_18mo boolean DEFAULT null;

El operador actualiza periódicamente estas verificaciones basándose en LinkedIn o el contacto directo con el candidato colocado. El bucle de entrenamiento pondera con más peso las colocaciones de larga retención.

El brief del candidato como artefacto de base de datos

El brief de inteligencia estructurado que produce el panel (descrito en el capítulo 03) se escribe en candidates.ai_analysis como texto. Pero la estructura del brief es lo bastante consistente como para funcionar como datos semiestructurados: las consultas de series temporales pueden extraer secciones específicas (el tramo, la matriz de ajuste por etapa, los veredictos del panel) y razonar sobre ellas a lo largo de la base de candidatos.

Esto permite consultas como:

-- Encontrar todos los candidatos con bandera de desajuste de etapa para enrutamiento
SELECT id, name, ai_analysis
FROM candidates
WHERE ai_analysis ILIKE '%Stage mismatch:%'
  AND status IN ('active', 'reviewing');

-- Encontrar todos los candidatos con bandera non-tech SUPPRESSED con un patrón de razón específico
SELECT id, name, ai_analysis
FROM candidates
WHERE ai_analysis ILIKE '%Non-tech flag:%SUPPRESSED%'
  AND ai_analysis ILIKE '%Goldman%early career%';

Una refactorización futura sacará estos campos estructurados del blob de texto a columnas dedicadas, habilitando una analítica más potente. La estructura actual es un estado intermedio pragmático: almacenar el brief como texto mantiene el esquema simple a la vez que permite la extracción basada en patrones.

Resumen del esquema

El conjunto completo de tablas que participan en el volante de datos:

candidates                  - identidad central + salida del motor de señales + ai_analysis
companies                   - empresas cliente objetivo + do_not_contact
jobs                        - puestos abiertos + clasificación de filtros + estado
job_candidate_pipeline      - filas activas del pipeline con etapa actual
pipeline_stage_history      - registro de transiciones de solo anexado con evidencia
recruiter_notes             - notas del operador, con marca de tiempo, tipificadas
job_candidate_notes         - notas acotadas a una fila específica del pipeline
scouts                      - identidades de scouts + nivel + estado de la relación
scout_submissions           - contrato de envío + grado del panel + resultado
candidate_embeddings        - representaciones multivectoriales (pgvector)
job_embeddings              - representaciones multivectoriales (pgvector)
outreach_log                - cada mensaje saliente con canal + resultado

Once tablas, todas relacionales, todas en una sola instancia de Postgres. Sin base de datos vectorial separada. Sin almacén de analítica separado. Sin sistema de registro separado. Toda la arquitectura de datos cabe en un único esquema SQL.

Esto es intencional. El coste y la complejidad operativa de ejecutar 4-5 sistemas de datos separados (que es la arquitectura de datos típica de "startup de IA" en 2026) es uno de los mayores gastos ocultos de un producto impulsado por IA. Refery lo evita por completo.

Por qué esto es novedoso

  1. Red de scouts como etiquetado HITL estructurado. Una red de más de 300 operadores con un contrato de envío estructurado produce etiquetas a un ritmo que ningún equipo interno de reclutamiento podría igualar.
  2. Libro mayor de resultados que abarca toda la cadena de predicción a colocación. Cada predicción que hace el sistema se valida con el tiempo frente a un resultado terminal almacenado junto a ella.
  3. Puntuación de calidad de scouts retroalimentada en la priorización. El sistema se vuelve más inteligente con el tiempo sobre a qué scouts escuchar, en función de su precisión realizada.
  4. Arquitectura de base de datos única. La búsqueda vectorial, el estado del pipeline, el historial, los embeddings y los registros de contacto viven todos en una sola instancia de Postgres. Esto es operativamente radical comparado con el stack multisistema típico de una startup de IA.
  5. Calibración trimestral con el operador en el bucle. Ni totalmente automatizada, ni totalmente manual. El ciclo de reentrenamiento preserva la interpretabilidad a la vez que se beneficia de los resultados acumulados.

El volante es lo que hace que la calidad de la IA de Refery mejore más rápido que la de un competidor que carece de la red de scouts. Los envíos de los scouts son el foso defensivo.