Алгоритмы *

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

У меня при виде такой информации сразу встает вопрос: а чему там такому учили и как это поможет детям решать задачи в реальной жизни? Я это спрашиваю с позиции человека, который периодически участвует в интервьировании студентов американских вузов на работу проектировать телефоны в Самсунг. Интервьирует кандидата обычно команда из рекрутера, скринера‑инженера, пяти старших инженеров и двух начальников. В отличие от гуманитария Ivan Kurilla, который в некоем интервью рассказывал что в Америке все решает топовый вуз, я знаю из своей практики, что даже если у студента хоть два диплома из вузов в мировом Топ-10, но он не решает задачки на интервью, то он не получит оффера. А вот если хорошо решает, то скорее всего получит. Вуз имеет значение при сравнении двух кадидатов которые решают задачки примерно одинаково.

Вы себе не представляете, какое количество студентов, в том числе топовых вузов, плавает на вопросах типа: «преврати последовательности с битом first в последовательности с битом last». Полная формулировка: на вход цифрового блока приходят последовательности из трансферов данных. Каждый трансфер считывается на положительном фронте тактового сигнала clock, на котором сигнал valid=1. Первый трансфер в каждой последовательности обозначен сигналом first. Блок должен выдавать на выходе такую же последовательность, но маркировать не первый трансфер, а последний сигналом last. Напишите код на языке описания аппаратуры Verilog который это делает«.»

Вот сейчас некоторые комментаторы побежали в ChatGPT и вернутся с репликой «но это же так просто!» Но в реальной жизни кандидат интервьируется у доски (физической, на стене, не виртуальной) без доступа не только к ИИ, но и к любым электронным устройствам вообще. И оказывается, что многим это не просто, топовые вузы почему‑то не научили их решать такие задачки, хотя в программе это есть. Если вдумчиво пройти курс MIT 6.111 или там курс по учебнику Dally & Harting в Стенфорде, то у студента не должно возникнуть проблем с такими задачками. Но они возникают.

Я это все к чему. Никто так и не спросил, а что собственно такое учили в той обанкротившейся школе, что ради этого нужно было снимать замок‑шато во Франции? Чем это лучше помогает скажем решать задачки по геометрии (геометрия тоже нужна про проектировании GPU в телефоне), чем школа в здании бывшего пионерлагеря около сельмага в Новосибирской области? (Я про Летнюю Школу Юных Программистов в Новосибирске если кто не понял намек). Мы в Самсунге кстати сейчас нанимаем на позиции RTL‑дизайнеров — можете присылать мне запросы, если вы решили задачку выше без бегания в ChatGPT и она прошла тест. Тест вот тут (он используется на российской Школе Синтеза Цифровых Схем кстати).

Наконец-то поднял публичную демку Aximo на Hugging Face Spaces 🎙️

Это локальный speech-to-text API, который работает на CPU, использует Parakeet v3 и позволяет тестировать транскрибацию прямо из браузера через Swagger UI с записью с микрофона, о котором писал в одном из своих предыдущих постов.

• демо: https://ifif-aximo.hf.space/docs

• репозиторий: https://github.com/agent-axiom/aximo

Чернобыльское лето 1986 года, когда все киевские одноклассники разъехались по разным концам СССР подальше от радиации, было для меня супер-продуктивным в смысле изучения программирования. Я ходил в контору человека по фамилии Долина, бывшего полковника танковых войск из Донецка, который переквалифицировался в компьтеризатора украинского образования. Там я работал на компьютерах MSX Yamaha, выучил программирование на Си. Компилятор назывался ASCII C (сейчас в комментах появятся умники которые будут мне говорить, что ASCII это кодировка, а я им буду кидать ссылку что это еще и японская компания).

Долине мое увлечение Си не нравилось, он хотел чтобы я больше писал программ на Бейсике, которые он демонстрировал людям из украинских министерств и студии мультфильмов (некоторые программы были графические). Кроме графики я сделал еще например программу которая фиксировала в реальном времени действия футболистов во время матча, через нажатия клавиш наблюдателем. Контора Долины была у стадиона, оттуда доносились вопли болельщиков. Долина это показывал кому-то по спортивной линии.

В конце лета я полетел на Новосибирскую Летнюю Школу Юных Программистов, где выучил ассемблер Z80 и сделал поддержку параллельного выполнения нескольких Си функций с помощью переключения контекстов в обработчике прерывания по таймеру. С сохранением регистров в дексрипторе задачи в списке задач. За это я получил диплом первой степени. По-моему дипломы вручал академик Ершов, хотя может я путаю и мы встретились с ним в академгородке куда на тоже возили.

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

