AI, ANN и иные формы искусственного разума
Первая статья из цикла «Аналитик в чужом процессе»
145 тысяч тикетов, почти 87 тысяч "аномалий" и уверенность, что Service Desk полностью сломан. Но один разговор с опытным специалистом первой линии заставил меня выбросить половину критериев, переписать анализатор и полностью изменить выводы. Эта статья — о том, почему большие данные сами по себе ничего не объясняют, если сначала не понять сам процесс.
12 июля флагманская GPT-5.6 Sol Pro после восьми часов размышлений побила лучший человеческий результат в задаче о длине пути градиентного спуска — и оформила его полноценной статьей на 14 страниц с доказательствами, таблицей констант и скриптом для их проверки. Прежний рекорд — оценка 2.29^n — принадлежал людям, но о нем мало кто знал: он так и не был опубликован. Историю двухлетнего противостояния людей и моделей исследователь OpenAI Себастьен Бубек рассказал в треде 10 июля, а уже через два дня объявил о падении рекорда.
Забавная история про то, как я решил разбавить актив в своем чате для друзей, добавив самого настоящего Т-800, который мог бы свободно общаться с участниками, не потратив копейки денег на API - чисто бесплатные модели с OpenRouter. Впрочем, впоследствий была попробована и локальная модель.
У меня 23 Telegram-канала. Не потому что я такой организованный — просто постепенно добавлял, пока не понял, что читаю примерно 3% из них, а остальное листаю вниз в поисках чего-то интересного.
Проблема известная. Телеграм устроен как хронологическая лента — свежее сверху, и неважно, интересно это тебе или нет. Алгоритмов нет. Персонализации нет. Только время публикации.
Я решил это починить. Так появился [CleanNews](https://t.me/clean_news_bot) — бот, который парсит твои Telegram-каналы и выдаёт персонализированный дайджест. В этой статье расскажу, как устроен рекомендательный движок: 5 сигналов, pgvector, контрастный вектор и жизнь без обучающего датасета в 10 миллионов записей.
Привет, «Хабр»!
Примеры запросов наглядно показывают, как нейросеть расшифровывает текст и воплощает его в графике. В одном промпте можно задать абсолютно всё: от стиля и освещения до общего настроения, ракурса, текстур и окружения. При этом даже незначительное изменение формулировки способно поменять итоговый результат.
В этом гайде мы собрали примеры для разных направлений: реалистичного фото, иллюстрации, брендинга и дизайна, 3D-визуализации и т. д. Для каждого из стилей – также привели примеры результатов генерации.
Приятного прочтения)
Последнее время я все чаще вижу одну и ту же картину.
Появился тикет. Программист копирует ссылку, передает ее AI-кодинг-агенту и через какое-то время получает готовый Pull Request.
Вроде бы красота.
Агент прочитал задачу, нашел нужный код, что-то поменял, запустил тесты и бодро написал, что все готово.
Только потом начинается самое интересное.
В Pull Request приезжает куча лишнего кода. Тесты зеленые, но сама функция не работает. Тикет уходит тестировщику и возвращается обратно. После исправления снова возвращается. А иногда оказывается, что агент вообще понял задачу не так, но программист этого даже не заметил, потому что сам тикет толком не прочитал.
Я не против AI-кодинг-агентов. Наоборот, я ими постоянно пользуюсь и считаю, что это уже обычный рабочий инструмент программиста.
Но инструмент, который быстро пишет код, не отменяет необходимость думать.
Искусственный интеллект уже ускорил написание кода, а способность систем безопасно принимать изменения осталась прежней. Отсюда – аккуратные пулл-реквесты, зелёные тесты и инциденты, которые проявляются только в продакшене. В статье разбираем, где возникает этот разрыв и какие инженерные guardrails помогают удержать скорость без роста хрупкости.
Об открытых языковых моделях написано много — и почти все статьи посвящены знакомству, в лучшем случае — «медовому месяцу» использования. Бенчмарки, рейтинги «лучших моделей года», полевые тесты на одной задаче, руководства. Гораздо реже говорят, что происходит потом: как ведет себя модель спустя месяцы непрерывной работы, где и почему начинает сбоить, что ломается под нагрузкой и какие инженерные решения постепенно вытесняют первоначальные представления о том, «как надо».
В WB-Tech мы занимаемся тем, что разворачиваем и сопровождаем открытые модели и агентные системы в собственной инфраструктуре — для внутренних задач и для заказчиков. Это классификация и обогащение входящих заявок, обработка документов, диалоговые системы с вызовом инструментов и другие сценарии, где LLM становятся частью бизнес-процесса, явно выходя за рамки демонстрационных возможностей модели.
Большинство наших клиентов приходят к локальному развертыванию не из любопытства, а из практической необходимости. Для одних вынос данных во внешний API запрещен требованиями безопасности, другим, экономика облачных моделей перестает нравиться на больших объемах. Поэтому вопрос «зачем держать модель у себя» оставим за скобками: конфиденциальность данных, предсказуемая стоимость при объемах и независимость от чужого API уже давно стали аксиомой в пользу самостоятельного хостинга для целого ряда задач.
Интереснее другое: что меняется после того, как модель начинает жить в продакшене, когда выясняется, что большая часть инженерной работы связана вовсе не с выбором LLM и приходится заново принимать решения об инференсе, промптах, агентной оркестрации, структуре ответов, управлении контекстом, параметрах генерации и даже хранении самих весов модели.
Большинство демо AI-агентов выглядят одинаково: есть чат, пользователь пишет задачу, модель красиво отвечает. Для презентации этого достаточно. Для реального бизнеса - нет.
Еще несколько лет назад разработчики на Java в основном обсуждали новые инструменты для создания программ, особенности архитектуры приложений и способы сделать сервисы быстрее и надежнее. Сегодня к этим темам добавился еще один важный вопрос — как искусственный интеллект меняет профессию программиста. Именно с этого началась пятая встреча в рамках MTC Web Services Meetup, которая собрала в Москве Java-разработчиков, архитекторов и инженеров.
Вместо привычной серии докладов организаторы открыли вечер большой дискуссией о том, как меняется современная разработка, чему теперь стоит учиться, какую роль играют ИИ-ассистенты и как их использование влияет на безопасность решений. Обо всем этом — в материале.
Полтора года назад мы работали как большинство команд разработки: заказчик приходил с задачей, мы её оценивали, согласовывали ТЗ и делали. Стандартный цикл.
Сейчас мы работаем иначе. Сами инициируем диагностику, сами ищем где автоматизация принесёт наибольший эффект, сами считаем ROI — до того как написана первая строка кода. Только потом договариваемся о разработке.
В этой статье — конкретная методология: как мы выбираем что автоматизировать, как считаем эффект в штатных единицах, как структурируем взаимодействие с промышленным заказчиком. С числами из реального проекта.
Один контрольный эксперимент — и один красивый ложный вывод, который мы чуть не опубликовали
После прошлой статьи о том, почему нормативные документы пришлось превратить в граф, а не просто загрузить их в векторную базу, нас несколько раз спросили одно и то же:
«А если взять GPT или другую топовую модель — неужели она действительно не сможет ответить на вопросы по СП и ГОСТ?»
А недавно тот же аргумент прозвучал в куда более жёсткой форме — на очной защите нашего проекта перед экспертами одной государственной грантовой программы по ИИ. Тезис звучал так: сервис для работы с нормативкой от маленькой команды обречён, потому что крупнейшие компании вкладывают в свои модели несопоставимо больше, — и поддерживать нишевую разработку на этом фоне нет смысла.
Аргумент понятен и звучит убедительно. Спорить с ним словами бесполезно — нужны данные. Так что считайте это исследование нашим развёрнутым ответом. Ниже — 3000 слепых оценок того, что фронтир-модели умеют на строительных нормах «из коробки», и что меняется, если поверх той же самой модели поставить доменный агентный поисковый контур.
Только не ждите вывода «наша система лучше всех LLM вообще» — его не будет. Мы показываем другое: там, где ответ обязан быть проверяемым по нормативному корпусу, агентный контур резко снижает число неподтверждённых ссылок — на одном и том же генераторе.
Заодно расскажем, как мы сами едва не попались — на методике, а не на моделях.
Giga4DQM — открытый проект, реализующий концепцию ИИ-агентов для автоматизированного расследования инцидентов с данными и построения целостной картины зависимостей в существующей БД. Система понимает вопросы на естественном языке, самостоятельно анализирует структуру базы, строит граф зависимостей и формирует диагностические запросы. Архитектура не привязана к одной СУБД: в качестве примера взята PostgreSQL, но подход может быть адаптирован к любой системе с развитым каталогом метаданных. В основе — мультиагентная архитектура на основе GigaChat и LangGraph. Код открыт, доступен для тестирования и внедрения.
Kadr: видеоредактор, в котором Claude Code монтирует рядом с тобой
Я задался вопросом: как должен выглядеть видеоредактор, если проектировать его в эпоху ИИ-агентов — не «редактор плюс кнопка с нейросетью», а инструмент, где агент работает на том же таймлайне, теми же операциями, что и человек? Ответа не нашлось, и я начал писать свой.
Эта статья не содержит туториалы по вайбкодингу и не разбирает технически неуспешные кейсы внедрений.
Основная задача — помочь тем, кто принимает решения для таких инициатив, не прогореть на идеях быстро внедрить AI для оптимизации рутины.
Почему желание сделать быстро и дёшево может обойтись в миллионные убытки? Показываю на самой простой аналогии с IKEA, а также предлагаю 3 скрининговых вопроса для проверки кандидатов. В конце честно поговорим о том, что делать, если дорогой AI-внедренец не по карману.
Статья не про надежду. Она про то, чтобы не дать себе не увидеть реальные риски, когда кажется, что другие уже на шаг впереди. Если вы технический специалист, который испытывает сложности в том, чтобы объяснить руководителю, почему лучше два раза подумать, прежде чем что-то внедрять, — поделитесь с ним этой ссылкой.
Если вы когда‑нибудь общались с популярными чат‑ботами или заглядывали на Character.ai, легко поддаться иллюзии, будто на той стороне экрана сидит живой человек. ИИ искусно шутит, сопереживает, злится и подыгрывает. Ведёт себя почти как человек. Но может ли за всем этим скрываться настоящее сознание и душа?
Если говорить кратко и прямо — за экраном только пустота и холодные математические расчеты.
Любая современная языковая модель представляет собой сложный калькулятор статистики, который предсказывает следующее, наиболее вероятное и приятное вам слово. Но не более того.
У LLM нет ни характера, ни настроения, ни личности. То есть ничего того, что свойственно человеческой психике.
Красивый фасад «души» быстро рассыпается в долгих диалогах. В текстовых ролевых играх (AI‑roleplay) это заметно сильнее всего: через 20–30 реплик бот теряет нить разговора, забывает детали и начинает безвольно поддакивать игроку.
Но неужели нельзя сделать ИИ хоть немного человечнее? Дать ему сознание? Возможно ли подарить языковой модели стабильный характер и живые эмоции без необходимости её переобучать? Рассказываем, как мы обошли ограничения нейросетей с помощью внешней программы.
Сейчас почти все представляют AI-разработку одинаково. Агент пишет код. Разработчик открывает diff, делает code review и разрешает релиз. То есть мы заменили программиста на AI, но сам процесс практически не изменился.
Но меня не покидает одна мысль. Есть известный принцип утки: если что-то плавает как утка, крякает как утка и выглядит как утка — скорее всего, это утка.
Почему бы не применить этот принцип к разработке? Если после изменений система проходит все тесты, выполняет продуктовые сценарии, не ломает существующее поведение, укладывается в требования по производительности и безопасности, то зачем вообще читать код? Мы ведь никогда не проверяли код ради кода. Мы всегда пытались понять только одно — правильно ли работает система. Раньше это было невозможно без code review. Код писал человек, и только другой человек мог оценить его качество.
Но теперь код все чаще пишет AI.
И возникает странная ситуация: агент способен написать или переписать тысячу строк за несколько минут, а человек будет читать их значительно дольше. Получается, что скорость генерации уже давно обогнала скорость проверки.
Дрон летит над карьером на Сахалине. Оператор сидит за пять тысяч километров и пьёт кофе. Между ними — только канал связи, и это в лучшем случае оптика, а в худшем — LTE-модем с одной палкой.
В прошлой статье я рассказал, что такое дронопорт и зачем он бизнесу. В комментариях резонно попросили: железо — понятно, а что с программной частью. Показываю.
Внутри разберём тонкости, о которых обычно молчат в презентациях:
— что на самом деле делает дрон, когда связь пропадает посреди миссии (спойлер: не падает);
— почему "разбить большую миссию на части" — это не арифметика, и при чём тут ветер и швы на ортофотоплане;
— зачем оператору видео с задержкой меньше секунды и почему телеметрия важнее картинки;
— как платформа дружит с ОРВД, ГИС и ERP заказчика — и почему в промышленности побеждает не самый красивый софт;
— и где нам приходится подбирать костыли, потому что не все методы SDK производителя открыты.
Я много работаю с кодинг‑агентами в Claude Code. В какой‑то момент поймал себя на том, что не представляю, на что уходят токены. Счёт в конце месяца есть, а из чего он складывается, непонятно.
Написал небольшую утилиту: она читает то, что Claude Code и так пишет на диск, и раскладывает расходы по статьям. То, что она показала, мне не понравилось.
Мультимодельная оркестрация – модная: вместо одной модели дёргаешь несколько разом, а отдельная модель-судья сводит их ответы в один. OpenRouter продаёт это под именем Fusion, Sakana AI – под именем Fugu, и обещание у обоих одно: связка обходит любую одиночную модель. Я решил проверить на реальных рабочих задачах – и первое место действительно занял оркестратор, обойдя и Claude, и GPT, и Gemini поодиночке.
Звучит как слайд из презентации вендора – примерно это и написала про свой Fusion команда OpenRouter. Но у меня остались логи всех 541 API-вызова: токены, деньги, время. И они портят красивую картинку. Например, 68% всех денег внутри Fusion уходит на один-единственный Claude Opus – выходит, за качество я доплачиваю больше чем вдвое, по сути, за обёртку вокруг модели, которую мог вызвать напрямую.
Дальше – по логам: как Fusion устроен изнутри, какие модели он дёргает на самом деле, где оркестрация реально бьёт одиночную модель, где сливает ей, и окупается ли она своих денег и полутора минут на ответ.