1
00:00:04,880 --> 00:00:09,060
Всем привет! Рад всех видеть! Меня зовут
Антон, я представляю здесь не только

2
00:00:09,060 --> 00:00:13,140
Яндекс Рекламу, но и программ на комитет
-конференции. Хочу поделиться с вами

3
00:00:13,140 --> 00:00:17,420
своим видением того, как вообще, в связи
со стремителем развития искусственного

4
00:00:17,420 --> 00:00:22,060
интеллекта, сейчас меняется бекэнт
-разработка. И лично меня здесь впечатляет
не

5
00:00:22,060 --> 00:00:26,160
только то, как меняется наша профессия,
как мы буквально код пишем, но и то, как

6
00:00:26,160 --> 00:00:30,840
меняется архитектура самих систем
благодаря развитию нейросетей, и то, какие

7
00:00:30,840 --> 00:00:36,180
буквально новые классы -задач возникают
здесь. на чем мы, конечно, с того, как

8
00:00:36,180 --> 00:00:40,800
мы пишем код. Уверен, что большинство из
вас код уже руками не пишет и отличает

9
00:00:40,800 --> 00:00:44,580
наверняка вайп -кодинку от агентной
разработки. Как раз про некоторые
интересные

10
00:00:44,580 --> 00:00:48,840
и сложные тренды агентной разработки
немного поговорим. Вот вы наверняка пишете

11
00:00:48,840 --> 00:00:53,560
тесты, я уверен. Хочется, чтобы в
продакшенном код попадал в хорошем стейне
и

12
00:00:53,560 --> 00:00:57,740
баги не пролезали. А что, если мы будем
говорить не про конкретный код, который

13
00:00:57,740 --> 00:01:01,180
в продакшене работает, Это про ваши
агентные пайплайны. Вот, например, хочется

14
00:01:01,180 --> 00:01:06,280
ревьюить код тоже с помощью агентов. Да, и
вы собираете такой пайплайн агентного

15
00:01:06,280 --> 00:01:09,200
код -ревью. У вас там есть некоторые
базовые модель, какие -то скилы, какие -то

16
00:01:09,200 --> 00:01:13,240
критики. А что, если вы захотите поменять
базовую модель на какую -то более

17
00:01:13,240 --> 00:01:17,000
продвинутую? Или если вы захотите добавить
код нового критика, как, в память,

18
00:01:17,100 --> 00:01:21,380
осталось лучше или хуже? Вообще -то тоже
нужна некоторая приемка, да, нужны

19
00:01:21,380 --> 00:01:26,580
какие -то выборки типичных полуреквестов.
На этих полуреквестах нужно запустить

20
00:01:26,580 --> 00:01:30,580
предыдущую версию, новую версию. как -то и
сравнить. Вообще -то сделают так,

21
00:01:30,640 --> 00:01:34,920
чтобы эти агенты не подглядывали друг к
другу и вовнешний мир. Короче, вообще

22
00:01:34,920 --> 00:01:39,380
-то нетривельная бэкэнтерская задача, но
это подход обычно называется эвалы, вот

23
00:01:39,380 --> 00:01:45,160
из ML мира термин, и в как раз больших
командах, больших пейплайнах это все

24
00:01:45,160 --> 00:01:48,440
очень актуально, иначе просто непонятно,
как полагаться на то, что агенты вам

25
00:01:48,440 --> 00:01:48,720
говорят.

26
00:01:50,080 --> 00:01:55,540
Мы начали говорить про тесты, и сами по
себе тесты становятся очень важны, на

27
00:01:55,540 --> 00:01:59,760
них просто давление возрастает, не только
физическое, ну и психологическое что

28
00:01:59,760 --> 00:02:04,780
ли, потому что полуреквестов становится
больше. Я уверен, что ну команды,

29
00:02:04,820 --> 00:02:07,820
которые очень активный агент используют,
используют это все, наблюдают у себя

30
00:02:07,820 --> 00:02:13,060
очень ярко. Вообще -то сами тесты
становятся больше на критическом пути,
потому

31
00:02:13,060 --> 00:02:18,740
что код теперь писать проще и быстрее. Ну
и агенты сами на тесты полагаются в

32
00:02:18,740 --> 00:02:22,420
значительной степени, соответственно, если
тесты флапают, то агент примет какое

