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

В этой статье описывается подробная последовательность для Windows 10 и RTX3090 по установке всего необходимого программного обеспечения (Python, Git, CUDA Toolkit, CMake, MSVC, Ninja, OpenSSL), сборке llama.cpp из исходников с поддержкой GPU, скачивания модели Qwen3.8-27B с Hugging Face, её конвертации в формат GGUF и квантизации в Q4_K_M (чтобы она целиком поместилась в видеопамять GPU), а так же приведены параметры запуска для локального сервера llama.cpp с OpenAI-совместимым API и веб-интерфейсом, позволяющим общаться с моделью через чат в браузере. Каждый шаг сопровождается объяснением, зачем он нужен, что делает каждая команда и что означает каждый параметр у команды.

В августе 2026 года появились новые подробности о первом устройстве OpenAI и Джони Айва. По данным СМИ, компания работает над небольшим портативным гаджетом без экрана примерно размером с хоккейную шайбу, с микрофонами, камерами и другими сенсорами. Из‑за формы его уже успели сравнить с пончиком. Сам OpenAI устройство пока официально не представлял. После заявлений Сэма Альтмана о то что компания создают новое революционное устройство, это выглядит довольно скромно. Умные колонки появились уже больше десяти лет назад.

Но, возможно, стоит уделить внимание не самому устройству, а тому к чему движется индустрия. OpenAI ещё в 2025 году, когда команда io Products вошла в компанию, говорил не об одном гаджете, а о создании семейства AI‑продуктов. А руководство OpenAI (включая Сэма Альтмана и финансового директора Сару Фриар) сформулировали на их взгляд другую фундаментальную проблему: компьютеры (гаджеты) уже научились видеть, понимать и рассуждать, но пользовательские интерфейсы всё ещё во многом принадлежат предыдущей технологической эпохе.

Думаю, что именно отсюда стоит обратить внимание и посмотреть, что сейчас происходит с AI‑очками, наушниками, колонками и другими экспериментальными устройствами. На рынке начинается борьба за новое направление — персональный ИИ компаньон, постоянно присутствующий слой между человеком, его устройствами и цифровым миром. А сегодняшние AI‑гаджеты, возможно, лишь первые интерфейсы к этой системе.

Самая распространённая ошибка — это попытаться автоматизировать всё сразу. Когда компания подключает чат на сайте, Telegram, WhatsApp, почту, консультации по продукту, претензии и сложные обращения одновременно.

После первых ошибок появляется вывод: «ИИ нам не подходит».

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

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

Меня зовут Алексей, моя команда делает прикладной ИИ для бизнеса. За этим порядком работ — опыт нескольких десятков проектов. Почти на каждом мы натыкались на одни и те же грабли в одном и том же месте: на входе, в данных.

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

В прошлой серии сравнил Qwen3.8-27B на своей карте с DeepSeek V4 Flash по API. Меня спросили: а если DeepSeek поставить на ту же карту, урезав до 2 бит? Ответ: 0.697 против 0.731 у той же модели на полной точности — минус 0.034 балла, реальная цена квантования или шум?

Вступление: Unreal Engine 5 — это действительно сложно.
1. UE5 - это не веб-приложение. Это не CRUD-сервис. Это не фронтенд на React.
2. Миллионы строк кода на C++ в самой кодовой базе движка.
3. Редактор с ручным управлением: большинство действий в UE5 делается через GUI — клики, перетаскивания, настройка параметров вручную.
4. Сложная архитектура: модули, плагины, подсистемы, зависимости между которыми не очевидны.
5. Blueprints: визуальное программирование, которое не очевидно автоматизировать.
6. Высокий порог входа: чтобы писать под UE5, нужно знать C++, архитектуру движка, систему actors, blueprints, render-pipeline.
7. Это не тот проект, где «дал агенту задачу и он сделал». Это проект, где большинство «экспертов по внедрению AI» сказали бы: «Тут автоматизация невозможна. Слишком сложно. Слишком много ручного управления. Слишком много неявных знаний».

И тем не менее. Сейчас на этом проекте AI пишет весь код на C++ сам, дебажит, перезапускает среду выполнения и сам проверяет результат, после чего дает добро проверить человеку. Вся разработка и внедрение фич — это постановка задачи по спеке и контроль в процессе. 98% времени — просто смотрим одним глазом в мониторы. 2% думаем и исправялем что пошло не так.

