WQuestions y los modelos de lenguaje

Son las 08:11 de un martes. La doctora Paredes abre el asistente de su sistema clínico antes de la primera consulta y escribe una línea: «¿qué medicación venía tomando María Gonzales y desde cuándo?».

Tres segundos después la pantalla responde, en español llano, que María tomaba enalapril 10 mg cada mañana desde el 14 de mayo de 2026. Sin cambios hasta el 10 de enero de 2027, cuando se le ajustó la dosis al rediagnosticarla con hipertensión de grado 2.

Para la doctora es trivial: una pregunta en castellano, una respuesta en castellano.

Pero entre el instante en que pulsó Enter y el instante en que apareció el texto hubo un viaje de ida y vuelta entre dos lenguajes, el natural y el estructurado. Vale la pena verlo desde adentro.

Por dentro, esa interacción no fue un acto único. Fueron seis pasos.

El modelo de lenguaje (da igual cuál; usamos modelo_lumen_2026 en los ejemplos, pero la mecánica es la misma) recibió el texto y lo leyó como una intención de consulta.

Eligió, del catálogo de funciones que el sistema le expone, la adecuada: consultar_tratamiento(paciente, periodo).

Tradujo el castellano a argumentos: «María Gonzales» se volvió el identificador maria_g, y «desde cuándo» se volvió un periodo que abarca todo el histórico.

Invocó la función, que por dentro corrió un patrón sobre el grafo. El grafo respondió con la prescripción vigente y su historia, usando la vigencia (D6) para devolver exactamente lo válido en cada momento.

Y al final el modelo lo recompuso todo en una frase fluida, con sus fechas y su causa.

Esa secuencia (usuario natural, modelo, función estructurada, grafo persistente, respuesta natural) es la forma canónica del momento tecnológico de 2026. Y es justo aquello para lo que WQuestions, sin habérselo propuesto, encaja.

Este capítulo defiende una tesis de tiempo: el momento de esta arquitectura es ahora. Porque solo ahora existe la pieza que traduce con soltura entre el lenguaje de las personas y el conocimiento estructurado.

Veremos por qué la pareja es complementaria y no casual, cómo se expone el modelo a un LLM, y qué se vuelve posible que antes era engorroso o imposible.

Por qué este es el momento, y no otro

Los modelos de lenguaje de la generación 2024–2026 son fluidos como ninguna tecnología anterior. Pero traen, dentro del mismo paquete, tres debilidades estructurales. No son fallos de implementación que se corrijan con una versión más: son límites de lo que un modelo generativo es.

Ahora mira la otra columna del balance. WQuestions tiene, casi por construcción, las tres propiedades que faltan del otro lado.

Persistencia sin ambigüedad: el grafo guarda y no olvida. Distinción entre lo afirmado y lo conjeturado: el cable estatus_factual marca cada hecho como confirmado, previsto o hipotético. Y trazabilidad: las cuatro relaciones del «por qué» (causado_por, motivado_por, con_finalidad, justificado_por, la decisión D7) dejan el razonamiento por escrito.

A cambio, al grafo le falta justo lo que el LLM hace mejor: la fluidez, la lectura de matices, la prosa que un humano lee con gusto.

De ahí la respuesta a la pregunta del título. Hace cinco años esta arquitectura no tenía interlocutor: traducir entre datos estructurados y lenguaje natural exigía analizadores frágiles y reglas a mano.

Hoy ese interlocutor existe, habla con fluidez y, lo decisivo, sabe invocar funciones por su cuenta. La simbiosis dejó de ser aspiración y pasó a funcionar.

El lexicon es un function schema

Hay una observación del capítulo 14 que conviene retomar, porque es la bisagra entre las dos mitades del sistema.

La recordarás así: una entrada del lexicon tiene exactamente la forma que esperan los protocolos de invocación de funciones. Aquí no la repetimos con el verbo vender de aquel capítulo. Tomamos el caso clínico que abre este, prescribir, y lo ponemos al lado de su esquema.

Primero, la entrada del lexicon, tal como vive por dentro del modelo: vocabulario natural en los aliases, roles canónicos en las claves:

