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

Разработчик на Хабре разбирает конкретный момент: когда одиночный вызов локальной модели перестаёт хватать — и что нужно добавить, чтобы получить настоящую backend-систему.

Когда простого вызова мало

Первая версия выглядит очевидно: frontend отправляет вопрос, FastAPI принимает `POST /ask`, backend дёргает Ollama и возвращает строку с ответом. Для демо хватает. Для помощника по документации — нет. Вопросы появляются сразу: на какие документы опирается ответ? Какие фрагменты попали в prompt? Почему один запрос обрабатывается две секунды, а другой — пятнадцать? Что происходит, если индекс не обновлялся три недели? Ответить на них простым вызовом LLM невозможно.

Что добавляет backend-слой

Автор вводит компоненты по одному, объясняя конкретную проблему, которую решает каждый: request_id — уникальный идентификатор запроса для корреляции логов и отладки конкретного сбоя sources — список документных фрагментов, которые попали в контекст модели, с указанием источника timings — разбивка времени по этапам: поиск в индексе, формирование prompt, генерация ответа rebuild index — отдельный endpoint для пересборки индекса без перезапуска сервиса * negative tests — проверка поведения при пустом корпусе, вопросах вне тематики и устаревшем индексе Стек полностью локальный: FastAPI для HTTP-слоя, Ollama для генерации, собственные эмбеддинги. Никаких внешних API-ключей.

API-контракт как граница системы

Один из ключевых тезисов статьи — важность явного контракта на уровне ответа. Когда `/ask` возвращает только строку, сервис остаётся чёрным ящиком. Как только ответ включает `request_id`, `sources`, `timings` и статус индекса — появляется возможность мониторить, отлаживать и улучшать.

«Показываю не как вообще устроен RAG, а путь от простого вызова локальной LLM к небольшому backend-проекту с API-контрактом, логированием, sources, timings и честными ограничениями».

Такой подход меняет отношение к сервису: вместо «модель как-то отвечает» появляется «система ведёт себя предсказуемо».

Честность про ограничения

Автор явно перечисляет, чего нет в проекте: авторизации, кеширования, поддержки многопользовательской нагрузки, CI/CD. Это делает статью полезнее большинства туториалов, где раздел с ограничениями либо отсутствует, либо сводится к дежурной фразе. Negative tests — отдельная тема. Проверяется поведение при пустом корпусе документов, при вопросах без релевантного контента в индексе и при обращении к индексу после добавления новых файлов без пересборки. Минимальный набор, но уже позволяет понять, где именно система даёт сбой.

Что это значит

Статья закрывает конкретный пробел: большинство материалов про RAG либо объясняют теорию, либо показывают «hello world» с LangChain. Здесь — работающий локальный сервис с observability-инструментами, который можно взять за основу реального проекта.