El lexicon como compilador

Un vendedor escribe en la tablet del local una sola palabra para cerrar la operación: tomar. Lo hace cien veces al día y nunca duda.

«El cliente tomó la camiseta visitante talla M.» La frase es transparente para cualquiera.

El problema empieza cuando esa misma palabra viaja por el resto del edificio.

En la sala de reuniones, la gerente anota que el comité «tomó una decisión sobre el nuevo proveedor».

En la cancha del torneo que la tienda patrocina, el relator narra que el delantero «tomó el balón en el área».

Y en el municipio de la esquina, un funcionario certifica que el alcalde le «tomó juramento» al nuevo regidor.

Cuatro veces el mismo verbo. Cuatro hechos que no tienen nada en común salvo seis letras.

Si el sistema del capítulo anterior tomara el verbo al pie de la letra, haría lo que hace un lector ingenuo: leer tomar, disparar una única firma y guardar las cuatro frases como el mismo tipo de evento.

El resultado sería una base de datos que cree que entregar una camiseta, deliberar en comité, recibir un balón y administrar un juramento son la misma clase de cosa.

Las consultas heredarían el desastre. Preguntar «¿qué decisiones se tomaron este mes?» devolvería también las ventas y las jugadas.

El error no se nota al escribir. Se cobra al leer.

El capítulo 13 nos dejó con el verbo entendido como contrato: cada uno declara qué roles exige y de qué eje sale cada valor.

Pero acabamos de ver que el verbo no basta como llave.

Tomar no es un contrato. Es una familia de contratos que comparten ortografía. Para elegir el correcto hay que mirar también qué acompaña al verbo.

Y ese trabajo, pasar del lenguaje a la firma exacta, no lo hace el verbo solo. Lo hace una pieza dedicada, que es la protagonista de este capítulo.

Dos lenguajes que no deberían tocarse

Conviene nombrar bien los dos mundos que el capítulo 13 puso frente a frente.

Por un lado está el catálogo canónico: la lista cerrada de roles (agente, tema, beneficiario, experimentador…) con sus firmas, sus ejes y sus reglas.

Es exacto, estable y completamente ilegible para quien no diseñó el modelo.

Ningún recepcionista, ningún médico, ningún relator va a escribir experimentador para registrar que a un cliente le encantó el postre.

Por el otro lado está el lenguaje del usuario: «vendedor», «comprador», «paciente», «socio», «el que pierde».

Vocabulario vivo, distinto en cada gremio, lleno de sinónimos y de palabras que significan varias cosas.

Es lo único que la gente sabe escribir, y lo único que un modelo de lenguaje recibe cuando lee una frase suelta.

Si obligáramos a estos dos mundos a tocarse, si el catálogo fuera la interfaz, habríamos construido una pieza de ingeniería impecable e inútil. La adopción se moriría en la primera capacitación.

La solución es interponer una capa de traducción entre ambos. Una capa que por fuera hable el idioma del usuario y por dentro emita tipos canónicos. A esa capa la llamamos lexicon, y su diseño descansa sobre dos decisiones que conviene enunciar de frente.

Si D8 fija qué pieza es la interfaz, su consecuencia natural es una promesa hacia el usuario final, que merece su propio número porque otras partes del libro la invocan:

El par D8–D9 reparte responsabilidades con nitidez.

D8 mira hacia adentro: los ingenieros pueden mover los engranajes sin romperle nada a nadie, porque la fachada permanece.

D9 mira hacia afuera: las personas pueden seguir hablando como hablan.

El lexicon sostiene las dos promesas a la vez. Estable hacia afuera, flexible hacia adentro.

El catálogo canónico es el corazón del sistema; el lexicon es su rostro. Y al mundo solo se le muestra el rostro.El contrato de D8

El lexicon en capas

Vale la pena ver la arquitectura de un vistazo antes de bajar al detalle.

La frase entra por arriba con las palabras del usuario. El lexicon la desenreda y la traduce a roles canónicos. El almacén, abajo, solo trabaja con identificadores.

Tres capas, y cada una puede cambiar sin molestar a las otras.

Autopsia de una entrada

Bajemos al detalle. Una entrada del lexicon es una «página» del diccionario, y cada pieza tiene un trabajo concreto. Tomemos un verbo del mundo de la tienda (el local de la escena inicial despacha camisetas al público) y desarmemos su entrada de vender:

