1 · La anatomía de la pregunta
La primera tentación de todo proyecto de recuperación es empezar por el motor. Elegir el almacén vectorial, decidir el modelo de embeddings, afinar el parámetro de búsqueda. Es una tentación comprensible —son las piezas que brillan en las demos— y es un error de orden. Antes del motor está la pregunta. No se puede diseñar un sistema de acceso si no se sabe, con precisión casi forense, qué va a pedirle la gente y qué consideraría un acierto. Este capítulo abre el libro desmontando esa pieza mínima que todo lo condiciona: la pregunta real.
La consulta que nadie escribe en los ejemplos
En los tutoriales, las preguntas llegan limpias: "¿Qué dice el convenio sobre las horas extraordinarias?". En la vida, las preguntas llegan como llegó aquella del despacho, un jueves a las doce, escrita en el cuadro de búsqueda de la demo interna: "plazo traslado sanción muy grave prescribio?". Sin acentos, sin verbo, con una errata, con dos conceptos (el traslado y la sanción) que el redactor no consideró necesario separar, y con una intención que solo se reconoce si uno conoce el asunto: alguien sospechaba que una sanción ya había prescrito y quería el plazo antes de una reunión.
Ningún motor del mundo habría entendido eso de forma fiable tratándolo como "una frase a vectorizar". Y sin embargo ese es el material que un sistema de acceso real procesa a diario. La primera decisión de arquitectura, por tanto, no es técnica: es decidir que la pregunta es un objeto de estudio. Antes de hablar de filtros o de top-k, un equipo que construye acceso serio se sienta con una lista de consultas reales y las disecciona.
Las cuatro capas de una pregunta
Toda consulta, por mal escrita que esté, lleva dentro cuatro capas que conviene separar a mano, porque el sistema las tratará por caminos distintos.
La primera capa es la intención: qué quiere realmente quien pregunta. ¿Quiere un dato puntual —un plazo, un porcentaje, una fecha— o quiere entender un concepto? ¿Quiere localizar un documento que ya sabe que existe, o no sabe si existe respuesta alguna? La pregunta sobre el plazo de prescripción de la sanción tenía intención fáctica: un número con unidades, días. Otra consulta del mismo despacho —"¿qué dice la jurisprudencia reciente sobre los despidos durante una IT?"— tenía intención sintética: no buscaba un dato, buscaba un panorama. La intención determina cuántos resultados se necesitan, con qué diversidad y con qué exigencia de cita exacta. Un dato puntual se sirve con una píldora y una referencia; un panorama se sirve con media docena de piezas de fuentes distintas.
La segunda capa es el contexto tácito: lo que quien pregunta da por supuesto y no escribe. Quien pregunta por "el convenio" en un despacho que asiste a empresas de tres sectores distintos está pensando, casi siempre, en uno concreto —el del sector de su cliente— y se sorprenderá si recibe el de otro. Ese convenio implícito no está en el texto de la consulta; está en el dominio, en el cliente activo, en la pantalla desde la que se pregunta. Es la primera señal de que el acceso necesitará más que el texto de la consulta: necesitará coordenadas externas que se convertirán en filtros. Lo veremos en la parte segunda.
La tercera capa es la jerga y su deformación: siglas, diminutivos del oficio, erratas. El despacho habla de ERE y de ERTE como si fueran la misma cosa para el que no es del gremio; escribe "finiquito" donde el documento fuente dice "liquidación de haberes"; escribe "prescribio" sin tilde. Esta capa importa porque los motores que leerán la consulta son, en el fondo, comparadores estadísticos: lo que no se parece en superficie, no se empareja. Gran parte de la ingeniería posterior —el híbrido, sobre todo— existe por culpa de esta capa.
La cuarta capa es la expectativa de respuesta: qué consideraría quien pregunta que ha acertado. Un plazo concreto con su cita. Un párrafo del convenio con su artículo. Una lista de sentencias ordenadas por fecha. Rara vez se escribe esta expectativa, y sin embargo es el único juez que cuenta: el sistema no acierta cuando devuelve lo estadísticamente parecido, acierta cuando devuelve lo que el usuario esperaba encontrar. Por eso la expectativa, una vez explicitada, se convierte en oro puro para el capítulo dieciocho: es la semilla del dataset de evaluación.
Por qué importa tanto este desmontaje
Podría parecer un capítulo de palabras cuando el libro promete técnicas. Es lo contrario. Cada capa de la pregunta prescribe una pieza del sistema, y saltárselas produce las arquitecturas cojas que todos hemos visto. Si se ignora la intención, se elegirá un único valor de top-k para todo —cinco resultados para el dato puntual y para el panorama— y ambas salidas quedarán mal. Si se ignora el contexto tácito, el sistema buscará en todo el corpus siempre, y devolverá el convenio equivocado con una confianza enorme. Si se ignora la jerga, el canal léxico de búsqueda parecerá innecesario hasta el día en que nadie encuentre nada sobre "ERTE". Y si se ignora la expectativa, no habrá forma honesta de saber si el sistema mejora o empeora cuando se cambia cualquier cosa.
Hay una razón más, heredada del primer libro. Al construir el corpus definimos cinco a diez preguntas reales por dominio como criterio de salida del acotamiento: eran la vara de medir de la construcción. Ahora esas mismas preguntas —y las que se acumularon desde entonces— vuelven a escena con otro papel: son las primeras interrogaciones del Rack, el banco de pruebas contra el que se afinará todo el acceso. Un sistema de acceso sin corpus de consultas reales es como un juzgado sin causas: puede tener todo el aparato y no haber aprendido nada.
El hábito que deja este capítulo
El criterio de salida de esta primera etapa no es un componente: es un documento vivo. Concretamente, una colección de consultas reales —no inventadas— que el equipo analiza con las cuatro capas a la vista: qué intención lleva cada una, qué contexto tácito se puede resolver hoy y cuál requerirá filtros, qué jerga aparece y contra qué vocabulario del corpus choca, y qué habría contado el usuario como acierto. Con unas treinta o cuarenta consultas diseccionadas, patrones que nadie esperaba saltan a la vista: que el 40 por ciento de las consultas son fácticas sobre plazos; que casi siempre se pregunta en singular y el corpus está en plural; que ciertas siglas nunca aparecen en los documentos tal y como los usuarios las escriben.
Ese documento es la materia prima de todo lo que sigue. Del capítulo dos saldrán sus definiciones de acierto; del tres, el contrato de recuperación; de la parte segunda, los filtros que resuelvan el contexto tácito; del dieciocho, el dataset de evaluación. Ninguno de esos pasos se podrá tomar bien si este primero se hizo con consultas de catálogo en lugar de consultas del oficio.
Criterio de salida
Una colección de al menos treinta consultas reales del dominio, cada una anotada con su intención, su contexto tácito, su jerga y su expectativa de respuesta. Sin este banco de preguntas diseccionadas, ninguna decisión posterior del libro es auditable.
En la siguiente página, la capa que merece capítulo propio: la expectativa de acierto. Porque "relevante" —se verá— es la palabra más malentendida de toda la ingeniería de recuperación.