Где заканчивается вызов LLM и начинается backend система: локальный RAG на FastAPI и Ollama
На практике хотел понять где заканчивается простой вызов локальной LLM и начинается backend система: с API контрактом, логированием, request_id, источниками, индексом документов, диагностикой и честными ограничениями.Сначала проект выглядел просто: frontend отправляет вопрос, FastAPI принимает POST /ask, backend вызывает локальную модель через Ollama и возвращает ответ. Это уже работало, но стало понятно такой вариант ещё нельзя назвать системой по документации. Модель отвечает, но непонятно на что она опирается, откуда взяла ответ, сколько времени занял каждый этап и что делать если документы изменились.
Локальный RAG без магии: sources, timings, request_id и отказ от генерации
На практике было интересно не просто вызвать локальную LLM из Python а понять, в какой момент такой вызов превращается в backend-систему: с API-контрактом, логами, request_id, источниками ответа, индексом документов, диагностикой и честным отказом отвечать, если данных в документах нет.В этой статье показываю не теорию RAG, а небольшой локальный проект, где хорошо видно, какие инженерные проблемы появляются вокруг LLM:что попадает в prompt;какие sources были найдены;сколько заняли retrieval и generation;когда backend должен не вызывать LLM;почему stale index может давать странное поведение;
Chrome-расширение для Upwork: архитектура, метрики и опыт разработки с помощью ИИ
В свободное время я иногда захожу на Upwork, чтобы посмотреть, какие проекты там сейчас появляются и как устроен рынок изнутри.Если убрать фильтры и посмотреть на общий поток вакансий, довольно быстро становится видно типичную картину: большое количество разработчиков конкурируют за очень стандартные и недорогие задачи. В таких условиях основная проблема смещается не на поиск интересных проектов, а на скорость их обработки и подачи предложений. Это особенно заметно в сегменте разработчиков, которые работают на массовом рынке: им важно быстро отсекать нерелевантные предложения и экономить connects.
Зачем backend разработчику Python, если он не собирается становиться data scientist
Начал смотреть в сторону Python не потому, что захотел стать data scientist.Мой основной опыт обычный back C#/.NET, банковские системы, REST API, микросервисы, Kafka, PostgreSQL, Docker/OpenShift, CI/CD и сопровождение. Позже добавилась Java/Spring Boot. То есть моя базовая картина мира это не notebooks и не обучение моделей а сервисы, интеграции, продакшен, логи и ответственность за результат.Но когда я начал разбираться с LLM быстро понял, вызвать модель можно почти из любого языка, а вот руками понять RAG, embeddings, локальные модели, чанкинг, evaluation и большинство новых AI инструментов проще всего через Python.
Как мы боремся с галлюцинации AI Master: гибридный Guard на Embedding + LLM Extractor на примере AI-RPG «Стирая Грань»
Каждый, кто пробовал создавать текстовые RPG или симуляторы на базе LLM (будь то GPT-4, DeepSeek или локальная 70B), сталкивался с проблемой «Yes-And» проклятия. По своей природе современные языковые модели — это идеальные импровизаторы. Они обучены поддакивать пользователю и развивать его мысль.В контексте игры это превращается в легальные читы. Игрок пишет: «Я достаю из кармана дымовую шашку и кидаю в охрану» или «Вообще-то я полковник ФСБ, пропустите». Что делает классический AI GM? Он послушно кивает: «Охрана кашляет в дыму, вы проходите»
Как заставить ИИ играть по правилам ролевой системы: архитектура авторитарного бэкенда для AI RPG
TL;DRСделать текстовую игру на базе LLM легко, если вас устраивает бесконечный неконтролируемый чат, который ломается через 30 ходов из-за модельного дрейфа и амнезии. Сделать полноценную RPG с детерминированными механиками, инвентарём, картой-графом и пермадезом — инженерная задача.Ниже — подробный разбор архитектурных решений, юнит-экономики, борьбы с гонками данных и инфраструктурных грабель, собранных при разработке проекта «Стирая Грань» (Beyond The Verge) — полностью русскоязычной AI RPG на стеке FastAPI + PostgreSQL/pgvector + Flutter Web.1. Фундаментальная проблема: Контекстное окно ≠ Игровая память
Почему RAG — это не просто «добавить поиск»: latency, качество и выбор стратегии retrieval
Главное: RAG — это не просто «поиск + LLM». В локальном эксперименте основная дополнительная нагрузка появилась не в vector DB, а в embedding запроса, росте размера prompt и его обработке моделью. Top-k, chunk size и retrieval mode оказались параметрами проектирования и контроля, а не техническими настройками «по умолчанию». Главный вывод: стратегию retrieval нужно выбирать под тип вопроса, структуру данных, latency budget и требований к качеству.Введение
Почему RAG — фундамент любой AI-трансформации
За последние годы большинство AI-проектов в компаниях стартуют одинаково: сначала делают чат-бота, затем добавляют агентов, автоматизируют отдельные процессы и ожидают роста эффективности.На практике такие проекты часто не дают устойчивого результата. Модель может корректно генерировать текст, демонстрации выглядят убедительно, но в реальной работе ответы оказываются нестабильными, противоречивыми и не связанными с внутренними стандартами компании.Основная причина — отсутствие единого слоя знаний.