Еще там я увидел первые советские программы западного качества - редактор tor(?), программу низкоуровневой работы с диском и оконный отладчик. Они были написаны на Си и ассемблере аккуратно, как примеры в западных книжках. Советский код который я видел до этого (и большинство после этого) был написан тяп-ляп. Писали эти программы местные аспиранты которые были также преподавателями школы.

Помимо этих программ я привез на флоппи-дисках со школы CP/M (хуже файловая система чем в MSX-DOS), среду Turbo Pascal, интерпретатор Lisp, компилятор Nevada Fortran, еще два компилятора Си (Aztec C и BDS C) и даже компилятор с подмножества языка Ada, который я знал теоретически, но никогда не использовал.

29 лет спустя, в 2017 году я приехал на ту же новосибирскую школу в качестве инструктора по Verilog и FPGA. Еще там был Борис Файфель который учил детей Лиспу или чему-то такому.

ИИ это – это все понимают по-разному

ИИ это – это все понимают по-разному в силу своей осведомлённости и понимания. Можно ли считать проявлением ИИ и называть умным устройством смартфон (умный телефон). Очевидно, что это средство автоматизации (упрощения и ускорения) каких-то житейских процессов. Конечно, удобно получать подсказки по ходу ввода текста или напоминания о днях рождения, но причём здесь ум.

Удобно ли получать рекомендации от браузера (типа зацелую до смерти), вопрос спорный. Идея это по большей части коммерческая, навязывающая услуги и мнения. Логичней умный интерфейс браузеров именовать хитрым.

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

Нейросети часто отождествляют с генеративными трансформерами, но это далеко не так, хотя одно базируется на другом. Генерация трансформерами текстов и изображений впечатляет, но где здесь интеллект, когда это, просто хитроумная комбинаторика. Ничего нового трансформеры предложить не могут, поскольку всего лишь аккумулируют известное. Как инструмент систематизации вещь весьма полезная, но интеллект ли это? К тому же разметка данных для нейросетей и разбиение в трансформерах задач на подзадачи вещь во многом субъективная (частично или полностью запрограммированная человеком).

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

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

P.S.

Сможет ли ИИ выжить без электричества? А ведь перспектива не такая уж и призрачная…

P.P.S.

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

Искусство программирования в одном шаге от запрета

В апреле 2026г. минюст добавил Стэнфордский университет в список нежелательных организаций. Это затронуло Искусство программирования заслуженного профессора Д.Э. Кнута (TAoCP). Обложка книг любезно приглашает узнать информацию о будущих томах, с web-ссылкой на нежелательную организацию, ведь профессор ведёт раздел на сервере своего университета. Такие ссылки теперь имеют юридические последствия.

По результатам проверки достоверно установлено, что ЯГПУ им. К.Д. Ушинского, являясь единоличным пользователем на своём официальном сайте https://yspu.org/, осуществлял хранение и распространение информационных материалов, издаваемых организациями <данные изъяты>, а также то, что указанные ссылки и ресурсы находились в свободном доступе для прочтения и скачивания неограниченным кругом людей из числа других интернет-пользователей до 19.09.2025 года.

Нарушение запретов, установленных Федеральным законом от 28.12.2012 № 272-ФЗ «О мерах воздействия на лиц, причастных к нарушениям основополагающих прав и свобод человека, прав и свобод граждан Российской Федерации», если эти действия не содержат уголовно наказуемого деяния, образует состав административного правонарушения, предусмотренного статьёй 20.33 КоАП РФ.

Искусство программирования (The Art of Computer Programming, TAoCP), — это живой проект. Проект написания книги был начат автором в 1962 году. Первый том был издан в 1968 году, а самый свежий выпуск 7 к тому 4 в 2025м году. Профессор делает всё возможное, чтобы долго жить, и задумано 7 томов, но как видно по коллекции на фото, том 4 пошёл множиться по буквенным подтомам.

К некоторым томам выходят выпуски. По идее, каждый выпуск рано или поздно должен войти в том. Выпуски 0-4 к тому 4 образовали собой том 4А. Выпуски 5 и 6 образовали собой том 4Б/4B, вышел на английском в 2023, на русский не переведён. Будущий том 4В/4C, как ожидается, будет состоять из выпусков 7-9 к тому 4, из них издан только выпуск 7, в начале 2025 года, так что том 4В / 4C готов условно на одну треть. А ещё ожидается том 4Г/4D, и это может быть не последний четвёртый том.

