Al·lucinacions LLM — com detectar-les, limitar-les i gestionar el risc en producció

Què són les al·lucinacions i per què apareixen

Una al·lucinació en un LLM és la generació d'informació que sona creïble però és factualment falsa o no justificada. No és un „error” en el sentit d'una fallada del sistema — és una conseqüència del funcionament dels models de llenguatge. L'LLM no „sap” com ho fa una base de dades — prediu el següent token més probable, basant-se en l'estadística d'entrenament. Quan al prompt apareix una pregunta per a la qual el model no té bona cobertura a les dades d'entrenament, genera la resposta „que sona més probable”. Sovint aquesta resposta és correcta. De vegades, no.

Escenaris típics d'al·lucinacions en aplicacions empresarials:

Citació de sentències judicials o paràgrafs de lleis inexistents en l'assessorament jurídic
Inventar noms de funcions, classes o biblioteques en la generació de codi
Proporcionar estadístiques o dates incorrectes en informes
Inventar contactes, adreces, números de telèfon
Mesclar fets relatius a diferents empreses o persones amb noms similars

Capa 1 — Grounding (RAG)

La tècnica individual més efectiva per reduir les al·lucinacions és el grounding — proporcionar al model documents o dades concrets com a context d'on extreure les respostes. RAG clàssic (Retrieval-Augmented Generation):

Pregunta de l'usuari → cerca dels fragments més rellevants dels documents (vector search en base pgvector / Qdrant / Milvus)
Fragments + pregunta → prompt amb instrucció „respon exclusivament basant-te en els documents següents”
Resposta del model → verificació que conté citacions/referències a les fonts

El RAG redueix les al·lucinacions típicament en un 60-80% en aplicacions tipus „respon preguntes sobre la nostra base de coneixement”. No les elimina completament — el model encara pot „interpretar” els documents de manera no justificada. D'aquí la necessitat de més capes.

Capa 2 — Self-consistency i ensemble

La self-consistency és una tècnica que consisteix a fer la mateixa pregunta diverses vegades (o a diferents models) i comparar les respostes. Quan les respostes són consistents — alta confiança. Quan difereixen — senyal que el tema és incert.

Variant pràctica: pregunta a Claude Sonnet, Llama 70B i Bielik la mateixa pregunta. Si els tres retornen el mateix nombre, data, fet — probablement correcte. Si difereixen — escalació a humà o a un model més car (Opus). Aquest patró, implementat en routing LLM de 8 nivells, combina la reducció de costos amb la millora de la fiabilitat.

Capa 3 — Evaluation pipelines

Una implementació en producció d'un LLM sense evaluation pipeline és com escriure codi sense proves. Mètriques concretes:

Faithfulness — si la resposta es deriva dels documents proporcionats. Mesurada per un segon model d'IA (LLM-as-judge) o per una biblioteca com RAGAS, deepeval.
Answer relevance — si la resposta aborda la pregunta de l'usuari.
Context precision — si els millors fragments han estat retornats pel retrieval (qualitat del vector search).
Groundedness score — percentatge d'afirmacions a la resposta per a les quals es pot indicar una font al context.

Cada nou build d'una aplicació basada en LLM hauria de passar un conjunt de 50-500 preguntes d'avaluació amb ground truth conegut. Si la faithfulness cau per sota del 90% — deployment blocked.

Capa 4 — Guardrails i validació d'output

Els guardrails són regles que validen l'output de l'LLM abans de lliurar-lo a l'usuari. Exemples:

Schema validation — l'output ha de complir un esquema concret (JSON Schema, Pydantic). Les al·lucinacions tipus „camps inventats” es detecten mecànicament.
Forbidden patterns — detecció i bloqueig de patrons no permesos (PII sense emmascarar, dades financeres fora de context, contingut potencialment nociu).
Citation enforcement — cada afirmació factual ha de tenir una cita de font. Si el model no cita — la resposta es rebutja.
Numeric range validation — els nombres a l'output es comproven pel que fa al sentit (per exemple, preu > 0, data ≤ avui, percentatge en rang 0-100).
Cross-reference check — comparació de l'output amb una base de fets (per exemple, KRS, diccionari de citacions de lleis).

Biblioteques: Guardrails AI, NeMo Guardrails, instructor (per a schema enforcement). La implementació pròpia sovint és més simple i barata de mantenir.

Capa 5 — Human-in-the-loop

Per a aplicacions d'alt risc (decisions jurídiques, mèdiques, financeres, de RH) la capa human-in-the-loop és indispensable. Els models d'IA no prenen la decisió final — donen suport a l'humà. Patrons concrets:

Draft + review — la IA genera una primera versió del document/resposta, l'humà verifica i accepta abans d'enviar.
Confidence threshold — les respostes amb baixa confidence (de self-consistency o explicit confidence asking) s'escalen automàticament a l'humà.
Random sampling QA — el 5-10% de totes les respostes de l'LLM s'auditen manualment, independentment de la confidence — mètrica base de qualitat al llarg del temps.
Feedback loop — l'usuari pot marcar una resposta errònia; el sistema aprèn i millora el retrieval, els prompts, els paràmetres.

Mesurament — com saber que la reducció funciona

Mètriques de producció concretes que val la pena monitoritzar:

Hallucination rate — percentatge de respostes classificades com a al·lucinació en l'avaluació manual (sampling). Objectiu: per sota del 2% per a aplicacions business-critical.
User feedback rate — percentatge d'usuaris que han marcat una resposta com a errònia.
Escalation rate — percentatge de consultes escalades a l'humà. Massa baix (per sota del 5%) — el sistema probablement omet casos incerts. Massa alt (per sobre del 30%) — el sistema no proporciona valor d'automatització.
Faithfulness score en proves de regressió — tendència mensual.
Time-to-correction — des de la detecció de l'al·lucinació fins a la implementació de la correcció (millor retrieval, nou guardrail, fine-tuning).

Conclusions per als decisors

Les al·lucinacions són manejables — requereixen inversió en arquitectura defensiva en múltiples capes. Les empreses que implementen LLM sense aquesta arquitectura, tard o d'hora topen amb un incident greu (publicació d'informació incorrecta a un client, decisió errònia basada en dades al·lucinades, dany reputacional). El cost de construir l'stack defensiu complet (RAG + evaluation + guardrails + human-in-the-loop) és típicament el 15-30% del cost de la pròpia implementació de l'LLM — i és una inversió absolutament necessària per a aplicacions de producció. Les conseqüències d'ometre'l són asimètriques: baix cost d'inacció en el 95% dels casos, catastròfic en el 5%.