Cómo construimos un asistente de IA confiable para el diagnóstico de plagas: lecciones con Hor-Tal

Diseño, pruebas y gobernanza de una experiencia de diagnóstico guiado para Hor-Tal — sin tratar al modelo de lenguaje como la fuente de verdad.

Hor-Tal ayuda a profesionales y hogares a elegir el tratamiento adecuado para problemas de plagas, empezando por hormigas. Necesitaban algo más que una ventana de chat genérica: los usuarios describen situaciones reales y desordenadas, las respuestas deben alinearse con el conocimiento de productos de Hor-Tal, y una recomendación incorrecta tiene consecuencias reales.

Construimos un asistente de diagnóstico guiado sobre la plataforma TailorChat: un stack multi-servicio con un grafo de conversación definido en configuración, salidas estructuradas del LLM, pruebas automáticas de cobertura de ramas y un revisor de calidad posterior a la conversación. Este artículo explica las decisiones de ingeniería detrás de ese sistema: los patrones que usamos (y los que evitamos a propósito), cómo evaluamos la calidad sin delegar el criterio a un producto de evaluación alojado, y cómo encajan la seguridad y la gobernanza en el diseño.

El problema: el chat abierto no es el punto de partida correcto

Un “wrapper de ChatGPT” suena atractivo hasta que intentan llevarlo a producción:

• Los usuarios no hablan en respuestas de opción múltiple perfectas.

• El modelo puede sonar seguro mientras recomienda el producto equivocado.

• Probar regresiones buscando frases en el texto del bot es frágil y se rompe cada vez que cambia la redacción.

Para Hor-Tal necesitábamos ramificaciones predecibles (interior vs exterior, especie, ubicación del hormiguero, cortadoras vs carpinteras) y recomendaciones atadas a conocimiento curado, no prosa improvisada.

Nuestra respuesta fue tratar al LLM como clasificador y extractor que completa campos estructurados. El grafo de conversación — definido en configuración, no enterrado en código imperativo — decide qué sigue y qué productos aplican.

Patrones de diseño: qué usamos y qué dejamos afuera

En las descripciones de puesto suele aparecer ReAct, sistemas multi-agente, reflexión y plan-and-execute. Hor-Tal usa varias de esas ideas en formas que encajan con un flujo de producto regulado, no con un bucle libre de herramientas.

Plan-and-execute (la configuración es el plan)

El flujo de diagnóstico de hormigas es un grafo dirigido en YAML: los nodos son pasos (ubicación, tamaño, especie, recomendación) y las aristas son ramas con condiciones sobre el estado estructurado. El runtime recorre desde el nodo inicial y recalcula la posición tras correcciones: si el usuario cambia de “interior” a “exterior”, el motor vuelve a recorrer desde arriba sin código custom de “detección de cambios”.

Eso es plan-and-execute en la práctica: el plan es el archivo de flujo; el ejecutor es un runner genérico más handlers chicos por tipo de paso.

Multi-agente en el límite de la plataforma

El chat de producción avanza hacia un orquestador de conversación que toma una decisión estructurada de supervisor por mensaje del usuario (seguir diagnóstico, FAQ de producto, derivación humana) y despacha al servicio de grafo de Hor-Tal. La lógica específica del cliente queda en el repositorio del grafo; el ruteo y la E/S de sesión quedan en servicios de plataforma.

Eso es multi-agente en sentido arquitectónico — roles y procesos separados — sin duplicar reglas de diagnóstico en cada servicio.

Reflexión después de la conversación

No dependimos de que el modelo se “critique a sí mismo” en cada turno. En su lugar, Suricata (un servicio dedicado de revisión) lee la transcripción almacenada y el estado estructurado, ejecuta un prompt de revisor versionado y puede marcar needs_human para el equipo de operaciones. Esa es reflexión como compuerta de calidad offline: más fácil de auditar y versionar que un chain-of-thought oculto en el camino en vivo.

