Hay una parte de los sistemas conversacionales de la que casi nadie habla, y que sin embargo es la que decide si todo lo demás funciona o no. Es, en resumen, el momento en que lo que dice el usuario se convierte en algo que la plataforma entiende. En Faktoria le hemos puesto nombre a esa pieza: Konect Parse.

No es un paso decorativo. Una persona llama por teléfono y dice «dos de septiembre de mil novecientos setenta y siete». El sistema necesita 02/09/1977. Otra persona escribe «quiero darme de baja». El sistema necesita saber que eso es una intención de cancelación, no un alta ni una incidencia. Entre medias hay un salto —del lenguaje natural al dato estructurado— que, si se resuelve mal, arrastra fallos al resto del flujo.

De la teoría al componente concreto

En los últimos días hemos publicado dos artículos que van al fondo de cómo entendemos la IA conversacional. Uno sobre por qué un LLM solo no basta y hace falta una arquitectura híbrida que combine modelos con lógica determinista. Otro sobre por qué, en muchos contextos, el procesamiento del lenguaje tiene que ocurrir en local, sin llamar a la nube.

Konect Parse es donde esas dos ideas dejan de ser principios y se convierten en algo que funciona dentro de Konect: es un microservicio especializado que transforma entradas conversacionales —ruidosas, coloquiales, imprecisas— en información estructurada, clasificada y lista para automatizar.

El problema que nadie ve

Cuando una persona interactúa con un asistente —por teléfono, por chat, por WhatsApp—, la entrada que le llega al sistema rara vez es limpia. En canales de voz, la transcripción (el famoso STT) viene con imprecisiones, repeticiones, muletillas, datos dictados de forma caótica y frases que empiezan en un sitio y acaban en otro. En texto, aunque hay menos ruido, el reto sigue ahí: hay que entender qué quiere hacer el usuario, qué dato está aportando y cómo debe reaccionar la plataforma.

Ese paso intermedio —de «lo que el usuario dice» a «lo que el sistema necesita entender»— es el cuello de botella silencioso de prácticamente todos los asistentes conversacionales que hemos visto fallar. Cuando esa capa está mal resuelta, da igual lo bueno que sea el resto del sistema: los datos llegan torcidos, las automatizaciones se rompen y el asistente acaba dando sensación de torpeza. Konect Parse existe para que esa capa deje de ser un problema.

Un enfoque híbrido, capa a capa

Aquí es donde Konect Parse aterriza la idea de arquitectura híbrida que defendíamos en el primer post. No resuelve todos los casos con la misma técnica: combina varios mecanismos y aplica el más adecuado a cada problema. El sistema trabaja en tres capas:

• Primera capa — reglas deterministas. Para variables que tienen un patrón claro como una fecha, un teléfono, un DNI, un IBAN o una cantidad. Estas cosas no necesitan un modelo generativo: necesitan buenas reglas, bien escritas. La latencia es prácticamente cero y el resultado es siempre el mismo para la misma entrada. Predecible, auditable y preciso.
• Segunda capa — fuzzy matching. Cuando lo que hay que hacer es clasificar entre un conjunto de opciones, como por ejemplo, distinguir entre «alta», «baja» e «incidencia», y el usuario lo expresa con variaciones léxicas, una comparación por similitud resuelve la mayoría de casos con fiabilidad. Sigue siendo rapidísimo y sigue sin hacer falta un LLM.
• Tercera capa — LLM como red de seguridad. Cuando las dos capas anteriores no tienen confianza suficiente en el resultado, Konect Parse escala al modelo generativo para interpretar semánticamente lo que el usuario quiso decir. Es la capa más potente, y también la que más recursos consume. Por eso se reserva para los casos en los que realmente aporta valor, no para los que ya estaban resueltos.

La clave de este diseño es casi una cuestión de criterio: saber cuándo no escalar. Invocar un LLM para normalizar una fecha que una regla resuelve en un milisegundo no es buena ingeniería, es desperdiciar recursos en un problema que no lo pedía. Konect Parse está construido con esa filosofía encima: a cada problema, la herramienta proporcionada. Ni más compleja de lo que hace falta, ni menos precisa de lo que el caso requiere.

