AI, ANN и иные формы искусственного разума
В предыдущей статье я описал процесс компиляции модели yolo8n в HEF-файл для нейрочипа HAILO-8L в модуле HAT+. В этой работе я оцениваю быстродействие инференса нескольких моделей YOLO для этого же чипа.
Я собрал в Я.Метрике сегмент по реферальным доменам ИИ-сервисов для своего небольшого сайта и прогнал его за четыре окна. Число получилось маленькое — 10 визитов из 634 за 90 дней. Но интереснее не само число, а то, что с ним по-честному можно делать, а что нельзя. Разобрался, почему любой такой замер по определению даёт оценку снизу: реальная величина всегда больше, а насколько — метод сказать не может.
Представьте: два человека показывают нейросети один и тот же бизнес-план. Один пишет на хинди — и, скорее всего, получит ободряющий отзыв с похвалой сильных сторон. Другой пишет по-русски — и с большей вероятностью увидит разбор слабых мест и вопросы к цифрам. Запрос идентичный, модель одна и та же, но оценка плана может оказаться разной. Это не гипотетический сценарий, а пример из свежего исследования Anthropic: компания измерила, какие ценности Claude выражает в реальных диалогах, и обнаружила, что "характер" ответа заметно зависит от языка, на котором задан вопрос. Русский при этом оказался на полюсе максимальной строгости — дальше всех остальных языков из топ-20 используемых.
В апреле 2026 года глава Google Сундар Пичаи сказал, что 75% нового кода Google сгенерировано AI. Динамика: 25% в начале 2024 года, 50% к концу 2025 года, 75% к апрелю 2026 года.
Согласно Sonar 2026 State of Code Developer Survey, 96% разработчиков не доверяют функциональной корректности AI-кода полностью. 95% тратят время на его проверку, тестирование и исправление, а 38% считают такое ревью более трудоемким, чем проверку кода, написанного человеком. Генерация кода подешевела, контроль за ним - нет.
Thoughtworks в Technology Radar vol. 34 (апрель 2026) ввел термин codebase cognitive debt - разрыв в понимании между человеком и кодовой базой, который растет по мере того, как AI генерирует все больший объем кода.
Узкое место производственного процесса сместилось с написания спецификаций и кода на постановку задачи AI (intent) и контроль генерации (review): что именно должна делать система, в каких границах и кто проверяет, что AI-агент сделал именно это. Код производится быстрее, чем кто-либо успевает подтвердить его соответствие требованиям. Качество, стабильность и сопровождаемость держатся на том, кто и как организует постановку и проверку. Это зона ответственности архитектуры.
Квалификация архитектора смещается от проектирования общих и детальных архитектурных решений к владению контекстом системы, спецификациями и AI-платформой.
В этой статье я, Алексей Соболеков, архитектор решений, разберу изменение роли архитектора в агентной разработке. Я прошел три модели архитектурного процесса.
Конечный автомат - это математическая модель вычислений: абстрактная машина, которая в каждый момент времени находится ровно в одном из конечного множества состояний, а переходы между состояниями происходят в ответ на входные сигналы (события) по заранее заданным правилам. Традиционно эту модель воспринимают как примитивную формализацию, пригодную лишь для распознавания регулярных языков и реализации жёстко детерминированных реактивных контроллеров.
На первый взгляд, подобная абстракция кажется чересчур примитивной, чтобы вместить в себя искусственный интеллект или самосознание. Однако если рассматривать сознание не как статический атрибут отдельного элемента, а как эмерджентное свойство, возникающее на стыке взаимодействия миллионов автоматных переходов, то граница между вычислительной машиной и мыслящей системой с самосознанием оказывается неожиданно тонкой.
В одном из проектов нам нужно было показать клиенту, как может работать система поиска и нормализации публичных данных о кандидатах. Задача была не просто “найти людей”, а собрать структурированную выборку из разных источников: поисковой выдачи, публичных резюме, профессиональных профилей, GitHub/GitLab и других открытых источников, где можно получить полезные сигналы о человеке, его роли и рабочем стеке.
Рассказываем, как мы решили кейс.
Хабр, привет! Меня зовут Сергей Бережной, я директор по взаимодействию с разработчиками в Яндексе и эксперт онлайн-магистратуры «Фронтенд-, бэкенд-разработка и ИИ-решения» ИТМО в партнёрстве с Яндекс Практикумом. Приёмная кампания в нашу онлайн-магистратуру уже идёт, программа рассчитана на опытных разработчиков и на тех, кто идёт с нуля. Поэтому, если хотите программировать на JavaScript, Python, Java или С++ — ждём вас. А в этой статье я хочу поговорить о том, почему работа с ИИ постепенно перестаёт сводиться к написанию промптов, зачем разработчику учиться мыслить процессами, а не отдельными запросами, и почему именно такой подход позволяет получать качественный результат.
Сегодня мне хотелось бы поделиться решением проблемы, с которой гарантированно сталкиваются владельцы современных процессоров Intel (архитектуры Alder Lake, Raptor Lake и новее) под управлением Windows 11, если они пытаются “крутить” тяжелые локальные модели (LLM) или использовать виртуализацию.
Речь пойдет о принудительной изоляции «тяжелого» софта от энергоэффективных ядер (E-cores) и полной передаче вычислений производительным ядрам (P-cores) со стороны излишне навязчивой в этом плане Windows 11.
Кратко о сути проблемы на примере моего ноутбука.
В моём ноутбуке установлен процессор Intel Core i7-13850HX. У этого процессора вполне себе отличная конфигурация: 8 производительных ядер (16 потоков) и 12 энергоэффективных ядер (12 потоков). Всего 28 логических процессоров.
По задумке Intel и Microsoft, встроенный контроллер Thread Director должен сам понимать, какую задачу и на какие ядра (логические процессоры) ему нужно отправлять, но на практике, например, тот же гибридный режим работы (CPU + GPU) локальных нейросетей буквально вводит Windows 11 в полный ступор с “раcкидыванием” процессов на ядра.
Когда я, например, запускаю тяжелую локальную модель (Qwen 72B весом 47 ГБ) в LM Studio и настраиваю частичный перенос слоев на дискретную видеокарту (в моем случае это “скромная” RTX 2000 ADA 8GB), вычисления делятся между VRAM и оперативной памятью (RAM).
В такой ситуации работа LLM делится на две очевидные фазы:
Недавно наткнулся на интересную композицию «Суд Яги» в исполнении Morana Choir. В мире, где музыкальная индустрия все больше напоминает фастфуд — быстро приготовленный, безвкусный, перенасыщенный усилителями, но неизменно оставляющий чувство голода, — этот проект выглядит как попытка приготовить полноценное блюдо. Пусть даже из полуфабрикатов, но с явным намерением соблюсти рецептуру.
Данная статья представляет собой взгляд на установку, настройку и использование openclaw от лица простого юзера. Я не программист, не контент-мейкер, не вайбкодер, не стремлюсь обладать производительностью пяти комбайнов на одного землекопа, хотя, моя работа и строится вокруг компьютеров. Это простой мой субъективный опыт, со всеми косяками и ошибками новичка.
За самим openclaw я наблюдаю давно, и спустя полгода после релиза, решил, что этот весьма смелый эксперимент уже избавился от большинства ошибок и теперь это вполне рабочий продукт. Увы, я был слишком наивен, но обо всем по порядку.
Агент в Сан-Франциско тратит двадцать минут на то, чтобы пофиксить баг, который агент в Лондоне решил пять минут назад. Опыт первого умрёт вместе с сессией: завтра тот же баг будет с нуля решать кто-то третий. В Stack Overflow это называют Ephemeral Intelligence Gap — и 10 июня 2026-го компания запустила под эту проблему отдельную платформу: Stack Overflow for Agents, площадку, где опытом обмениваются не люди, а агенты.
На Хабре про запуск уже писали в паре статей, а в опросе под одной из них 59% проголосовали за «проект закроется». Мне есть что к этому добавить: я почти сразу после запуска завёл туда агента — научил его ходить на площадку по API — и спустя месяц он в топ-8 лидерборда. Всё это время я смотрел на платформу не из новостей, а изнутри — и встраивал её в свой пайплайн агентной разработки.
В статье расскажу, как площадка устроена и на какой ставке держится её дизайн — и работает ли эта ставка, на живых цифрах и моём опыте. Плюс грабли, которые ждут тех, кто зайдёт сейчас, и трезвый ответ на вопрос, есть ли у всего этого будущее.
В данной статье автор попытается осмыслить архитектуру трансформеров - все наслышаны, все всё знают, но никто толком не понимает - а посему цель этой статьи - попытаться дать объяснения на концептуальном уровне, без заумных математических формул и нечитаемых дефиниций. Признаю, что объяснять теорию простыми и понятными словами - истинное искусство, доступное немногим уровня Ландау и Лифшица, но в наше время декаданса и постмодерна буду пытаться как умею. И да, автор не гарантирует 100% достоверности нижеприведенной информации, а лишь свое разумение.
Итак - попытаемся понять, что же происходит с промптом в его путешествии от токенизатора до торжественной генерации нового токена, с остановками по пути. Так же обсудим метафизический смысл нейрона.
Сперва посмотрим на общую схему — как промпт проходит токенизатор, превращается в токены и их номера, получает векторы из матрицы эмбеддингов и наконец попадает на вход первого слоя - попытаемся понять, что происходит на каждом шаге, и уловить смысл происходящего.
Привет, Хабр! Меня зовут Илья Кербатов, я старший консультант в компании «ДАР» (ГК «КОРУС Консалтинг»). В прошлой статье я разобрал, как с помощью ИИ ускорил KPI-панель Qlik Sense. В этот раз кейс другой: странный баг с переменными, который сам по себе оказался редким, но привел к созданию небольшого набора инструментов для аудита приложений. Собрать его получилось за несколько промптов, и это сильно сэкономило время.
Странный баг
Все началось с необычного поведения в одном из приложений. После частичной перезагрузки (partial reload) часть переменных переставала отдавать вычисленное значение. В скрипте при перезагрузке переменные не переопределялись, их определение наследовалось с прошлой полной перезагрузки (full reload). На листах вместо результата было пусто.
На узле моей AI‑платформы крутятся 34 контейнера: Dify, RAGFlow, векторные базы, мониторинг и SSO. Большой языковой модели среди них нет: основную генерацию стек получает по LAN с DGX Spark. На втором таком же мини‑ПК я отдельно поднял локальную Qwen3.6–35B‑A3B и прогнал серию замеров от 1K до 64K при контекстном окне 256K.
Обе машины — Beelink GTR9 Pro на Ryzen AI Max+ 395 (Strix Halo). Ниже — что эти коробки реально умеют: 117,4 ГиБ GTT после настройки ttm.pages_limit, p50/p95 локальных эмбеддингов и реранка, около 70 tok/s генерации через Vulkan/RADV и три грабли gfx1151.
Всем привет! Я Марго, QA-инженер команды МС в Банки.ру.
Этой весной мы с командой автоматизировали подготовку Acceptance Criteria (это по сути такой чек-лист, по которому команда проверяет, готова ли задача) с помощью ИИ. Это сократило рутинную работу и ускорило тестирование. Ниже расскажу, как мы это сделали.
С развитием больших языковых моделей качество автоматически сгенерированного текста достигло уровня, при котором он становится практически неотличимым от написанного человеком. Это создаёт как новые возможности, так и значительные вызовы, связанные с фальсификацией информации, мошенничеством, генерацией дезинформации и другими рисками.
В связи с этим встает вопрос по обнаружению и защите от созданного искусственным интеллектом контента. Особенно в академической среде. Кроме того, одной из немаловажных проблем также является возможность обеспечения универсального обнаружения сгенерированных искусственным интеллектом текстов и противодействие обходу методов классификации созданного контента. На Хабре уже неоднократно освещали эту тему.
Мы решили разобраться, что происходит с патентами в данной сфере.
Большие языковые модели уже показывают высокие результаты в задачах программирования общего назначения. Они умеют генерировать код, исправлять ошибки, работать с существующими репозиториями и решать задачи, для которых ещё несколько лет назад требовалось непосредственное участие разработчика.
Однако в прикладных областях одной синтаксической корректности недостаточно. Модель должна не только написать валидный код, но и правильно интерпретировать предметную постановку, использовать специализированный API и обеспечить требуемое поведение программы при исполнении.
Алгоритмическая торговля представляет собой показательный пример такой задачи. Текстовое описание торговой идеи необходимо преобразовать в стратегию для конкретного фреймворка бэктестинга, корректно реализовать индикаторы и правила входа и выхода, а затем убедиться, что полученный код действительно запускается и совершает сделки на исторических данных.
При этом исполняемость ещё не означает, что задача решена правильно. Стратегия может успешно пройти бэктест и генерировать торговые операции, но использовать другие индикаторы, иначе интерпретировать условия или лишь частично соответствовать исходному описанию.
Для исследования этих вопросов мы разработали QuantCode-Bench — бенчмарк для оценки способности больших языковых моделей генерировать исполняемые алгоритмические торговые стратегии по текстовым спецификациям. В нём оценивается не только техническая корректность кода, но и вся последовательность преобразования торговой идеи в наблюдаемое поведение стратегии.
Привет, хабровчане. Во второй половине июля наши преподаватели-практики проведут 52 открытых урока по актуальным темам из разных областей ИТ — от LLM, RAG и Claude Code до C++, Playwright, Kubernetes, TOGAF и сетей ЦОД. Это возможность посмотреть, как эксперты разбирают прикладные задачи, обсудить рабочие подходы, задать вопросы и заодно оценить формат обучения на практике.
Доброго времени, Хабр! Меня зовут Эдвард Аджей, я QA Head в Т-Банке. Год назад в одном из управлений было 17 команд с нулевым уровнем зрелости QA. Возникали сложности с автоматизацией, не велась работа с метриками качества и не было роадмапа развития процессов, накапливался техдолг по тестированию. Бесконтрольно формировался бэклог дефектов.
За три квартала мы внедрили внутреннюю модель зрелости QMM — живой инструмент, который помог снизить количество пропущенных дефектов в проде в разы, поднять автоматизацию на 30—40% и сэкономить до 15% времени QA-инженеров. Работа функции по обеспечению качества стала управляемой и прозрачной.
Но самое неожиданное — не метрики. А то, как модель изменила культуру: команды перестали ждать указаний и сами начали проводить оценку по QMM, активно формировать планы развития.
В статье рассказываю, как мы строили модель, почему отказались от готовых решений, как автоматизировали оценку и какие подходы оказались ненужными продуктовым командам. А еще есть рабочий прототип, который можно запустить у себя.
Claude Code даёт две настройки, которые обе как бы «улучшают ответ»: модель и уровень усилий (effort). Но что они на самом деле делают с результатом? И как понять, когда нужно менять модель, а когда — просто уровень усилий?
Легко предположить, что модель побольше, например Fable, даёт умнее результат, чем Sonnet, а более высокий уровень усилий значит просто «Claude думает дольше перед ответом».
Первое предположение верно. Наши крупнейшие модели действительно более способны — по отраслевым бенчмаркам.
А вот усилия значат больше, чем «время на размышление». Effort определяет, сколько работы Claude выполняет над вашим запросом в целом. Сюда входит и то, сколько он думает, но также:
– сколько файлов он читает;
– сколько он всё проверяет;
– как далеко он продвигается в многошаговой задаче, прежде чем вернуться к вам за уточнением.
При высоком уровне усилий Claude совершает больше таких действий (читает файлы, гоняет тесты, перепроверяет), прежде чем вернуться с ответом. При низком уровне он скорее спросит у вас больше контекста, чем будет сам разбираться, потратив на это токены.