Локальный 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-инструментами, который можно взять за основу реального проекта.