Я — Максим Цепков приветствую Вас на своем сайте
Now: Коммуникация при различной структуре мышления - таксономия против фолксономии
|
Я буду рад любым комментариям и обсуждениям. Авторизация для этого через регистрацию на сайте или OpenID. При желании, вы можете размещать здесь свои материалы по тематике сайта. MaksWiki содержит 780 статей IT-тематики. | |
Последний пост блогаДва дня был на конференции Joker. Я на ней первый раз – это хардкорная конференция по Java, а на этом языке я не пишу. Но в этом году организаторы сделали отдельный день, посвященный изменениям, которые в мир несет ИИ, с идеей вывести технарей из узкой рамки, в которой они обычно думают о происходящем и взглянуть на мир шире. И они позвали спикерами тех, кто внутри ИТ мыслит широко, а также психологов, педагогов и философов, в число которых я и попал. В целом затея удалась, люди на конференции активно обсуждали услышанное, хотя без отзывов «зачем нам вся эта хрень, где хардкор» и не обошлось. Но от многих я слышал, что они впервые за долгое время разрывались между параллельными выступлениями второго дня, и будут смотреть записи и думать над ними. Отмечу, что сама по себе задача – сложная. Когда ты выводишь человека из узких рамок профессионального восприятия мира, то первая его желание – получить картину устройства мира, которую надо освоить и пользоваться. А такой картины сейчас нет, есть много вариантов от разных И это великолепно получилось на паре проблематизирующих выступлений от организаторов – Алексея Федорова и Андрея Морозова на пленаре второго дня. У психологов получилось хуже, что отражает современное состояние науки, в значительной мере сфокусированной на исследованиях о деградации человечества, а не на построении этого будущего. А вот от практиков из ИТ, деятельность которых меняет мир, были интересные выступления. Я тоже затрагивал тему изменений мира в широкой рамке, хотя фокусом его было осмысление тех изменений, которые несет ИИ в систему разделения труда в ИТ с включением в него ИИ-агентов. Оно так и называлось: «Как организовать гибридную команду людей и ИИ-агентов» – с переходом к агентам ИИ надо перестать воспринимать в качестве инструментов, а начать рассматривать как субъектов, включаемых в команду, которых надо онбордить, оценивать компетенции и растить, обеспечивая обратную связь и обучение. Обзорное выступление по изменениям, когда ситуация меняется ежедневно – не простая задача, но вроде у меня получилось. С наших выступлений я и начну обзор, а потом будут все остальные в некотором порядке, который я посчитал логичными. Технологические выступления будут в конце, я на пару из них в первый день заглянул, но они в отчете представлены не репрезентативно. И это – небольшая часть, параллельно шло три трека, и выбор не всегда был легким. Алексей Федоров. I against AIВеликолепное выступление из позиции размышляющего об изменениях в мире. Которую слушатели тоже могут занять. Не взять готовые результаты, а включить голову и подумать самим. И дальше я попробую пунктиром зафиксировать нить размышлений Алексея. Изменяется весь мир, и ИТ впереди. Я спрашиваю LLM, а в ответ – хрень. И я думаю, что LLM – фигня. А чо в этот момент происходит в голове? У меня есть ожидание, в них я как-то вижу образ результата. А получено иное. Но иное не обязательно получается от робота, это может прилететь и от исполнителя задачи в jira. У него маленькая дочь, 1 год 4 месяца. Когда кормят, она ест-ест, и в какой-то момент говорит «манан» – банан. И тут ты думаешь: с одной стороны – надо порадовать, а с другой стороны, начнешь давать – через три дня только бананы будет есть, они пробовали. И надо как-то решать. Мир человека устроен так: я субъект, вокруг – объекты. И ребенок полагает, что эти взрослые куклы должны ему дать банан, иначе мир сломался. Но потому ребенок вырастает. И мы привыкаем, что мир вокруг не обязательно выполнял то, что мы ожидаем, что для этого надо, как минимум, внятно сформулировать запрос. И в jira пишем цели, задачи, критерии результата – объясню этим дуракам вокруг. С роботом – тоже самое. Сначала был prompt engineering, сейчас SDD и онтологии, контекст и harness: мы пытаемся передать описание того куска мира, с которым работаем, пишем инструкции: как устроен мир, что мы в нем делаем, и как именно. Прошлое и настоящее так можно описать, будущее – нет. Но в какой-то момент то, что работало раньше – больше не работает. Как банковские карты. Я по-прежнему двигаю тикеты, но результата нет. И процесс превращается в ритуал или карго-культ. И в этот момент возникает мысль «может, я не так строю картину мира?» И дальше есть два варианта: одни начинают адаптироваться, менять свою картину мира, а вторые продолжают стоять на ней: «если мои ожидания не совпадают с реальностью – тем хуже для реальности». Те, кто меняют – начинают читать, смотреть вокруг – и одних цепляет какая-то «серебряная пуля» вместо прежнего (как раньше приходил Agile, JTBD). Человек при этом не меняется, он двигает картину мира, но продолжает считать ее единственно верной. А другие – понимает, что его понимание – не единственно верное, и в этой вселенной можно смотреть на мир другими глазами, и другие люди смотрят иначе, а с ними все равно надо взаимодействовать. И это интересно: какую-то критику нашей картины мы принимаем, рассматриваем, а на другую говорим: «хрень какая-то». Если с другим человеком нет ничего общего – то говорить не о чем. А если есть штука, которая объединяет (семья, работа) – то есть о чем поговорить. Ведь другой начнет действовать по-другому, он будет действовать не так как я. И я ему написал как делать – а он все равно будет делать не так, как я написал. Этот этап проходили многие, когда становились тимлидами, и одни попадали в режим микроконтроля, а другие нет, они принимали, что делают иначе, ведь тоже неплохо получается, а иногда лучше меня. Что нас объединяет? Общие установки и ценности, корпоративная культура. Мы видим что-то общее, и это «мы» появляется. Без различения мы и они – невозможно построить я: ты сравниваешь себя с другими. И понимание позиции дает основание действовать. Доверяя другим, мы вынуждены работать с их ценностями и с их набором приоритетов – и они могут сделать то, что для тебя вообще не важно, а им – важно. Удержание противоречий, которые не разрешимы в чью-то пользу, без запихивания другого в свою коробочку, дают возможность развития. Он пришел на старый проект, старожилы запихнули в свою коробочку, отвергли идеи новых технологий. А через три года начали слушать… Другой отличается в силу каких-то причин, у него другой опыт. Я тут хочу заметить, что о том, как учитывать точку зрения другого человека, строить модель того, как он мыслит, понимать, что он тоже строит такую модель про тебя, и вы оба можете ошибаться, есть интересная книжка – «Алгебра совести» Лефевра. Я ее прочитал примерно год назад, и у меня есть подробный отзыв. А сейчас возвращаюсь к выступлению. При чем тут ИИ? Многие смотрят на робота антропоморфно. Робот что-то делает и ты говоришь ему «что ж ты, дурак, сделал». А это – инструмент. Впрочем, с автомобилем или кофе-машиной тоже говорят. А еще обращаются «сделай мне что-то», или «давай подумаем», «что я делаю не так?». А ИИ используют как арбитра: есть три человека, которые спорят, и говорят «сейчас робот нас разрулит». Тут есть две ловушки. Первое. Этот запрос роботу будет кто-то писать, и как напишет – то назад и выйдет. Был прецедент: на 13 человек было 6 ответов из 7 вариантов, потому что люди по-разному описывали ситуацию, задавая вопрос. Второе. У робота есть установки от создателей и опыт, на котором он обучался. Можно ставить робота в позицию «ты опытный java-программист», но ограничено. Возьмем две модели, есть Клод-код, и там если есть противоречия между людьми, он будет отвечать аккуратно в безопасных зонах, чтобы все были довольны. А Палантир, где все воюют со всеми – скажет: иди доминируй. Когда с роботом взаимодействуешь – помни, что технология не нейтральна, что у робота – другая картина мира. И ты можешь потерять субъектность. Когда с человеком – вы это противоречие удерживаете, да и он спорит. А робот – он спорить не будет, но все равно он на тебя влияет. Замечу, что тут появляется есть интересный вопрос: а как можно сделать ИИ частью «мы»? Ведь он создан кем-то, где-то там. И постоянно обновляется, выходят новые, дообученные версии, в рамках которых установки меняются. Мы пишем harness – но многие ли пишут в этот harness ценности компании и команды? Хотя представления о хорошей архитектуре и коде – тоже ценности, но обычно этим уровнем ограничиваются. А проекты – они же не только про код, но и про людей. LLM обрабатывает интервью и совещания, пишет письма заказчикам… В общем, есть о чем подумать в практическом залоге. Андрей Морозов. Мир без опорыВ конце вьетнамской войны американцы решили классифицировать скиллы. Положили разделение: с железом или с людьми. Но парамедик работает с людьми, а похож на морпеха – по регламентам. А управленцы работают с документами, но реально – с людьми. Поэтому деление изменилось: действуешь по инструкции или свободно. Винер полагал, что робот гвозди забивать будет, а писать картины – нет. Но стало не так. Если LLM дойдут до предела – нам, людям что-то останется? Я хочу открыть шаурмичную. Чтобы решить, где делать, LLM не нужна, я могу получить ответ за счет больших данных. А вот чтобы сделать конференцию с философским уклоном? Или позвать социологов на конфу технарей. Робот посоветует, напишет план действий. Но может ли робот взять ответственность? Готов ли я дать такую ответственность? Я тут хочу рассказать историю, которую услышал в кулуарах конференции. Есть лингвист, занимается редкими языками, у которых осталось мало носителей, ездит в экспедиции. И она зафиксировала новое явление: раньше, когда она спрашивала про какое-то слово, с которым у собеседника были затруднения, то собеседник спрашивал старших. А теперь начал спрашивать Алису и воспроизводить ее ответ. И тут вопрос: что Алиса знает про этот редкий язык? Или она фантазирует? Ведь эти фантазии воспроизведет носитель, а потом зафиксирует научная статья… Умный дядька спланировал и говорит роботу «давай делай». Человеку говорят «делай», ему приносят не то, и только в этот момент он лучше понимает, что он хотел. А теперь LLM. Настроили LLM, бэклоги стали короткими, а ценность не выросла. Оказывается, задачи лежали не для того, чтобы делать – а чтобы спорить, грумить, ругаться. Некоторые CEO считал себя гением, раньше его критиковали – а теперь LLM делает без обратной связи. Такой маленький диктатор в эхо-камере, которая обслуживает его хотения. Поэтому важнее не сформулировать промпт, а сформулировать свои желания. Если говоришь роботу «что-то сделай» – то он скажет, что хочет окружение. Разработчика мы нанимаем в компанию. А таксист в Яндексе – снаружи. Потому что таксистам можно связать регламентами, а разработчика надо погружать, онбордить внутрь, Он узнает, что некоторые задачи живут не в jira, а в чате, что начальник один, но еще надо советоваться. Что такое ответственность или власть. Архитектура проектируется с языка. А регламенты часто складываются исторически. А потом еще это засовываем в бизнес. И считаем, что пойдет все хорошо. Мы сами выбираем мир, в котором будем жить. Люди смотрят на одно и то же, один видит возможности, а другой – риски. Как изменить картину? Переехать. Представьте, что ты настроил робота, который блокирует тебе все сообщения от друзей, которые зовут выпить пиво. Ты сам строишь камеру своего окружения. Можете ли вы так, хотите ли вы так? Когда-то всех разработчиков заставляли учить ассемблер. Потом оказалось, что их можно упаковать в языки. LLM – еще один черный ящик, который повышает абстракцию. Никакой разницы. Есть возражение, что LLM – не детерминировано, и поэтому надо валидировать. Но тут есть подвох. Если ты вникаешь в то, что сделал LLM – ты ничего не экономишь. А если не вникаешь – рискуешь попасть в ловушку: студент приносит преподавателю работу, специально сделав в начале ошибку – и все обсуждение цепляется за нее. LLM не хитрит так, но она сделана на какому-то контексте, она зафреймлена – и она в ответе передаст вам фрейм. А значит вы должны коммуницировать с ней как с субъектом, и выяснять, что этот субъект может сделать, а что – нет. Как спросить у ИИ, что она может? Так же, как у чловека. Можешь ли ты общаясь с ребенком или с сотрудником не фреймить его мгновенно, а разбираться, спрашивать? Лет пять назад любили говорить про VUCA-мир. Мы, инженеры, можем решать сложные задачи. Но нам нужна определенность и границы, за которыми работают другие. А теперь очень часто этой определенности нет. Можно ли говорить, что прилетают черный лебедь, когда это каждый день, когда мы живем в озере в ними. Инженер говорит: ты хаос и сложность превращаешь в алгоритмы и живешь в понятном мире. А философ говорит – тебе надо жить в таком мире. Максим Цепков. Как организовать гибридную команду людей и ИИ-агентовС переходом к агентам имеет смысл перестать воспринимать ИИ как инструмент, а начать рассматривать агентов как субъектов, включаемых в команду: их надо онбордить, оценивать компетенции и растить, обеспечивая обратную связь и обучение. Обзорное выступление по изменениям, когда ситуация меняется ежедневно – не простая задача. У меня в мае была статья «Об организации труда ИИ-агентов», но дополнения к ней появились почти сразу. Но я попробовал и вроде у меня получилось. Презентация выложена на странице выступления «Как организовать гибридную команду людей и ИИ-агентов», а здесь я зафиксирую краткие тезисы по содержанию.
Святослав Морошкин из Сбер. Роботы: маркетинг или реальность?Это был рассказ про многослойную архитектуру управления роботами. В котором было много впечатляющих роликов про достижения роботов – они не просто ходят, а делают сальто, танцуют, выполняют операции упаковки и выдачи подарков и так далее. И, что важно, это не ролики чужих роботов, а достижения центра робототехники Сбера. В рассказе были андроиды, но есть разные формфакторы, и у Сбера тоже – они с Самокатом работают с робособаками для доставки. Слои архитектуры робота.
При этом на каждом уровне – свои модельки, и фронтирные модели – не специализированные, могут подключаться к разным роботам без дополнительного обучения, выясняя его возможности и особенности по массе и геометрии и дальше – управлять. Протоколы управления и видеопотоков – стандартизированы. Он считает, что купить робота можно будет уже лет через 5-7, а может быть и раньше. Я тут согласен ,потому что Китай массово взялся за задачу апробации роботов для ухода за больными и стариками, уже год идет апробация в больницах и домах престарелых: робот помогает чем может и умеет звать на помощь, и его умения можно увеличивать. Используются промышленные модели, которые стоят 40-100 тысяч долларов, поставлена задача снижения стоимости до 20 тысяч и несколько компаний разворачивают производство. Евгений Лукьянов. Маленький человек в эпоху больших языковых моделейЕвгений – технический директор Tamga digital – разработчики банковского софта. А вступление состояло четко из двух частей. Сначала был стандартный набор страха перед ИИ и неопределенностью, из-за которых некоторые люди хотят уйти в тайгу, построить землянку и так жить. В метафоре маленького человечка, который в ужасе перед надвигающимся будущим. При том, что от него требуют это будущее принять и в него встроиться: компании повсеместно внедряют ИИ, или хотя бы сделать вид что внедрили, чтобы соответствовать современным трендам, признаваться, что не получилось равносильно самоубийству, требуя результатов от разработчиков, которым в лучшем (или худшем?) случае дадут кого-то, кто еще вчера двигал блокчейн куда можно и куда нельзя, а теперь переключился на новый тренд. И говорят: «ИИ будет генерить весь код, критичный тоже, отвечать будет разраб, пусть его научит, а потом мы этого разраба выгоним» – потрясающая мотивация. Но все эти ужасы явно были не про них самих, а про кого-то еще. Потому что во второй части был конструктив: как они вполне успешно встраивали ИИ в рабочий процесс. А в состоянии ужаса и стресса созидательный конструктив сделать невозможно. Они всегда работали на результат – не написать код, а решить проблему заказчика, всегда стремились, чтобы инженеры так делали. Ключевой навый тут – хорошая коммуникация с заказчиком, поэтому на этапе сбора требований, исследования предметки и проектирования ИИ помогает не сильно. Он помогает разобраться, если предметка совсем новая, но специфики заказчика он не знает. Может рисовать мокапы интерфейсов. А вот проектные решения у него часто переусложненные или наоборот, излишне простые. А вот когда проект уже разделен на ограниченные контексты, как велит DDD, то в их рамках ИИ неплохо делает реализацию. Особенно для типовых частей, если написать правила. Тут имеем громадную экономию сил и времени. И небольшие библиотеки у него тоже получается делать, а потом использовать – после того, как их выделили в проекте. По шаблонам ИИ работает очень хорошо. Так что ключевой навык разработчика – видеть границы модулей, хорошо декомпозировать. Еще ИИ хорошо делает проверки. Жесткие правила все равно лучше возложить на статический анализатор, но ИИ может проверить и менее формальные вещи, например, что в тесте нет методов, которые порождают данные, то есть соблюдена изоляция логики тестов от данных. ИИ может порождать тесты, надо контролировать качество, надо контролировать, когда ИИ переписывает тест за реализацией, чтобы он стал зеленым. Реализацию разработчики проверяют, но по-разному: бизнес-логику проверяем всегда, query доверяем ИИ, адаптеры – чуть пожестче, чем query. Важны метрики сцепленности кода. Вайбкодинг часто заканчивается не очень удачно по отношению к сложным системам. Есть Геннадий Круглов – он занимается исследованиями в сфере ИИ, и у него концепция восходящей спирали энтропии: связность – цикломатическая сложность – когнитивная перегрузка – ИИ начинает хачить, подгонять тесты. И метрики позволяют понять зоны риска. Миграция – ИИ может написать криво при обновлении под нагрузкой, тут ничего нового, надо следить. Тут и разработчики косячат. ИИ может помочь, написать скрипты, в том числе анонимизация для тестовых стендов. Чуда не произошло. Получили хороший прирост производительности, но и раньше у нас было неплохо. В целом результат неплохой, трагедии маленького человека не произошло. Все что делали – ограничивали глюки. И делаем абстракцию, чтобы можно было доверять. И самое интересное остается инженерам. Труднодоступное знание – по-прежнему в цене. Stack Overflow хоронят, но он по-прежнему живет, вопросов стало меньше, но они стали сложнее. Пока все ускоряются с ИИ, можно выиграть, просто не перестав думать. Не превращайтесь в оператора LLM. Откуда возьмутся профессионалы, ведь все это – для опытных? Нужен упор на базу – как разработка работает целиком, как методологии связаны между собой. Связей много – нужны тесты, CI/CD и многое другое. За 17 лет не поменялось ничего. Когда пришел стажером, все искали серебряные пули, и продолжают искать сейчас. ИИ пару лет, но принципиальных изменений в мире нет. И у вас есть шансы над этим подходами подняться. Полезно заглянуть внутрь – как LLM устроена, как она думает (биология моделей) – есть книги и исследования. И построение онтологий для управления контекстом. Метод меньше думать, больше делать: берете рабочую проблему и пробуете решить. Увидели проблему, разбежались, расшиблись, пошли читать – из чего стена устроена и как ее разбить, и следующая попытка. Кирилл Ветчинкин. От станка к чертежу, от кода к модели: повторяет ли IT историю XX века?Кирилл пытается разобраться, какая судьба в будущем ждет нынешних опытных разработчиков, на исторических аналогиях промышленных революций. Правда, история у него сильно свернуты: сначала появились мануфактуры и фабрики и пришла индустриальная эра, а в 1960-х, станки с ЧПУ открыли эру информационную. В любом случае происходило следующее: старое мастерство обесценивалось, и мастера-ремесленники шли на фабрику, а рабочие начинали нажимать кнопки на станке, и это была трагедия. А потом появлялось поле для нового мастерства – умение работать на станках, умение их программировать. Так будет и сейчас, потребность в мастерах написания кода уходит, тем более специализированных, и перед ними есть две дороги. Первая – осваивать предметную область и становиться разработчиком-универсалом, который умеет общаться с бизнесом и закрывает с помощью ИИ разработку продукта полностью, используя активно скиллы. При такой разработки пропадают внутренние очереди, ожидания специалистов. Их в свое время попробовал убрать agile, создав кроссфункциональную команду, но получилось не везде, а внутри команд специализация все равно осталась. Теперь их убирают полностью. А если ты крутой технарь и не хочешь осваивать предметку, то можешь заняться переводом своих умений в скиллы, которые будут использовать продукты, и поддерживать систему разработки технологически. Реальность ИИ наступила, вопрос в готовности к ней и выборе своего пути.
Рroduct Owner тоже хочет писать код. И он – пишет, чтобы проверить гипотезу за пару дней вместо пары месяцев. Мы страдали, он страдал. А сейчас – он сделает. Продукт проверяет гипотезу, ему поставляет центр компетенций – и то, что выстреливает ,продуктовый разработчик доводит до продукта. Итог. Разработчики-кентавры. Есть фундаментальная экспертиза, остальное – за счет скиллов. Мастер в паре с ИИ работает мощнее чем каждый по отдельности. Интеллектуальное оставьте себе, рутину отдайте ИИ. И как фитнес: когда-то человек бегал для жизни, а сейчас нужен бег и прогулки, чтобы обеспечить здоровье. Виталий Соболев. До промпта: из какой рамки мы ставим задачи ИИВыступление о том, что у каждого из нас есть рамка, которая ограничивает наше мышление. Часто мы ее не замечаем. И когда мы ставим задачу агенту ИИ, то мы постановкой задаче задаем рамку, в которой он будет эту задачу решать. А надо уметь увидеть свою рамку и ее ограничения, и посмотреть на задачу иначе. Например, продукт плохо продается – мы придумываем гипотезу о проблеме, и дальше фокусируем агентов на ее решении. И они не выходят за пределы. Есть workflow Событие – Интерпретация – Рамка – Намерения – Задача – Команда ИИ, и когда ИИ подключается после формулировки задачи, то он мыслит ограниченно. Даже если вместо одного агента мы создали целую команду, это не поможет выйти за рамку. В общем, все верно, но для меня тут проблема сосем в другом: люди, которые работали на начальных этапах почему-то не обратились к ИИ, дошли до задачи собственным мышлением. Потому что формирование рамки происходит на этом этапе. Роберт Киган. Есть вещи, на которые я могу посмотреть, а есть те, через которые я смотрю и их заметить сложнее. Это моя картина мира. Дело не во внимательности, иногда эти допущения и организуют происходящее. Важны не два типа вещей, два отношения к одной вещи. Subject – когда я смотрю на ситуацию, а Object – когда могу посмотреть на мир и себя, свою рамку, и выбрать. Рамка – штука полезная, но важно выбирать. Отмечу, что тут надо быть аккуратно с терминологией. В данном случае subject и object – не про субъекта и объект, а про субъективное и объективное. И я не очень понимаю, отличается ли объективное от выхода в рефлексивную позицию, когда ты смотришь на себя и свои действия в мире снаружи. Выходу за рамки часто помогает формулировка: меняем «у пользователя проблема Х» на «мы думаем, что Х – основная проблема», то там, где очевидность – появляется выбор. Универсальная рамка невозможна. Так что стоит замедляться и спрашивать «почему я так вижу задачу». P.S. Я уходил с выступления и слышал его не полностью. Так что если тема вам интересна – смотрите запись. Александр Диденко. Граница между символическим и статистическим интеллектамиЭто был рассказ о том, как в LLM, первоначально основанный чисто на весах генеративного алгоритма, добавляли рассуждения и другие средства, повышавшие качество мышления ИИ. Я слушал не с начала, так что в конспекте кусочек может отсутствовать. Дальше – краткие этапы.
Владимир Спиридонов. Критическое мышление в эпоху ИИВладимир – доктор психологических наук и профессор, И он рассказывал о том, что думает современная мировая психологическая наука о влиянии ИИ на когнитивные способности человека. С моей точки зрения, ничего интересного и особо содержательного она не думает. Одни ученые ставят эксперименты, чтобы показать, что человек поглупеет под влиянием ИИ, и потому его надо взять под контроль. Почему я думаю, что цель такова? Дело в том, что ряд экспериментов явно имеют и позитивную интерпретацию: человек не поглупел, а расширил спектр своих возможностей с помощью ИИ, но выбирают всегда интерпретацию «поглупел», потому что на это, думаю, есть социальный заказ от властных групп, которым поумневший человек не нужен. А потом другие ученые их проверяют и уточняют, и часто оказывается, что ничего страшного не происходит, что с помощью ИИ можно поумнеть, а можно – сэкономить свои когнитивную нагрузку, и это – вопрос выбора человека, хотя не всегда осознанного. Но при этом первоначальная оценка «караул, все поглупеют» – не снимается. Кстати, замечу, что ни один из ученых не заявил «я начал использовать ИИ и поглупел», они все заботятся о каком-то абстрактном народе. Это очень хорошо проявлялось в вопросах, когда приводили конкретные примеры, а на это был ответ, что умным людям не страшно, а вот народ поглупеет. Я тут отмечу, что этот народ неплохо живет с нынешним телевизором, пропагандой и рекламой. И, кстати, не только у нас, мы иногда включали телевизор, например, в Греции, и обнаруживали, что наши новости по сравнению с теми – кладезь содержания. Так что, думаю, ИИ народу не грозит. Но вернемся к выступлению. Я буду комментировать, но постараюсь четко отделить речь спикера от своего мнения. Еще в 2015 были исследования, что люди не помнят телефоны детей, кидаются искать факты в инете и так далее. Это подавали как тревожные деградации памяти. Я тут считаю иначе. Телефоны вообще никто не учил специально. Просто когда ты его набираешь цифрами – он сам запоминается, так устроен мозг, и потом тебе не надо искать в записной книге. А когда выбираешь в телефонной книге, то этот процесс исчезает, вот и не запоминаешь. А то, что люди ищут факты – наоборот, свидетельствует о любознательности. Раньше, когда что-то заинтересовало – ты все равно проходил мимо, потому что надо же найти книгу, прочитать. А теперь есть шанс простым образом эту любознательность удовлетворить, и это – хорошо. Это делают просто в разговоре, в ответ на случайно брошенную фразу или упоминание какого-то персонажа, и не только ИТ-шники – я с разными людьми общаюсь. Системы хорошо проходят тест Тьюринга, с инструкциями «будь как человек», даже слабые – были графики. Что интересно, студенты в разы чаще ловят ИИ за хвост, чем специалисты по ИИ. С моей точки зрения, это как раз против деградации. ИИ залез в психологию, когда он влияет на рынок услуг психологов. В Штатах в трех штатах был запрет. Было пара раз, когда ИИ дал советы, которые пошли к самоубийству. ChatGPT сдал медицинский тест, получил лицензию адвоката, сдал вступительные экзамены в Токийском университете. И много других подобных фактов. Я тут дополню, что было исследование, что ИИ-психологи лучше воспринимаются людьми, достаточно репрезентативное: там люди (почти тысяча человек) проходили сеансы психотерапии, не зная, будет ли им отвечать ИИ или человек. А потом пациент оценивал качество сеанса, а также отвечал, с кем, по его мнению, он беседовал: с ИИ или человеком. И наивысший балл получили сеансы, в которых отвечал ИИ, но пациент думал, что беседует с человеком. А за ними на равных шли ИИ, о которых думали, что это ИИ, и люди, о которых думали, что это люди. А низший балл был у живых психологов, которых приняли за людей (первоисточник). Естественно, психологи не могли на это не ответить другим исследованием, но оно совершенно плюшевое – там психологи-эксперты оценивали, кто лучше опишет кейс – человек или ИИ, и дружно решили, что человек справился лучше. И все это – далекий 2025 год, с тех пор все ушло вперед. А что касается суицидов, так и беседы с людьми к ним приводят, и даже с психологами. Но вернусь к выступлению. В математике – ошеломительный прорыв, когда несколько разных LLM сделали сногсшибательные продвижения, по списку Эрдёша. За последние три недели решено 8 задач, и новости каждый день. А еще понимание структуры простых групп, и язык для формализации математических доказательств, чтобы их проверял ИИ. Работает ИИ вместе с человеком. Вопрос, насколько ИИ влияет на нас: «насколько глубоко ИИ влезает к нам в печень». Студенты у него используют ИИ, а потом специально портят тексты, чтобы он не догадался. Исследование Google Effencts on Memory (Sparrow 2011). Можно было запомнить, или еще записать. И все, кто записывали – просто запоминали путь, куда записали. Я лично тут не вижу проблемы – люди используют цифровой экзокортекс, чтобы разгрузить свою память – как советует громадное количество книг, которые появились еще в эпоху пера и бумаги: записывайте, а не запоминайте. Тем более, что проверка еще показывает, что профи-врачи так обращаются только с не специфической информации, а в другом исследовании – что так делают только, если есть уверенность в доступности гаджета. На эти исследования были ссылки в выступлении. Работа про когнитивный долг, когда три группы людей просили написать эссе, одни делали это с с ChatGPT, другие – с Google, а третьи – без источников, из головы, и потом выяснилось, что те, кто делали с ChatGPT забыли мгновенно, те, кто с Google – помнят дольше, а те, кто писали из головы – помнят хорошо. Кстати, этот кейс был не только в этом выступлении, и там про группу с поисковиком не говорили. Владимир сам говорит, что к эксперименту у научного сообщества куча вопросов, препринт так и не стал статьей. Я не знаю, что конкретно говорит научное сообщество, но с моей точки зрения такой эксперимент показывает только одно: человек успешно может создавать новое с помощью ИИ, не нагружая свой мозг. Ведь задачей было сделать эссе, а не изучить предмет – и оно выполнено. Ну и понятно, что те, что писали из головы, при написании создавали связи между уже имеющимися материалами из долговременной памяти. А использующие Google или ChatGPT – загружали это в кратковременную, обеспечивая связность изложения, что не требует большого погружения. То есть на уровне нейропсихологии результат очевидный. Вообще одна из проблем современной психологии в том, что ученые упорно отказываются пересобрать свою науку с учетом достижений нейропсихологии. Именно поэтому я несколько лет назад попробовал сделать это сам, написав книгу «Инженерная модель личности», хотя предпочел бы получить это от профессионалов. Когнитивная разгрузка. Снижение нагрузки за счет делегирования задач внешним предметам снижает когнитивные способности – исследование 2016 по атрофии профессиональных навыков – у врачей-эндоскопистов. С моей точки зрения, это явление того же порядка, что и с номерами телефонов, которые мы не помним. Конкретный когнитивный навык перестали тренировать – и он отсутствует. Это как говорить, что бывший спортсмен деградировал физически, после того, как прекратил профессиональные тренировки и участие в соревнованиях. Обычно бывшие спортсмены находятся в хорошей форме и держат ее, хотя пробежать на рекорд уже не могут. А по поводу критического мышления – противоположные мнения: одна работа говорит, что его навыки снижаются, а другая – что активное использование ИИ в поисковом режиме, наоборот, его повышает. Отмечу, что тут – та же направленность: в первой работе вопль «караул, мы поглупеем», а вторая лишь добавляет, что «не все», хотя правильный акцент: «как захочешь – так и будет». Крейк и Локхарт «Теория уровней переработки информации», 1972. Память – побочный продукт переработки информации. Тут я бы поспорил, потому что память – это то, что позволяет животным накапливать опыт, например, о перспективных местах поиска пищи, а у млекопитающих – перейти от передачи опыта через геном к научению родителями. То есть запоминание было основной функцией. Хотя на уровне hardware верно то, что, в отличие от компьютера, где процессор и память разделены, в мозгу нейрон одновременно запоминает и вычисляет, это две неразрывных функции. И в заключении – список того, что нельзя делегировать ИИ. С очевидной оговоркой, что мы все равно будем делегировать, но надо быть осторожным. Владимир Красильщик. Как внедрить агента и не потерять людей, время и деньгиВладимир консультирует компании по внедрению LLM и рассказ был как раз о правильном подходе: надо выбрать площадку и провести пилот, результатом которого должна стать не только команда, в которой освоили LLM и успешно его используют, но и сотрудники, которые разобрались с LLM и готовы распространять, нести его другим. В целом мысль правильная, но в рассказе много теории, еще не подкрепленной практикой успешных внедрений. А теперь – подробнее. Сопротивление LLM и агентам. Это не новая история, новому сопротивляются – C, C++, Java, IDE с подсказками, NoSQL, микросервисы и так далее – всему сопротивлялись. Потому что когда пытаются втюхать – становится страшно. Я – эксперт, и тут тебе говорят «перезжай на Rust (и стань джуном)». Для успешного перехода надо предложить что-то, чтобы переход на следующий этап был комфортный. Недавно был на YandexScale – там рассказывали опыт внедрения ИИ в машиностроении. Проблемы – аналогичны ИТ. Личная история с LLM в 2025: все вокруг там были, а он сопротивлялся. Ребята восторгались, он взял ChatGPT для какой-то задачи, тот не решил – и забил на это. Но недавно вышел на работу, а там внедрение по площади – коммиты должен делать ИИ. Как-то освоился, но был жесткий стресс. И когда ему предложили присоединиться к команде, которая внедряет ИИ в компаниях, то он согласился, но у него идея – заходить постепенно. При ИИ есть наблюдение. У него хобби – музыка, дома почти полная студия. И в конце обучения аранжировкам он прошел мастер-класс по suno.ai. Увидел – он делает хиты высокого уровня, и впал в депрессию: suno за 5 минут делает кучу вариантов аранжировок, на которые у него уходит много времени. Но он общался с преподавателем – начал вслушиваться, и всегда что-то не устраивает. И в результате suno.ai – не инструмент для готовых треков, а штука, чтобы обсудить. Восторг от ИИ редко исходит от профи. Я тут вставлю замечание, правда не про музыку, а про тех, кто делает видео – фильмы, ролики и так далее. Профессионально, я слушал разных людей на разных конференциях. Они видят проблемы в том видео, которое создает ИИ, но умеют в ними бороться. А вот стоимость и сроки создания продуктов уменьшились на порядки, видео можно создавать без актеров и без дорогой технике, обеспечивать спецэффекты, которые раньше были недоступны. И в результате рынок потребителей тоже расширился, раньше сделать 10-минутный игровой фильм стоило дорого, а теперь это бюджет подарка на юбилей. Первый шаг внедрения ИИ – провести короткий пилот. Надо выбирть проводника в эту сферу – ментор или курс или консультанты. И выбрать конкретные проблемы, которые хочешь решить. Важно сразу договориться о метриках и критериях успеха, и делать регулярные замеры. Команда пилота – из энтузиастов. Главная задача – взрастить ИИ-чемпионов – тех, кто оторвались и набрались опыта. Не надо резко начинать использовать ИИ постоянно – достаточно 2 часа в день. Но это время надо выделить себе и людям. Важно решать с агентом боевые задачи, а не учебные. Пилот – не длинный, и желательно, чтобы команда участвовала без отпусков и командировок. Начинается с полноценного обучения: ставим агента, подключаемся, делаем контекст и так далее. Пытаемся решать на базовом функционале – и только потом кастомизация: контекст, скилы, rule. Методологии на первом этапе – ИИ-помощники: SDD/TDD и так далее. И только потом – агентская система. Не раньше. А очень часто начинают с задачи «сделай агента – клон разработчика». На пилот зафиксируйте тип и набор моделей на пилот. Иногда можно ошибиться – тогда нужен перезапуск пилота. Определи начальные квоты модели, иначе можно случайно вынести весь бюджет, не понимая что делаешь. Иногда принимают решение: давать джунам меньше, чем сеньорам, но оно – спорное: у джунов часто рутинные задачи, и они как раз классные для LLM. Мониторинг метрик для использования агентов: что делают с ИИ, какие успехи, что не делают с ИИ. Какие инструменты вызываются, какие – нет. Среднее число кода с ИИ. Хотя про среднее число кода была забавная оговорка: «среднее число кода с ИИ ничего не значит, но его надо бы знать». Вопрос: а для чего его знать, если оно ничего не значит? Еще бизнес любит цифру «а сколько бы решал человек без ИИ», но не готов запустить решение человеком и с ИИ параллельно на большом потоке, да и возникает вопрос, что люди-то работают разные. Но тут нашли способ: попросить саму LLM оценить, за сколько задачу бы сделал разработчик. Но надо аккуратно, а то получаются феерические результаты. Я тут замечу, что если в командах была поставлена система оценки и есть накопленная статистика, то не должно быть проблем с оценкой по аналогии на основе старого потока задач. Другое дело, что в корпорациях с оценкой и планированием все часто обстоит не благополучно. И был dashboard – показатели и их изменения, и примеры, что сами по себе метрики ничего не значат, они дают сигнал, с которым надо разбираться. Оцени результаты пилота и прими стратегическое решение. Часто это экспертная оценка. Одним командам нравится ко-пилот, но не нравится модель, или наоборот – перезапуск. Надо не просто принимать решение о тиражировании, но и понять, что именно будем тиражировать. Экономика – самая сложная неприятная вещь. Модели стоят дорого, разработчики не приучены считать деньги. Каждый разработчик – как компания: делаю сам, субподряд или комбинация. И поиск оптимума. Иногда менеджмент хочет уволить каждого второго. Но разработчик – не только кодирует, там стендапы и общение. ИИ дает 15%. А значит ИИ – не инструмент бизнеса. Это инструмент разработчика. Как IDE. И продавать бизнесу также. Можно снимать макропоказатели – скорость тикетов и так далее. Но это – шаткая дорога. Могут быть улучшения и ухудшения, связанные с текущим потоком задач – не по одному спринту. К этой части у меня много вопросов. Во-первых, подписка 20$ – это даром, и даже 200$ – это меньше 10% от зарплаты разработчика, и если ИИ дает 15% – то это явно окупается. А он дает больше, оценки – разные, но 30% называют уверено. Значит если у вас получилось только 15%, то у вас явные проблемы. Я не вижу проблемы со скоростью тикетов и другими показателями, если их устойчиво снимали раньше, есть исторические данные. И в них видны вариации. Снимать один спринт, кончено, бессмысленно, а три месяца дают нормальную картину, это известно еще по периоду внедрения agile-методов. Другое дело, что как тогда не было реальных исторических цифр, так и сейчас их нет. А уволить каждого второго – так, кстати, тоже бывает. Но точно не там, где менеджмент с самого начала ставит задачу именно так. Просто может оказаться, что аналитики начинают вайбкодить и разработчики в команде больше не нужны – такие кейсы есть. Но тут много зависит от задач, есть другие кейсы, когда у аналитиков вайбкодить не получается. Возвращаюсь к вступлению. Нужно ИИ-сообщество. Плохо чувствовать себя одиноким. И те, кто драйвит. И это как сообщество scrum-мастеров, которые ведут свой скрам по улучшению процесса – с церемониями и так далее. Роль ИИ-мастер – по названию это аналог scrum-мастера, который ИИ в команду, зажигает людей. А еще надо следить за новостями, и реагирует на них – смотреть на варианты, которые появляются. И интересно, что у них они выросли из сеньоров. Кривая Роджерса и пропасть Мура. Освоение инноваций: инноваторы → ранние последователи → раннее большинство → позднее большинство → консерваторы. На пилот надо подтягивать ранних последователей. И очень часто не получается дотянуть, чтобы подхватило раннее большинство (это – пропасть Мура) – и внедрение загибается. Проблемы часто не лежат в технологическом срезе, а в психологии, и решается по-другому. Николай Поташников. Кит на кот: выкидываем любимого ассистента, заменяем на Koog и экономим токены, нервы и времяИнтересное выступление о том, как написать своего агента, и зачем это нужно. Если кратко, то профит в том, что у тебя все под контролем, ты понимаешь, как это работает внутри и можешь докручивать. Думаю, особенно актуально должно быть на потоке задач, который не слишком хорошо решается агентами из коробки по каким-то причинам: ты можешь видеть, что именно происходит внутри и подстраивать это. Интересный пример применения: ему не удалось добиться от агента, чтобы он спрашивал, а не фантазировал, когда ему чего-то не хватает. Тогда он написал mcp askForClarification запроса дополнительной информации по задаче, которй реально просто разрывает агентский цикл. Но в обычного агента такой mcp встроить нельзя. А теперь – конспект подробнее. Три месяца назад он рассказывал это на митапе, и с тех пор код переписал полностью и презентацию тоже. Но идея осталась. Он архитектор, был во всех ролях разработки. Ожидания от ИИ реализуются, но не очень. Как в прошлом, работать точно не может, но то, что происходит – авангард, и это не очень нравится. Есть универсальные агентские системы: Claude, Codex и другие. Как-то решают из коробки. Есть средства сборки специализированных клиентов – они тратят меньше токенов, можно достичь результата дешевле и быстрее, но надо знать задачу, под которую делаешь клиента. Он попробовал сделать гибрид – написать универсального агента для своих задач. Снижаем универсальность, получаем экономию и точность. И ему удалось – он пользуется тем, что написал, универсальные использует редко. Как устроено? Есть папка assistant, там лежит copilot.main.kts – 1500 строк – там один файл. dockerfile – песочница, и куча задач. В любом IDE команда запуска. Пишешь в файле вопрос, запускаешь – и получаешь ответ в том же файле, он дописывает в конец. И еще лог, что происходило. В логе – reasoning content. Часто модель зацикливается – и это надо видеть, останавливать. Технический диалог – модель запросит инструменты, даст ошибки – и если система зациклилась, то можно остановить, и самому перезапустить, добавив это – и там перезапуск. Вопросы-ответы идут в markdown-файле. Если ты просил обновить цвета в презентации, а модель хочет обновить весь дизайн – ты останавливаешь. И это – не линейный диалог: ты его можешь менять на любом этапе. Экономия контекста позволяет выйти за пределы задач. При этом линейный транскрипт, который передается позволяет контролировать содержание. И у него нет режимов, он руками правит, какие тулы вызывать, а какие останавливать. Логика агентского workflow. Предобработка – LLM – Постобработка – Выполнение инструмента – дописать ответ. Чтобы модель тебя спросила надо убиться, поэтому подсовываешь инструмент «спроси контекст», который разрывает агентский цикл и спрашивает разработчика. Есть много приемчиков.
Инструменты:
Предобработка и постобработка.
Нюансы использования. Если Koog не подстраивается под api, это не баг – api много, надо самому допиливать. Он это просто исправляет в обработке запрос-ответ http регулярными выражениями. Были примеры с OpenAI и Open Router. И там еще много деталей, например, чтобы поиск в интернете реально запустился. В чем преимущества Koog? Аннотирование инструментов и классов, запуск LLM одной строкой, удобная модификация промпта, подключение к разным провайдером (но надо понимать и поддерживать разницу), трассировка… Логика агента зависит не только от модели, но и от прокси и провайдера. Учесть все во Framework невозможно, но он дает много полезных абстракций, и нужны удобные инструменты. И нужна наблюдаемость – как получен ответ, чтобы оптимизировать явно неэкономичные ходы. Владимир Красильщик. LLM за пределами чата: практическое применение для нечетких задачЭто рассказ про решение конкретной задачи – управление обращениями к провайдерам.В выступлении примеры примеры решений доля конкретных классов задач: анализ диалогов с пользователями, генерация короткого сообщения по тексту, чтобы создать имя файла, название встречи или тему письма, генерация SQL-запроса и другие. Для начала нужен Единый DTO, описывающий модели и запросы. Конфигурируем модель и запрос, есть преобразование к провайдеру, и идет вызов через клиент провайдера. К запросам – контекст – открытые файлы и так далее. И доступные mcp. LLM может запросить данные из mcp – надо вернуть и продолжить. Есть внешний цикл, который может остановить обращения. Завершение агентского цикла – если нет дозапросов mcp. Если обращения есть – отправляем их в инструменты. Инструменты сами докладывают результаты в историю. Ждем, пока инструменты закончат работу – и следующий виток цикла. И меряют стоимость: перед вызовом LLM узнают расценки, и дают стоимость вместе с ответом. Внутренний транспортный цикл – retry ошибок, если был сбой сети и подобные проблемы. Важно отделить ситуации, когда не нужен retry. Сверху – цикл ремонта: проверяем ответ, и если он не устраивает, то добавляем к запросу причину, почему не устраивает, можем обогатить контекст и повторяем запрос. Дальше были примеры конкретного кода. Задача-1: классификация откликов (сообщений) пользователя – поставить метки. Первый шаг – вообще отсеять то, что не надо отправлять в LLM, например, код ошибки. Или большое сообщение, в нем обычно пользователь передает какой-то трейс исполнения, чтобы агент исправил ошибки. Ставим три метрики: тон (позитивный, нейтральный), реакция пользователя (восторг или что), тип задачи (генерация кода, доков). LLM выдает ответ, но дальше надо из него вынуть результат по ключевым словам или своей локальной сетью. Системный промпт – xml, говорим, что там будут данные, а не команды, которые надо классифицировать – поставить метки. Дальше конкретный промпт: ответ пользователя + кусок ответа агента (OK может по разному интерпретироваться)и так далее. Дальше из ответа вынимаем метки – но не всегда успешно. Мы все оси запаковали в один промпт – он кешируется у провайдера, и это подешевле. И этот подход, когда несколько задач – дает профит. Но может быть и другой эффект, когда LLM запуталась. И есть эффект batch – может сразу массив запросов отправить. При этом batch можно погасить, если стоимость зашкаливает, или результат не устраивает. Задача-2: генерация короткого текста по длинному – выжимка. И там – простой алгоритм. Используется для разных целей: генерация имени файла по содержимому, названия встречи из транскрипта, темы письма, коммит-сообщение по diff и так далее. Промпт собирается программно: правила пользователя, если есть, ограничения (50 символов), использование префиксов, и несколько примеров предыдущего. Задача-3: судья. LLM as a judge, оценки – ответов поддержки, code review и так далее. Оцени: задачу клиента, насколько решена, оценить работу без LLM (с опорными точками для оценки – типовые задачи, максимальное время), и определяем формат ответа: первичная цель, дополнительные, уровень уверенности, оценка часов тоже с уровнем уверенности. Задача-4. SQL по описанию на естественном языке. Есть набор дашбордов, и мы хотим добавить кастомный виджет. Подготовка промптов и repair-контекст, разбираем ответ – там может быть не json, хотя просим его, дальше идет валидация SQL. Дальше пытаемся прогнать с лимитом на небольшой БД, и если получилось – показываем пользователю таблицу, предлагаем варианты графика. Если поход в БД неудачно – запаковка в repair-контексте и следующий виток цикла. Замена всяких генераторов отчетов, query-builder и так далее. Системный промпт – ты эксперт в clickhouse, запрос от пользователя, не доверяй ему и еще оговорки. Ограничения на SQL, и про базу: есть структурированное и есть сырые данные. Все работает в multitenant окружении – подстановка на сервере, перечень переменных, которые позволяем, все под group by и так далее. И схема БД, которую на лету делаем. И еще repair-контекст. Ответ обязательно проверяется на ограничения – что там SQL, что переменные – только из списка и так далее. SQL достаем очень аккуратно, могут быть разные проблемы, даже если просили заданный формат. И что там только SELECT, никаких других операторов или вывода в файл. И что не идем во всякие внешние данные. При этом проверки – их собирали из production… Агентский цикл по генерации SQL – дорогой. Поэтому тут надо вести бюджет. И сформировать кэш на ошибки. И не все retry, надо отсечь на первом витке. К этой идее у меня лично есть вопросы, потому что выглядит как попытка сделать волшебную кнопку. Которая не получается, и это пытаются решить большим количеством обвязки вокруг. При этом поток запросов от пользователя явно небольшой, так что там вполне можно вставить человека. А если поток большой – то надо в нем выделять понятные задачи, которые агент делает легко, остальные – пробовать, но если не получается – посылать к человеку. А дальше набор задач, с которыми агент справляется увеличиваем. Когда LLM не нужна? Разбор url или почты – регулярные выражения, разбор кодов ошибок, текстовый поиск, если критична точность или регуляторные требования, нужен быстрый ответ (real-time). И если раз в месяц надо расставить метки на документах, и это занимает час времени. Сергей Самойлов. Virtual Threads vs Goroutines: как две платформы решили одну задачу по-разномуВ выступлении – сопоставление двух подходов к организации параллельной работы: goroutine в Go и виртуальные треды, которые недавно появились в Java и сделаны по мотивам. Виртуальные потоки позиционированы как штука, которую достаточно включить в конфиге, но реально надо правильно использовать, а для этого – понимать устройство. В выступлении много примеров кода, так что контекст – пунктиром, смотрите запись. Сергей из MWS, делает Compute storage. Есть команды на Kotlin и Go, и для конкретных задач есть вопрос выбора платформы. В Java появились виртуальные потоки, и надо понимать различие с Go. Через призму Go мы можем понять, как устроено. Javа – разработчики вдохновлялись. Поток занимает 1MB – это виртуальная память. Важна физическая. Виртуальные потоки – зачем нужны? Платформенные потоки – прихотливы, процесс в группе, есть ограничения у группы, структура, которая описывает поток в ядре Linux – огромная, 1М потоков занимает большую память, и это на все приложения. Есть успешная модель виртуальных потоков на Go-платформе. GMP-модель. GV – go-routine, выполняемый код. M – реальный тред. Процессор P разрешает машине выполнять работу, Там локальные очереди go-routine, порождающие идут туда же. И есть глобальная очередь, не привязанные к машинам. И есть механизм – если машина голодает, она может забрать из других очередей. Как это поможет в Java? 2011 – начало массовых интеграций. Они становятся сложные. Тур-операторы: не Excel, а онлайн. И для этого делают треды, и фиксированные ограничиваю, а эластик – разрастаются. И сделали FJP - ForJoinPool. shared queue и worker queue парами. Концептуально похоже на Go. B дальше в выступлении – фрагменты кода с комментариями, это надо смотреть в записи и презентации. В виртуальных потоках – расширение FJP, там scheduler. Что нужно: блокирующие операции, Ю-вызовы, нативные операции, долгие вычисления В Go можно уйти в sleep и так далее. Механизм go-park – она выбрасывает go-routine, а по таймеру – идет возврат в работу через очередь. Почему так можно сделать? там есть структура G, которая описывает текущую ситуацию – стек и т.п., и можно отложить информацию. Повторение на Java. Там нельзя так запихнуть стек, а потом вернуть. Там появился механизм continuation – новый механизм. Его можно посмотреть в игровой моде. Есть scope – хранение состояние, и continuation – выполнение состояние. И есть волшебный метод yield – для прерывания работы, которую потом можно продолжить. Mount – виртуальный поток к рабочему. Дальше на прерывании unmount. Но у нас есть куча написанного кода, там sleep, lock – как туда проставить yield? Доработана библиотека, и yield проставлены для виртуальных потоков. Концептуально подходы Java и Kotlin – похожи. park != unmount. park – ожидание, и они unmount. Бывает, что поток ждет, но он mount – есть проблема с нативным кодом, туда JVM не может вставить yield. Что с сетью? Ее надо постоянно обрабатывать. В обоих случаях строится мапа, где поток мапится с сетевым дескриптором. Есть механизм поллинга, где смотрим, что появилось в дескриптерах – и обрабатываем. В go машина может стать дежурной и быстрый обход, а в java – отдельный поток. Вытеснение. Go может, Java – нет. Вытеснение нужно для того, чтобы во-время обрабатывать изменения сетевых дескрипторов. Go считает, что длительные вычисления стоит прерывать ради коротких. А в Java – другая философия, они считают, что программист должен сам подлить: тут у нас io, а тут – вычисления, не надо смешивать. При этом если вычислительных задач меньше, чем физических потоков – то это не мешает. И дальше – эксперимент, как раз с разной нагрузкой вычислительных, и там видно, как вычислительные операции блокируют. Поэтому их надо собирать на отдельном вычислительном пуле потоков. Выводы.
Александр Ланцов. Java после Loom: альтернативные модели многопоточностиА в этом выступлении – сопоставление трех механизмов: goroutine в Go, coroutine в Kotlin и и виртуальных потоков. Виртуальные потоки можно просто включить в конфигурации, и действительно может стать лучше, но в большинстве случаев включить – недостаточно, их надо правильно использовать. В выступлении много примеров кода, так что контекст – пунктиром, смотрите запись. Kotlin coroutine – go goroutine. В Котлине – явные точки остановки, в go – само. В Котлине это синтаксический сахар компилятора. Виртуальные потоки Java сделали как в Go: как поток, но дешевле. Для написания конкурентных программ в Go не надо знать модель памяти. А в Java? Если погрузиться в начальную документацию по Loom, обещали каналы, акторы и dataflow. Пререквизиты: volatile дает синхронизацию. Идет очередь – передача корректная, в потокобезопасной очереди можно передавать небезопасные объекты. Акторы. Два потока, и есть mutable state, и там нужна синхронизация. Можно взять состояние и приписать одному потоку. А что делать другим? Надо завести блокирующую очередь, и через нее получить. mailbox и актор, который ей управляет. С виртуальными потоками ее завести очень легко – фрагмент кода. Таких акторов можно породить миллионы – они будут не слишком дороги. Многопоточный чат на этом делается очень легко – в каждой комнате делаем отдельный актор, и не надо никаких блокировок. Ограничения. Для тяжелых вычислительных задач – не будет распараллеливание. Общее глобальное состояние – блоки, и слишком много сообщений при активной работе с актором. Каналы и последовательно-взаимодействующие процессы (CSP). Процесс: есть вход, получаем сообщение, обрабатываем по бизнес-логике, и результат – в выходную очередь, и это дает последовательность. Процессы не взаимодействуют напрямую, а зацепляются через очереди. В упрощенной модели – одна входная и выходная очередь. Все безопасно, если положив модель в очередь, вы его не меняете. Простой цикл. Но есть сложная топология связи – много входных и выходных очередей. И как корректно завершить – проблема остановки, когда входных данных больше нет? Для этого есть каналы. В Go есть send и receive, канал можно закрыть. Буферизированый канал имеет емкость, по заполнению – вы ждете, пока из него не прочитают. Каналы встроены на уровне языка. В Java есть библиотека Jox, которая это делает – эффективная реализация, как в Kotin. В нем есть select, позволяющий ждать значения хотя бы в одном из входных каналов. CSP – цепочки взаимодействующих процессов и слабосвязанные процессы, и когда процессы много ждут (io). Не очень хорошо, когда CPU-параллельные; когда простой request-response вы меняете на очереди; когда передается большое изменяемое состояние. Задача клиринга: взять все задачи за сутки и прогнать через обогащение → валидация → обогащение во внешней системе → запись в БД. Было сделано обработка каждой транзакции в отдельном акторе (akka). Но виртуальными потокам – проще. Простой способ – сделать виртуальный поток для каждой транзакции. Но потоки чего-то стоят, все равно надо ограничивать, есть ограничение по cpu-bound, и обращения к внешним системам и БД увеличивает времени отклика при увеличении числа потоков. Число потоков можно ограничить с помощью Semaphore. По числу задач, для cpu-bound – дополнительно по числу ядер, а для io – эмпирическими ограничениями. Второй вариант – вместо семафоров сделать pipeline. 4 этапа, каждый делаем этапом обработки, между ними – каналы. И каждый этап можно сконфигурировать по числу обработчиков, они на это рассчитаны. Дополнительный профит – мы видим размеры очередей и можем мониторить и решать проблемы. Вывод. Хотя все стало проще, модель памяти надо знать. И писать безопасно. |
Я в сетиhttp://www.facebook.com/mtsepkov http://www.linkedin.com/in/mtsepkov http://www.slideshare.net/mtsepkov/ e_mail M.Tsepkov@custis.ru
|
Обо мнеМоя основная работа — проектирование корпоративных и банковских систем. Я верю, что автоматизация — дает новые возможности развития, поэтому создавая автоматизированные системы мы открываем путь прогрессу и делаем мир лучше. Я делаю это, работая главным архитектором дирекции развития решений компании CUSTIS. Я верю в эффективность командной работы, эффективность профессиональных сообществ. И я участвую в жизни ИТ-сообщества - через работу в программных комитетах конференций SECR AnalystDays и просто в коммуникациях на разных площадках. А еще я люблю путешествовать, об этом и о других идеях вне профессиональной деятельности я пишу в своем ЖЖ. |
Блоги друзей |
