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 sola 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 ajustó la dosis al rediagnosticarla con hipertensión de grado 2. Para la doctora la escena 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 ocurrió un viaje de ida y vuelta entre dos lenguajes (el natural y el estructurado) que vale la pena ver desde adentro.

Vista por dentro, esa interacción no fue un acto único sino una secuencia de seis pasos. El modelo de lenguaje (da igual cuál: modelo_lumen_2026 en nuestros ejemplos, pero la mecánica es idéntica para cualquiera) 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 estructurados: «María Gonzales» se volvió el identificador maria_g; «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 bitemporal (D6) para devolver exactamente lo válido en cada momento. Y, al final, el modelo recompuso todo en una frase fluida, con sus fechas y su conexión causal.

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 exactamente aquello para lo que WQuestions, sin habérselo propuesto, resulta estructuralmente diseñado. 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 mediante function calling y MCP, y qué se vuelve posible que antes era engorroso o sencillamente 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 complementarias. Persistencia inequívoca: 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 (D7)— dejan el razonamiento por escrito. A cambio, al grafo le falta justo lo que el LLM hace mejor: la fluidez lingüística, la lectura de matices, la prosa que un humano lee con gusto.

De ahí la respuesta a la pregunta del título de la sección. Hace cinco años esta arquitectura no tenía interlocutor: traducir entre datos estructurados y lenguaje natural exigía parsers frágiles y reglas a mano. Hoy ese interlocutor existe, habla con fluidez y —el punto decisivo— sabe invocar funciones por su cuenta. La simbiosis pasó de ser una aspiración a ser operativa.

El lexicon es un function schema

Hay una observación que ya hizo el capítulo 14 y que conviene retomar en limpio, porque es la bisagra entre las dos mitades del sistema. Lo recordarás así: una entrada del lexicon tiene exactamente la forma que los protocolos de function calling esperan. Aquí no la repetiremos con el verbo vender de aquel capítulo; tomemos el caso clínico que abre este, prescribir, y pongámoslo 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 como una 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 precisamente 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 convierten en metadatos del esquema y aportan una validación semántica extra. Y la lista de obligatorios es, literalmente, el campo required.

Lo que esa identidad 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 un catálogo de funciones. Las herramientas que ya existen para function calling consumen ese catálogo 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 herramientas externas se expongan a los modelos de lenguaje de forma uniforme. La idea es modesta y por eso poderosa: en vez de que cada aplicación invente su propia 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é tipo de respuesta devuelve; cualquier modelo que «hable MCP» puede usar ese servidor sin una línea de pegamento adicional.

Para WQuestions la consecuencia es casi una tautología: el servidor MCP de un sistema WQuestions es el lexicon expuesto como funciones. Cada verbo se vuelve una herramienta de ingesta; cada consulta-WH habitual se vuelve una herramienta de consulta; cada explicación del «por qué» se vuelve una herramienta de auditoría. Mira cómo se ve 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 corporativo (piensa en un «asistente del director financiero», un «asistente del médico de cabecera», un «asistente del periodista de investigación») se construye conectando un LLM a ese servidor. No hay glue code enmarañado: hay un catálogo declarativo de funciones y un modelo que las elige 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: jamás escribe SQL, jamás abre un tablero, jamás aprende un lenguaje de consulta. El lexicon del spa es la API y el LLM es el traductor. El sistema se vuelve operable conversacionalmente sin que el negocio renuncie a un gramo de su rigor estructural.

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 reificadas (D4), todas validadas contra el catálogo. La prosa original queda como nota de respaldo; la estructura entra al grafo, donde se vuelve consultable, agregable y auditable. Fíjate en la última llamada: el control futuro entra con estatus_factual: previsto, no como un 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 (la misma paredes de nuestra sesión, pero ahora en su faceta de investigación) 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 sustrato común, los tres dominios viven en el mismo grafo, cada uno con su dialecto. Ella escribe una sola 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 correlaciona por cercanía temporal y compone una respuesta narrativa. Es posible porque ambos dominios comparten el mismo modelo subyacente: 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 volcar todo en prosa y dejar que el modelo encuentre lo que necesita. Funciona, sí, pero gasta el presupuesto a una velocidad ingenua. Tres cifras, tomadas de los dominios que modelamos en la Parte V:

Pero la compresión, con ser importante, no es lo que más cambia el cálculo. El segundo factor pesa más: la ambigüedad. La prosa obliga al modelo a reinterpretar coreferencias («él», «el doctor», «la paciente mencionada»), a inferir 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 WQuestions entrega ese esqueleto ya reconstruido. El modelo puede dedicar su capacidad a lo suyo: razonar, conectar, redactar con fluidez. La economía es doble (menos tokens y mejor calidad de respuesta) y 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, una pieza de software o un sensor, según el verbo. Aquello no era adorno; es justo la propiedad que un futuro multi-agente reclama. Imagina, a tres años vista, un sistema empresarial donde varios LLMs especializados (uno clínico, uno financiero, uno legal) colaboran sobre el mismo grafo. Cada uno trae su sub-lexicon; 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, y la única que justifica todo el aparato conceptual de las cinco primeras partes. WQuestions, expuesto vía MCP, es una pieza de infraestructura para la IA conversacional empresarial. No un producto, no un framework: una capa estructural sobre la que se construyen aplicaciones.

Tres fuerzas se alinearon a la vez. Los modelos de lenguaje volvieron operativa la simbiosis entre prosa y estructura. Protocolos como MCP estandarizaron el cable. Y el costo de cómputo bajó hasta el punto en que un asistente conversacional con grafo persistente es asequible para una empresa mediana. Hace cinco años faltaban las tres; hoy están las tres. De ahí la tesis de tiempo con la que abrimos: el momento de WQuestions es ahora.

Lo que el capítulo 27 explora es el lado expansivo de esta misma 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 la especulación, porque ahí —y solo ahí— es donde este libro se permite mirar hacia adelante.