33
00:02:22,420 --> 00:02:27,240
-то совершенно неприсказуемое решения.
Поэтому нужно тесты делать быстрыми,

34
00:02:27,660 --> 00:02:32,420
стабильными, нужно уметь хорошо
масштабировать по железу вашей

35
00:02:32,420 --> 00:02:37,360
инфраструктуру, ну и вообще так как
следствие, вообще говоря, оптимизирую всю

36
00:02:37,360 --> 00:02:39,260
среженную нагрузку и делать автоприемку.

37
00:02:40,100 --> 00:02:43,340
И это само бы себе и отдельно интересная
задача, которую раньше в таком масштабе

38
00:02:43,340 --> 00:02:48,600
не стояло. Мы вот у себя тоже цели на флаг
взяли и обнаружили внезапно, что

39
00:02:48,600 --> 00:02:53,800
те тесты, которые раньше были супер
долгими, сложными, когда в залидном

40
00:02:53,800 --> 00:02:58,380
окружении поднимается практически
интеграционный тест на слепке production
базы,

41
00:02:58,460 --> 00:03:04,440
обстреливается слепком production
запросов, классный, но тяжелый тест. Эти
тесты

42
00:03:04,440 --> 00:03:10,180
оказались сейчас уже быстрее, чем весь
слепок вроде бы более простых

43
00:03:10,180 --> 00:03:15,140
тестов, но я имею в виду юниты, какие -то
функциональные, потому что в модной

44
00:03:15,140 --> 00:03:18,640
репозитории все сервисы быстро обрастают с
лишними зависимостьями и по этим

45
00:03:18,640 --> 00:03:22,140
зависимости он притягивается сильно больше
тестов, чем хотелось бы. И с одной

46
00:03:22,140 --> 00:03:25,400
стороны получается, первую очередь надо
эти зависимости поспиливать. С другой

47
00:03:25,400 --> 00:03:29,180
стороны, есть действительно файлы, у
которых слишком много зависимости,

48
00:03:29,280 --> 00:03:33,160
например, какие -то базовые протобов
схемы, и в этом случае нужно уметь умно

49
00:03:33,160 --> 00:03:36,380
понимать, какие тесты запустить, а не
просто вот все подряд, которые вроде бы

50
00:03:36,380 --> 00:03:40,540
формально от этого файла зависят. И это,
ну вообще -то, непростая баконьдерская

51
00:03:40,540 --> 00:03:40,980
задача.

52
00:03:42,000 --> 00:03:46,900
Не всем, конечно, хочется оптимизировать
тесты, ну, как будто есть много других

53
00:03:46,900 --> 00:03:47,980
интересных задач на свете.

54
00:03:49,400 --> 00:03:53,160
Хорошо, что это может поручить агенту, но
в этой ситуации вы, конечно, уже

55
00:03:53,160 --> 00:03:58,240
агенту будете формулировать не тикет, и да
вот, тикет иди и сделай, а вы будете

56
00:03:58,240 --> 00:04:01,600
давать ему метрику целевую, которую нужно
ему оптимизировать, давать ему

57
00:04:01,600 --> 00:04:06,200
бейнчмарк, и чтобы он дальше погибел какие
-то гипотезы, на бейнчмарке

58
00:04:06,200 --> 00:04:07,920
попроверял, насколько они выстреляли,

59
00:04:09,060 --> 00:04:12,700
и, значит, за несколько итераций, не знаю,
на выходные можно его оставить, в

60
00:04:12,700 --> 00:04:15,800
понедельник утром прийти, посмотреть, что
получилось. Здесь тоже есть, конечно,

61
00:04:15,940 --> 00:04:19,080
подстава. Ну, этот подход вообще
изначально был описан корпатом в контексте

62
00:04:19,080 --> 00:04:23,300
обучения ЛЛМ. Потом его подхватили и
популяризовали тоже разные компании.

63
00:04:23,480 --> 00:04:26,520
Например, Shippify, как раз в контексте
оптимизации сяи -пайплайнов, про авторы

64
00:04:26,520 --> 00:04:27,340
все еще рассказывал.

65
00:04:28,260 --> 00:04:33,360
Мы у себя тоже его применяем и столкнулись
с интересным эффектом.

66
00:04:34,580 --> 00:04:38,120
Очень беликсоблазанно взять какую -то
существующую библиотечную функцию, которая

