Recomendaciones de herramientas vía Grounded Search: cómo LucidFlow evita la trampa de alucinación LLM

Pregunta a un LLM genérico qué herramienta usar para un proceso de negocio específico y obtienes recomendaciones confiadas con un patrón de fallo predecible: el modelo recomienda herramientas que eran las mejores en su clase hace unos años (la añada de sus datos de entrenamiento), cita precios que están desactualizados o fabricados, y cita URLs de producto que o redirigen, o devuelven un error 404, o apuntan a un producto completamente distinto. Incluso los modelos de última generación hacen esto, porque la tarea de recomendación misma es intrínsecamente temporal: la respuesta correcta cambia cada trimestre conforme salen nuevas herramientas, los competidores consolidados suben precios y las categorías se unifican. Ninguna cantidad de escala arregla un problema de antigüedad de datos de entrenamiento. De hecho, según un análisis cualitativo de Gartner 2026, la volatilidad de las ofertas de software de IA dificulta enormemente que los datos de entrenamiento estáticos sigan siendo útiles para la toma de decisiones de compra.

El modo de fallo concreto que auditamos en la Knowledge Base LucidFlow antes de lanzar la capa grounded search: los modelos recomendaban plataformas RPA de 2026 para tareas donde un competidor nativo de IA de añada 2026 ha tomado explícitamente la categoría, citaban precios anuales basados en páginas de precios públicas de 2026 que desde entonces han pasado detrás de muros de ventas corporativos, y citaban confiadamente URLs que eran la página de producto del proveedor hace unos años pero que ahora son una redirección a una página de inicio genérica. Las recomendaciones se leen como autoritativas porque el modelo es bueno escribiendo prosa convincente. Fallan como guía real de selección de productos.

La capa de recomendación de herramientas de LucidFlow usa Gemini 3.1 Pro con grounding de Google Search como su proveedor primario. El modelo se invoca con `tools: [{ googleSearch: {} }]` en la configuración de generación, lo que permite a Gemini ejecutar búsquedas web en tiempo real durante la respuesta y anclar su salida en las páginas que recupera. El prompt instruye explícitamente al modelo a buscar páginas de precios antes de recomendar en lugar de depender de la memoria, y a establecer el campo de madurez como nuevo para herramientas lanzadas en los últimos 18 meses en lugar de anclarse en los competidores consolidados previos al límite de entrenamiento.

La información de grounding devuelta de cada llamada se registra en los logs: las consultas de búsqueda web que el modelo ejecutó y las URLs recuperadas (las fuentes de grounding) que informaron la respuesta. Esto es lo que hace que la recomendación sea auditable. Un revisor puede inspeccionar los logs y ver que para una recomendación dada, el modelo buscó la cadena literal 'best automation tools for accounts payable enterprise 2026', recuperó tres páginas de producto específicas más una reseña de G2, y produjo su recomendación a partir de esa evidencia. El revisor puede luego verificar las fuentes antes de dar su aprobación. Una recomendación que habría sido poco confiable desde un LLM genérico se vuelve auditable a través de la capa de grounding. Este enfoque se alinea con las mejores prácticas de observabilidad de Google Cloud 2026 para sistemas basados en agentes.

Parámetros técnicos: la llamada grounded search usa el modelo con grounding Gemini 3.1 Pro, un tiempo de espera de 60 segundos (más largo que el estándar porque la búsqueda grounded necesita intrínsecamente más tiempo), y una temperatura de generación baja (0,2). La temperatura de 0,2 es deliberada: suficientemente alta para sacar a la luz herramientas no obvias que el modelo podría pasar por alto de otro modo, y suficientemente baja para mantener la salida factual y reproducible entre llamadas. La respuesta se valida contra un esquema Zod que requiere un rango de precio mensual con valores mínimos y máximos explícitos, una cadena que describe el modelo de precios, un enumerado de madurez ('new' o 'established') y una matriz de alternativas con dos a tres opciones, cada una con su propio rango de precio y razonamiento.

Grounded search es el proveedor primario, pero no puede ser el único. La búsqueda web en tiempo real puede fallar por razones comunes: límites de llamadas de API, errores de red temporales o tiempos de espera en consultas inusualmente amplias. La capa de recomendación necesita seguir siendo útil incluso cuando el proveedor principal falla. Por ello, implementa una cadena de fallback explícita de tres niveles, donde cada nivel está diseñado para preservar la mayor calidad de recomendación posible y degradarse de manera transparente cuando el nivel superior no está disponible.

1. Primario: Gemini 3.1 Pro + grounding de Google Search. Datos web en tiempo real, auditables mediante metadatos de grounding. Este es el camino por defecto y gestiona la gran mayoría de las llamadas en producción.
2. Fallback: Grok. Utiliza datos de entrenamiento en lugar de búsqueda en tiempo real. Aunque puede presentar cierto sesgo hacia herramientas consolidadas, sigue siendo un recomendador muy capaz y sus datos de entrenamiento son relativamente recientes. Se activa cuando la llamada primaria de Gemini falla con un error recuperable, siempre que la verificación de disponibilidad de Grok confirme que el servicio está activo.
3. Último recurso: degradación grácil. Devuelve un estado que indica que no hay recomendaciones disponibles en ese momento, entregando una lista de herramientas vacía en lugar de fabricar recomendaciones falsas. La interfaz de usuario muestra este estado de forma explícita, presentando el resto del análisis de transformación (niveles de madurez, ahorros, ROI) sin sugerencias de herramientas. Este comportamiento es el correcto porque una recomendación ausente es más honesta que una alucinada.

