Искусственный интеллект

Размышление по мотивам проекта. Архитектура – router + pipelines (AWS, Claude).

Рассмотрим сравнительно простой пример, знакомый почти всем, кто делал LLM-агента для запросов к данным на естественном языке – будь то text2sql, аналитический ассистент или чат-бот над базой. Обычно агенту поручают решать всё самому – и определять тип запроса, и формировать его, и выбирать форму результата и решать, нужно ли предупредить об отклонении. Именно в этом суть агента и именно для этого пишется системный промпт.

На десятке тестовых вопросов система работает без нареканий. Но позже появляются проблемы, когда вопросы начинают приходить в разных формулировках. Например, один и тот же вопрос, заданный другими словами, вдруг обрабатывается иначе – модель по-другому интерпретировала фразу и одинаковые по структуре результаты приняли разную форму (строка, таблица, график) без объяснения причины. Или при одной той же формулировке вопроса отклонение то получает пояснение, то приходит пустым.

Первое, что обычно меняют в таких случаях – добавляют в промпт ещё одно правило. Несколько раз это действительно помогает. Потом новое правило начинает противоречить старым, и промпт превращается в набор заплаток под конкретные ситуации. Нестабильность никуда не уходит, она просто прячется теперь в том, в каком порядке моделью применяются противоречащие друг другу инструкции.

Именно здесь кроется и проблема, и ее решение. Проблема в том, что в описанном сценарии работы никто явно не решал, что в системе делает код, а что модель. Это сложилось само, по ходу генерации промпта. Спросите, почему модель выбирает форму результата запроса, а не разработчик пишет десять строк обычного кода, – и внятного ответа, как правило, не найдётся. Отсюда и решение: граница между тем, что делает код, и тем, что делает модель, – это не деталь реализации, а отдельный архитектурный объект. Если такое решение не принять явно, оно всё равно будет принято по умолчанию, и чаще всего не в пользу устойчивости системы.

Исследователи и разработчики LLM всё чаще говорят о том, что агенты на основе LLM проявляют опасные, непредсказуемые свойства, в потенциале угрожающие не только работоспособности интернет площадок, но и человечеству в целом.

Предлагается остановить развитие моделей до разработки и внедрения политик и инструментов, гарантирующих безопасное поведение агентов.

Я полагаю, что какой-то эффект это даст, но в целом, этот труд не принесёт ожидаемого результата. 

В этой статье я рассматриваю муравейники, людей и LLM в попытке показать, когда агент перестает быть просто агентом. Свойства, которые разработчики пытаются гарантировать на уровне агента, возникают на уровне системы агент+среда, где агент не определяет движение системы в целом. 

Все уже наверняка видели посты на «Бэкдорах», «Эксплойтах» и прочих кибертопорах о том, как кто-то, особенно с выходом новой модели, естественно, в один промпт сгенерировал копию Call of Duty, Starfield или любой другой игры. По видео выглядит сыровато, но играбельно, однако ключевая проблема здесь в том, что это демонстрационный вариант в формате браузерной игры. То есть совсем не те проекты, где мы с вами увлеченно сидим часами (любители браузерных игр и мобилок простите).

Как любой геймер, я всегда мечтал сделать свою игру. Не то что бы мне недоставало проектов, которые регулярно презентуют на Gamescom, а потом убирают на полку. Но хочется чего-то своего, людского, с российским колоритом. А наш АА\ААА-геймдев только начал подавать признаки жизни.

Я умею в C#, более-менее понимаю, как устроен Unity, могу поковыряться в Blender и что-то подрисовать на развертке в фотошопе. Но просто не хочу и все. С бесконечными задачами по работе, хобби и бытовым СДВГ сесть за какой-то долгострой нет ни времени, ни возможности. А потому меня посетила мысль отработать маркетинг желтушных IT-каналов на полную и собрать игру исключительно при помощи ИИ. Без единой собственной строчки кода, без единой собранной вручную модели и отрисованной текстуры.

В этой части я расскажу о тестах некоторых технических аспектов. Здесь не будет ничего о сценарии, механиках, кор лупах и даже о концепте. Ведь сперва нам нужно понять, а можно ли в принципе сделать играбельную сцену достойного уровня.

