responder a preguntas muy amplias,
recopilar información repartida en múltiples páginas,
sintetizar grandes volúmenes de contenido,
o trabajar con webs que contienen mucho “ruido” semántico además de la información principal.
En este artículo vamos a explicarte en profundidad por qué ocurre esto, cómo funciona realmente el entrenamiento de los agentes, qué limitaciones tiene la tecnología actual y qué puedes hacer para obtener resultados mucho mejores.
Si quieres quedarte con la idea principal, es esta:
Los agentes de IA funcionan especialmente bien con preguntas específicas y contextos bien estructurados.
Cuando se entrenan con URLs, no solo leen el contenido importante, sino también muchos elementos secundarios que pueden contaminar la base de conocimiento.
Los listados completos, catálogos amplios o respuestas muy largas no siempre encajan bien con el funcionamiento natural de un chatbot.
La mejor estrategia depende del caso de uso: a veces conviene entrenar con URLs, otras veces con texto plano estructurado, FAQs o una combinación cuidadosamente diseñada.
Cuando entrenas un agente de IA en Scoreapps, ya sea con una URL o con bloques de texto, el sistema no “memoriza” la información como lo haría una base de datos clásica.
Lo que hace es un proceso técnico de búsqueda semántica basado en embeddings.
El sistema analiza el contenido que le proporcionas, ya sea una web o un texto.
Divide ese contenido en fragmentos más pequeños, conocidos como chunks.
Cada chunk se transforma en un embedding, es decir, en una representación numérica de su significado semántico.
Cuando un usuario hace una pregunta, el sistema busca los chunks más parecidos semánticamente a esa pregunta.
Esos fragmentos recuperados se envían al modelo de IA, que genera una respuesta usando ese contexto.
Esto significa que el agente no “lee toda la web de nuevo” cada vez que responde, sino que trabaja a partir de los fragmentos que el sistema considera más relevantes para esa pregunta concreta.
Cuando entrenas un agente con una URL, el sistema no solo captura el contenido principal que a ti te interesa.
También puede capturar muchos otros elementos de la página, por ejemplo:
menús de navegación,
footers,
enlaces legales,
avisos de cookies,
formularios,
banners,
textos repetidos en varias páginas,
atributos ALT de imágenes,
bloques ocultos o colapsables,
fragmentos de diseño,
llamadas a la acción,
e incluso contenido semánticamente parecido repartido por varias URLs distintas.
Todo eso genera chunks adicionales.
Y ahí aparece el problema: la base de conocimiento se llena de contenido que compite con la información verdaderamente importante.
Imagina una web de formación que tiene:
una página de agenda,
una página general de cursos,
varios PDFs descargables,
bloques desplegables,
testimonios,
formularios,
y menús que repiten términos como “cursos”, “programa”, “formación” o “metodología”.
Aunque para ti la información clave sea “la lista exacta de cursos con fechas y precios”, para el sistema todo ese contenido puede parecer semánticamente relacionado.
El resultado es que, cuando alguien pregunta algo amplio como:
“¿Cuáles son todos los cursos disponibles?”
el sistema puede recuperar fragmentos parciales, incompletos o mezclados de distintas fuentes, y no necesariamente el resumen más limpio o más útil.
Una limitación muy importante en este tipo de arquitecturas es que el sistema no envía todo el contenido entrenado al modelo en cada pregunta.
En su lugar, recupera solo un número limitado de chunks relevantes.
De forma simplificada, si el sistema trabaja con un top-k reducido, puede ocurrir algo así:
tienes 20 chunks procedentes de URLs,
tienes 1 chunk muy bueno con un resumen claro en texto plano,
pero el sistema solo selecciona 5 chunks para responder.
Si esos 5 chunks elegidos son fragmentos dispersos de distintas páginas que comparten palabras parecidas, el chunk con el resumen ideal puede quedarse fuera.
No basta con que una información exista en el entrenamiento.
También tiene que ser recuperada en el momento exacto de la pregunta.
Y cuando hay mucho ruido o demasiadas fuentes similares, esa recuperación puede no ser óptima.
Los chatbots con IA están especialmente optimizados para:
responder preguntas concretas,
resolver dudas puntuales,
sintetizar información,
mantener conversaciones ágiles,
y ofrecer respuestas útiles en formato breve.
Por ejemplo, preguntas como estas suelen funcionar muy bien:
“¿Cuál es el precio de este servicio?”
“¿Qué horario tenéis?”
“¿Cuál es la diferencia entre este curso y el anterior?”
“¿En qué fechas se imparte esta formación?”
“¿Qué incluye el plan premium?”
En cambio, peticiones como estas son mucho más delicadas:
“Dame todos los cursos con todas sus fechas, precios y modalidades.”
“Hazme un resumen completo de toda la web.”
“Enumera todos los servicios, todas las ventajas y todas las condiciones.”
“Muéstrame todo el catálogo sin omitir nada.”
No porque el agente “funcione mal”, sino porque ese tipo de solicitud se parece más a una extracción documental exhaustiva que a una conversación natural de chatbot.
Además del problema de recuperación, hay otra limitación estructural: los modelos de IA tienden a sintetizar.
Los LLMs no están diseñados para comportarse como un buscador literal o como una base de datos relacional. Su objetivo natural es producir respuestas que parezcan útiles, legibles y razonables.
Eso hace que, ante una petición muy amplia, el modelo tienda a:
resumir,
seleccionar,
agrupar,
omitir detalles secundarios,
o priorizar lo que considera más relevante.
Además, nuestros agentes tienen límites de seguridad y operativos para evitar respuestas excesivamente largas.
Este tipo de limitación existe para proteger el sistema y mejorar la experiencia de uso, por ejemplo para:
evitar respuestas interminables,
prevenir bucles de generación,
proteger la infraestructura frente a abusos,
mantener tiempos de respuesta razonables,
y asegurar conversaciones más naturales en canales como web, WhatsApp o Telegram.
Cuando la información necesaria para responder bien excede lo que razonablemente cabe en una sola respuesta, el modelo se ve obligado a condensar.
Y al condensar, puede:
dejar fuera elementos,
simplificar demasiado,
mezclar datos de varias fuentes,
o generar una respuesta incompleta.
Uno de los conceptos más importantes para entender este comportamiento es la alucinación.
Una alucinación ocurre cuando un modelo genera un dato incorrecto, inventado o no suficientemente sustentado en el contexto recibido, pero lo expresa con apariencia de seguridad.
Puede ocurrir, por ejemplo, que el modelo:
invente una fecha plausible,
suponga una modalidad de curso,
mezcle condiciones de dos páginas distintas,
complete una información incompleta con algo que “suena lógico”,
o responda como si conociera un dato que en realidad no tiene bien recuperado.
Esto no es exclusivo de Scoreapps.
Es una limitación general de los modelos de lenguaje actuales, incluidos los de OpenAI, Google y otros grandes proveedores.
Aunque la tasa de alucinación ha mejorado mucho en los últimos años, sigue siendo un reto abierto de toda la industria.
Porque los LLMs son modelos probabilísticos y no deterministas.
No aplican reglas rígidas tipo “si falta este dato, responde exactamente X”. En lugar de eso, generan texto basándose en probabilidades y patrones.
Por eso, cuando el contexto es:
incompleto,
ambiguo,
contradictorio,
demasiado amplio,
o está fragmentado en demasiados chunks,
el modelo puede rellenar huecos de forma incorrecta.
Aquí está uno de los puntos más importantes de todo este tema.
Muchas veces, para mejorar muchísimo la precisión en un caso concreto, habría que entrenar al agente con una fuente súper limpia y estructurada, por ejemplo un bloque de texto plano con un resumen muy claro.
El problema es que, si solo haces eso, el agente pierde contexto sobre el resto de la web.
Si entrenas un agente únicamente con un documento como este:
AGENDA DE CURSOS
1. Curso A | Fechas | Precio
2. Curso B | Fechas | Precio
3. Curso C | Fechas | Precio
el agente probablemente responderá muy bien a preguntas como:
“¿Qué cursos hay?”
“¿Qué fechas tiene el Curso B?”
“¿Cuál es el precio del Curso C?”
Pero ya no podrá responder bien sobre:
la historia de la empresa,
el equipo,
la metodología,
artículos del blog,
preguntas generales del negocio,
o cualquier otro contenido que no esté en ese documento.
Por eso no existe una única configuración ideal para todos los casos.
Todo depende de cuál sea el objetivo real del agente.
Conviene entrenar con URLs si quieres que el agente pueda responder sobre contenidos variados de la web, por ejemplo:
quiénes sois,
qué servicios ofrecéis,
dudas frecuentes,
metodología,
información general,
contenidos de blog,
páginas informativas,
o contenidos relativamente bien separados entre sí.
Este enfoque suele funcionar muy bien en negocios como:
restaurantes,
clínicas,
gimnasios,
inmobiliarias,
tiendas,
negocios locales,
páginas corporativas,
y webs con preguntas frecuentes claras.
Conviene usar bloques de texto muy bien organizados cuando el agente necesita responder con alta precisión sobre:
tarifas,
catálogos,
listados cerrados,
agendas,
inventarios,
temarios,
comparativas,
o información muy sensible al detalle.
Especialmente si quieres que el agente devuelva datos exactos como:
nombres,
fechas,
precios,
modalidades,
cantidades,
códigos,
o listas completas.
Hay webs donde un mismo tema aparece repetido de muchas formas distintas:
una página resumen,
una página detallada,
un PDF,
una agenda,
un desplegable,
una ficha,
una landing,
un artículo relacionado,
etc.
A nivel humano eso no parece un problema, porque tú entiendes que “todo habla del mismo curso”.
Pero para el sistema sí puede serlo.
Si una cadena semántica como “Curso Practitioner de PNL” aparece en varias URLs, con formatos diferentes y detalles repartidos, el sistema puede recuperar trozos de varias de esas fuentes.
ante una pregunta muy concreta, puede acertar perfectamente;
ante una pregunta amplia, puede construir una respuesta parcial o inconsistente.
Por ejemplo:
Pregunta específica: “¿En qué fechas se imparte el curso X?” → suele funcionar bien.
Pregunta amplia: “Dime todos los próximos cursos” → es mucho más probable que falle o resuma demasiado.
En la práctica, los agentes suelen aportar muchísimo valor cuando se usan para resolver dudas que al usuario le costaría más encontrar por sí mismo.
Por ejemplo:
dudas sobre servicios,
preguntas sobre metodología,
preguntas sobre condiciones,
aclaraciones de conceptos,
orientación personalizada,
comparación entre opciones,
filtrado de información concreta,
o soporte conversacional.
En cambio, pedir al agente que actúe como si fuera un listado exhaustivo de una base de datos no siempre es la mejor experiencia.
En esos casos, a menudo es mejor combinar el agente con:
una página de agenda,
una sección FAQ,
un enlace directo,
una tabla estructurada,
o una fuente de verdad muy clara y específica.
A continuación te dejamos las mejores prácticas que recomendamos cuando un agente no responde como esperabas al entrenarlo con URLs.
Si hay información que debe salir con precisión máxima —por ejemplo cursos, precios, fechas, planes o condiciones— conviene tenerla también en un formato limpio y estructurado.
Idealmente:
texto plano,
resumen ejecutivo,
frases claras,
un dato por línea o por bloque,
sin decoración innecesaria,
sin contenido duplicado,
y con formato consistente.
Las URLs son muy útiles, pero no siempre son la mejor fuente para preguntas que exigen exactitud exhaustiva.
Si necesitas precisión alta en un listado o agenda, complementa con:
documentos de texto estructurado,
FAQs,
bloques de conocimiento específicos,
o instrucciones internas del agente.
Las FAQs o bloques de pregunta-respuesta son especialmente útiles para:
dudas recurrentes,
objeciones comerciales,
preguntas difíciles,
respuestas delicadas,
y casos en los que quieres controlar mucho el tono o la exactitud.
Por ejemplo:
“¿Dónde puedo ver el listado completo?”
“¿Qué incluye este plan?”
“¿Cómo se reserva?”
“¿Cuáles son las modalidades disponibles?”
Una pregunta muy útil es esta:
¿Qué quiero que haga realmente mi agente?
Porque no es lo mismo un agente pensado para:
captar leads,
resolver dudas comerciales,
dar soporte,
filtrar preguntas,
orientar al usuario,
responder sobre un catálogo,
o sustituir una búsqueda documental completa.
Cuanto más claro sea el objetivo, mejor podrás decidir cómo entrenarlo.
Si ya existe una página excelente para mostrar una agenda completa, una tabla comparativa o un listado extenso, muchas veces la mejor estrategia es que el agente:
responda de forma breve,
aclare la duda principal,
y derive al usuario a la URL correcta para ver el detalle completo.
Esto suele ofrecer una experiencia mejor y más fiable que intentar forzar al agente a reproducir toda esa información dentro del chat.
En muchos casos es buena idea indicar en las instrucciones algo como:
que no invente datos,
que, si la pregunta requiere un listado completo, redirija a una URL concreta,
que priorice respuestas específicas,
que aclare cuando no tenga seguridad,
o que no intente resumir exhaustivamente una agenda larga.
Si ahora mismo necesitas maximizar la precisión mientras seguimos mejorando esta tecnología, estas son las opciones más recomendables:
Entrena el agente con texto plano bien estructurado.
Añade preguntas y respuestas frecuentes.
Evita entrenarlo con URLs si esas URLs generan demasiado ruido.
Esta opción es útil si tu prioridad es que el agente responda correctamente sobre una fuente cerrada de datos.
Entrena el agente con URLs para que conozca más partes de tu web.
Acepta que algunas preguntas muy amplias no serán el caso de uso ideal.
Añade en las instrucciones que, para listados completos, derive a la página correspondiente.
Esta opción suele ser más recomendable cuando el agente tiene una función conversacional general y no una función de catálogo exhaustivo.
En muchos casos, la solución más inteligente es híbrida:
usar URLs para el conocimiento general,
usar texto estructurado para la información más importante,
usar FAQs para preguntas críticas,
y definir instrucciones claras para redirigir cuando sea necesario.
Supongamos una academia o centro formativo.
Una estrategia sensata sería:
Entrenar con URLs para que el agente conozca la historia, la metodología, el equipo y la información general.
Añadir una fuente estructurada con los cursos más importantes, fechas y precios.
Crear FAQs con preguntas del tipo:
“¿Dónde veo el listado completo de cursos?”
“¿Qué modalidades tenéis?”
“¿Cuál es el próximo curso disponible?”
Indicar en las instrucciones del agente que, cuando el usuario pida un listado completo, remita a la página oficial de agenda.
Así consigues un mejor equilibrio entre amplitud, precisión y utilidad real.
Estamos investigando continuamente mejoras en el comportamiento de los agentes para casos como este. Entre las líneas de trabajo habituales en este tipo de sistemas están:
aumentar la recuperación de contexto relevante,
mejorar la priorización de fuentes más limpias,
reducir el peso del ruido procedente de navegación o estructura web,
reforzar las instrucciones internas para minimizar alucinaciones,
y optimizar el comportamiento del agente en preguntas amplias o dependientes del tiempo.
Aun así, es importante ser transparentes: esto no es un ajuste trivial.
No se trata de activar un simple interruptor. Requiere cambios profundos en cómo se recupera, prioriza y presenta la información al modelo, y además hay que validar cuidadosamente que una mejora en un caso de uso no empeore otros.
En la mayoría de negocios, los agentes funcionan muy bien y resuelven con un grado de acierto muy alto las preguntas específicas que más valor aportan al usuario.
El reto aparece sobre todo cuando se pretende que el chatbot:
reconstruya listados muy amplios,
agregue información dispersa en múltiples ubicaciones,
o condense grandes volúmenes de información en una única respuesta breve.
Es decir: no estamos ante un fallo absoluto del sistema, sino ante un desajuste entre el comportamiento natural de un chatbot conversacional y un caso de uso que exige extracción exhaustiva de datos.
Si estás haciendo pruebas y detectas respuestas que no son correctas o no se ajustan a lo que necesitas, la mejor forma de ayudarnos a analizarlo es enviarnos:
La pregunta exacta que hiciste al agente.
La respuesta que dio el agente.
La respuesta que esperabas obtener.
Las URLs o fuentes de entrenamiento usadas.
Si existe, el bloque de texto o FAQ donde debería estar la información correcta.
Con eso podemos evaluar mucho mejor si el problema está en:
la recuperación del contexto,
el ruido del entrenamiento,
la amplitud de la pregunta,
la estructura de las fuentes,
o el propio diseño del caso de uso.
Si quieres sacar el máximo partido a tu agente de IA, nuestra recomendación es esta:
usa el agente para resolver dudas específicas y aportar valor conversacional,
estructura muy bien la información crítica,
apóyate en FAQs cuando necesites precisión,
y no intentes convertir el chatbot en un sustituto exacto de una agenda, una tabla o un catálogo completo si ese contenido ya puede mostrarse mejor en una página dedicada.
En otras palabras: el mejor agente no es el que intenta hacerlo todo, sino el que está bien orientado al tipo de preguntas para las que realmente aporta valor.
Si quieres, nuestro equipo puede ayudarte a revisar:
cómo estás entrenando el agente,
qué fuentes conviene mantener o eliminar,
qué preguntas deberían ir a FAQs,
y cómo enfocar mejor el prompt de instrucciones para tu caso de uso.
Así podremos orientarte hacia una configuración mucho más eficaz y adaptada a lo que realmente necesitas.