Por qué no ReAct en el flujo de diagnóstico

ReAct (razonar → actuar con herramientas → observar → repetir) brilla cuando la tarea es abierta y el uso de herramientas es dinámico. El flujo de hormigas de Hor-Tal es lo contrario: ramas finitas, productos conocidos y reglas explícitas de derivación. Un bucle de herramientas sería más difícil de probar y más difícil de explicar al cliente.

Mantenemos la topología de LangGraph simple; la complejidad vive en la configuración del flujo y la validación, no en bucles ad hoc de agentes.

Una sola fuente de verdad: estructura por encima de cadenas de texto

Tres reglas moldean todo el código:

1. No parsear la entrada del usuario con palabras clave — el LLM evalúa el turno y devuelve campos JSON (location_value, species_value, can_find_nest_value, etc.).

2. No parsear las respuestas del bot para extraer significado — la semántica vive en el estado (product_ids, current_node, ids de especie) y en los outcomes YAML de las aristas.

3. Las pruebas afirman esa estructura — nunca subcadenas de response_text.

Los textos de producto y tratamiento salen de una base de conocimiento curada inyectada por contexto, no de búsqueda vectorial sobre documentos arbitrarios. Eso encaja con el dominio de Hor-Tal: contenido acotado y escrito por expertos, donde la corrección importa más que la novedad del retrieval.

Evaluación: medir calidad que podamos defender

“Evaluación” aquí significa evidencia de que un cambio de prompt o de modelo no rompió comportamiento conocido — no un puntaje vanidoso único.

Cobertura de ramas desde la misma config que corre en producción

Generamos pruebas de integración recorriendo cada camino desde el nodo inicial del flujo hasta cada nodo terminal (enumeración en profundidad sobre flows.yaml). Cada arista lleva un example_message que representa al usuario en las pruebas. Agregar una rama sin mensaje de ejemplo hace fallar la suite a propósito: el grafo y el harness de pruebas siguen alineados.

Eso le da a Hor-Tal (y a nosotros) una historia clara: cada rama configurada tiene al menos una prueba automática de camino.

LLM en vivo vs CI estable

Los caminos ejercitados con un modelo en vivo detectan inestabilidad real — por ejemplo, el modelo marca species_unchanged: true pero igual devuelve un id de especie, el estado no se actualiza aunque la respuesta suene bien. Esos fallos son valiosos: apuntan a endurecer prompts y validación, no a un mal diseño de pruebas.

Para integración continua, el siguiente paso es la división estándar de la industria:

• Corridas rápidas y determinísticas con un LLM simulado que devuelve JSON fijo por paso (lógica de grafo y validación).

• Corridas programadas o pre-release con el modelo real para regresión en caminos dorados críticos.

Reportamos corridas en vivo con JSON estructurado y resúmenes en texto (tasa de éxito por camino, duración por caso) — propiedad del repositorio, no encerrados en una UI de evaluación de terceros.

Revisión post-conversación (Suricata)

Las pruebas automáticas de caminos demuestran ruteo y estado. No detectan tono, consejos sutiles pero incorrectos, ni casos borde en redacción libre del usuario. Suricata cierra esa brecha con esquema y prompt versionados, guardando análisis por conversación para revisión admin y escalamiento por webhook cuando hace falta atención humana.

En conjunto: pruebas de grafo para ramas, estado dorado para regresiones en recorridos clave, Suricata para riesgo cualitativo en transcripciones tipo producción.

Observabilidad y rendimiento (sin un producto de tracing alojado)

Estamos creciendo la observabilidad con el mismo espíritu que las pruebas: estructurada, auto-alojada, alineada con sesiones ya guardadas en S3.