verbo: prescribir
  tipo_situacion: accion_prescribir
  obligatorios: [agente, paciente, medicamento_prescrito]
  opcionales:   [frecuencia, duracion, momento]
  aliases:
    agente:                ["doctor", "médico", "doctora"]
    paciente:              ["paciente"]
    medicamento_prescrito: ["fármaco", "medicación", "medicina"]
    frecuencia:            ["cada cuánto", "tomas por día"]

Y ahora el mismo objeto, serializado como el tool schema que un modelo recibe al arrancar la conversación. No hay traducción manual: es la misma información en otra envoltura.

{
  "name": "accion_prescribir",
  "description": "Registrar una prescripción médica.",
  "input_schema": {
    "type": "object",
    "properties": {
      "agente":                { "type": "string", "eje": "Q", "description": "doctor, médico, doctora" },
      "paciente":              { "type": "string", "eje": "Q", "description": "paciente" },
      "medicamento_prescrito": { "type": "string", "eje": "K", "description": "fármaco, medicación, medicina" },
      "frecuencia":            { "type": "string", "eje": "K", "description": "cada cuánto, tomas por día" },
      "duracion":              { "type": "string", "eje": "K" },
      "momento":               { "type": "string", "eje": "T" }
    },
    "required": ["agente", "paciente", "medicamento_prescrito"]
  }
}

La correspondencia es uno a uno, y vale enumerarla para que no quede en intuición difusa.

El verbo se vuelve el name. El tipo_situacion es el tipo de objeto que la función devolverá al asentarse en el grafo.

Los aliases de cada rol alimentan la description, que es la pista que el modelo lee para reconocer cómo se expresa ese rol en lenguaje natural.

Los ejes de origen (Q, O, K, T) se vuelven metadatos del esquema y añaden una validación extra. Y la lista de obligatorios es, literalmente, el campo required.

Lo que eso implica en la práctica es contundente. Para exponer WQuestions a un LLM no hay que escribir un adaptador a medida. Hay que exportar el lexicon como catálogo de funciones.

Las herramientas que ya existen lo consumen sin tocar una línea. Lo que en otras arquitecturas es un proyecto de integración, aquí es una función de serialización.

MCP: el cable estándar

En 2024, Anthropic publicó la especificación de MCP (Model Context Protocol), un estándar abierto para que las herramientas externas se expongan a los modelos de lenguaje de forma uniforme.

La idea es modesta y por eso funciona. En vez de que cada aplicación invente su manera de conectar un LLM a sus datos, MCP define un protocolo común.

Un servidor MCP declara qué funciones ofrece, qué argumentos acepta y qué devuelve. Cualquier modelo que hable MCP puede usarlo sin una línea de pegamento.

Para WQuestions la consecuencia es casi una obviedad: el servidor MCP de un sistema WQuestions es el lexicon expuesto como funciones.

Cada verbo se vuelve una herramienta de ingesta. Cada consulta habitual, una herramienta de consulta. Cada explicación del «por qué», una herramienta de auditoría.

Mira cómo queda el servidor del spa, el mismo Spa Oasis de la Parte V, una vez publicado:

Tools expuestas:

  ingesta:
    - registrar_sesion(cliente, lugar, inicio, fin)
    - aplicar_promocion(cliente, promocion, momento)
    - redimir_beneficio(cliente, beneficio)

  consulta:
    - sesiones_de_cliente(cliente, desde, hasta)   -> Lista[Sesion]
    - cliente_califica_fidelidad(cliente)          -> bool
    - clientes_con_intencion_de_contratar()        -> Lista[Cliente]

  auditoria:
    - por_que_este_cobro(pago)                      -> Explicacion
    - estado_de_cliente_en(cliente, momento)       -> Estado

Un asistente conversacional de empresa (el «asistente del director financiero», el «asistente del médico de cabecera», el «asistente del periodista de investigación») se construye conectando un LLM a ese servidor.

No hay código de pegamento enmarañado. Hay un catálogo de funciones y un modelo que elige cuál usar según la conversación.

El servidor MCP de un sistema WQuestions no es un componente que haya que escribir; es el lexicon, mirado desde afuera.La economía de la integración

Tres casos de uso, ya posibles en 2026

Conviene aterrizar la idea en escenarios concretos (no especulación, sino cosas técnicamente factibles hoy) donde WQuestions encaja justo en el hueco que el LLM no llena solo.