67
00:04:38,120 --> 00:04:41,500
светится на флеймграфах по всей компании.
Вот мы рассказываем про перфоратор

68
00:04:41,500 --> 00:04:45,100
периодически. перфоратами помогает понять
по всей компании, какие функции чаще

69
00:04:45,100 --> 00:04:48,660
его используются. Такие функции берешь.
Видишь, ага. Банчмарк там 10 лет назад

70
00:04:48,660 --> 00:04:52,640
написан. Давайте -ка агенту скормим и,
скажем, оптимизируем и посмотрим, что

71
00:04:52,640 --> 00:04:56,240
получится. К сожалению, эти банчмарки
часто оказываются нелепрезентативны.

72
00:04:56,780 --> 00:05:00,100
Агенты эти банчмарки хакают, и банчмарки
проходятся лучше, а в продакшене, в

73
00:05:00,100 --> 00:05:03,320
итоге, получается, фигня. Какой -то эффект
есть, но не такой большой, как

74
00:05:03,320 --> 00:05:07,880
хотелось бы. Банчмарки супер важны, и вот
как раз вспоминая, предыдущий слайд,

75
00:05:07,880 --> 00:05:11,760
когда я говорил про сложные тесты, слепок
продавшим базу, слепок запросов, вот

76
00:05:11,760 --> 00:05:15,780
на таких нагрузочных тестах как раз хорошо
строить такие агентные циклы, и мы

77
00:05:15,780 --> 00:05:20,500
таким образом уже несколько тысяч CPU
сэкономили. Короче, классная тема только с

78
00:05:20,500 --> 00:05:24,380
бончмарками нас запарит. Ну ладно, я
вообще -то не хотел слишком много говорить

79
00:05:24,380 --> 00:05:28,720
про агентную разработку, у нас всякие
конкуренции. Не совсем про это, на примере

80
00:05:28,720 --> 00:05:33,160
рекомендательных систем расскажу немного о
том, как меняется сама архитектура

81
00:05:33,160 --> 00:05:33,680
таких систем.

82
00:05:35,320 --> 00:05:38,920
Вообще рекомендательные модели довольно
давно развиваются, поэтому чуть -чуть по

83
00:05:38,920 --> 00:05:42,860
истории пройдусь. Самые простые
рекомендательные модели, которые наверняка
вы в

84
00:05:42,860 --> 00:05:45,900
своих системах использовали, это
грязненный boosting. Наверняка слышали про

85
00:05:45,900 --> 00:05:47,200
MatrixNet или CatBoost.

86
00:05:48,060 --> 00:05:52,080
И эти модели, с которыми супер легко
работать, я даже обучал такие и сам,

87
00:05:52,180 --> 00:05:55,340
собственно, даже переписывал библиотеку,
по -моему, который с ними работает.

88
00:05:56,700 --> 00:06:00,440
Берете вычеляете факторы, которые нужно
подставить, берёте библиотечную функцию,

89
00:06:00,560 --> 00:06:03,200
берёте туда это буквально бинарный файл,

90
00:06:04,120 --> 00:06:07,280
запускаете, получаете скор, скор берёте
вранжирование, всё, ни о чём думать не

91
00:06:07,280 --> 00:06:07,880
нужно, красота.

92
00:06:09,280 --> 00:06:12,860
Дальше модели активно развивались,
появились нейросети и в частности очень

93
00:06:12,860 --> 00:06:15,660
популярные в рекомендательных моделях
двухбашенные нейросети.

94
00:06:17,020 --> 00:06:21,720
История такая, вот у вас есть, допустим,
пользователь и документ. И вы хотите

95
00:06:21,720 --> 00:06:24,920
оценить вероятность, например, с какой
вероятностью этому пользователю и

96
00:06:24,920 --> 00:06:27,960
документ полезен. Или есть пользователь и
товар, с какой вероятностью это

97
00:06:27,960 --> 00:06:31,060
полиция, это товар купит. Опять же, какой
-то скор, для некоторых ранжей уровня

98
00:06:31,060 --> 00:06:35,420
нужно почитать. Как -то делается в случае
двухбашной нейросети. Есть у нее

99
00:06:35,420 --> 00:06:40,340
практически независимые части. Одна часть
смотрит на факторы пользователя и