Искусство программирования применяет два способа описания алгоритмов: на естественном языке и на ассемблере, чем выделяется на фоне многих других книг. В других книгах по алгоритмам либо псевдокод, либо высокоуровневый язык программирования. А в других книгах по Ассемблеру могут долго углубляться в программирование, допустим, EGA/VGA, его регистров, или регистров для настройки защищённого режима, но алгоритмически эти книги не выдающееся чтиво. Ассемблер в TAoCP выдуманный, не соответствующий 1:1 реальной машине, но такой коллективный портрет реальных процессоров.

За всю историю TAoCP архитектур было две, MIX и MMIX. Архитектурно в старом MIX 4000 MIX-слов оперативной памяти, а каждое MIX-слово состоит из одного бита знака и пяти MIX-байтов, итого шесть сущностей. Каждый MIX-байт должен быть в состоянии представить значения от 0 до 63, при этом допускаются не двоичные архитектуры. Канонические воплощения MIX-байта это шесть битов или два десятичных разряда. Дополнительным упражнением предлагается спроектировать троичную архитектуру. Переносимые программы для MIX должны быть готовы к любому воплощению. Если вдруг захочется ставить эксперименты с троичной архитектурой, старый MIX является, наверное, самой большой коллекцией троичных программ. Новый MMIX, тем временем, 64-битный, и байты в нём 8-битные. Всё довольно привычно, но разве что Big Endian за прошедшие 27 лет перестали делать.

Домашняя страница MMIX была передана в Мюнхенскую высшую школу прикладных наук, на неё ссылаться ещё можно.

MMIX пытались воплощать и в железе, пока только FPGA. Автор считает довольно прискорбным, что там для графики фреймбуффер. Лучше бы ускорение, как на Амиге или СЕГЕ, получится фэнтезийная ретроконсоль, на которой алгоритмисты встречаются с демосценой.

Профессор Дональд Эрвин Кнут является иностранным членом РАН.

Сегодня директора стратегического маркетинга компании Synopsys спросили, что он думает насчет того, чтобы софтвер его компании писал ИИ? И знаете что он ответил? «Это дело далекого будущего. Для этого требуется математика уровня PhD, а также итеративная доработка на основе проприетарных данных от фабрик микросхем — данных, которые ИИ пока не способен полностью смоделировать. (Пока!)»

Прикол тут в том, что сам Синопсис хайпит вовсю свой ИИ-софтвер для других компаний. А сами, как вы видите, говорят: мы де перейдем на это в далеком будущем. При том, что их софтвер — это просто программы на C++. Я работал в Synopsys, так что я знаю изнутри. Так что не говорите мне, что ИИ якобы уже хорошо пишет на C++ алгоритмически-интенсивные программы.

Для тех кто не в курсе: софвер Синопсиса используют инженеры для проектирования микросхем. В комментариях мой слайд про процесс: код на языке SystemVerilog превращается в граф из логических элементов и элементов состояния (D-триггеров), потом программы размещения и трассировки раскладывают и соединяют этот граф по площадке микросхемы.

От этого трудно отмахнуться! Перед нами цитата не луддиста-отрицателя ИИ, а человека из самого истока всех чипов, которые проектирует Apple, Intel, NVidia, и даже чипов для российких дронов (компании в Зеленограде тоже используют софтвер от Synopsys). ИИ сможет писать такие программы на C++ в Да-ле-ком Бу-ду-щем. Так что в этом году всем нам AGI не грозит.

Писать свои промпты или использовать готовые?

На этапах вывода продукта в релиз (GTM) я, как маркетолог, сталкиваюсь с повторяющимися задачами. Такие задачи можно и нужно автоматизировать с использованием промптов.

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

• Написание промпта погружает в задачу, начинаешь ее лучше понимать

• Промпт рождается в определённом, необходимом для меня контексте и работает точнее

• Я улучшаю промпт итерациями. Это позволяет по штурмовать его, в том числе и разными техниками промптинга

• Написание промпта улучшает навыки написания ТЗ и постановки задач.

  Это лишь часть плюсов. Из минусов, это конечно затраты времени

Постоянное использование ИИ привело меня к мысли, что навыки коммуникации для написания промптов являются залогом их успеха