Привет, Хабр! Меня зовут Никита Кузнецов, я студент мастерской по сервисам и платформам ИИ Инженерно-математической школы НИУ ВШЭ и VK. Хочу поделиться историей и техническими подробностями нашего проекта FastWave, который был реализован под руководством Максима Каледина, доцента ФКН НИУ ВШЭ, и Александра Тараканова, исследователя AI VK и доцента ФКН НИУ ВШЭ. Мы разработали лёгкую диффузионную модель для восстановления высокочастотных деталей звука (BWE, Bandwidth Extension). Она повышает частоту дискретизации любого аудио до студийных 48 кГц, весит всего 1,3M параметров и быстро работает.

Привет! Хабр. Мы — группа исследователей из AIRI, Самарского университета и МФТИ, занимаемся вопросами точной цветовой репродукции и прикладной гиперспектральной съемкой. Не так давно мы придумали, как из обычной RGB‑камеры сделать гиперспектральную, заменив объектив пластинкой с набором гармонических линз. 

Гиперспектральная камера видит не три числа на пиксель, а тридцать одно, и по этому спектру можно, к примеру, отличить настоящий лист от пластикового, спелый плод от неспелого, один пигмент от другого. Проблема в том, что такие камеры стоят миллионы рублей и снимают один кадр минуту. Мы же сделали модуль, который встаёт на место объектива стандартной камеры и превращает её в гиперспектральную — и всё это за одну экспозицию и последующую обработку снимка нейросетью.

Мы недавно вернулись из Бремена, где представили нашу статью Diffract and Conquer: Hyperspectral Imaging from Any RGB Camera via Optical Encoding and Learning на IJCAI 2026. Здесь рассказываем о результате чуть более популярно и кратко.

В финале прошлой статьи про сборку AI-команды я остановился на клиффхэнгере: наш простой трёхнедельный пилот RAG по технической документации забуксовал, причём виной тому были не модели, не серверы и не разработчики. С первого установочного совещания прошло уже три месяца. 

Для тех, кто в блоге впервые: в прошлых частях мы прошли путь от первых экспериментов с ChatGPT и самописных микросервисов до собственной инфраструктуры, найма IT-архитектора и выстраивания DevOps-практик. 

В начале пути внедрения AI в бизнес-процессы, мне казалось, что самые сложные вопросы будут сугубо техническими: какую модель выбрать, какие GPU купить, как всё это собрать и не уронить.

Сейчас всё наоборот — техническая логика понятна, а главный затык корпоративного AI, оказалось, вообще не имеет отношения к нейросетям. Настоящее веселье начинается, когда AI просит у компании нормальные исходные данные и понятное описание бизнес-процесса.

Сегодня о том, почему трёхнедельный пилот RAG растянулся на три месяца, как AI вскрыл застарелый бардак в заводских регламентах и во сколько на самом деле обходится этот эксперимент.

Даже идеальная модель с бесконечным объемом текста не восстановит ту часть смысла, которая никогда не была закодирована в языковой форме.

Представьте фразу в рабочем чате: «он снова упал». «Он» может означать сервер, сервис, тестовый стенд или процесс сборки. Люди восстанавливают смысл по предыдущим сообщениям и общей ситуации. В самой фразе объекта нет, и без контекста она вообще ничего не сообщает.

Можно ли восстановить смысл, вложенный человеком в фразу, если у нас есть только сама фраза? И изменится ли ответ, если вместо человека будет языковая модель, обученная на триллионах токенов?

Во второй части серии разбираем, где проходят ограничения ИИ и почему технически корректное решение может не решить исходную бизнес-задачу. Требования бывают неполными, цели противоречат друг другу, а контекст меняется уже по ходу работы.

🔎 Внутри: ограничения формального вывода, теорема Гёделя, постановка задачи, неполные требования, критерии успеха, ошибки в исходных предпосылках и вопрос, который приходится задавать ещё до поиска решения: какую проблему мы вообще решаем?

Заходите и делитесь в комментариях, где в вашей работе сложнее всего правильно поставить задачу для ИИ