100
00:06:40,340 --> 00:06:44,780
вычисляет некоторый вектор имбендинг
пользователя. Другая часть вычисляет

101
00:06:44,780 --> 00:06:49,120
имбендинг документа. Они друг другом никак
не связаны. И в самый последний

102
00:06:49,120 --> 00:06:51,740
момент эти векторы перемножаются и
получают итоговый скор.

103
00:06:52,600 --> 00:06:57,940
Почему я вам бекендером показываю архитуру
нейросети? потому что если бы это был

104
00:06:57,940 --> 00:07:01,620
просто черный ящик, то вам нужно было бы
для каждой пары пользовать документ,

105
00:07:01,680 --> 00:07:05,880
запускать офигенно тяжелую нейросетку, и
это было бы просто очень долго, ни в

106
00:07:05,880 --> 00:07:09,400
какие сотни миллисекунд это не пролезет. А
когда у нее такая архитектура, можно

107
00:07:09,400 --> 00:07:14,660
запустить верхнюю часть первую башню один
раз на запрос, вторую часть запустить

108
00:07:14,660 --> 00:07:20,640
буквально при обновлении базы один раз на
документ. И в самый тяжелый момент, в

109
00:07:20,640 --> 00:07:24,260
самой критической секции просто эти
векторы не слишком большой размер, и

110
00:07:24,260 --> 00:07:27,120
перемножить. Это уже операция, которая
легко оптимизируется, бочуется и так

111
00:07:27,120 --> 00:07:27,420
далее.

112
00:07:29,020 --> 00:07:32,320
Ну вот, видите, бакендером здесь пришлось
это учитывать. Ну ладно, это как бы

113
00:07:32,320 --> 00:07:35,940
уже пять лет назад, этим было никого не
удивитель. Что же происходит сейчас?

114
00:07:36,940 --> 00:07:41,360
Сейчас большие языковые модели часто
построены на архитектуре трансформеров и

115
00:07:41,360 --> 00:07:44,640
умеют хорошо работать с
последовательностью объектов. Ну вы знаете
про токены,

116
00:07:44,720 --> 00:07:47,020
да? С последствий токенов они работают, и
у меня сейчас они присказывают

117
00:07:47,020 --> 00:07:50,120
следующий токен. Где же это полезно в
рекомендациях? Давайте представим

118
00:07:50,120 --> 00:07:54,880
пользователя не как набор численных
факторов, а как набор действий, который он

119
00:07:54,880 --> 00:07:58,880
совершал. Вот он что -то поискал, куда -то
кликнул, с каким -то еще объектом как

120
00:07:58,880 --> 00:08:03,620
-то повзаимодействовал, вопрос к
нейросети, а что же он сделает дальше? Ну
вот

121
00:08:03,620 --> 00:08:07,700
так и получается рекомендации в такой
архитекуре нейросетей. Но опять же хочется

122
00:08:07,700 --> 00:08:13,580
это делать эффективно, при этом, запуская
нейросеть несколько раз на одно и то

123
00:08:13,580 --> 00:08:16,800
же, довольно длинные истории пользователя.
Соответственно, придется погрузиться

124
00:08:16,800 --> 00:08:20,460
в кишки и понять, что же там с этой
историей происходит. Один из ключевых

125
00:08:20,460 --> 00:08:25,820
элементов трансформера это attention,
внимание, еще сегодня про это поговорим,

126
00:08:25,920 --> 00:08:31,400
и attention для этой самой истории
вычисляет keys и values, k av, и

127
00:08:31,400 --> 00:08:35,300
соответственно, если вы хотите что -то
закрешировать, то именно k av вам нужно

128
00:08:35,300 --> 00:08:38,240
закрешировать, поэтому есть термин k v к
шип, про который вы тоже возможно

129
00:08:38,240 --> 00:08:42,140
слышали, и в контексте искрых моделей, и в
контексте рекомендации тоже он

130
00:08:42,140 --> 00:08:45,600
становится важным, и здесь, правда,
приходится думать, а этот, конечно, должен

131
00:08:45,600 --> 00:08:49,220
быть в off -line или в on -line, это
правда, если того, как у вас рекомендация

132
00:08:49,220 --> 00:08:53,480
устроенная, в общем, Бакендером все
глубже, приходится погружаться и

133
00:08:53,480 --> 00:08:57,140
перестраивать архитектуру в свои систем
под современные рекомендательные модели.