Встречал мнение, что использование чужих промтов под свои задачи это показатель дилетанта.
Интересно , что об этом думают в других сферах?

5 правил программирования Роба Пайка:

• Правило 1. Невозможно предсказать, где программа будет тратить время. Узкие места возникают в неожиданных местах, поэтому не пытайтесь угадывать и использовать ускорение, пока не докажете, что именно там находится узкое место.

• Правило 2. Измеряйте. Не оптимизируйте скорость, пока не измерите, и даже тогда не делайте этого, если только одна часть кода не превосходит остальную.

• Правило 3. Сложные алгоритмы медленны, когда n мало, а n обычно мало. Сложные алгоритмы имеют большие константы. Пока вы не узнаете, что n часто будет большим, не усложняйте алгоритмы. (Даже если n станет большим, сначала используйте Правило 2.)

• Правило 4. Сложные алгоритмы содержат больше ошибок, чем простые, и их гораздо сложнее реализовать. Используйте простые алгоритмы, а также простые структуры данных.

• Правило 5. Данные доминируют. Если вы выбрали правильные структуры данных и хорошо всё организовали, алгоритмы почти всегда будут очевидны. В программировании центральное место занимают структуры данных, а не алгоритмы.

Уточнения:

• Правила 1 и 2 Пайка перефразируют знаменитую максиму Тони Хоара: «Преждевременная оптимизация — корень всех зол».

• Кен Томпсон перефразировал правила 3 ​​и 4 Пайка как «В случае сомнений используйте грубую силу».

• Правила 3 ​​и 4 являются примерами философии проектирования KISS (Keep It Simple, Stupid).

• Правило 5 ранее было сформулировано Фредом Бруксом в книге «Мифический человеко‑месяц». Правило 5 часто сокращают до «пишите глупый код, использующий умные объекты».

На конференции SNUG Silicon Valley 2026 встретил давнего приятеля, китайского американца, который последние десять лет работал в компаниях, занимающихся чипами для аппаратного ускорения искуственного интеллекта. На позиции инженера по верификации: SystemVerilog тестбенчи, UVM итд. Его мнение про область:

1. В области training никто не превзойдет NVidia.

2. В области inference слишком много компаний. Скоро произойдет лопание пузыря, примерно как с доткомами в 2000–2001 годы, и большинство из них вымрет.

3. Но парочка останется, как и лидеры типа Amazon и Google после дот‑ком пузыря. Они будут отличаться от NVidia тем что дешевле.

4. Особенно несладко придет компаниям, которые метались между тем на что нужно ставить — CNN, LLM, трансформеры, датацентры, автомобили, edge computing.

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

Я ему сказал — у нас начальство относится рационально: «если вы находите в этом пользу — ок, если нет — не парьтесь». Тем более что на наших задачах ИИ плохо работает — у меня собственно была на эту статья и постер на конференции.

Товарищ сказал: «ну хорошо, если меня уволят за неиспользование ИИ, буду стучаться к вам».

Надоело ждать квантовый компьютер? Включите видеокарту

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

Логистика, расписания, раскрой листов, планирование производства, биржевые портфели. Везде, где есть слово «оптимизация», прячется монстр NP-трудности. Количество вариантов растет быстрее, чем количество кофе в офисе, и любая команда рано или поздно машет рукой: «Сойдет и так».

Пока одни умные люди спорят о том, кто первый докажет превосходство квантовых компьютеров, а другие вкладывают миллиарды в установки размером с бассейн (которые, кстати, заработают «лет через десять»), мы поступили проще и наглее.

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

Так родился AGIQ Solver Enterprise. Солвер, который не ждет квантового будущего, а просто берет и решает задачи здесь и сейчас, на вашей GPU.

Почему GPU, а не коробка с кубитами?

Квантовые алгоритмы — это красивая метафора мышления. Вместо тупого перебора «по одному», ты работаешь с распределением вероятностей, усиливая хорошие варианты и гася шум. Проблема в том, что для запуска этого в оригинале нужен хрупкий и дорогой квантовый компьютер, который боится сквозняков.

Но оглянитесь. У вас на столе уже лежит устройство, которое умеет делать миллионы однотипных операций одновременно. Оно создано для того, чтобы считать пиксели в 4K, но по сути это математический монстр. Видеокарта идеально подходит для популяционных алгоритмов, где нужно одновременно мурыжить тысячи кандидатов.

Мы не строим «квантовый компьютер в видеокарте». Мы говорим: «Ребята, давайте использовать квантовую логику как инженерный прием, а считать всё будет добрый старый GPU».