Dos ejemplos para que se vea

Ejemplo 1: una fecha dictada por voz

Una persona llama a un servicio y, cuando se le pide su fecha de nacimiento, dice:

«Dos de septiembre de mil novecientos setenta y siete.»

La transcripción STT devuelve esa cadena tal cual. El sistema la pasa a Konect Parse indicándole que espera una fecha en formato DD/MM/YYYY. Konect Parse la procesa con su primera capa y devuelve:

02/09/1977

Sin ambigüedad, sin intervención de ningún modelo generativo, en prácticamente cero milisegundos. El flujo puede seguir sin friccionar al usuario y sin tirar tokens de un LLM para algo que no los necesita.

Ejemplo 2: una intención expresada en lenguaje natural

Un usuario escribe en el chat:

«Quiero darme de baja.»

El sistema le pasa esa frase a Konect Parse junto con las tres intenciones posibles del flujo: alta, baja, incidencia. Konect Parse las compara con similitud léxica y devuelve un ranking:

baja: 0.95 · alta: 0.03 · incidencia: 0.02

Con eso, la plataforma sabe con qué rama del flujo seguir. Sin llamar a la nube, sin esperar a un modelo y sin ambigüedad. Si la frase hubiera sido más ambigua, como podría ser«me estoy pensando si seguir con vosotros», probablemente ninguna de las opciones habría pasado el umbral de confianza y se habría escalado al LLM, que sí tiene la capacidad de interpretar intención a nivel semántico.

Y todo sin llamar a la nube

El segundo pilar de este diseño conecta directamente con el post sobre NLP en local. Konect Parse corre íntegramente dentro de la infraestructura donde se despliegue Konect. ¿Por qué? Para una administración pública, una entidad sanitaria o cualquier organización con obligaciones de cumplimiento serias, que las conversaciones y los datos que contienen no viajen a servidores de terceros no es «un plus»: es un requisito. Y cuando la comprensión del lenguaje se resuelve en local, ese requisito deja de depender de contratos y pasa a estar garantizado por diseño.

Además, ejecutar todo en local tiene un efecto secundario que los equipos técnicos valoran: latencia predecible. No hay viajes de red, no hay cuotas de API, no hay caídas de un proveedor externo que se lleven por delante todo el contact center.

Lo que aporta a Konect

Puesto en Konect, este microservicio mueve tres cosas que se notan en el resultado final:

• Categorización más fina. Konect identifica antes y mejor qué quiere el usuario, diferencia tipologías de consulta y reduce ambigüedades antes de que el flujo avance. Cuanto mejor se entiende la entrada, menos errores arrastra todo lo demás.
• Normalización consistente. Fechas, documentos, teléfonos, cantidades, IBAN… se interpretan y estructuran siempre de la misma manera, independientemente de cómo los haya dictado el usuario.
• Mejor enrutado. Cuando la plataforma entiende bien lo que se le pide, decide mejor qué hacer a continuación: redirige a la rama correcta, activa la automatización adecuada, completa el proceso o pide una aclaración solo cuando de verdad hace falta. Menos rebotes, menos conversaciones atascadas.

Y desde el punto de vista de arquitectura, encapsular todo esto como un microservicio especializado le da a Konect modularidad, capacidad de evolución y una separación limpia de responsabilidades. Si mañana cambia el modelo que usamos en la tercera capa, o añadimos nuevos tipos de variables, el resto de la plataforma ni se entera.

Por qué esto importa

Volviendo al hilo de los tres artículos: si algo hemos aprendido de los últimos años montando asistentes conversacionales en entornos reales, es que la calidad del procesamiento de entrada es la que determina la calidad de todo lo que viene después. Si esa capa falla, no hay integración, flujo ni LLM que lo arregle aguas abajo.

Y por el contrario, cuando esa capa está bien resuelta, el resto del sistema respira. Las conversaciones avanzan con más naturalidad, las integraciones reciben datos fiables y la plataforma puede operar con confianza en escenarios reales. Konect Parse es, precisamente, la pieza que permite a Konect convertir conversaciones en acciones. No solo hablar: entender con criterio, procesar con eficiencia y actuar con fiabilidad.