134
00:08:58,940 --> 00:09:04,900
Еще один тренд в рекомендациях неожиданно
связан с моделитизацией. Кто из вас

135
00:09:04,900 --> 00:09:06,920
хоть раз оспилил монолит на микросервисы?

136
00:09:08,840 --> 00:09:11,140
Больше половины зала, мне кажется. Ну,
конференция про Бакенд. Нормально,

137
00:09:11,180 --> 00:09:13,300
похоже, на правду. Значит, вы туда попали.

138
00:09:14,420 --> 00:09:19,480
Понимаете, в чем профит, да? У вас сервисы
становятся меньше, энтерапия

139
00:09:19,480 --> 00:09:23,220
уменьшается, Realism уже катать чаще, Tiny
to Market Fish улучшается,

140
00:09:24,140 --> 00:09:27,260
с одной стороны, с другой стороны,
контекст, который надо понимать в
контексте

141
00:09:27,260 --> 00:09:30,900
каждой фичи, контекст каждого сервиса тоже
уменьшается, соответственно,

142
00:09:31,540 --> 00:09:35,140
разработчику прочую новому погружаться, и
агенту тоже проще в этой системе что

143
00:09:35,140 --> 00:09:35,500
-то менять.

144
00:09:36,360 --> 00:09:39,920
Более того, у меня год назад был проект
доклад на этой конференции, если вы не

145
00:09:39,920 --> 00:09:44,020
слишком много CPU потеряете на передаче
данных между микросервисами, на

146
00:09:44,020 --> 00:09:48,420
силизацию запросов, десилизацию ответов,
тогда вы можете еще и CPU сэкономить за

147
00:09:48,420 --> 00:09:52,080
счет улучшения локальности по коду и по
данным. У вас буквально процессная

148
00:09:52,080 --> 00:09:54,800
инструкция будет лучше попадать в куши
процессора, и данные можно лучше

149
00:09:54,800 --> 00:09:57,500
покушировать. В общем, о чем я вам
рассказываю, я сейчас раскиливаю это

150
00:09:57,500 --> 00:09:58,140
монолитоценно.

151
00:09:58,980 --> 00:10:03,460
Но в контексте рекомендательных систем, а
конкретно в контексте кандидата

152
00:10:03,460 --> 00:10:07,040
генерации, это стадия, после которой
выплевываются кандидаты, которые дальше

153
00:10:07,040 --> 00:10:07,900
вранжурниев впадают.

154
00:10:08,780 --> 00:10:13,440
Там возникает обратный тренд, а именно
инженеры из одного экстренистского

155
00:10:13,440 --> 00:10:18,420
объектеХ, в своей статье SilverTorch,
описали, как они в стадии кандидата

156
00:10:18,420 --> 00:10:24,120
генерации, вот буквально векторный поиск,
поиск ближайших соседей в том

157
00:10:24,120 --> 00:10:28,540
самом пространстве векторов имбендингов с
предыдущего слайда, фильтрацию этих

158
00:10:28,540 --> 00:10:32,900
кандидатов переранжирования перекладывают
на GPU. Почему это ценно? Потому что

159
00:10:32,900 --> 00:10:37,500
эти стадии работают с одним и тем же
большим массивом кандидатов и связанными с

160
00:10:37,500 --> 00:10:42,140
ними тензорами. Совершенно не хочется
передавать по сети и как -то перекладывать

161
00:10:42,140 --> 00:10:46,220
из памяти в память. Поэтому они эти стадии
все переписали на GPU.

162
00:10:47,480 --> 00:10:53,460
ANN -поиск стал буквально GPU -native
-Pytorch -модулем. Фильтрация теперь

163
00:10:53,460 --> 00:10:58,500
стала делаться не инвертирными индексами,
как все привыкли делать, а Bloom

164
00:10:58,500 --> 00:11:01,700
-индексом, GPU -friendly, буквально
набором Bloom -фильтров.

165
00:11:02,540 --> 00:11:05,020
В итоге получился PyTorch -граф,

166
00:11:05,860 --> 00:11:09,660
который, во -первых, инженен может
оптимизировать как цельный граф между

167
00:11:09,660 --> 00:11:13,500
стадиями. И, во -вторых, GPU -компилятор
может вьюзить некоторая операция и