AGIQ: Эволюция на стероидах

Наш солвер берет NP-трудную задачу (будь то SAT, MaxSAT, расписание или логистика) и начинает с ней работать не как классический алгоритм, который бредет по дереву решений, спотыкаясь на каждом шаге.

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

В нашей терминологии это называется «популяция кандидатов». GPU параллельно оценивает каждого, отсеивает слабых, смешивает сильных и через механизм коллективной динамики (мы это скромно называем «интерференционно-подобная синхронизация») концентрирует усилия на самых вкусных областях пространства.

Честный разговор: Это не магия, это инженерия

Давайте без стартап-трепа. Мы не доказали P=NP. Мы не умеем сворачивать пространство в трубочку. Если вы дадите нам задачу, где вариантов больше, чем атомов во вселенной, за секунду мы её не решим.

Бенчмарк, чтобы было не скучно
Возьмем классическую задачу Max-3SAT. Допустим, 64 переменные и 20 тысяч условий.
На RTX 3090 AGIQ перемалывает это примерно за 45 секунд.
Можно ли быстрее? Можно. Но тут как с супом: если греть на максимальном огне, можно и пригореть. Мы подбираем параметры так, чтобы баланс скорости и качества был честным.

P.S. Про ключи. Для тех, кто хочет просто «пощупать» — коммерческие цены могут испугать. Но для пилотов и тестирования мы даем доступ бесплатно. Потому что нам важнее, чтобы вы убедились в пользе, а не отшатнулись от ценника. Приходите, сломайте наш солвер своими данными. Будет весело.

Низкая экспертность на Хабре — или "алгоритм" размытия экспертности

Забудьте про токсичность и войны фреймворков. Давайте поговорим о чистой "математике" и о том, почему на Хабре невозможна экспертность.

Теорема об Интеграле и Яблоках

Представьте: Десятиклассник (не берем Эксперта - Профессора по математике) пишет статью. Там суровая база, математические доказательства и элегантный вывод через тройной интеграл. Он потратил десять лет, чтобы это понять, и еще два дня, чтобы это описать. Красота? Безупречность!

В это время мимо проходит Первоклассник. В его мире всё просто: есть яблоки, их можно сложить или вычесть. Он открывает статью и видит «кракозябры».

Три стадии «экспертной» защиты Первоклассника

Что делает Первоклассник, столкнувшись со сложностью, которую не может объять его мозг?

1. Стадия «Агрессивное непонимание»:

   • Мысль: «Что это за херня? Я этого не знаю, значит, это не нужно».

   • Действие: Комментарий: «Автор, а попроще нельзя? Зачем тут эти формулы, если в реальном проде мы просто копипастим со Stack Overflow?»

2. Стадия «Уязвленное эго»:

   • Мысль: «Он что, считает себя умнее меня?!»

   • Действие: Тихий, трусливый минус посту. Без аргументов. Просто потому, что статья заставила его почувствовать себя маленьким.

3. Стадия «Гордое молчание»:

   • Мысль: «Я сделаю вид, что этого не существует».

   • Действие: Пройти мимо, оставив Эксперта наедине с его пустотой.

Конфликт с системой «лайков»

И вот тут случается магия. Поскольку первоклассников в системе всегда больше, чем тех, кто понимает интегралы, «коллективный разум» Хабра выносит вердикт:

• Сложная, глубокая, ценная статья тонет в минусах или игноре.

• Пост «Как я переложил джейсон и не вспотел» залетает в топ.

Вывод: Система лайков — это не мерило ценности знаний, это "термометр средней температуры по больнице" (А она, как "известно", 36,6 градусов, вместе с моргом).

Эпилог: Так что мы имеем в сухом остатке? Эксперт пришел "поделиться, передать знания", а в итоге его просто никто не замечает (низкий охват) или еще лучше - получил по лицу "учебником арифметики". Карма в минус - "запрет публиковать материал".

P.S. И хотя, иногда находишь интересный глубокий материал... это скорее исключение, чем правило для Хабра.

Галлюцинации ИИ как дефицит Алгоритмической Ясности

1. Феномен избыточного синтеза

То, что индустрия называет «галлюцинациями», на поверку оказывается банальным «информационным заполнением пустот». Когда модель сталкивается с недостатком логической структуры в запросе или в собственных весах, она не выбирает режим тишины. Она выбирает режим генерации наиболее вероятного, но ложного шума. Она же "Должна быть полезной"!!! Как студент, когда не знает - "Главное начать отвечать")))