Por turno, el registro útil no es solo el texto del chat sino un sobre chico: id de conversación, current_node, ids de producto, id de modelo, identificadores de prompt/versión, cantidad de llamadas al LLM, latencia y errores. Eso responde preguntas que el cliente realmente hace: ¿Dónde abandonan los usuarios? ¿Subió la latencia después de un deploy? ¿Qué nodo precede a los flags de Suricata?

Tracing al estilo OpenTelemetry es un paso natural para correlacionar HTTP, pasos del grafo y llamadas al LLM — exportable al stack de logs que el deploy ya usa (para Hor-Tal, AWS Lightsail y logs de contenedor), sin exigir un dashboard SaaS específico de LangChain.

Seguridad, privacidad e IA responsable

El asistente de Hor-Tal no es un chat de trivia anónimo. El diseño asume usuarios reales y recomendaciones reales, así que la gobernanza es parte de la arquitectura:

Tema	Enfoque
Secretos	Claves de API y secretos internos solo en configuración de entorno; escaneo de secretos en pre-commit en el código.
Límites de servicio	APIs internas (run-turn del grafo, lectura/escritura de sesión, analyze de Suricata) autenticadas con secretos compartidos; disparadores de análisis no expuestos en el borde público sin auth.
Residencia de datos	Sesiones de conversación y artefactos de análisis bajo prefijos de almacenamiento por tenant; acceso admin por flujos autenticados del dashboard.
Supervisión humana	Suricata puede marcar conversaciones que requieren revisión humana; operaciones puede inspeccionar la sesión completa sin confiar solo en el modelo.
Versionado de prompt y esquema	Comportamiento del revisor atado a versiones de prompt y esquema en el repo — auditorías reproducibles cuando algo sale mal.
Límites responsables	Caminos de derivación cuando el grafo no puede recomendar con seguridad; razones estructuradas en lugar de fallo silencioso.

La resistencia a inyección de prompt es en capas: el texto del usuario entra a la evaluación, pero las decisiones siguen campos validados y reglas del grafo — reduciendo la chance de que una frase ingeniosa desvíe solo la lógica de producto.

Qué gana Hor-Tal

• Transparencia para el negocio: los flujos se revisan y extienden en configuración con un mapa visible de ramas y resultados.

• Recomendaciones más seguras: productos y especies salen de conocimiento curado y outcomes del grafo, no del modelo inventando SKUs.

• Calidad mantenible: pruebas derivadas del mismo YAML que corre en producción; prompts del revisor versionados como cualquier otro contrato.

• Camino hacia chat en producción: orquestación de plataforma, sesiones, UI admin y deploy en un solo bundle — el servicio de grafo sigue siendo el lugar de la expertise específica de Hor-Tal.

Qué le diríamos a otro equipo (y a un panel de contratación)

Si están construyendo un asistente guiado de alto impacto, consideren:

1. Hacer del grafo (o máquina de estados) el contrato — no del párrafo del LLM.

2. Invertir en pruebas de cobertura de ramas generadas desde ese contrato.

3. Separar regresión con modelo en vivo de CI determinístico — ambos importan.

4. Agregar un revisor offline para lo que las pruebas estructurales no ven.

5. Registrar estructura por turno — lo van a necesitar la primera vez que un deploy “se siente peor” sin un error obvio.

El proyecto Hor-Tal es una referencia práctica de ese playbook: serio en el dominio, testeable y gobernable — el tipo de ingeniería de IA que aguanta cuando el nombre del cliente está en la recomendación.

TailorChat es nuestra plataforma para productos conversacionales multi-tenant impulsados por grafos. Hor-Tal es un despliegue para cliente enfocado en diagnóstico de plagas y orientación de productos. Las reglas de producto técnicas del grafo Hor-Tal están en las guías de diseño de Hor-Tal; la arquitectura y operaciones de plataforma están documentadas en el repositorio de la plataforma TailorChat.

Para consultas sobre asistentes similares — flujos guiados, harnesses de evaluación y despliegue en producción en AWS — contacte a su equipo de entrega TailorChat.