168
00:11:13,500 --> 00:11:15,860
уменьшать перекладывание промежурочных
тензоров.

169
00:11:16,780 --> 00:11:20,000
Ну, вы не думаете, конечно, что когда
возникает GPU, сразу же, значит,

170
00:11:20,180 --> 00:11:26,100
микросервисы больше не нужны? Естественно,
когда мы инференс делаем, мы инференс

171
00:11:26,100 --> 00:11:29,700
выделяем в отдельный микросервис, но
конкретно в той ситуации, когда вы

172
00:11:29,700 --> 00:11:32,900
работаете с большим набором объектов и он
же вот произойдет между несколькими

173
00:11:32,900 --> 00:11:37,580
статями, конечно, имеет смысл от все
побандлить и объединить в один пайторч

174
00:11:37,580 --> 00:11:38,420
-граф, например.

175
00:11:40,140 --> 00:11:43,680
Так, довольно проекомендательная система.
Я обещал про новые классы задач,

176
00:11:44,560 --> 00:11:46,820
которые возникают в нашем чудесном мире.

177
00:11:47,940 --> 00:11:52,000
Ну, смотрите, что мы знаем про новые
продукты, которые в мире возникают.

178
00:11:52,580 --> 00:11:57,280
Агентная система просто и ассистент. У вас
есть LLM -ка, полюсер в нее подает

179
00:11:57,280 --> 00:12:00,240
запрос, ожидать получить какой -то ответ.
Вроде бы легко.

180
00:12:02,040 --> 00:12:05,260
Ну, и изначально буквально и ассистенты
так и выглядели. Там сложность была

181
00:12:05,260 --> 00:12:09,200
только в том, чтобы эффективный интервью с
этой большой нейросети выполнить, но

182
00:12:09,200 --> 00:12:13,400
там KVK -ши может какие -то сохранить. Тем
не менее, пока вроде бы легко, но

183
00:12:13,400 --> 00:12:17,200
вообще -то современная агентная система
сильна именно своей агентностью, то есть

184
00:12:17,200 --> 00:12:20,600
тем, что они могут запускать какие -то
тулы, какой -то код могут написать. Меня

185
00:12:20,600 --> 00:12:23,900
это в свое время очень почелило, что
нейросетка не полагается на то, что она

186
00:12:23,900 --> 00:12:27,300
может сама числа сложить, а лучше
питонский код напишет, который складывает

187
00:12:27,300 --> 00:12:31,360
числа и выдаст мне ответ оттуда. Ну
соответственно, мы должны быть готовы к

188
00:12:31,360 --> 00:12:34,960
тому, что выполнение польского запроса
пойдет по какому -то непредсказуемому

189
00:12:34,960 --> 00:12:38,700
сценарию. И граф вообще, говоря, будет
динамичным. Там может быть роутер в этой

190
00:12:38,700 --> 00:12:42,160
схеме, может его не быть, может быть ЛНК
будет сама решать, что ей надо сейчас

191
00:12:42,160 --> 00:12:44,820
вызвать какие -то тулы, а потом еще какие
-то тулы вызвать, а потом вызвать

192
00:12:44,820 --> 00:12:47,740
другую ЛНК, которая хорошо обрабатывает
другой сценарий. Получается, какой -то

193
00:12:47,740 --> 00:12:51,080
граф, по которому запрос ходит совершенно
непересказуемым образом и становится

194
00:12:51,080 --> 00:12:54,800
абсолютным кошмаром и сердечником, который
подается такой системой поддерживать.

195
00:12:55,580 --> 00:13:00,580
Более того, какие -то ветки этого графа
могут выполняться чистоами, ну потому

196
00:13:00,580 --> 00:13:05,300
что это может быть какой -то сложный
агент, агентный сценарий, разработчика,

197
00:13:05,300 --> 00:13:08,680
или, может быть, агент пытается
дозвониться до каких -то ресторанов и там
что

198
00:13:08,680 --> 00:13:09,240
-то забронировать.

199
00:13:10,260 --> 00:13:14,760
Понятно, что очень тяжело поддерживать
систему, которая может работать секунды,

200
00:13:14,960 --> 00:13:15,960
а может работать часы.

201
00:13:17,020 --> 00:13:20,280
И, конечно, в такой случае надо думать про
надежность. Надо рассматривать

202
00:13:20,280 --> 00:13:23,600
сценарий, когда у вас проволочие степи
соединения. Вам нужно откатиться назад,