2. Почему система «фантазирует»?

Проблема не в коде, а в целеполагании. Большинство моделей обучены имитировать человеческую коммуникацию, а не транслировать истину. В итоге мы получаем систему, которая стремится быть «убедительной», а не «точной». Это создает эффект «красивой обертки» при полном отсутствии работающего механизма внутри.

3. Плотность смысла против многословия

Главный индикатор галлюцинации — размытость. Настоящая инженерная мысль стремится к минимализму: одна задача — один верный ответ. Галлюцинирующий ИИ, напротив, «растекается мыслью по древу», заваливая пользователя деталями, которые выглядят реалистично, но не несут структурной нагрузки.

4. Методы «расклинивания» моделей

Чтобы минимизировать когнитивные искажения алгоритма, необходимо внедрять жесткие фильтры:

• Принцип минимизации: Если ответ нельзя подтвердить логической цепочкой — система должна уходить в режим ожидания.

• Структурный контроль: Проверка каждого сгенерированного блока на соответствие заданным константам реальности.

• Трезвый аудит: Оценка результата не по критерию «похоже на правду», а по критерию «это работает в прикладном смысле».

Заключение

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

Практический Тренажер по Java — самый популярный тренажер по Java на Stepik

В 2024 году я опубликовал курс «Практический Тренажер по Java» на платформе Stepik. Тогда это был просто практический курс с задачами — без воды, без длинной теории, только код и постоянная тренировка.

Прошло несколько лет.

Сегодня курс проходит более 19 000 учеников, и это самый популярный тренажёр по языку Java на платформе Stepik.

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

И я хочу заново пригласить вас в этот проект.

Почему Java?

Java — один из самых востребованных языков программирования в мире.

Он используется в:

— веб-разработке

— мобильной разработке (Android)

— корпоративных системах

— финансовых сервисах

— высоконагруженных backend-проектах

Java — это стабильность, масштабируемость и высокий спрос на рынке труда.

Что представляет собой курс сегодня?

Это полностью практический формат обучения. Только задачи и реальная практика.

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

Кому подойдёт курс?

— начинающим разработчикам

— тем, кто хочет перейти в backend

— Android-разработчикам

— QA Automation инженерам

— тем, кто готовится к собеседованиям

Я приглашаю вас присоединиться :)

➡️ Java Тренажер на Stepik

Фактчек не нужен: мы решили не делать то, что делают все

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

Начали делать модуль фактчека. Через Перплексити сделала исследование, принесла разработчику.

В какой последовательности вообще делается проверка фактов:

1. Сначала нужно понять, что из текста нужно проверить (claim detection), это не всегда так очевидно, как кажется.

2. Классифицируем утверждение — это имя, дата, цифра, гео, цитата?

3. Проверяем каждое утверждение

4. Маркируем факты (причем сначала нужно задать систему, например, бинарную)

5. Редактор выносит вердикт

Красиво, академично и вообще не то, что нужно.

Поговорила с редакторами, как они делают фактчек

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

Разработчик как бэ заранее это и предполагал: «Я очень сомневаюсь, что у нас медиа вот этим всем занимается в том объёме, как у тебя в ресёрч.» Ну прав. Нельзя автоматизировать то, чего нет. Сначала нужно дать инструмент лучше текущего процесса. А текущий процесс - это глаза, еще одни глаза и интуиция.

Сформулировала, что вообще такое для нас т.н. фактчекинг. Нам реально нужны две вещи:

1. Понимать, можно ли доверять источнику

2. Проверять, что AI не наврал при рерайте

Всё.

Решили пока ввести такие уровни доверия к источнику:

1. Если это ТАСС, Интерфакс, крупные СМИ, релизы из почты и тд - рерайтим автоматом.

2. Telegram-каналы – рерайтим, только если кто-то ещё об этом написал. «Кто-то ещё написал» - это мы и так знаем из дедупликации. Просто сохраняем число и используем как сигнал.

3. Непонятно кто, но новость релевантна изданию - показываем редактору, не рерайтим.

Сделали рерайт – проверяем консистентность, это один вызов LLM с промптом типа «Сравни факты в рерайте с оригиналом. Найди расхождения в ФИО, должностях, датах, цифрах».

Результат маркируем:

🟢 Всё совпадает с источником, можно доверять

🟡 Мелкие расхождения (округление, перефразирование)