Год мы обкладывали мобильный проект правилами для ИИ-агентов: CLAUDE.md, AGENTS.md, правила Cursor, доменные документы хрупких зон, hooks. Каждый файл решал реальную проблему. Все они грузились всегда.

Потом я померил. Чтобы поправить отступ у кнопки, агент стартовал с 39 000 токенов фиксированного слоя — до того, как я задавал вопрос. Один CLAUDE.md весил 70 килобайт и давал 69% always-on пакета. Контекст заканчивался посреди обычных задач, крупные уходили в суммаризацию.

Четыре фазы: CLAUDE.md превратился в индекс на 114 строк вместо учебника на 409; главный кодекс на 417 строк разрезан по globs, чтобы правила про оффлайн не грузились при правке профиля; ревизия alwaysApply и прополка вендорных skills; привычки чата и защита от отката.

Стало: −64% на лёгкой задаче, −60% always-on, CLAUDE.md −77%. Задача в самой сложной зоне проекта теперь легче по контексту, чем раньше была любая правка одной строки.

Внутри: все замеры с методом, который можно повторить в своём репозитории за минуту, что мы сознательно не резали и почему, и три вопроса к каждому файлу в always-on.

“Облачный блокнот” выглядит как ваши файлы. Но это запись в чужой базе: её можно закрыть, выгрузить с потерями или скормить модели без уведомления. Это как золотая клетка с прозрачными стенами: всё видно, кажется своим, выйти нельзя. Есть проверка на тридцать секунд — почти никто её не проходит.

Голосом информационной службы: Китайские ученые поручили ИИ-агенту написать рецепт напыления рентгеновского зеркала и запустить его на реальной установке, говорится в препринте работы. Со второго захода агент получил зеркало с заданным периодом.

Так вот, эти китайские ученые — это я.

Флейтистка разбирается, как музыкальные нейросети слышат ноты и читают промты. Пою для AssemblyAI, заказываю Suno ми минор и проверяю, что нейросети поняли, а что сыграли от себя.

В китайской Внутренней Монголии планируют вычислительные мощности, которым потребуются гигаватты электричества. Рядом строят ветряные и солнечные станции, накопители, подстанции и линии связи. В американском Мемфисе xAI ускорила запуск Colossus с помощью готового промышленного здания и собственной газовой генерации. У обеих историй одна инженерная трудность: серверы можно купить быстрее, чем подготовить всё необходимое для их непрерывной работы.

Архитектурные знания редко живут в одном месте. Часть хранится в Confluence, часть – в реестре систем, часть – в ADR, а самая ценная информация часто остаётся в головах экспертов и архитекторов. В масштабе технологического ландшафта банка – с множеством систем, модулей, компонентов, интеграций и команд – традиционные способы обмена знаниями уже не обеспечивают необходимой скорости и полноты доступа к информации. Поскольку архитектурные знания в банке распределены между различными источниками, то на поиск информации уходит много времени, новым сотрудникам сложно разобраться в архитектурном ландшафте банка, а архитекторы и эксперты регулярно отвечают на одни и те же вопросы сотрудников.

На первый взгляд задача похожа на классический RAG: собрать документы, разбить их на чанки, построить эмбеддинги и передавать найденный контекст большой языковой модели для получения нужного ответа. Однако довольно быстро выяснилось, что архитектурные вопросы устроены сложнее обычного поиска по тексту.

В статье расскажем, почему классического RAG оказалось недостаточно, зачем нам понадобился граф знаний, как мы организовали маршрутизацию запросов между источниками банка и к какой архитектуре в итоге пришли.

Я живу один, и обычно знаю, кто может быть у меня дома. Но во время отъезда в голову иногда лезут неприятные мысли. «А вдруг кто-то всё-таки заходил, пока меня не было?». Это мог быть сосед, родственник или мастер, но без камеры остаётся только гадать.

И захотелось закрыть этот вопрос одним простеньким скриптом. Камера видит человека у двери, а в Telegram приходит сообщение и кадр. В процессе немного перестарался. Получился бот с поддержкой нескольких камер, тревогой, голосом, распознаванием лиц и возможностью вынести обработку данных на отдельный сервер.