{
  "verbo": "vender",
  "tipo_situacion": "accion_vender",
  "roles": {
    "agente":       { "canonico": "agente",       "aliases": ["vendedor", "el que vende", "el que despacha"] },
    "tema":         { "canonico": "tema",         "aliases": ["producto", "lo vendido", "camiseta"] },
    "beneficiario": { "canonico": "beneficiario", "aliases": ["comprador", "cliente", "el que compra"] },
    "por_cuanto":   { "canonico": "por_cuanto",   "aliases": ["precio", "monto", "importe"] }
  },
  "obligatorios": ["agente", "tema", "beneficiario", "por_cuanto"],
  "opcionales":   ["momento", "lugar_de", "moneda", "instrumento"],
  "ejemplo": "El vendedor le vendió una camiseta al cliente por 49.90 dólares"
}

Son seis piezas, y conviene leerlas como lo que son: la declaración de una función con su manual de uso adjunto.

1. verbo. La llave que activa la entrada. Puede ser una palabra suelta (vender) o un patrón compuesto (tomar [decisión]), como veremos al resolver la polisemia.
2. tipo_situacion. El código interno exacto con el que el evento se ancla en la caja K. Es el motor oculto; el usuario nunca lo ve ni lo escribe.
3. roles y sus aliases. Aquí vive D9. El rol canónico es agente, pero la lista de aliases le enseña al sistema que «vendedor», «el que vende» y «el que despacha» significan lo mismo. Gracias a eso, «el vendedor le vendió una camiseta al cliente» y «el agente transfirió un producto al beneficiario» producen el idéntico registro.
4. obligatorios y opcionales. Las reglas de seguridad de la firma. Dictan qué roles no pueden faltar para que el hecho se acepte. Una venta sin precio se rechaza; una venta sin lugar, no.
5. ejemplo. Una frase humana real. No es adorno: el motor de pruebas (y, cada vez más, el modelo de lenguaje) lee este ejemplo para aprender cómo se usa el verbo en la práctica.

Visto así, el lexicon deja de parecerse a un glosario y empieza a parecerse a un compilador.

Un compilador toma código legible para humanos y lo traduce a instrucciones exactas que la máquina ejecuta, comprobando de paso que los tipos cuadren.

El lexicon hace eso con el lenguaje: toma una frase, la traduce a una tripleta y comprueba que la firma se cumpla.

El código fuente es el español. El binario es el hecho atómico del capítulo 7.

El idioma de los modelos: function calling

Aquí ocurre una de esas coincidencias que parecen casualidad y no lo son.

Los modelos de lenguaje se conectan al software de una empresa mediante un mecanismo estándar: el uso de herramientas.

El patrón es simple. La aplicación le entrega al modelo un catálogo que describe cada herramienta, sus parámetros y cuáles son obligatorios.

Cuando un usuario pide algo con sus palabras, el modelo elige la herramienta adecuada y emite una llamada con cada parámetro en su sitio.

Lo notable es que ese formato JSON es estructuralmente idéntico a una entrada del lexicon. Tomemos la misma entrada de vender y reescribámosla en el esquema que un modelo espera recibir:

{
  "name": "accion_vender",
  "description": "Registrar una venta: transferencia de un bien con compensación monetaria",
  "input_schema": {
    "type": "object",
    "properties": {
      "agente":       { "type": "string", "eje": "Q", "description": "vendedor, el que vende, el que despacha" },
      "tema":         { "type": "string", "eje": "O", "description": "producto, camiseta, lo vendido" },
      "beneficiario": { "type": "string", "eje": "Q", "description": "comprador, cliente, el que compra" },
      "por_cuanto":   { "type": "number", "eje": "N", "description": "precio, monto, importe" },
      "momento":      { "type": "string", "eje": "T", "description": "cuándo ocurrió" },
      "lugar_de":     { "type": "string", "eje": "L", "description": "dónde ocurrió" }
    },
    "required": ["agente", "tema", "beneficiario", "por_cuanto"]
  }
}

Las correspondencias son uno a uno, y vale la pena nombrarlas para que no quede como una impresión vaga:

El tipo_situacion del lexicon se vuelve el name de la herramienta. Los aliases de cada rol se vuelven la description, que es justamente la pista que el modelo usa para saber qué significa el parámetro. El eje de origen (Q, O, N…) determina el type y aporta una validación semántica extra.

Y la lista de obligatorios es, literalmente, el campo required del esquema.

No hay que traducir nada a mano ni mantener dos cosas en paralelo. El lexicon es el catálogo de herramientas.

Exponerlo a un modelo es convertirlo a JSON y entregarlo. Lo que en otras arquitecturas es un proyecto de integración, aquí es una función de exportación.

