El equipo de AI Sous-chef lanza una app y un bot con IA en la nube en 2,5 meses

La aplicación recibió una lista de ingredientes, devolvió una receta en el formato requerido y mostró al usuario una ensalada de patatas y berenjenas crudas. Las instrucciones omitían el paso de cocinar esos ingredientes. Según el equipo de AI Sous-chef, ese fue uno de los comentarios que recibió tras el lanzamiento. Para un desarrollador, el problema resulta familiar: la respuesta del modelo supera las comprobaciones técnicas, pero el usuario obtiene un mal resultado.

En un análisis publicado en Habr, el equipo explica cómo desarrolló en dos meses y medio una app para Android y un bot de Telegram con un backend compartido. El valor práctico del artículo está en los detalles: cómo se seleccionan las versiones de los prompts, qué se comprueba en las respuestas y por qué esas comprobaciones todavía no bastan.

Dos clientes, un backend compartido y prompts en archivos

El flujo es sencillo: el usuario fotografía los ingredientes o los introduce como texto, confirma la lista reconocida y recibe propuestas de platos. La aplicación móvil, desarrollada con React Native, y el bot comparten un servidor basado en Python y FastAPI. El reconocimiento de ingredientes y la generación de recetas se reparten entre dos modelos en la nube; las solicitudes se envían a la API de Yandex.

Las instrucciones se almacenan por separado del código: cada tarea tiene un archivo de sistema y otro de usuario. Las versiones que se utilizarán se definen en pin.json. Por ejemplo, el reconocimiento puede mantenerse en v1 mientras que para las recetas se elige otra versión ya preparada. Un cargador lee los archivos y sustituye los valores en expresiones como {{ products }}. Si falta un archivo o un valor obligatorio, genera un error.

Esto permite modificar la redacción sin reescribir la función que llama al modelo. Sin embargo, hay un detalle operativo: la asignación de versiones se almacena en caché en la memoria del proceso. Después de modificar pin.json, es necesario reiniciar o vaciar la caché. Los textos de las instrucciones, en cambio, se vuelven a leer cada vez que se invoca el cargador.

También existe un límite más importante. Según describen los autores, la lista de ingredientes se inserta también en la instrucción de sistema. El uso de archivos separados no separa por sí solo los datos del usuario de las reglas de comportamiento del modelo. Todavía hay que comprobar cómo responde a instrucciones ajenas a la tarea incluidas en el texto de entrada.

La validación del JSON comprueba la estructura; una receta necesita otra evaluación

Al generar recetas, la aplicación solicita JSON mediante un parámetro de la API, analiza la respuesta con json.loads y comprueba la estructura esperada con model_validate. Esto ayuda a detectar respuestas que el código no puede procesar. Sin embargo, la presencia de los campos obligatorios no dice nada sobre si los pasos de preparación están completos.

Tras recibir el comentario sobre las patatas crudas, el equipo empezó a perfeccionar el prompt. La respuesta original no se conservó, por lo que no existe una comparación verificable del antes y el después. Los autores no afirman que el problema esté resuelto.

El repositorio reúne diez escenarios de prueba: entrada vacía, un solo ingrediente, cantidades fraccionarias, texto ambiguo y otros casos. Se documentan ingredientes adicionales, instrucciones imprecisas y errores de formato. Pero todavía no hay una métrica única y fiable: entre las pruebas cambiaron a la vez los prompts, los parámetros de generación y el procesamiento de las respuestas.

El uso de latest en las direcciones de los modelos limita aún más la reproducibilidad. La versión del prompt puede mantenerse, mientras el modelo asociado a esa dirección se actualiza. Para realizar ejecuciones comparables hay que guardar la entrada, la respuesta, los parámetros y la identificación más precisa disponible del modelo.

Qué puedes aplicar a tu propio producto

AI Sous-chef incorpora el modo AI_MODE=stub: en lugar de realizar solicitudes a la nube, la aplicación recibe ingredientes y recetas predefinidos. Estas respuestas resultan útiles para probar la interfaz y la interacción entre componentes. El modo no mide la calidad de la generación, porque no genera contenido.

Desde la perspectiva de producto, otra limitación de la primera versión resulta reveladora: se podía confirmar la lista reconocida, pero no corregirla. El usuario veía el error y no podía eliminar un ingrediente incorrecto antes de pasar al siguiente paso. La edición de la lista pasó a ser una de las mejoras previstas a corto plazo.

Según el artículo, el repositorio principal se publica bajo GNU AGPL v3.0. Permite estudiar el cargador de prompts, la selección de versiones, la validación de respuestas y la sustitución de los modelos por datos predefinidos. Para adaptar la implementación hay que tener en cuenta las estructuras de la aplicación concreta y el comportamiento de la caché.

Para un equipo que desarrolle un servicio similar, el caso propone una forma útil de trabajar: comprobar por separado el procesamiento de la respuesta y su contenido, guardar los ejemplos problemáticos y comparar los cambios en condiciones idénticas. Almacenar los prompts en archivos facilita el mantenimiento. Las pruebas de calidad, en cualquier caso, deben obtenerse a partir de respuestas reales.