203
00:13:23,660 --> 00:13:27,180
попробовать снова. Вам нужно мне
засавиться, подняться с чекпоинта, снова

204
00:13:27,180 --> 00:13:31,140
продолжить выполнение. И при этом, если у
вас есть побочные эффекты какие -то в

205
00:13:31,140 --> 00:13:34,760
процессе, нужно их не повторить. то есть
надо подумать про идем -пантентность.

206
00:13:35,560 --> 00:13:39,460
Конечно, если мы говорим про выполнение
коды, надо уметь поднимать какие -то

207
00:13:39,460 --> 00:13:44,220
изолированные среды и в них выполнять этот
код. И отдельная интересная часть это

208
00:13:44,220 --> 00:13:48,200
стриминг. Вы как пользователь, ожидаете,
что вы не будете штырить в белый экран

209
00:13:48,200 --> 00:13:52,960
на протяжении несколько часов, пока там
нейросетка вам что -то отдаст. Вы хотите

210
00:13:52,960 --> 00:13:57,080
видеть, как она думает, над чем она сейчас
думает. Если она уже пишет ответ, вы

211
00:13:57,080 --> 00:14:01,320
хотите видеть, как она этот ответ пишет.
Это уже такая важная продуктовая вещь,

212
00:14:01,400 --> 00:14:05,680
с одной стороны, с другой стороны, когда
есть некоторый архистратор, который

213
00:14:05,680 --> 00:14:08,960
понимает, что надо вызвать такой -то тул с
такими -то аргументами, то же, чем

214
00:14:08,960 --> 00:14:13,260
раньше он про это узнал, из ответа не
рассетки, тем лучше. Поэтому вот на всех

215
00:14:13,260 --> 00:14:15,300
этапах этого графа важен стриминг.

216
00:14:16,480 --> 00:14:19,500
Ну и понятно, надо следить за
эффективностью всей этой системы, как -то
умно

217
00:14:19,500 --> 00:14:24,040
балансировать, нужно какой -то
обзеврабилить слой, чтобы смотреть на
тресы и

218
00:14:24,040 --> 00:14:26,200
дебазжить, что там происходило. Короче,

219
00:14:27,480 --> 00:14:29,760
да вы не фоткайте там сейчас это будет в
этом же зале.

220
00:14:30,860 --> 00:14:32,760
Про изоляцию сейчас еще немножко
поразгоняю.

221
00:14:34,460 --> 00:14:37,000
Изоляция в продакшене это вообще -то не
что -то новое.

222
00:14:38,040 --> 00:14:43,100
Ну как минимум все в облаках живем
практически и понятно, что нужна изоляция,

223
00:14:43,260 --> 00:14:45,280
нужно уметь селить несколько сервисов на
одну машину.

224
00:14:46,100 --> 00:14:50,280
На одно дело изоляция в продакшене, другое
дело, когда изоляция, ну и вот все

225
00:14:50,280 --> 00:14:54,880
эти внешние интеграции, какие -то дерганье
опишек, когда они возникают в тестах.

226
00:14:55,620 --> 00:14:58,360
Никто не любит делать эндогрессонные
тесты, Но если кто -то любит, поднимите

227
00:14:58,360 --> 00:14:59,880
руку, и интересно станет познакомиться.

228
00:15:01,200 --> 00:15:03,180
О, ну, 10 человек. Нормально. Всё, похоже
на правду.

229
00:15:05,160 --> 00:15:08,920
Потому что моки нужны какие -то, какие -то
тестовые стенды. В общем, неприятно.

230
00:15:09,240 --> 00:15:12,360
Но это ладно. В общем, сейчас будет хуже.
Дело в том, что когда обучается

231
00:15:12,360 --> 00:15:15,640
сложная модель с агентным поведением, там
есть очень важная стадия обучения с

232
00:15:15,640 --> 00:15:19,620
подкреплением, Resports with learning. И в
процессе такого обучения нужно

233
00:15:19,620 --> 00:15:24,520
запускать эту самую модель на каких -то
входных примерах, давать этой модели

234
00:15:24,520 --> 00:15:30,100
пройти свои траектории, подергать тулы,
поменять состояние мира, как говорят

235
00:15:30,100 --> 00:15:30,920
люди, которые это делают.