1 · Asistente operativo de un negocio

El dueño del Spa Oasis, en lugar de revisar reportes, conversa con su sistema. Cada turno se traduce a una o más llamadas a las funciones del lexicon del spa:

— ¿Cuántos clientes nuevos vinieron este mes?
  → 23 clientes nuevos en mayo, 30 % más que abril. Los miércoles
    concentraron el 40 % del crecimiento.

— ¿Y cuáles de los nuevos están cerca del beneficio de fidelidad?
  → Cinco están a una o dos sesiones del beneficio. Tres reservaron
    para esta semana; los otros dos no aparecen hace más de diez días.

— Mándales un mensaje a los que no vinieron.
  → Borrador listo para Mariana C. y Tomás R. ¿Lo envío?

El modelo no sabe de spas. Sabe del lexicon. El grafo guarda el estado real; la conversación es la interfaz, no la base de datos.

Lo notable es lo que el dueño no hace. No escribe SQL. No abre un tablero. No aprende ningún lenguaje de consulta.

El lexicon del spa es la API, y el LLM es el traductor. El sistema se vuelve manejable a base de conversación sin que el negocio pierda un gramo de rigor.

2 · Ingesta automática desde texto libre

Un hospital tiene veinte años de historias clínicas en prosa. Migrarlas a un sistema estructurado tradicional es un proyecto millonario que exige reescribir cada nota a mano. Con WQuestions y un LLM el flujo se invierte. Toma una nota cualquiera:

«Paciente femenina de 54 años, refiere cefalea persistente de 3 días de evolución, presión arterial 145/92 mmHg al examen. Se diagnostica HTA grado 1 y se inicia tratamiento con enalapril 10 mg cada mañana. Control en 30 días.»Una nota clínica típica

Se procesa con un prompt que le entrega al modelo el lexicon clínico y le pide: «extrae todas las situaciones de esta nota». El modelo emite (usando function calling una vez por situación) los hechos atómicos ya tipados:

ingest("consultar", roles={
    "agente": dra_paredes, "paciente": maria_g,
    "momento": fecha_nota, "motivo": cefalea,
})
ingest("medir", roles={
    "agente": dra_paredes, "paciente": maria_g,
    "medida_de": presion_arterial,
    "monto": "145/92", "unidad": mmHg,
})
ingest("diagnosticar", roles={
    "agente": dra_paredes, "paciente": maria_g,
    "diagnosticado_como": hta_g1,
})
ingest("prescribir", roles={
    "agente": dra_paredes, "paciente": maria_g,
    "medicamento_prescrito": enalapril,
    "frecuencia": cada_manana,
})
ingest("controlar", roles={
    "paciente": maria_g, "agente": dra_paredes,
    "momento": fecha_nota_mas_30,
    "estatus_factual": previsto,
})

Cinco situaciones (D4), todas validadas contra el catálogo. La prosa original queda como respaldo; la estructura entra al grafo, donde se puede consultar, sumar y auditar.

Fíjate en la última llamada. El control futuro entra con estatus_factual: previsto, no como hecho consumado. El grafo distingue lo que pasó de lo que está planeado, justo la distinción que un LLM por sí solo no sostiene.

3 · Razonamiento entre dominios

Una periodista económica estudia el efecto de una reforma tributaria sobre las ventas minoristas.

Tradicionalmente tendría que cruzar bases inconexas: el registro de ventas con un esquema, los datos macro con otro, las noticias políticas en texto libre.

Con WQuestions como suelo común, los tres dominios viven en el mismo grafo, cada uno con su dialecto. Ella escribe una petición; el modelo la parte en dos consultas, una por dominio, cada cual con su type_constraint:

noticias = query(Pattern(
    fixed={"tema_categorico": impuesto_consumo},
    type_constraint="noticia_politica",
    ask={"agente": Var(), "momento": Var(), "contenido": Var()},
))

ventas = query(Pattern(
    fixed={"sector": retail},
    type_constraint="agregado_ventas_trimestral",
    ask={"momento": Var(), "monto": Var()},
))

Las dos listas vuelven al modelo, que las cruza por cercanía en el tiempo y compone una respuesta narrativa.

Funciona porque los dos dominios comparten el mismo modelo debajo. La periodista no necesita saber que detrás hay dos bases, dos esquemas y dos sistemas. El grafo absorbió los dos, y el LLM razona sobre uno solo.

