Por qué un LLM no reemplazará a un buen parser. Caso con repuestos de automóviles

Un cliente vino con una tarea que, al principio, parece casi ingenuamente simple — tanto que resulta un poco sospechosa.

Hay un catálogo: más de 50 000 posiciones, y no está quieto, sino que crece constantemente por los proveedores, que trabajan a su propio ritmo y no se preocupan demasiado por la uniformidad de los nombres. Por otro lado — un flujo de pedidos en el que ya no queda ninguna estructura: alguien escribe el número de artículo, alguien la modelo del coche, alguien intenta describir el problema en lenguaje humano, y alguien se limita a algo como “necesito pastillas delanteras para Audi A4 B8 urgente”, como si el sistema tuviera que entenderlo por la entonación.

Los gestores que trabajan con esto a diario normalmente no explican exactamente cómo lo hacen. Simplemente miran el texto y extraen el sentido con bastante rapidez, pero si se observa con más atención, queda claro que no hay ninguna magia de comprensión. Más bien es una habilidad consolidada de reconocimiento de patrones: un conjunto de palabras se descompone instantáneamente en entidades familiares que se han ido acumulando durante años en la cabeza — tipo de pieza, modelo, generación, sustituciones admisibles, parámetros críticos. No es leer el texto, es trabajar con un manual interno que dejó de ser explícito hace tiempo.

Y en ese contexto surge inevitablemente la primera y más obvia propuesta: conectemos un LLM, que “entienda” todo esto.

Dónde falla esta idea

El problema es que tareas como esta se confunden con facilidad con problemas de comprensión del lenguaje, aunque en esencia están más cerca de una filtración ingenieril con restricciones estrictas que de un análisis semántico.

Tomemos ejemplos sencillos. Oil filter 2.0L diesel Audi A4 y Oil filter 2.0L petrol Audi A4 — desde el punto de vista de la cercanía lingüística es casi la misma descripción, la diferencia parece cosmética, aclaratoria, algo que el modelo perfectamente puede “promediar” como poco relevante. Pero en realidad ya son dos entidades físicas distintas, y un error aquí no se convierte en una pequeña discrepancia, sino en incompatibilidad.

Lo mismo ocurre con los discos de freno: Audi A4 B7 brake disc 280x22 y Audi A4 B8 brake disc 280x25 parecen casi idénticos, especialmente si miras como texto. La diferencia de tres milímetros de espesor en el espacio semántico casi desaparece, se disuelve en la semejanza general, pero en la realidad ingenieril precisamente esa diferencia es la clave que separa “vale” de “no vale en absoluto”.

Y aquí es importante fijar un punto: el modelo no “se equivoca” en el sentido habitual. Simplemente hace lo que mejor sabe hacer — encuentra lo que es cercano en significado. El problema es que aquí el significado no es la medida principal.

Búsqueda vectorial y la elegante ilusión de proximidad

El siguiente paso que suele venir a la mente casi automáticamente son los embeddings y la búsqueda vectorial. A primera vista hasta parece la dirección correcta: los textos se convierten en vectores, luego simplemente buscamos las coincidencias más cercanas, y parece que el problema se resuelve con más elegancia.

En la práctica todo choca con la misma cosa fundamental: el espacio vectorial funciona bien donde “semejanza” realmente significa proximidad útil, pero empieza a fallar donde importan diferencias estrictas en parámetros concretos. Acerca front brake pads y “pastillas delanteras”, porque allí el sentido coincide, pero también acerca con tanta seguridad 280x22 y 280x25, porque para él son simplemente dos conjuntos de caracteres muy parecidos, y no dos parámetros ingenieriles mutuamente excluyentes.

Y en algún momento se vuelve obvio que toda esa cercanía semántica empieza a jugar en contra de la tarea: el sistema comienza a encontrar “casi correcto”, y en este dominio casi correcto suele significar incorrecto.

Intento de “simplemente entrenar nuestro propio modelo”

A continuación suele surgir otra idea comprensible: si los modelos listos no consideran la especificidad, entonces hay que entrenar el propio, con nuestros datos, para nuestra nomenclatura.

Suena racional, pero solo hasta que se mira el volumen de lo que eso requiere. Para que un modelo distinga de manera estable parámetros críticos — tipo de motor, plataforma, dimensiones, compatibilidad de piezas — se necesitan no solo datos, sino una enorme cantidad de ejemplos cuidadosamente etiquetados, donde cada correspondencia esté confirmada por una persona que sabe exactamente lo que hace.

Y aquí normalmente llega la realidad. Los datos o no existen, o son insuficientes, o son ruidosos e incompletos, y el intento de llevarlos a la calidad necesaria se convierte en un proyecto largo aparte, cuya complejidad empieza a competir con la propia tarea. La ironía es que en ese momento la “solución ML simple” de repente resulta más cara que reglas escritas con cuidado.

Qué hay que hacer en realidad

Si se quita toda la inclinación habitual hacia soluciones “inteligentes”, la tarea resulta bastante terrenal. No hace falta comprender el texto en el sentido humano, no hace falta adivinar la intención ni buscar análogos semánticos. Hace falta otra cosa: descomponer la cadena de entrada en una estructura y luego trabajar ya no con texto, sino con un conjunto de campos estrictamente definidos.

De una cadena como Brake disc ventilated front R 280x25 Audi A4 B8 hay que extraer no el “sentido”, sino la estructura: tipo de pieza, configuración, posición, dimensiones, modelo y generación. Tras eso la búsqueda se convierte en una comparación habitual de parámetros, donde o coincide, o no, o se permite un rango estrictamente definido si la lógica de negocio lo autoriza.

Y en ese momento se ve que la parte más difícil de todo el sistema no va de algoritmos. Va del dominio. De cómo están hechas las piezas, qué parámetros son críticos, cómo se relacionan entre sí, qué puede considerarse equivalente y qué no se puede tocar bajo ninguna circunstancia. Es un vocabulario que normalmente no parece tecnología, por eso suele subestimarse.

Dónde un LLM es realmente apropiado

Eso no significa que el LLM quede fuera del sistema, como a veces se quiere declarar en un arranque de honestidad ingenieril. Simplemente su papel resulta mucho más estrecho y, siendo sinceros, bastante mundano.

Funciona bien donde el texto de entrada está desestructurado, ruidoso, escrito como sea y lo contiene todo a la vez. En esos casos el modelo sí extrae la estructura bastante bien: reconoce el modelo del coche, el tipo de pieza, generaciones, posiciones, incluso cuando todo está mezclado en una frase sin orden.

Pero después ya no hace falta. Tras la fase de extracción comienza la zona donde no se puede trabajar con probabilidades y similitudes, porque el coste del error es demasiado directo. Ahí quedan la normalización, el diccionario, las correspondencias exactas y las reglas de compatibilidad.

Y ese, probablemente, es el punto principal de toda esta historia.

En vez de una conclusión

En tareas como esta casi siempre existe la tentación de encontrar “un modelo más inteligente” que lo resuelva todo por sí mismo. Es una ansia comprensible — ahorra tiempo en la parte desagradable del trabajo, donde hay que ocuparse no de tecnologías sino del dominio.

Pero la realidad es más simple y un poco más aburrida: si la tarea exige precisión, no la salva ni la semántica, ni la proximidad vectorial, ni el intento de entrenar una inteligencia universal para el caos local de los datos. Salvan la estructura, las reglas y comprender qué parámetros del sistema son realmente críticos.

Y a veces la herramienta menos interesante resulta ser la única que realmente funciona.