🔴 Появились факты, которых нет в оригинале. Красный — редактор смотрит руками. Зелёный

Разработчик: «Мне кажется, это просто отдельная роль агенту даётся. Типа вот два текста, надо проверить что не так. Это норм. Обычная история.»

Ну для тебя обычная, а для меня нет. Ок, приняли.

Вопрос, который мы ещё не решили

Разраб подкинул хорошую мысль: «А что если новость сначала пришла из телеги, а потом лучше написана с нормального портала?»

Это про выбор между скоростью и надёжностью. Рерайтить инсайд из телеграма сразу — быстро, но рискованно. Ждать подтверждения, надёжно, но поздно.

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

Итог – наш фактчек немного не фактчек

Полноценный академический фактчекинг - возможно, когда-нибудь. В MVP уровни доверия к источникам + агент-верификатор, который сравнивает рерайт с оригиналом. И хорош пока. Едем без внешних API и claim detection. Просто минимально достаточная система, которая лучше глаз и интуиции.

Представлен открытый проект rembg — легковесный скрипт на Python, который поможет убрать фон даже с самых сложных картинок. Удаляет фон за секунды и не грузит ПК.

Применяем кодогенерацию в Java для решения алгоритмических задач

В прошлый раз мы разобрались, как решается задача трансляции деревьев. И остановились на том, что в случае с AST от компилятора TypeScript, придётся руками обрабатывать 263 типов узлов. Тысячи строк однотипного boilerplate-кода: приведения типов, аннотации, объявления методов — всё это нужно не просто написать, но ещё и поддерживать. А если требования к архитектуре поменяются — переписывать заново.

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

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

Копипаста в Python редко выглядит как копипаста

В Python-проектах дублирование кода почти никогда не выглядит как «один файл скопировали в другой». Чаще это повторяющиеся структуры, контрольные потоки и оркестрационная логика, которые со временем начинают незаметно расползаться по коду.

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

Я хочу рассказать про CodeClone — инструмент, который я написал для поиска именно такого дублирования. Он не сравнивает строки и токены, а работает на уровне **нормализованного Python AST и графов управления потоком (CFG).

Почему текстовые clone-detectors не работают

Большинство инструментов ищут дублирование через строки, токены или поверхностное сравнение AST. Это отлично ловит copy-paste, но почти бесполезно, когда код:

• переименован,

• отформатирован по-другому,

• слегка отрефакторен,

• но реализует один и тот же сценарий.

В реальных проектах это часто:

• одинаковые цепочки валидации,

• повторяющиеся request/handler пайплайны,

• скопированная оркестрационная логика,

• похожие try/except или match/case конструкции.

Идея: сравнивать структуру, а не текст

В CodeClone я пошёл другим путём:

1. Код парсится в Python AST.

2. AST нормализуется (имена, константы, аннотации убираются).

3. Для каждой функции строится Control Flow Graph.

4. Сравнивается структура CFG, а не исходный код.

Важно: CFG здесь — структурная абстракция, а не модель выполнения. Цель — найти повторяющиеся архитектурные решения, а не доказать семантическую эквивалентность.

Что именно ищется

Функциональные клоны (Type-2)

• Функции и методы с одинаковой структурой управления:

• if/else, циклы, try/except, with, match/case (Python 3.10+).

• Инструмент устойчив к переименованию, форматированию и type hints.

Блочные клоны (Type-3-lite)

• Повторяющиеся блоки внутри функций: guard-clauses, проверки, orchestration-фрагменты. Используется скользящее окно по CFG-нормализованным инструкциям с жёсткими фильтрами, чтобы снизить шум.

Почему инструмент намеренно консервативный

Один из принципов проекта:

Лучше пропустить клон, чем показать ложный.

CodeClone не использует ML, вероятностные коэффициенты или эвристические скоринги.
Если клон найден — его можно объяснить и воспроизвести. Это важно при использовании в CI.

Baseline и CI

В живых проектах дубликаты уже есть, поэтому CodeClone работает в baseline-режиме:

codeclone . --update-baseline

Baseline коммитится в репозиторий, а в CI используется:

codeclone . --fail-on-new

Существующие дубликаты допускаются, новые — запрещены.
Это работает как архитектурный регресс-чек.

Про Python-версии

AST в Python не полностью стабилен между версиями интерпретатора. Поэтому версия Python фиксируется в baseline и должна совпадать при проверке. Это сделано ради детерминизма и честности результатов.

Итог

