Que son as alucinacións e por que aparecen
Unha alucinación nun LLM é xerar información que soa crible pero que é factualmente falsa ou inxustificada. Non é un „erro” no sentido de fallo do sistema — é unha consecuencia do xeito en que funcionan os modelos de linguaxe. O LLM non „sabe” do mesmo xeito que unha base de datos — predí o token seguinte máis probable, en base ás estatísticas de adestramento. Cando no prompt aparece unha pregunta para a que o modelo non ten boa cobertura nos datos de adestramento, xera a resposta „que soa máis probable”. Moitas veces esa resposta é correcta. Ás veces — non.
Escenarios típicos de alucinacións en usos empresariais:
- Citar resolucións xudiciais ou artigos de leis inexistentes en asesoramento xurídico
- Inventar nomes de funcións, clases ou bibliotecas ao xerar código
- Dar estatísticas ou datas incorrectas en informes
- Inventar contactos, enderezos, números de teléfono
- Mesturar feitos referentes a empresas ou persoas con nomes similares
Capa 1 — Grounding (RAG)
A técnica individual máis eficaz para reducir alucinacións é o grounding — proporcionar ao modelo documentos ou datos concretos como contexto do que debe extraer as respostas. RAG clásico (Retrieval-Augmented Generation):
- Pregunta do usuario → busca dos fragmentos de documento máis relevantes (vector search nunha base pgvector / Qdrant / Milvus)
- Fragmentos + pregunta → prompt coa instrución „responde unicamente en base aos documentos a continuación”
- Resposta do modelo → verificación de que contén citas/referencias ás fontes
O RAG reduce as alucinacións tipicamente nun 60-80% en usos do tipo „responde preguntas sobre a nosa base de coñecemento”. Non as elimina por completo — o modelo aínda pode „interpretar” os documentos de xeito inxustificado. De aí a necesidade de capas adicionais.
Capa 2 — Self-consistency e ensemble
A self-consistency é unha técnica que consiste en facer a mesma pregunta varias veces (ou a varios modelos diferentes) e comparar as respostas. Cando as respostas son coherentes — alta confianza. Cando difiren — sinal de que o tema é incerto.
Variante práctica: pregúntalle a Claude Sonnet, Llama 70B e Bielik o mesmo. Se os tres devolven o mesmo número, data, feito — probablemente correcto. Se difiren — escalada ao humano ou a un modelo máis custoso (Opus). Este patrón, implementado no routing LLM de 8 niveis, combina redución de custo con mellora da fiabilidade.
Capa 3 — Evaluation pipelines
Despregar un LLM en produción sen evaluation pipeline é como escribir código sen tests. Métricas concretas:
- Faithfulness — se a resposta deriva dos documentos proporcionados. Medida cun segundo modelo de IA (LLM-as-judge) ou cunha biblioteca do tipo RAGAS, deepeval.
- Answer relevance — se a resposta aborda a pregunta do usuario.
- Context precision — se o retrieval devolveu os mellores fragmentos (calidade do vector search).
- Groundedness score — porcentaxe de afirmacións na resposta para as que se pode mostrar fonte no contexto.
Cada nova build dunha aplicación baseada en LLM debería pasar un conxunto de 50-500 preguntas de avaliación con ground truth coñecido. Se a faithfulness baixa por debaixo do 90% — deployment bloqueado.
Capa 4 — Guardrails e validación da saída
Os guardrails son regras que validan a saída do LLM antes de entregala ao usuario. Exemplos:
- Validación de esquema — a saída debe cumprir un esquema concreto (JSON Schema, Pydantic). As alucinacións de tipo „campos inventados” detéctanse mecanicamente.
- Forbidden patterns — detección e bloqueo de patróns non admisibles (PII sen enmascarar, datos financeiros fóra de contexto, contidos potencialmente daniños).
- Citation enforcement — cada afirmación factual debe ter cita de fonte. Se o modelo non cita — rexéitase a resposta.
- Validación de rangos numéricos — os números na saída verifícanse en termos de sentido (por exemplo, prezo > 0, data ≤ hoxe, porcentaxe no rango 0-100).
- Cross-reference check — comparación da saída cunha base de feitos (por exemplo KRS, dicionario de citas de leis).
Bibliotecas: Guardrails AI, NeMo Guardrails, instructor (para schema enforcement). A implementación propia adoita ser máis simple e máis barata de manter.
Capa 5 — Human-in-the-loop
Para aplicacións de alto risco (decisións xurídicas, médicas, financeiras, de RRHH) a capa human-in-the-loop é imprescindible. Os modelos de IA non toman a decisión final — apoian ao humano. Patróns concretos:
- Draft + review — a IA xera a primeira versión do documento/resposta, o humano verifica e acepta antes de enviar.
- Confidence threshold — as respostas con baixa confianza (de self-consistency ou de explicit confidence asking) escálanse automaticamente ao humano.
- Random sampling QA — o 5-10% de todas as respostas do LLM audítanse manualmente, independentemente da confianza — métrica de calidade base no tempo.
- Feedback loop — o usuario pode marcar unha resposta como errónea; o sistema aprende e mellora o retrieval, prompts, parámetros.
Medición — como saber que a redución funciona
Métricas de produción concretas que vale a pena monitorizar:
- Hallucination rate — porcentaxe de respostas clasificadas como alucinacións na avaliación manual (sampling). Obxectivo: por baixo do 2% para aplicacións business-critical.
- User feedback rate — porcentaxe de usuarios que marcaron a resposta como errónea.
- Escalation rate — porcentaxe de consultas escaladas ao humano. Demasiado baixa (por baixo do 5%) — o sistema probablemente está omitindo casos incertos. Demasiado alta (por riba do 30%) — o sistema non aporta valor de automatización.
- Faithfulness score en tests de regresión — tendencia mensual.
- Time-to-correction — desde a detección da alucinación ata a implementación da corrección (mellor retrieval, novo guardrail, fine-tuning).
Conclusións para os decisores
As alucinacións son xestionables — requiren investimento nunha arquitectura defensiva en varias capas. As empresas que implementan LLM sen esta arquitectura, máis cedo ou máis tarde, encontrarán un incidente grave (publicación de información errónea a cliente, decisión errónea baseada en datos alucinados, dano reputacional). O custo de construír un stack defensivo completo (RAG + evaluation + guardrails + human-in-the-loop) é tipicamente o 15-30% do custo da propia implementación do LLM — e é un investimento absolutamente necesario para usos en produción. As consecuencias de omitilo son asimétricas: custo baixo de inacción no 95% dos casos, catastrófico no 5%.