El efecto práctico es que una frase suelta se convierte en un hecho estructurado sin que nadie escriba un parser. El prompt que recibe el modelo es casi todo catálogo:

SISTEMA. Eres un extractor de hechos WQuestions. Dada una frase en español,
devuelve SOLO un JSON con la situación y sus roles canónicos.

Catálogo (verbo → situación · roles obligatorios):
  vender → accion_vender · [agente, tema, beneficiario, por_cuanto]
  tomar  → accion_consumir · [agente, tema]

Frase del usuario: "El vendedor le vendió una camiseta al cliente por 49.90 dólares"

Y la respuesta llega lista para asentarse en el grafo, ya traducida a roles canónicos:

{
  "tipo_situacion": "accion_vender",
  "agente": "vendedor_17",
  "tema": "camiseta_88",
  "beneficiario": "cliente_1042",
  "por_cuanto": 49.90
}

Esa salida es exactamente el conjunto de tripletas tipadas del capítulo 7. Cada par rol–valor se vuelve un cable; por ejemplo, el beneficiario se lee como una tripleta del eje M que sale del evento y aterriza en una persona:

Y una vez asentada, la situación completa se descompone en los cables que ya conocemos:

(venta_001, instancia_de,  accion_vender)   ∈ M(O, K)
(venta_001, agente,        vendedor_17)     ∈ M(O, Q)
(venta_001, tema,          camiseta_88)     ∈ M(O, O)
(venta_001, beneficiario,  cliente_1042)    ∈ M(O, Q)
(venta_001, por_cuanto,    49.90)           ∈ M(O, N)

El modelo nunca vio la palabra por_cuanto hasta que el lexicon se la nombró; el usuario nunca la verá en absoluto. Esa es la promesa de D9 cumplida de extremo a extremo: el español entra por arriba, la tripleta canónica sale por abajo, y la etiqueta interna jamás se le exige a una persona.

Y esa promesa no caduca al escribir el hecho. Vale también al preguntar por muchos.

El gerente pide «el total vendido por cada vendedor este mes» con sus palabras, y el lexicon resuelve «vendedor» contra agente y «total» contra por_cuanto, sin que él vea jamás una etiqueta canónica.

El informe recorre miles de ventas, y se pide y se devuelve en el idioma de la tienda.

Resolver la polisemia: tomar, otra vez

Volvamos a la escena del principio. Cuatro frases que comparten el verbo tomar y nada más.

¿Cómo evita el lexicon confundirlas?

La respuesta es decepcionantemente directa, y por eso funciona: una entrada distinta para cada significado.

El lexicon no busca una regla mágica que cubra todos los usos de tomar. Declara una lista de patrones, cada uno apuntando a su tipo de situación, y deja que el complemento decida.

{
  "tomar [decisión | acuerdo | resolución]": {
    "tipo_situacion": "accion_decidir",
    "obligatorios": ["agente", "tema"],
    "ejemplo": "El comité tomó una decisión sobre el nuevo proveedor"
  },
  "tomar [el balón | la pelota | el pase]": {
    "tipo_situacion": "accion_recuperar_posesion",
    "obligatorios": ["agente", "tema"],
    "ejemplo": "El delantero tomó el balón en el área"
  },
  "tomar [juramento]": {
    "tipo_situacion": "acto_juramentacion",
    "obligatorios": ["agente", "paciente"],
    "ejemplo": "El alcalde le tomó juramento al nuevo regidor"
  },
  "tomar": {
    "tipo_situacion": "accion_consumir",
    "obligatorios": ["agente", "tema"],
    "ejemplo": "El cliente tomó un refresco en la cafetería del estadio"
  }
}

El procedimiento es, otra vez, el de un compilador. El sistema intenta encajar la frase desde el patrón más específico hacia el más general.

Si aparece «tomar el balón», gana la entrada de fútbol. Si aparece «tomar juramento», gana el acto de juramentación.

Y solo cuando ningún patrón con complemento coincide, como en «tomar un refresco», cae la regla genérica de consumir.

El orden importa: lo específico primero, lo genérico como red de seguridad. La figura siguiente lo muestra con los colores de cada eje.

La consecuencia es la que da título al capítulo.

La complejidad del lenguaje no se elimina, porque sería imposible. Se muda al lugar correcto: al diccionario.

Quien modela datos puede registrar un significado nuevo de tomar, como «tomar un préstamo», añadiendo una entrada de texto, sin tocar una línea del núcleo.