Проблема: UE5 — редактор с ручным управлением
Главная сложность UE5 для автоматизации — это не отсутствие API. Python в UE5 позволяет вызывать почти всё в редакторе программно. Проблема в другом: цепочки действий очень сложные.
Одно действие в редакторе — это одна команда. Но реальная задача — это цепочка из десятков и сотен действий, которые должны быть выполнены в правильном порядке, с правильными параметрами, с обработкой ошибок на каждом шаге.

Примеры сложных цепочек:
1. Написание блюпринтов в редакторе: создать граф нод, соединить их, настроить параметры, скомпилировать, проверить. Это неочевидный процесс, который требует понимания визуального программирования UE5.
2. Создание и настройка actors: создать actor, добавить компоненты, настроить свойства, привязать к уровню, проверить рендер.
3. Настройка материалов и шейдеров: создать материал, настроить параметры, подключить текстуры, применить к мешу, проверить визуально.
4. Работа с ландшафтом и освещением: создать ландшафт, настроить слои, расставить источники света, запечь освещение.

Каждое из этих действий можно вызвать через Python или напрямую через C++ blueprinted. Но оркестрация цепочки — это нетривиальная задача. Нужны управлять последовательностью действий, обрабатывать ошибки, проверять промежуточные результаты.

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

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

Отсюда появляются prompt injection, попытки извлечения системных инструкций, обход ограничений и утечки информации через ответы модели.

С этой проблемой мы столкнулись при разработке FlautFast — нашей LLM внутри инфраструктуры FlautCompany.

В отделе FlautSecurity мы решили не пытаться закрыть все эти проблемы одним классификатором. Так появился FlautGuard — защитный слой между пользователем и моделью.

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

Вы запускаете большую MoE‑модель (например, Qwen, DeepSeek, Mixtral) на локальной машине через llama.cpp / llama-server, но скорость генерации токенов в разы ниже ожидаемой. Статья — для Linux-пользователей с гибридными процессорами Intel 12-го поколения и новее и видеокартами NVIDIA (CUDA). Конфигурация: RTX 4070 (12 ГБ), i5-12600K, 32 ГБ DDR5-6000.

Статья написана по мотивам публикации "Local LLM Inference Optimization: The Complete Guide" и является частью цикла статьей по траблшутингу и оптимизации работы языковой модели на локальных машинах.

Начну с запроса, который приходит примерно во все отделы примерно всегда:

«Есть тезисы и цифры. Нужна презентация к завтра. Ну сгеренируйте там что-нибудь, есть же ИИ».

Это почти дословная цитата, причём из разных подразделений независимо друг от друга. « У нас есть ИИ» оказалась устойчивой народной формулировкой и решением всех проблем.

Если делать руками, одна презентация это часа четыре-шесть: структура, текст, вёрстка. Потом три-пять кругов правок, и каждый круг это пересборка. А ожидание ровно одно: должна быть кнопка «сделать красиво».

Мы решили проверить, существует ли уже такая кнопка. Не по обзорам, а на своём материале.

Нашел на Reddit интересный тред с простым вопросом: «Какой AI-тренд тихо умер?» Сам недавно рассуждал об этом же — много с чем не согласен, но материал классный, решил сделать из него пост. В комментариях пользователи вспоминают хайп последних лет, спорят о конкретных технологиях и пытаются понять, какие из них действительно оказались полезными, а какие просто красиво выглядели на демо, но оказались бестолковыми в реальности.

ИИ в разработке постепенно перестает быть отдельной экспериментальной темой. Его встраивают в IDE, подключают к корпоративным системам через MCP, используют для создания приложений и подготовки кода. Одновременно появляются новые среды, плагины и подходы к архитектуре данных.

Этим изменениям посвящена секция «Идеи и тренды в разработке» на INFOSTART TECH EVENT 2026, которая пройдет 8–10 октября в Санкт-Петербурге. В программу уже вошли восемь докладов - от рабочих прототипов до технологий, которые пока находятся на стадии активных экспериментов....

При LoRA‑дообучении адаптеры обычно применяются ко всем слоям модели, хотя активность разных слоев во время обработки промпта заметно различается. Возникает вопрос: можно ли выбрать более «умные», активные слои для конкретной темы и получить прирост качества?

Проверил гипотезу на Qwen3-1.7B: воспроизвёл метод из статьи Act‑LoRA, добавил свою метрику по градиентам, статистически проверил устойчивость сигнала и получил результат, который многое объясняет о том, как на самом деле работает LoRA‑дообучение.

