Локальный RAG на FastAPI и Ollama: от простого вызова LLM к production backend

Un desarrollador en Habr analiza un momento específico: cuándo una simple llamada a un modelo local ya no es suficiente — y qué es necesario añadir para obtener un verdadero sistema backend.

Cuándo una simple llamada no es suficiente

La primera versión parece obvia: el frontend envía una pregunta, FastAPI recibe `POST /ask`, el backend llama a Ollama y devuelve una cadena con la respuesta. Para una demostración, es suficiente. Para un asistente de documentación — no. Las preguntas surgen inmediatamente: ¿en qué documentos se basa la respuesta? ¿Qué fragmentos entraron en el prompt? ¿Por qué una solicitud se procesa en dos segundos, mientras que otra tarda quince? ¿Qué sucede si el índice no se ha actualizado en tres semanas? No es posible responder a estas preguntas con una simple llamada a un LLM.

Lo que añade la capa backend

El autor introduce componentes uno por uno, explicando el problema específico que cada uno resuelve: request_id — un identificador único de solicitud para correlacionar logs y depurar fallos específicos sources — una lista de fragmentos de documentos que entraron en el contexto del modelo, con indicación de la fuente timings — desglose de tiempo por etapas: búsqueda en el índice, formación del prompt, generación de la respuesta rebuild index — un endpoint separado para reconstruir el índice sin reiniciar el servicio * negative tests — verificación del comportamiento con un corpus de documentos vacío, preguntas fuera del tema e índice desactualizado La pila es completamente local: FastAPI para la capa HTTP, Ollama para la generación, embeddings personalizados. Ninguna clave de API externa.

Contrato de API como límite del sistema

Uno de los puntos clave del artículo — la importancia de un contrato explícito a nivel de respuesta. Cuando `/ask` devuelve solo una cadena, el servicio sigue siendo una caja negra. Una vez que la respuesta incluye `request_id`, `sources`, `timings` y estado del índice — es posible monitorear, depurar y mejorar.

"No estoy mostrando cómo funciona RAG en general, sino el camino desde

una simple llamada a un LLM local hasta un pequeño proyecto backend con un contrato de API, logging, sources, timings y limitaciones honestas". Este enfoque cambia cómo ves el servicio: en lugar de "el modelo de alguna manera responde", obtienes "el sistema se comporta de manera predecible."

Honestidad sobre limitaciones

El autor enumera explícitamente lo que falta en el proyecto: autorización, almacenamiento en caché, soporte de carga multiusuario, CI/CD. Esto hace que el artículo sea más útil que la mayoría de los tutoriales, donde la sección de limitaciones no existe o se reduce a una frase estándar. Los negative tests son un tema separado. El comportamiento se verifica con un corpus de documentos vacío, con preguntas sin contenido relevante en el índice, y al acceder al índice después de añadir nuevos archivos sin reconstruir. Un conjunto mínimo, pero suficiente para entender exactamente dónde el sistema falla.

Qué significa esto

El artículo cubre una brecha específica: la mayoría del material sobre RAG explica la teoría o muestra "hello world" con LangChain. Aquí — un servicio local funcional con herramientas de observabilidad que puede servir como base para un proyecto real.