La base de datos sigue sin saber nada de español. El lexicon hace todo el trabajo.

Dos clases de alias: por rol y por dominio

Hasta aquí los apodos han sido por rol: dentro de la entrada de vender, «vendedor» equivale a agente.

Pero hay un segundo nivel, indispensable para que esto funcione de verdad en una empresa.

Hay palabras que valen para todo un gremio, sin importar qué verbo se use. Una tienda siempre habla de «vendedor», «boleta» y «caja». Una clínica, de «paciente», «historia» y «diagnóstico».

Repetir esos apodos en cada entrada sería absurdo. Para eso el lexicon admite dialectos de dominio: un archivo pequeño que se carga encima del catálogo.

{
  "dominio": "tienda_central",
  "aliases_de_dominio": {
    "vendedor":      "agente",
    "boleta":        "comprobante",
    "caja":          "lugar_de",
    "catálogo":      "catalogo",
    "despachar":     "verbo_vender",
    "talla":         "atributo_medida"
  }
}

Con ese dialecto cargado, un vendedor escribe «despaché una camiseta talla M en la caja dos» y el sistema traduce «despaché» al verbo vender, «caja» al rol lugar_de y «talla» al atributo de medida.

Todo sin que ninguna entrada de verbo mencione la palabra «caja».

El núcleo permanece intacto, y la tienda, la clínica y el municipio sienten cada uno que el software se hizo a su medida. Es el mismo motor hablando tres jergas.

El tercer nivel: la lengua

Vuelve un segundo sobre lo que acaba de pasar, porque hay algo que conviene no dejar escapar.

Para que el sistema entendiera «despaché una camiseta en la caja dos» no hizo falta tocar el catálogo, ni migrar un dato, ni retraducir nada. Se cargó un archivo de apodos.

Y al mecanismo le da igual de dónde venga la palabra nueva.

Si los apodos por rol son locales a un verbo y los de dominio son globales a un gremio, queda un tercer nivel con la misma maquinaria: global a una lengua entera.

Que eso sea posible no es mérito del lexicon. Es mérito de lo que hay debajo.

El grafo no guarda palabras. Guarda identificadores, y un identificador no está escrito en ningún idioma.

cliente_1042 no es la palabra «cliente». Es un nodo del eje Q que sería el mismo si el sistema se hubiera programado en finés.

Un diagnóstico no se guarda como el texto «infarto», sino como cie10_I21, un individuo de K con su URI internacional colgada, como vimos en el capítulo 3.

Y accion_vender no es el verbo «vender», sino un tipo de situación con su contrato de roles, al que cada venta concreta se ata con un instancia_de.

El efecto se ve mejor con las tres frases juntas. Un vendedor en Lima, uno en Chicago y uno en Hamburgo registran la misma operación cada uno como sabe:

es → «El vendedor le vendió una camiseta al cliente por 49.90 dólares»
en → «The seller sold a shirt to the customer for 49.90 dollars»
de → «Der Verkäufer verkaufte dem Kunden ein T-Shirt für 49,90 Dollar»

«Vendedor», seller y Verkäufer son tres aliases del mismo rol canónico agente. Las tres frases compilan, en consecuencia, a la misma estrella de tripletas que ya conocemos:

(venta_001, instancia_de,  accion_vender)   ∈ M(O, K)
(venta_001, agente,        vendedor_17)     ∈ M(O, Q)
(venta_001, tema,          camiseta_88)     ∈ M(O, O)
(venta_001, beneficiario,  cliente_1042)    ∈ M(O, Q)
(venta_001, por_cuanto,    49.90)           ∈ M(O, N)

No hay una versión española de esos cables y otra alemana. Hay cables. La consecuencia práctica es la que le importa a una empresa con oficinas en tres países: el reporte de ventas consolidado no requiere homologar nada, porque nunca hubo tres bases de datos que homologar. Hubo una, y tres puertas de entrada.

El grafo no habla ningún idioma: habla matemáticas. Coordenadas sobre siete ejes, no palabras de un diccionario local.Por qué el idioma nunca llega al fondo

Y aquí el uso de herramientas de más arriba cobra un alcance que quizá pasó desapercibido.

Si el lexicon se convierte en catálogo de herramientas y el modelo de lenguaje es quien lo consume, la puerta de entrada ya es multilingüe por construcción.

El modelo recibe la pregunta en japonés, elige la entrada correcta y emite la llamada con los roles canónicos. Al responder hace el camino inverso.

