Локальный 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-проектов в компаниях стартуют одинаково: сначала делают чат-бота, затем добавляют агентов, автоматизируют отдельные процессы и ожидают роста эффективности.На практике такие проекты часто не дают устойчивого результата. Модель может корректно генерировать текст, демонстрации выглядят убедительно, но в реальной работе ответы оказываются нестабильными, противоречивыми и не связанными с внутренними стандартами компании.Основная причина — отсутствие единого слоя знаний.
RAG в enterprise: 70-80% проблем не в модели, а в данных
Жемал Хамидун, Head of AI Alpina Digital, CPO AlpinaGPT