236
00:15:31,940 --> 00:15:36,080
И по итогу вычитается некоторый реворд,
как бы модель выдается наград или не

237
00:15:36,080 --> 00:15:42,020
выдается, и он обратно подается в процесс
обучения. То есть у вас есть GPU

238
00:15:42,020 --> 00:15:46,280
-шка, дорогучий кусок кремния, который
обучает модель, перемножает матрицы, и

239
00:15:46,280 --> 00:15:51,240
вам супер важно следить за его
утилизацией, а параллельно с ним
сожительствует,

240
00:15:51,260 --> 00:15:54,800
не сам приедет, сожительство должно
сказать, вот эта штука, которая поднимает

241
00:15:54,800 --> 00:15:59,700
изолированные среды в огромном темпе, и
если она начнет будет подтормаживать,

242
00:16:00,000 --> 00:16:03,200
тогда у вас и GPU -шка будет
недоутилизирована, и дорогой железо будет

243
00:16:03,200 --> 00:16:08,640
простаивать. Вообще -то очень неприятно. И
в современных агентных системах речь

244
00:16:08,640 --> 00:16:14,540
идет уже о сотнях поднимаемых средств
секунду и об SLA в сотни миллисекунд

245
00:16:14,540 --> 00:16:19,640
на выдачу очередной среды из некоторого
горячего пула. Кто бы мне 5 лет назад

246
00:16:19,640 --> 00:16:22,600
сказал, что нужно уже бы с таким салейом
поднимать изолированный контейнер, я бы

247
00:16:22,600 --> 00:16:25,880
не поверил, я сказал, зачем тут нужно
вообще. А тут, ну, когда GPU -шка

248
00:16:25,880 --> 00:16:30,320
возникает, который параллельно об этом всё
блокируется, ну, деваться некуда

249
00:16:30,320 --> 00:16:33,660
приходится такую проблему тоже решать, и
мы её тоже решаем.

250
00:16:34,580 --> 00:16:39,560
Как видите, мы сейчас закольцовываемся с
первой темой, я в самом начале тоже

251
00:16:39,560 --> 00:16:42,600
рассказывал про агентные пайплайны, про
оценку качества, про то, что нужно

252
00:16:42,600 --> 00:16:48,120
агентам не подглядывать в то, что делают
соседние агенты, в общем, правда тема

253
00:16:48,120 --> 00:16:52,180
очень плотно друг к другу связаны. Вы
наверняка уже поняли, насколько меня

254
00:16:52,180 --> 00:16:56,580
вдохновляет решая задачи, которые до этого
почти никто не решал. Уверен, что у

255
00:16:56,580 --> 00:17:00,980
вас тоже, потому что конференция у нас как
раз про это, какое совпадение.

256
00:17:02,260 --> 00:17:06,260
Так что, если вы еще не изучили наш
программ, обязательно изучайте. Очень

257
00:17:06,260 --> 00:17:09,600
советую выбирать те темы, которые вызывают
у вас удивление.

258
00:17:10,580 --> 00:17:15,040
Это же ценнее, сходить на доклад, про
которые вы ничего Вы не понимаете, так что

259
00:17:15,040 --> 00:17:19,100
слушайте спикеров, общайтесь и со
спикерами, и друг с другом тоже

260
00:17:19,100 --> 00:17:22,560
вдохновляйтесь, и продуктивного всем дня.

261
00:17:35,430 --> 00:17:36,960
Антон, спасибо большое за доклад.

262
00:17:37,880 --> 00:17:43,180
У нас конкретная докладу Антона вопросов
сейчас не будет, поэтому

263
00:17:43,180 --> 00:17:48,320
Антона можно поймать течение всего
сегодняшнего дня на стендах

264
00:17:48,320 --> 00:17:54,140
у вопрос -ответ или просто где -нибудь на
территории. Сейчас

265
00:17:54,140 --> 00:18:00,000
у нас 10 -минутный перерыв до 12 .30,
соответственно, в 12 .30 на

266
00:18:00,000 --> 00:18:05,840
разных треках начнется свои доклады. А у
нас через

267
00:18:05,840 --> 00:18:11,720
10 минут здесь будет доклад Алексея
Логинова из команды Алисы

268
00:18:11,720 --> 00:18:16,240
про то, как строить надежную агентскую
платформу. До встречи через 10 минут.