La base de datos, mientras tanto, sigue sin enterarse de qué idioma se habla arriba.

Lo que cambia de una lengua a otra es la capa de apodos y los enredos propios de cada una. El tomar del español tiene su equivalente en cualquier idioma vivo.

La espina dorsal es común y solo cambia la piel. Los idiomas son pieles que el lexicon pone y quita sobre el mismo cuerpo de conocimiento.

A hombros de gigantes

Sería ingenuo —y arrogante— presentar el lexicon como una invención sin ancestros. La lingüística computacional lleva tres décadas construyendo catálogos inmensos con esta misma lógica de verbos, roles y firmas. Cualquier implementación seria del lexicon debería alimentarse de ellos en lugar de empezar de cero.

WQuestions no compite con estas obras. Se apoya en ellas.

Se pueden sacar las firmas de FrameNet, alinear las clases de VerbNet y usar los datos de PropBank para entrenar el extractor.

El camino ya está en buena parte pavimentado. Lo que aporta el lexicon es atarlo todo a un catálogo único de roles con su eje puesto, y exponerlo por una sola puerta.

Un vistazo al catálogo en acción

Para que esto no quede en el aire, mira varias entradas juntas, de dominios sin relación entre sí.

Fíjate en tres cosas: que los roles se reciclan, que los apodos cambian con el gremio aunque el esqueleto no, y que los casos raros (verbos sin agente, verbos invertidos) encajan sin forzar nada.

{
  "vacunar": {
    "tipo_situacion": "accion_vacunar",
    "roles": {
      "agente":      ["enfermera", "personal sanitario"],
      "paciente":    ["paciente", "vacunado"],
      "tema":        ["vacuna", "antígeno"]
    },
    "obligatorios": ["agente", "paciente", "tema"],
    "ejemplo": "La enfermera vacunó a 47 niños con la triple viral el sábado"
  },

  "multar": {
    "tipo_situacion": "accion_multar",
    "roles": {
      "agente":          ["autoridad", "ente regulador"],
      "paciente":        ["multado", "infractor"],
      "monto":           ["importe de la multa"],
      "justificado_por": ["norma aplicada", "artículo"]
    },
    "obligatorios": ["agente", "paciente", "monto", "justificado_por"],
    "ejemplo": "La municipalidad multó al local por ocupar la vereda"
  },

  "invocar": {
    "tipo_situacion": "accion_invocar_funcion",
    "roles": {
      "agente":      ["llamador", "cliente API", "el modelo"],
      "tema":        ["función invocada", "herramienta"]
    },
    "obligatorios": ["agente", "tema"],
    "ejemplo": "El modelo invocó la función accion_vender con los parámetros extraídos"
  },

  "llover": {
    "tipo_situacion": "evento_meteorologico",
    "roles": {
      "lugar_de":    ["región", "ciudad"],
      "intensidad":  ["leve", "moderada", "torrencial"]
    },
    "obligatorios": [],
    "notas": "Verbo impersonal: no exige agente ni ningún rol obligatorio.",
    "ejemplo": "Llovió torrencialmente sobre la ciudad durante seis horas"
  }
}

El catálogo entero, mirado en perspectiva, revela tres cosas que valen oro para quien implementa.

Un sistema empresarial maduro puede tener un lexicon de varios miles de entradas. Las que acabas de ver son apenas el cimiento, pero ya muestran el patrón: el conocimiento del dominio vive en texto declarativo, no en código, y crece agregando entradas, no reescribiendo el motor.

Qué gana quien lo implementa

Conviene cerrar nombrando con claridad la diferencia entre tener un lexicon y no tenerlo.

La genialidad de los siete ejes es el corazón del modelo, sí. Pero su adopción (el que una clínica, un banco o una tienda lo usen sin sentir que cambiaron de idioma) depende entera y exclusivamente de este traductor. El catálogo es el motor; el lexicon es el volante. Y nadie conduce agarrando el motor.

Un compilador no le pide al programador que escriba en binario. El lexicon no le pide al usuario que escriba en canónico. Esa es toda la diferencia entre un modelo elegante y un modelo que la gente usa.La tesis del capítulo

Nos queda un frente abierto.

El lexicon resuelve las palabras con varios significados y la jerga. Pero el lenguaje guarda trampas más finas: la negación, la duda, el tiempo verbal que no coincide con el del hecho, las metáforas que ningún diccionario anticipa.

Es hora de poner el modelo entero a prueba contra los casos que de verdad duelen. Eso es el próximo capítulo.