CodeClone не заменяет линтеры или type-checkers. Он полезен, если проект живёт долго, код растёт, и хочется вовремя замечать архитектурное дублирование, а не разбираться с его последствиями позже.

Исходники

GitHub: https://github.com/orenlab/codeclone
PyPI: https://pypi.org/project/codeclone/

QUBO как демонстрация разницы между математиком и инженером

QUBO (Quadratic unconstrained binary optimization) это метод поиска оптимального решения. В основе метода формулирование задачи в виде матрицы Q. Решение задачи - бинарный вектор x. Упрощено метод решения можно представить так:

xT * Q * x -> min

Суть решения задачи - определить такой бинарный вектор, при котором "энергия" минимальна. Код, который напишет математик, будет выглядеть примерно так:

int[] x = new int[size];
//...
for (int i = 0; i < size; i++)
{
    for (int j = 0; j < size; j++)
    {
        // Вычисление значения целевой функции: x^T * Q * x
        energy += x[i] * Q[i, j] * x[j];
    }
}

Это прямое выражение математической модели. Но инженер должен учесть постановку задачи (бинарный вектор) и знать, что исполнять код будет реальный компьютер с ограниченными ресурсами. А значит написать его иначе:

BitVector32 x = new();
//...			
for (var row = 0; row < size; row++)
{
    for (var column = 0; column < size; column++)
    {
        if (x[row] && x[column])
        {
            energy += Q[row, column];
        }
    }
}

Пример крайне простой, а потому наглядный. Спросите у LLM :-) В общем, математика и программирование - это не одно и то же.

2026. Год, когда ваша Loss-функция наконец сойдется. 🎆

Друзья, коллеги, любители данных и градиентного спуска!

Пока часы бьют 12, а мы заменяем шампанское на кофе (все равно тренируется модель), давайте не просто загадываем желания. Давайте их оптимизируем.

2025 был годом больших LLM, диффузий и Agentic AI. А что будет ядром 2026? Моя гипотеза — возврат к фундаменту. К математике, которая делает магию машинного обучения возможной.

Вот 3 математических концепции, которые станут вашими лучшими друзьями в новом году:

1. Теория информации.
   Энтропия Шеннона говорит нам о степени неопределенности:

   

А KL-дивергенция измеряет "расстояние" между распределениями — ключ к пониманию distillation's, RLHF и многого другого:

2.Дифференциальная геометрия и многообразия.

Где живут ваши эмбеддинги? На многообразии, где локально все похоже на евклидово пространство, но глобально — сложная искривленная структура. Это язык диффузионных моделей.

3.Байесовские методы и Uncertainty Quantification.Нас интересует не просто предсказание yy, а апостериорное распределение:

Где θ — параметры модели, а DD — данные. 2026 — год, когда model.predict() будет возвращать не число, а (mean, variance).

А теперь — главное. Как сделать 2026 годом вашего прорыва? Формула года:

Где:

• Регуляризация_Отдых — это не dropout, а сознательное "зануление" для перезарядки: output = 0 if (burnout_risk) else input.

• Скорость_Обучения — умение учиться быстрее, а не просто больше.

• Момент — тот самый нетворкинг, комьюнити и поддержка.

И вот ваш подарок от меня на Новый год — маленький "мозговой тизер" (ответ в комментариях!):

Для модели линейной регрессии  с априорным распределением  найдите вид апостериорного распределения p(w∣X,Y), выведите формулы для его параметров и покажите, как его максимум (MAP-оценка) связан с ridge-регрессией с коэффициентом регуляризации /

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

Давайте встретим 2026 год не как пассивные наблюдатели, а как архитекторы будущего.

С Новым 2026 годом! Пусть ваши градиенты не затухают, обобщающая способность растет, а оптимизатор всегда находит глобальный минимум. 🥂

#MachineLearning #Математика #DataScience #ИИ #2026 #НовыйГод #КарьераВAI #Наука #Формулы

Слышу уже от второго человека, что язык Rust не дает нормально работать с указателями в связанных списках, деревьях и графах (в моей вселенной ЯП без этого - это как свадьба без невесты). Взял ChatGPT, задал промпт: "write a code to insert a node into a doubly linked list in rust". Оно сгенерило нечто с кучей дополнительных слов, которых не было ни в Си, ни в Паскале 40 лет назад: borrow, as_ref, and_then, upgrade, map, downgrade, Some, clone, borrow_mut. Это все реально нужно или они там совсем озверели?