Una elección arquitectónica importante en la capa de recomendación de herramientas es que realiza una única llamada de LLM por proceso, en lugar de una llamada por tarea. El prompt del sistema orienta el trabajo del modelo hacia un enfoque holístico, preguntando si una sola plataforma puede gestionar múltiples tareas del flujo de trabajo. El prompt prioriza activamente las plataformas consolidadas, bajo la premisa de que una plataforma integrada que sea lo suficientemente buena en cada tarea supera a cuatro herramientas especializadas que requieran integraciones complejas. Esta es la mejor práctica corporativa y se aplica directamente desde el diseño del sistema.

Consecuencia práctica: un proceso con diez tareas automatizables generalmente regresa con dos o tres recomendaciones de herramientas en lugar de diez, donde cada recomendación se asocia a múltiples tareas. Una plataforma moderna nativa de IA para cuentas por pagar puede cubrir cinco tareas con una sola suscripción; una API de procesamiento de documentos junto con un motor de flujo de trabajo puede cubrir el resto. Esto refleja mejor cómo se implementa realmente una transformación en las empresas, ya que los equipos adquieren plataformas integradas en lugar de herramientas aisladas, lo que hace visible el coste de integración desde el primer momento.

Pensamiento en primeros principios integrado al prompt

Un detalle técnico relevante: el prompt instruye al modelo a considerar el proceso entero de forma holística, incluyendo aquellas tareas marcadas como no automatizables. Una tarea puede no ser automatizable mediante un clasificador estático, pero sí eliminable por una plataforma moderna (por ejemplo, un sistema de autoaprobación elimina la necesidad de revisión manual). El prompt permite al modelo incluir estas tareas en una recomendación y explicar en el razonamiento cómo la herramienta puede eliminar la tarea por completo. Esto resuelve el escenario que una recomendación a nivel de tarea siempre omitiría: a veces la respuesta correcta no es automatizar la tarea, sino eliminarla.

A medida que avanzamos en 2026, la integración de datos web en tiempo real plantea un desafío operativo importante: el coste de API y la latencia de red. Cada consulta de búsqueda grounded añade entre 2 y 4 segundos al tiempo de respuesta total y consume tokens adicionales al procesar los resultados de búsqueda web devueltos por Google Search. Para mantener la experiencia de usuario ágil sin comprometer la precisión, LucidFlow ha implementado una capa de almacenamiento en caché semántico de nivel intermedio.

Esta capa de caché semántica identifica consultas conceptualmente idénticas (por ejemplo, peticiones sobre el precio de una herramienta específica de automatización de facturas) y sirve los resultados de búsqueda previamente validados si se encuentran dentro de una ventana de frescura de 24 horas. Según las directrices de arquitectura de Google Cloud 2026, la optimización del contexto de entrada mediante el filtrado selectivo de fragmentos de búsqueda puede reducir el consumo de tokens de entrada en más de un 30% sin perder la fidelidad de la respuesta grounded.

Cada recomendación devuelta por el camino grounded-search se conforma al mismo esquema validado por Zod. La estructura es de gran utilidad porque muestra a qué se compromete realmente la plataforma a extraer para cada recomendación: no afirmaciones en prosa, sino campos estructurados.

const toolRecommendationSchema = z.object({
  recommendations: z.array(
    z.object({
      taskIds: z.array(z.string()),
      toolName: z.string(),
      description: z.string(),
      reasoning: z.string(),
      monthlyPrice: z.object({ min: z.number(), max: z.number() }),
      pricingModel: z.string(), // "per seat" | "flat rate" | "usage-based" | ...
      url: httpsUrlSchema, // HTTPS only; non-HTTPS -> cadena vacía
      maturity: z.enum(['new', 'established']),
      alternatives: z.array(
        z.object({
          name: z.string(),
          url: httpsUrlSchema,
          monthlyPrice: z.object({ min: z.number(), max: z.number() }),
          reasoning: z.string(),
        })
      ),
    })
  ),
});

Tres propiedades a resaltar en ese esquema. Primero, el campo de URL aplica la validación de URL HTTPS: un transformador que devuelve una cadena vacía para URLs que no sean HTTPS en lugar de propagar enlaces inseguros al producto. Segundo, el modelo de precios es una cadena de texto libre en lugar de un enumerado porque los modelos de precios varían de formas que un enumerado no puede capturar (por asiento con descuentos por volumen, por ejecución con tope mensual, basado en el uso con un mínimo, etc.). Tercero, la matriz de alternativas es requerida y no vacía por convención: el prompt instruye al modelo a incluir una o dos alternativas con su propio rango de precio y razonamiento, porque una recomendación sin alternativas es una propuesta de ventas en lugar de un análisis. El esquema no obliga a que las alternativas no estén vacías, pero el diseño del prompt asegura que se incluyan.