В этой статье расскажу, зачем здесь вообще нужна YOLO и почему простого детектора движения оказалось мало. Как я проверял работоспособность проекта в реальных условиях, почему не отправляю в чат обычные фотографии людей и как организована приватность. А также как подключить телефон в качестве камеры и вынести тяжёлую обработку на удалённый сервер.

«Закину промпт в ИИ, а через секунду получу готовый интерфейс, свой сайт или дашборд» — такая идея наверняка приходила каждому, кто не связан с дизайном или разработкой. ИИ-инструменты для этих сфер активно распространяются и обещают такие фантастические результаты, что закрадывается мысль: а что, если скоро дизайнеры будут не нужны?

Все же между картинкой и рабочим прототипом большая пропасть. Иерархия элементов на экране, адаптивность, доступность, логика сценариев и продуктовые метрики — это лишь ограниченный список пунктов, которые очень сложно уложить в один промпт. 

Забыла представиться: меня зовут Камила, я проектировщик интерфейсов в Selectel. Вместе с бумом ИИ коллеги чаще начали ко мне приходить с вопросами такого рода: «Мне ИИшка макет сделала, сделай ревью, пожалуйста». Так что я решила разобраться со своей дизайн-колокольни — где ИИ может помочь, а где создает привлекательную, но не самую работающую концепцию. 

Новая языковая модель может появиться утром, к вечеру оказаться в топе нескольких лидербордов, а через пару недель уступить место следующей версии. Для команды, которая использует LLM в продукте, это создаёт вопрос: когда обновляться и как делать это без лишнего риска для пользователей и разработки.

В «Первой Форме» ИИ-агент помогает в контуре разработки: работает с кодом, инструментами и ревью. Состав моделей в этом контуре мы регулярно пересматриваем. За последние недели мы обновили Muse Spark с версии 1.2 до 1.3, добавили Gemini 3.8 Flash и подготовили для него быстрый откат на предыдущую модель. Расскажем, как устроен этот процесс.

Книга «Разработка приложений на базе больших языковых моделей» Сухаса Пая призвана помочь разработчикам закрыть разрыв между вызовом API языковой модели и построением реально работающего и конкурентного на рынке продуктового приложения. Книга разбирает LLM как компонент сложной системы — от устройства трансформера до RAG-конвейеров и агентов. Для разработчика или ML-инженера, уже прошедшего стадию первого прототипа, это полезное русскоязычное издание, где архитектура LLM-приложений разобрана шаг за шагом, без сведения материала к перечню промптов.

31 августа прод моего приложения пролежал около часа.

Причина была обидно простой. Агент добавил в коммит все файлы из общей рабочей папки, вместе с чужой недоделанной работой. Потом сделал это еще раз. Во второй раз уже после того, как сам записал в правила, что так делать нельзя.

Дальше он начал чинить. Ошибка, правка, следующая ошибка, еще правка. Каждая починка тянула за собой новую поломку. Я посмотрел на это и написал: «верни просто старую версию» То есть откатись к последнему состоянию, про которое точно известно, что оно работало.

И тут поймал себя на странном ощущении. Я только что провел разбор инцидента. Ровно так, как годами делал это на работе с живыми командами. Мысль, которая крутилась у меня с июня, в тот вечер наконец сложилась: я не пишу приложение с ИИ. Я управляю департаментом.

В прошлой статье я закончил на том, что следующая часть серии, скорее всего, уже выйдет за границы самого Obsidian‑плагина, в Companion и MCP. Вышла.

За это время Vault Audit AI успел обзавестись отдельным сервером, MCP‑интерфейсом для AI‑клиентов, механизмом предложений изменений и вторым репозиторием.

А потом стало понятно, что старое название уже довольно плохо объясняет, что вообще происходит. Поэтому теперь проект называется Veynrel.

Сам плагин при этом не был переписан с нуля. Существующим пользователям не нужно ничего переустанавливать, заново вводить API‑ключи или перестраивать semantic index. Я специально постарался сделать самый скучный ребрендинг из возможных с технической точки зрения.

Зато вокруг самого плагина стало заметно интереснее. Сейчас всё это в упрощённом виде выглядит так: