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

Один доклад сделали уже про то как работает симплекс метод линейного программирования.
Сегодня 24.10.2025 в 16.00 будет следующий доклад.

Кому интересно подключайтесь!
https://telemost.360.yandex.ru/j/60806382544603
Позже выложу запись.

🎓 Метод ветвей и границ: как компьютеры находят оптимальные решения без полного перебора

Что делать, если вариантов слишком много, чтобы их перебрать все?
В ходе лекции мы разберём один из ключевых алгоритмов современной оптимизации — метод ветвей и границ, лежащий в основе промышленных солверов вроде CPLEX и HiGHS.

🔹 Поймём, почему полный перебор невозможен
🔹 Разберём идею ветвления и границ на примере задачи коммивояжёра
🔹 Увидим, как солверы применяют этот метод в логистике, производстве и финансах

Вот запись доклада про метод ветвей и границ от 24 октября.

#текучка #касдев #метод_разрыва
Во вторник скатался в командировку. Нужно сделать аппарат для измерения изделия. Пока разбирался, что и зачем надо измерять срезал им треть работы. Если в деньгах то миллионов на 5-7 наэкономил кажется. В этот проект я все равно не смог влезть, есть уже готовый аппарат который лучше работает. Но мы быстренько придумали и согласовали другой проект. Кажется для того, чтобы я просто продолжал приезжать и помогал разбираться. :))

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

Если этот проект стартанет, что буду еще и железки делать. Говорят что лучше не лезть в хард, но среда вокруг есть и я видел что делать хард конечно сложнее софта писать, но вполне реально.

Младшему ребенку 5.5 лет, попросил научить его читать.
Что делает папа айтишник (иишник) ?
Я сел и написал программу, которая выдает набор слогов или слов. Ребенок читает что-то одно, программа слушает. И если ребенок угадал, то слово пропадает и появляется новое.
С ИИ написал первую итерацию за час, На вторую еще 3-4 часа ушло. В общем очень просто.

ИИ - сила.

Если кому код нужен, пишите. Он на питоне. Скрипт могу просто сбросить. Установщик пока писать не готов.
Чтобы программа слушала - надо нажимать на пробел.

Приехал в Питер поучаствовать в круглом столе насчет ИИ и цифровизации в архитектуре

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

Мне тут прислали новость.

Терренс Тао выпустил знаковую статью о том, как улучшать работу математиков при помощи LLM (AlphaEvolve).
И там есть ссылка на мои работы! Прикольно.

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

Для решения этой теоремы я и освоил оптимизационные методы, а после понял, что если я пишу программы для доказательства теорем, то надо всё таки переставать заниматься математикой.

Очень мне нравится идея функционального подразбиения в системном мышлении. Практически про все можно спросить "для чего оно".
И это сразу ставит всё на свои места. Например относится та или иная задача к классу VRP ( Vehicle Routing Problem). Сам по себе "класс задач" штука размытая. А вот если подумать каким методом и какой библиотекой решать задач, то сразу все становится понятно.

UPD. Как то непонятно написал. Попробую чуть-чуть по конкретней.
Разделение задач на классы, если делается просто так, то оно схоластическое.
А вот если мы решаем что мы будем пользоваться эвристикой для решения VRP, значит эта задача VRP класса.
А если эвристика не подходит и мы ее делаем на MIP или CP солвере, то уже неважно VRP это или нет. Если там какой-то элемент не VRP но мы его через

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

#мысль

Сформировалось определение джун/миддил/сеньор для своей компании.

Джун потребляет внимание.
Сеньор производит или экономит внимания больше чем потребялет.
Миддл производит внимания примерно столько же сколько потребляет.

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

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

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

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

Тоже получилось такое функциональное, а не схоластическое определение.
Оно не универсальное, но для меня то, что нужно.

UPD. Главное не изображать сеньора и не работать молча, если ты не на 200% уверен в том, что делаешь. А то потом приходится доделывать и чинить в сжатые сроки, и это потребляет еще больше внимания, чем просто вовремя спросить.

UPD2. Внимание это время руководителя на задачу.

#ии #прогноз

Давно собирался продолжить писать прогноз изменений на следующие 10-20 лет в мире из-за ИИ.

Получается простыня. Потому просто накидаю тезисы. Может позже раскрою отдельно некоторые.

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

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

3. Вырастет роль уникальных знаний и инфобеза.

4. У России много ресурсов, мы будем скорее в плюсе. Будем следующие 10-20 лет заниматься импортозамещением, автоматизацией производства, кластеры темных заводов.
5. При повышении безработицы увеличится уровень войн и беспорядков. Просто потому, что это тоже занятость человека. Усилятся армии США, Европы. Усилится позиция России как производителя оружия. Турбулентность будет серьезная.

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

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

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

9. Софт будет дешеветь, но рынок вырастет благодаря парадоксу Джевонса.

10. Скорость прогресса определяется скоростью адаптации людей, а не развитием ИИ. ИИ уже забегает вперед. Есть естественные механизмы замедления прогресса. Каждая крупная организация заинтересована в монополизации и сохранении статус кво. Дорогое тестирование лекарств и их лицензирование про это. Мир очень вязкий, потому упорство важнее мозгов. Это относится и к людям, и к ИИ. Правда этот механизм отключается в период войн, а мы как раз в эпохе смены гегемона…

Продолжаем открытые семинары
Следующий доклад будет завтра 21.11.2025 в 16.00 по Москве.

Ссылка на подключение
https://telemost.360.yandex.ru/j/60806382544603

🎓 Метод Branch and Cut: в теории и на практике

Метод ветвей и границ не является панацеей при решении задач дискретной оптимизации.
Современным солверам приходится пользоваться миксом из различными подходов, чтобы быть эффективными.
В ходе доклада мы разберём метод Cutting Plane, который часто применяют вместе с методом ветвей и границ. Эту связку и называют Branch and Cut.

🔹 Мы напомним всю необходимую информацию из предыдущих докладов про LP и Branch and Bound
🔹 Разберем основу метода Cutting Plane, а именно добавление новых ограничений, которые упрощают решение задачи
🔹 Рассмотрим различные способы как генерировать эти ограничения (каты), а также управлять ими
🔹 Приоткроем завесу черного ящика, а именно воспользуемся API солвера SCIP, чтобы собственными глазами посмотреть на добавляемые каты

Через полчаса начинаем https://telemost.360.yandex.ru/j/60806382544603

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

#мысль
Декларативное против императивного.

Поймал тут одну важную мысль.
Языки описания мат моделей для ЦЛП по сути своей декларативные. Это очень крутая, но контринтуитивная штука.
С одной стороны тебе надо просто задать "что" ты хочешь получить, а не "как". И это очень здорово так как алгоритм на базе ЛП более гибкий, Если ты сделал алгоритм/эвристику с конкретным "как" делать, то как только у заказчика изменится обстановка, алгоритм придется переделывать. Скажем высокий сезон прошел и пошел низкий. Конкретный алгоритм так же плохо обобщается. А в ЛП с этим всем красота и благодать.

Но при этом люди не отделяют "что" от "как". Постоянно в ТЗ заказчики занимаются прямым руко-водстмом. Объясняют как делать ту или иную штуку.
Заказчики ладно, им можно. А вот исполнитель хороший, который работает с солверами, должен уметь разделять.

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

Более менее измеримых вещей которые можно сделать я тут вижу две:

1. Думать и осознавать что написание целевой функции для солвера это важная часть работы, чуть ли не главная. Все остальное это просто формальная корректность или оптимизация скорости.
2. Чтобы понять правильно ли сформулирована ЦФ, надо подумать какое солвер может найти максимально бесполезное решение с заданной ЦФ.


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

1. Копай отсюда и до обеда.
2. Я хочу чтобы все унитазы к вечеру блестели.

Приехал в Екатеринбург общаться с коллегами/партнерами. Очень полезно общаться в живую. Уже доволен результатами. Осталось только получить клиента с живыми деньгами

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

1. На этапе прототипа надо рассматривать самое сложное а не простое. Я это называю принципом Ильи Муромца, позже напишу пост.
2. Язык описания данных не должен просачиваться в модель. Между ними надо делать переходник и дальше делать с моделью, что тебе удобно. В одном проекте не стал так делать, и до сих пор огребаю.
3. Если по какой-то установке не надо принимать решения, то она выкидывается из модели. Например труба. Даже если решение есть, например что качать некоторым насосом, то чуть чуть загрубив задачу мы от этого можем избавиться, то это надо смело выкидывать из модели.
4. Заказчику надо делать визуализацию в его формате, а уже потом переходить на правильный. Они уже привыкли и сходу в своем формате все видят. И он может оказаться в чем то и правильней.
5. Абсолютно правильные рассуждения против комбинаторного взрыва. Надо понимать какие решения ключевые и выбирать сначала их варианты а потом все выстраивать вокруг.
6. Тесты

Насчет ЦЛП против перебора. Главное, что победителей не судят. Я видел аналогичные проекты, которые делались подобным подходом и проваливались.
Здесь перебора хватило и прекрасно. CP кажется здесь лучше должен подходить прямого перебора и ЦЛП.

Кажется, что докладчик местами переизобрел велосипед и мог бы воспользоваться готовыми библиотеками, чтобы скажем организовать перебор. Но это просто экономия 10-20% времени проекта, а не рисков. И главное, что проект сделан. И здесь вопрос просто в том, к чему человек привык.

Я бы его все равно бы стал делать при помощи ЦЛП, скорее всего мне было бы легче с перебором, но было бы сложнее с интервалами времени.
Но сложность задачи на глаз такая, что я тоже скорее всего сделал бы. Прямо сейчас сдаем ЦЛП алгоритм для завода с большим числом SKU с более разнообразными заморочками. Правда у нас со временем попроще.

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

Запись семинара

Виталий Черненко (Амальгама), Практическое применение комбинаторной оптимизации на примере задачи планирования молочного завода. YouTube | Дзен | RuTube (~1 час 25 минут).