La economía de tokens, en limpio

Los modelos de 2026 manejan ventanas de contexto enormes: un millón de tokens, dos, cuatro. El instinto fácil es volcarlo todo en prosa y dejar que el modelo encuentre lo que necesita.

Funciona, sí, pero gasta el presupuesto a una velocidad ingenua. Tres cifras de los dominios de la Parte V:

Pero la compresión, con ser importante, no es lo que más cambia el cálculo. Pesa más la ambigüedad.

La prosa obliga al modelo a resolver a quién se refiere cada «él», «el doctor» o «la paciente mencionada». A deducir relaciones implícitas. A reconstruir la estructura desde cero.

Todas esas operaciones consumen atención: tokens efectivos que no se invierten en razonar sobre el contenido, sino en rearmar el esqueleto.

El grafo entrega ese esqueleto ya montado. El modelo puede dedicar su capacidad a lo suyo: razonar, conectar, redactar con fluidez.

La ganancia es doble, menos tokens y mejor respuesta. Por eso no se reduce a una partida en una factura de cómputo.

Multi-agente, de forma nativa

Recuerda la agencia contextual (D5): el rol agente lo puede ocupar un humano, una organización, un programa o un sensor, según el verbo. Aquello no era adorno. Es justo la propiedad que reclama un futuro con varios agentes.

Imagina, a tres años vista, un sistema donde varios LLMs especializados (uno clínico, uno financiero, uno legal) colaboran sobre el mismo grafo. Cada uno trae su sub-lexicon y cada uno entra al grafo como agente cuando asienta un hecho:

(diagnostico_001, agente, lim_clinico_v3)     ∈ M(O, Q)
(asiento_001,     agente, lim_financiero_v2)  ∈ M(O, Q)
(opinion_001,     agente, lim_legal_v1)       ∈ M(O, Q)

El grafo registra quién dijo qué y cuándo, exactamente como registraría a un médico de carne y hueso. Y conviene verlo como la tripleta que es: un cable del eje M que sale del evento y aterriza en el agente, sea humano o software:

La trazabilidad es uniforme: el sistema audita a los humanos y a los modelos con la misma maquinaria, sin un canal aparte para cada naturaleza de agente. Es D5 cobrando un sentido que, cuando se enunció en el capítulo 9, todavía sonaba abstracto.

WQuestions como infraestructura

Cerremos con la idea más ambiciosa del libro, la única que justifica el aparato conceptual de las cinco primeras partes.

WQuestions, expuesto vía MCP, es una pieza de infraestructura para la IA conversacional de empresa. No un producto, no un framework. Una capa sobre la que se construyen aplicaciones.

La distinción no es retórica. Un producto se compra. Un framework se aprende. Una infraestructura se da por sentada.

Quien escribe una aplicación web no piensa en TCP/IP. Un sistema que mueve dinero no piensa en SWIFT. Y cuando una conversación con un asistente fluye, nadie piensa en el grafo de abajo. La infraestructura es lo que se vuelve invisible porque funciona.

El proyecto, hoy, todavía no está listo para serlo. Le faltan piezas: persistencia industrial, motor de inferencia, los dos tiempos completos, un lexicon poblado con miles de verbos en varios idiomas. El capítulo 31 las enumera sin disimulo.

Pero la arquitectura está completa, y el momento empuja a favor.

Tres fuerzas se alinearon a la vez. Los modelos de lenguaje hicieron funcionar la simbiosis entre prosa y estructura. Protocolos como MCP estandarizaron el cable. Y el costo de cómputo bajó hasta hacer asequible, para una empresa mediana, un asistente con grafo persistente.

Hace cinco años faltaban las tres. Hoy están las tres. De ahí la tesis con la que abrimos: el momento de WQuestions es ahora.

El capítulo 27 explora el lado expansivo de esta idea. Si WQuestions fuese infraestructura, ¿qué aplicaciones se vuelven posibles que antes no lo eran?

Algunas suenan a ciencia ficción. Otras resultan obvias en cuanto se las nombra. Las dejaremos sobre la mesa sin disimular que son especulación, porque ahí, y solo ahí, es donde este libro se permite mirar hacia adelante.