Звучит как очередной заголовок из серии «будущее уже наступило»: берём обычный Wi-Fi, несколько дешёвых ESP32 и внезапно видим на экране человека, который находится за стеной. Без камеры, без датчиков на человеке и даже без какого-нибудь браслета.

Я наткнулся на проект RuView, раньше он назывался WiFi-DensePose. В итоге полез смотреть, что там внутри: репозиторий, документацию, модели и issues. Если коротко: проект настоящий. Но ESP32 за девять долларов пока не превращает квартиру в рентген-кабинет.

Вы дописали правило в .cursor/rules. Агент его прочитал, согласился и через два хода сделал ровно то, что правило запрещает. Иногда с извинением: да, правило было, я его нарушил.

Другой день, другой проект: правило на месте, но в контекст оно не попало вообще, и узнать об этом было неоткуда. Третий случай: попало всё сразу, вместе с вложенными AGENTS.md со всего дерева проекта, и половина окна ушла на инструкции ещё до первой строки кода.

Причины у этих трёх случаев разные: в первом правило конкурирует с задачей внутри промпта, во втором не доходит до модели, в третьем доходит вместе с сотней чужих. Общее одно: вы создали файл в папке проекта, открытой в Cursor, и считаете, что задали агенту дисциплину.

Привет! Я Никита Векессер, Product Owner AI-продуктов в Orion soft.

Что представляет собой реальная практика внедрения ИИ в России? В этой статье я хочу показать статистику, которую мы честно собрали на российском enterprise-рынке, и дополнить ее нашим опытом. Без претензии на абсолютную истину расскажу, как развитие AI в России выглядит с нашей стороны.

Привет, Хабр! Сбер недавно выкатил новую модель, GigaChat Audio. Сейчас я надиктовываю модели этот текст голосом — финальный штрих в истории о том, как я проводил её тест‑драйв. 

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

Меня зовут Данила @pushnoydan, я мидл‑разработчик и занимаюсь бэкендом микросервисов. А параллельно — большой любитель ИИ‑моделей: в свободное время копаюсь в них, чтобы лучше понимать возможности свежих релизов, стараюсь применять на работе, чтобы упростить рутинные задачи. 

GigaChat Audio — audio‑native LLM. В течение дня я поручал ей разбирать голосовые коммуникации от коллег, составлять саммари по аудиозаписям и выводить ключевой контекст из записей различных встреч. Давайте посмотрим, как модель показала на реальных задачах.

Привет, Хабр! Меня зовут Никита Хробостов, я QA-инженер в Just AI. Тестирую диалоговые системы: чат-ботов и голосовых ботов, часть из них с обращениями в RAG.

Моя работа устроена так: беру схему диалога на Холсте, примеряю на себя роль клиента и последовательно прохожу сценарий. Задаю вопрос и проверяю ответ, соглашаюсь — смотрю, правильно ли сработал переход, отказываюсь — проверяю фолбэк. Так приходится проходить десятки сценариев, которые в крупном проекте быстро складываются в большой объем ручной работы.

Чтобы было понятно про объемы. На проекте голосового бота у нас 13 активных сценариев, на чат-боте один. Чтобы проверить один сценарий целиком, нужно от 40 до сотни с лишним звонков, а тест-кейсов при этом в два-четыре раза больше: зависит от дизайна. На полную проверку одного небольшого сценария уходит 5–6 часов.

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

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

По прогнозу Международного энергетического агентства (МЭА), к 2030 году дата-центры, ИИ и криптовалюты должны суммарно потреблять около 945 ТВт·ч в год — столько же, сколько сейчас потребляет вся Япония. Центр тяжести этого предложения — в слове «должны». Как бы ни прекрасна была мечта об AGI, все низменно и редукционистски упирается в банальную проблему — в доступность электроэнергии. Но если бигтехи в пресс-релизах обещают открывать огромные десятигигаваттники, значит, проблем с питанием нет — правда же? Да?

А давайте проверим.

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

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

Решил посчитать, сколько раз языковые модели отзываются плохо о конкретной компании. Вроде простая задача: прогнать запросы через несколько моделей, разметить тональность ответов, поделить негативные на общее число. У меня получилось три негативных ответа из 358 — 0,8%. Число выглядело спокойным, и я чуть не отправил его в отчёт как есть.

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

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