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 best-in-class hace dos o tres 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 404, o apuntan a un producto completamente distinto. Incluso los modelos frontier hacen esto, porque la tarea de recomendación misma es intrínsecamente temporal: la respuesta correcta cambia cada trimestre conforme salen nuevas herramientas, los incumbents suben precios y las categorías se consolidan. Ninguna cantidad de escala arregla un problema de añada de datos de entrenamiento.

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 2022 para tareas donde un competidor nativo-IA añada 2025 ha tomado explícitamente la categoría, citaban precios anuales basados en páginas de precios públicas de 2023 que desde entonces han pasado detrás de muros de ventas enterprise, y citaban confiadamente URLs que eran la página de producto del proveedor hace tres años pero que ahora son una redirección a una homepage genérica. Las recomendaciones se leen como autoritativas porque el modelo es bueno escribiendo prosa autoritativa. 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 config 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 pricing antes de recomendar en lugar de depender de la memoria, y a establecer el campo maturity a 'new' para herramientas lanzadas en los últimos 18 meses en lugar de anclarse en los incumbents previos al cutoff de entrenamiento.

La grounding metadata devuelta de cada llamada se loguea: 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 la recomendación 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 2025 2026', recuperó tres páginas de producto específicas más una review de G2, y produjo su recomendación a partir de esa evidencia. El revisor puede luego verificar las fuentes antes de firmar. Una recomendación que habría sido no confiable desde un LLM genérico se vuelve auditable a través de la capa de grounding.

Parámetros técnicos: la llamada grounded search usa el modelo con grounding Gemini 3.1 Pro, un timeout de 60 segundos (más largo que el timeout Gemini estándar porque la búsqueda grounded necesita intrínsecamente más tiempo), y una temperatura de generación baja (0,2). La temperatura 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, 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 min/max explícito, una cadena describiendo el modelo de precios, un enum de madurez ('new' | 'established') y un array de alternativas con dos a tres alternativas llevando cada una su propio rango de precio y reasoning.

Grounded search es el proveedor primario, pero no puede ser el único. La búsqueda web en tiempo real puede fallar por razones mundanas: rate limits de API, errores de red transitorios, timeouts en queries inusualmente amplias, y la capa de recomendación necesita permanecer útil incluso cuando el primario falla. La capa de recomendación de herramientas implementa una cadena de fallback explícita de tres niveles, con cada nivel elegido para preservar tanta calidad de recomendación como sea posible mientras se degrada transparentemente cuando el nivel superior no está disponible.

1. Primario: Gemini 3.1 Pro + grounding de Google Search. Datos web en tiempo real, auditables vía grounding metadata. Este es el camino por defecto y maneja la vasta mayoría de llamadas de producción.
2. Fallback: Grok. Usa datos de entrenamiento en lugar de búsqueda en tiempo real, así que puede tener algo de sesgo de incumbency, pero sigue siendo un recomendador capaz y sus datos de entrenamiento son relativamente recientes. Activado cuando la llamada primaria Gemini falla con un error reintentable. La verificación de disponibilidad de Grok gate esto: si Grok también está no disponible, la cadena salta al nivel de último recurso.
3. Último recurso: degradación grácil. Devuelve un estado indicando que no hay recomendaciones disponibles, con una lista de herramientas vacía en lugar de fabricar recomendaciones. La UI saca a la luz este estado explícitamente, mostrando el resto del análisis de transformación (niveles de madurez, ahorros, ROI) sin sugerencias de herramientas. Este es el comportamiento correcto porque una recomendación faltante es más honesta que una alucinada.

Una elección arquitectónica sutil en la capa de recomendación de herramientas: hace UNA llamada LLM por proceso, no una llamada por tarea. El system prompt enmarca explícitamente el trabajo del modelo como pensamiento holístico: 'These tasks form a [processName] workflow. Can ONE platform handle multiple tasks?' El prompt empuja activamente al modelo hacia plataformas consolidadas: 'A consolidated platform that is good enough at each task beats 4 best-in-class tools that require complex integration.' Esta es la best practice enterprise, y se desprende del diseño en lugar de aplicarse después del hecho.

Consecuencia práctica: un proceso con diez tareas automatizables generalmente regresa con dos o tres recomendaciones de herramientas en lugar de diez, cada recomendación mapeando a múltiples tareas. Una plataforma moderna nativa-IA para cuentas por pagar puede cubrir cinco tareas con una sola suscripción; una API de comprensión de documentos más un motor de flujo de trabajo puede cubrir el resto. Esto está más cerca de cómo realmente se implementa una transformación: los equipos compran plataformas, no herramientas puntuales, y saca a la luz el compromiso de coste de integración explícitamente en lugar de esconderlo detrás de una larga lista de recomendaciones de herramientas individuales.

Pensamiento en primeros principios integrado al prompt

Un detalle más subestimado: el prompt instruye al modelo a considerar el proceso entero holísticamente, incluyendo tareas marcadas como no automatizables. Una tarea puede ser no automatizable a la vista del clasificador estático de patrones, pero eliminable por una plataforma moderna: un sistema de auto-aprobación quita la necesidad de revisión manual por completo, por ejemplo. El prompt permite al modelo incluir estas tareas en una recomendación y explicar en el razonamiento por qué la herramienta puede eliminar la tarea. Esto atrapa el caso que una recomendación a nivel tarea siempre perdería: a veces la respuesta correcta no es automatizar la tarea sino eliminarla.

Cada recomendación devuelta por el camino grounded-search se conforma al mismo esquema validado por Zod. La forma vale la pena leerla una vez porque muestra a qué se compromete realmente la plataforma a sacar a la luz para cada recomendación, no claims 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 transform que devuelve cadena vacía para URLs no-HTTPS en lugar de propagar enlaces inseguros al producto. Segundo, el modelo de precios es una cadena texto libre en lugar de un enum porque los modelos de pricing varían de formas que un enum no puede capturar (per-asiento-con-descuentos-por-volumen, por-ejecución-con-tope-mensual, usage-based-con-mínimo, etc.). Tercero, el array de alternativas es requerido y no-vacío por convención: el prompt instruye al modelo a incluir una a dos alternativas con su propio rango de precio y reasoning, porque una recomendación sin alternativas es un pitch de ventas en lugar de un análisis. El esquema no fuerza alternativas no-vacío, pero el diseño del prompt asegura que llegan.