1
00:00:00,000 --> 00:00:29,980
 Субтитры создавал DimaTorzok

2
00:00:30,000 --> 00:00:59,980
 Подписывайтесь на наш канал!

3
00:01:00,000 --> 00:01:29,980
 Подписывайтесь на наш канал!

4
00:01:30,000 --> 00:01:59,980
 Подписывайтесь на наш канал!

5
00:02:00,000 --> 00:02:29,980
 Подписывайтесь на наш канал!

6
00:02:30,000 --> 00:02:59,980
 Подписывайтесь на наш канал!

7
00:03:00,000 --> 00:03:29,980
 Подписывайтесь на наш канал!

8
00:03:29,980 --> 00:03:59,960
 Подписывайтесь на наш канал!

9
00:03:59,980 --> 00:04:29,960
 Подписывайтесь на наш канал!

10
00:04:29,980 --> 00:04:59,960
 Подписывайтесь на наш канал!

11
00:04:59,960 --> 00:05:29,940
 Подписывайтесь на наш канал!

12
00:05:29,960 --> 00:05:59,940
 Подписывайтесь на наш канал!

13
00:05:59,940 --> 00:06:29,920
 Подписывайтесь на наш канал!

14
00:06:29,920 --> 00:06:59,900
 Подписывайтесь на наш канал!

15
00:06:59,900 --> 00:07:29,880
 Подписывайтесь на наш канал!

16
00:07:29,880 --> 00:07:59,860
 Подписывайтесь на наш канал!

17
00:07:59,860 --> 00:08:29,840
 Подписывайтесь на наш канал!

18
00:08:29,860 --> 00:08:59,840
 Подписывайтесь на наш канал!

19
00:08:59,840 --> 00:09:29,820
 Подписывайтесь на наш канал!

20
00:09:29,820 --> 00:09:59,800
 Подписывайтесь на наш канал!

21
00:09:59,800 --> 00:10:29,780
 Подписывайтесь на наш канал!

22
00:10:29,780 --> 00:10:59,760
 Подписывайтесь на наш канал!

23
00:10:59,760 --> 00:11:29,740
 Подписывайтесь на наш канал!

24
00:11:29,760 --> 00:11:59,740
 Подписывайтесь на наш канал!

25
00:11:59,740 --> 00:12:29,720
 Подписывайтесь на наш канал!

26
00:12:29,740 --> 00:12:59,720
 Подписывайтесь на наш канал!

27
00:12:59,720 --> 00:13:29,700
 Подписывайтесь на наш канал!

28
00:13:29,700 --> 00:13:59,680
 Подписывайтесь на наш канал!

29
00:13:59,680 --> 00:14:29,660
 Подписывайтесь на наш канал!

30
00:14:29,680 --> 00:14:59,660
 Подписывайтесь на наш канал!

31
00:14:59,680 --> 00:15:29,660
 Подписывайтесь на наш канал!

32
00:15:29,660 --> 00:15:59,640
 Подписывайтесь на наш канал!

33
00:15:59,640 --> 00:16:08,820
 Про текстовые агенты и обновления в текстовых агентах, про голосовые агенты, про поиск и вообще домен AI-серч в интернете, в файлах и так далее.

34
00:16:09,160 --> 00:16:13,020
 И автоматизация процессов с помощью лоу-код инструмента Workflows.

35
00:16:13,900 --> 00:16:22,840
 Если чуть подробнее посмотреть на каждый из этих блоков, хотелось бы сегодня рассказать, куда мы хотим двигаться по каждым из этих направлений.

36
00:16:23,180 --> 00:16:30,400
 Это такие самые ближайшие планы и ближайшие инструменты, которые будут появляться в AI-студию в следующие месяцы.

37
00:16:31,640 --> 00:16:40,480
 На первом вебинаре в части про Responses мы много рассказывали про управление контекстом, про Truncation, то есть для автоматического обрезания диалогов,

38
00:16:40,480 --> 00:16:46,780
 про новый компонент мониторинга и трейсинга, чтобы отслеживать работу агентов, и обновление раздела мониторинга.

39
00:16:47,360 --> 00:16:50,700
 Конечно, мы хотим развивать дальше автоматическое управление контекстом.

40
00:16:50,880 --> 00:16:55,420
 Транкейшн — это первый подход, но он далеко не единственный возможный.

41
00:16:55,420 --> 00:17:02,740
 Мы хотим более гибко и умно уметь работать с контекстом, и в этом направлении у нас скоро будут обновления

42
00:17:02,740 --> 00:17:10,420
 по поводу более умного, качественного сжатия истории диалога при работе с длинными цепочками историй.

43
00:17:11,000 --> 00:17:17,500
 Скиллс. Про них были вопросы и в комьюнити, и понятно, что сейчас скиллы стали по сути стандартом.

44
00:17:17,940 --> 00:17:20,840
 В ближайшее время у нас появится поддержка скиллов в Респонсос.

45
00:17:21,760 --> 00:17:27,480
 Даже могу немножко тут засполерить, что они уже практически готовы, у кого прям очень горит,

46
00:17:27,660 --> 00:17:29,360
 и есть интерес попробовать как можно раньше.

47
00:17:30,240 --> 00:17:36,600
 Приходите, пишите, будем давать возможность, для части пользователей сможем выдать бета-доступ.

48
00:17:36,600 --> 00:17:45,200
 И отправка файлов в Респонсос API, тоже один из самых, наверное, частых запросов от клиентов, от пользователей.

49
00:17:45,300 --> 00:17:53,200
 То есть возможность напрямую в модели отправлять разные типы файлов, PDF, .docx и так далее, без отдельного построения поискового индекса.

50
00:17:53,760 --> 00:17:57,780
 По голосовым агентам мы в первую очередь целимся в повышение качества.

51
00:17:57,780 --> 00:18:06,300
 Повышение качества за счет более больших новых моделей для обработки длинных контекстов чатов.

52
00:18:06,700 --> 00:18:09,960
 Это новые модели синтеза для голосовых сценариев.

53
00:18:10,400 --> 00:18:19,260
 Это конструктор промтов, потому что на самом деле то, как будет сформирован промт для голосового агента, очень сильно сейчас влияет на качество этого робота.

54
00:18:19,260 --> 00:18:24,260
 И в целом набор оптимизаций и улучшений по диалоговым механикам.

55
00:18:24,860 --> 00:18:28,920
 Про поисковые продукты. Здесь у нас основной фокус остается на качестве.

56
00:18:29,120 --> 00:18:35,880
 Причем как на качестве поиска в интернете, так и на качестве поиска по файлам, то есть на RAC сценариях.

57
00:18:36,420 --> 00:18:41,060
 Из обновлений, которые скоро появятся, это поиск по нескольким индексам.

58
00:18:41,060 --> 00:18:46,960
 Те, кто использует RAC, знают, что сейчас у нас ограничение на один подключенный векторный индекс в Responses.

59
00:18:47,320 --> 00:18:52,360
 Это ограничение мы хотим снять и дать возможность искать по нескольким поисковым индексам одновременно.

60
00:18:53,340 --> 00:18:59,460
 И что касается лоукода, то здесь у нас также продолжается тренд на упрощение использования.

61
00:18:59,600 --> 00:19:03,260
 Это новые кубики в workflows для автоматизации сценариев.

62
00:19:03,580 --> 00:19:08,460
 Это более тесная интеграция с теми инструментами, которые есть уже сейчас внутри AI-студия.

63
00:19:08,880 --> 00:19:16,060
 И это дальнейшие шаги по упрощению работы и старта, и собирания запуска потоков в workflows.

64
00:19:17,000 --> 00:19:21,100
 Если говорить про следующие мероприятия, которые касаются обучения,

65
00:19:21,100 --> 00:19:24,980
 то хотели бы вас пригласить на вебинар, который будет 6 августа.

66
00:19:25,540 --> 00:19:28,840
 Он будет таким предваряющим вебинаром по теме скиллов.

67
00:19:29,420 --> 00:19:34,620
 Мы вообще начнем говорить о том, что такое скиллы, как их можно уже сейчас реализовывать в AI-студию,

68
00:19:35,000 --> 00:19:36,440
 не дожидаясь отдельного API.

69
00:19:36,980 --> 00:19:42,460
 И через какое-то время мы, как и сказал, добавим возможность и создавать,

70
00:19:42,800 --> 00:19:45,860
 и автоматически использовать скиллы в Responses API.

71
00:19:46,240 --> 00:19:48,160
 Зачем вообще мы проводим эту серию?

72
00:19:48,440 --> 00:19:50,940
 В чем я имею в виду AI-студия сериалов?

73
00:19:51,520 --> 00:19:57,700
 В первую очередь, конечно, мы видим, что есть большой набор вопросов, запросов.

74
00:19:57,940 --> 00:19:59,920
 Не везде получается разобраться в документации.

75
00:20:00,280 --> 00:20:02,100
 Много разных компонентов, платформа большая,

76
00:20:02,180 --> 00:20:06,320
 поэтому мы хотим помочь разобраться и начать работать с компонентами AI-студия.

77
00:20:06,820 --> 00:20:08,520
 Конечно, нам важен рост комьюнити.

78
00:20:08,720 --> 00:20:13,460
 И, в общем-то, сегодня мы подробнее поговорим, куда мы вообще хотим двигаться,

79
00:20:13,860 --> 00:20:17,040
 что собирают клиенты в наших технологиях и что у нас будет появляться новое.

80
00:20:17,040 --> 00:20:23,500
 И, наверное, ключевое, нам очень важна обратная связь разными способами и лично, и в чатах.

81
00:20:23,800 --> 00:20:28,620
 Поэтому, если у вас есть что поделиться, что-то болит или, наоборот, что-то нравится,

82
00:20:28,880 --> 00:20:32,760
 пожалуйста, подходите, рассказывайте, с удовольствием все это обсудим.

83
00:20:33,360 --> 00:20:36,160
 Более такой формальный способ. У нас есть отдельный портал.

84
00:20:36,400 --> 00:20:41,820
 Вы можете оставить там ваши идеи, мы все их отсматриваем и учитываем при приоритизации следующих фичей.

85
00:20:41,820 --> 00:20:45,620
 Поэтому, если у вас какие-то есть горящие запросы, чего не хватает в iStudio,

86
00:20:46,100 --> 00:20:51,140
 и что мы не рассказываем в фланах, но очень нужно, пожалуйста, оставляйте ваши идеи.

87
00:20:51,660 --> 00:20:56,460
 Если переходить к сегодняшнему мероприятию, то мы подготовили несколько выступлений.

88
00:20:57,180 --> 00:21:00,540
 Два выступления будут от наших партнеров-клиентов.

89
00:21:01,080 --> 00:21:04,920
 Одно будет посвящено текстовому агенту от компании DemiLand.

90
00:21:05,360 --> 00:21:13,580
 Коллеги расскажут о том, как они построили чат-бот в разных мессенджерах на базе iStudio для текстовых сценариев.

91
00:21:14,060 --> 00:21:19,640
 А коллеги из компании StroyNrk.com расскажут как раз про голосовых агентов и те сложности,

92
00:21:19,640 --> 00:21:22,920
 с которыми столкнулись при построении и как они эти сложности решали.

93
00:21:23,660 --> 00:21:28,260
 В заключение будет мастер-класс от архитектора из Яндекс.Клауд,

94
00:21:28,560 --> 00:21:33,620
 который расскажет про разные подходы к проектированию архитектур и агентов.

95
00:21:34,440 --> 00:21:39,720
 Ну а начать мы бы хотели с бонусного доклада от Сережи Нарбута.

96
00:21:39,960 --> 00:21:44,460
 Это руководитель разработки в iStudio.

97
00:21:44,460 --> 00:21:54,240
 И мы много говорим про разные API в iStudio, как они работают, но мы понимаем, что как бы сейчас разработкой мало кто пишет код самостоятельно с нуля.

98
00:21:54,440 --> 00:21:57,200
 То есть, как правило, это делают агенты уже сейчас.

99
00:21:57,640 --> 00:22:06,860
 И о том, как можно писать код для работы с iStudio с помощью кодекса, который работает в iStudio, подробно расскажет Сережа.

100
00:22:12,920 --> 00:22:18,320
 Всем привет. Счастья, здоровья. Мечтал сказать эту фразу со сцены достаточно давно.

101
00:22:19,140 --> 00:22:25,100
 И я чуть-чуть хочу рассказать про то, что сейчас мир уже достаточно изменился.

102
00:22:25,220 --> 00:22:32,340
 Если раньше все говорили про модельки, то на самом деле сейчас все движется вокруг Harness, вокруг агентов.

103
00:22:33,260 --> 00:22:41,620
 Мы в iStudio активно идем и разрабатываем режим совместимости с OpenAIP, а в OpenAIP есть свой, собственно, готовый агент.

104
00:22:41,620 --> 00:22:47,840
 Готовый Harness — это кодекс. И его достаточно просто запустить поверх нас.

105
00:22:47,960 --> 00:23:00,780
 Что для этого нужно? Для этого нужно всего лишь написать небольшой TOML файл с профилем для подключения к Яндекс.Студии и запустить, собственно, кодекс с нужным профилем.

106
00:23:01,740 --> 00:23:06,320
 Что же такое этот TOML файл? Во-первых, это два файлика.

107
00:23:06,700 --> 00:23:14,320
 Один из этих файлов — это, собственно, само описание профиля, то есть endpoint, способ авторизации, ограничение различных моделей.

108
00:23:14,440 --> 00:23:17,460
 А второй файл — это вот этот JSON-файл.

109
00:23:17,760 --> 00:23:25,060
 Задержим три себя просто набор моделей с их описаниями для кодекса для того, чтобы он лучше ими использовал.

110
00:23:25,440 --> 00:23:33,840
 Например, там можно задать промт отдельный, можно описать размер контекста, окна, всякий reasoning, уровни reasoning, которые поддерживают модели.

111
00:23:33,840 --> 00:23:37,020
 И запустить с флагом Яндекса и Естудии.

112
00:23:37,100 --> 00:23:45,560
 Тогда ваш кодекс будет работать напрямую поверх моделей наших, развернутых у нас, и полноценно полностью работать.

113
00:23:46,620 --> 00:23:51,920
 Соответственно, сейчас можно посмотреть уже написанную инструкцию по тому, как подключить.

114
00:23:52,000 --> 00:23:56,900
 Там есть и пример полного файла конфигурации и, собственно, сам JSON.

115
00:23:59,080 --> 00:24:02,140
 Что ж, давайте тогда посмотрим, зачем нам все это нужно делать.

116
00:24:02,300 --> 00:24:04,720
 Казалось бы, мы подключили, и что дальше?

117
00:24:07,060 --> 00:24:11,680
 Здесь вот еще есть ссылочка, кстати, на MCP к Яндекс.Облаку.

118
00:24:11,960 --> 00:24:15,540
 Так что если вы хотите управлять Яндекс.Облаком при помощи MCP,

119
00:24:15,680 --> 00:24:20,980
 вы также можете его подключить к кодексу абсолютно нативными способами и взаимодействовать с облаком.

120
00:24:21,860 --> 00:24:22,680
 Что нам это дает?

121
00:24:23,540 --> 00:24:27,900
 Во-первых, у многочисленных агентов, таких как, например, OpenCode,

122
00:24:28,320 --> 00:24:30,840
 у них есть некоторые проблемы с веб-серчем.

123
00:24:30,840 --> 00:24:33,840
 Веб-серч вам нужно настраивать полностью самим.

124
00:24:34,220 --> 00:24:37,320
 В респонсе с API и, соответственно, в кодексе поддержан веб-серч,

125
00:24:37,820 --> 00:24:40,280
 то есть поиск в интернете нативно.

126
00:24:40,620 --> 00:24:41,900
 Этот инструмент просто работает.

127
00:24:42,080 --> 00:24:47,060
 Соответственно, многочисленные задачи, которые решаются при помощи поиска,

128
00:24:47,800 --> 00:24:50,100
 агент из коробки теперь умеет делать.

129
00:24:50,960 --> 00:24:56,020
 Соответственно, вы можете полностью работать с нашими моделями,

130
00:24:56,020 --> 00:25:00,820
 работать с нашими агентами, искать информацию в интернете нативно,

131
00:25:00,960 --> 00:25:05,460
 через кодекс и для всяких задач его использовать.

132
00:25:06,260 --> 00:25:08,660
 Я слышал часто в комьюнити, как все говорили,

133
00:25:08,780 --> 00:25:12,100
 что достаточно сложно документацию Яндекс.Студии получить.

134
00:25:13,700 --> 00:25:15,740
 Сложно, если бы не было веб-серча.

135
00:25:16,500 --> 00:25:19,060
 Веб-серч прекрасно с этим справляется.

136
00:25:19,440 --> 00:25:21,580
 Я здесь запускаю агента без всяких MCP.

137
00:25:21,680 --> 00:25:23,720
 Это чистый агент с чистым веб-серчом.

138
00:25:23,720 --> 00:25:27,120
 И спрашиваю у него простой вопрос, если я там не опечатался, конечно.

139
00:25:27,640 --> 00:25:28,900
 Что же такое AI-студия?

140
00:25:29,640 --> 00:25:31,040
 Агент про AI-студию ничего не знает.

141
00:25:31,160 --> 00:25:31,960
 Это чистый кодекс.

142
00:25:32,180 --> 00:25:33,820
 Никаких системных промтов, ничего нет.

143
00:25:34,400 --> 00:25:38,100
 И мы видим то, что агент при помощи веб-серча пошел в интернет.

144
00:25:38,760 --> 00:25:40,760
 Буквально на сайт Яндекс.

145
00:25:40,980 --> 00:25:42,860
 AI-студия, смотреть документацию.

146
00:25:44,760 --> 00:25:46,260
 И вот он что-то написал.

147
00:25:46,320 --> 00:25:48,140
 Я, к сожалению, не вижу отсюда, что он написал,

148
00:25:48,220 --> 00:25:50,940
 но что-то вроде бы достаточно адекватное.

149
00:25:50,940 --> 00:25:54,520
 И теперь я в целом спрашиваю у агента

150
00:25:54,520 --> 00:25:57,680
 всякую информацию про сам респонс.

151
00:25:57,720 --> 00:25:58,740
 Как создать агента?

152
00:25:59,640 --> 00:26:05,620
 И сейчас мы увидим то, что он опять при помощи инструмента поиска по интернету,

153
00:26:05,880 --> 00:26:08,400
 который мы, кстати, недавно достаточно крупно обновили

154
00:26:08,400 --> 00:26:10,580
 и рассказывали на одном из предыдущих докладов,

155
00:26:11,060 --> 00:26:12,920
 он идет и ищет документацию.

156
00:26:14,300 --> 00:26:16,200
 Что из этого можно сделать?

157
00:26:16,260 --> 00:26:19,840
 То, что кодекс просто при запуске поверх AI-студия

158
00:26:19,840 --> 00:26:22,080
 может прекрасно находить любую информацию,

159
00:26:22,200 --> 00:26:24,000
 в том числе документацию, и писать агентов.

160
00:26:24,340 --> 00:26:25,900
 Вон он тут какой-то уже код написал,

161
00:26:25,900 --> 00:26:28,900
 как запустить агента поверх респонса SAP,

162
00:26:29,180 --> 00:26:32,860
 даже голосового агента и поверх Node.js, по-моему.

163
00:26:33,420 --> 00:26:35,000
 То есть он все нашел, все примеры,

164
00:26:35,120 --> 00:26:36,120
 теперь все он это знает.

165
00:26:38,600 --> 00:26:40,300
 Вот он все еще продолжает писать.

166
00:26:41,340 --> 00:26:43,900
 И чуть позже, когда он закончит писать,

167
00:26:43,960 --> 00:26:45,900
 я попрошу у него более сложную задачку.

168
00:26:46,680 --> 00:26:48,080
 Это рассказать про векторные индексы,

169
00:26:48,120 --> 00:26:50,300
 как ими пользоваться с точки зрения кода.

170
00:26:51,260 --> 00:26:52,560
 По-моему, я там опять опечатаюсь,

171
00:26:52,560 --> 00:26:54,520
 но это не так важно, модель прекрасно меня поймет.

172
00:26:56,160 --> 00:26:57,560
 Что же опять произойдет?

173
00:26:57,840 --> 00:26:58,720
 Все аналогично.

174
00:26:59,200 --> 00:27:01,020
 Инструмент не знает, что это такое.

175
00:27:01,120 --> 00:27:02,560
 У него есть инструмент веб-серч,

176
00:27:02,900 --> 00:27:04,380
 и он идет искать информацию.

177
00:27:05,200 --> 00:27:06,100
 Только это печатаем.

178
00:27:10,220 --> 00:27:12,260
 Как вы видите, то, что во время поиска

179
00:27:12,260 --> 00:27:14,620
 прямо в интерфейсе вы видите строчки,

180
00:27:15,260 --> 00:27:17,020
 название сайтов, которые он ищет,

181
00:27:17,100 --> 00:27:18,340
 какие сайты он открывает,

182
00:27:18,700 --> 00:27:20,300
 какие запросы он даже посылает.

183
00:27:21,740 --> 00:27:24,540
 И, как мы видим, вот снова он нашел нам код,

184
00:27:24,820 --> 00:27:28,080
 полностью скрипт, как создать векторный индекс,

185
00:27:28,380 --> 00:27:31,720
 как его использовать, все с нашей документацией.

186
00:27:32,120 --> 00:27:33,600
 Соответственно, используя кодекс,

187
00:27:34,020 --> 00:27:35,920
 вы получаете доступ к нашей документации

188
00:27:35,920 --> 00:27:37,400
 и в целом любой информации в интернете.

189
00:27:37,940 --> 00:27:39,700
 Нативно через нас не нужно настраивать

190
00:27:39,700 --> 00:27:42,000
 никакие интеграции, например, с DuckDuckGo

191
00:27:42,000 --> 00:27:44,320
 или прочими, и покупать дополнительные токены

192
00:27:44,320 --> 00:27:46,560
 в сторонних API.

193
00:27:48,360 --> 00:27:49,420
 Вот, все работает.

194
00:27:50,860 --> 00:27:52,500
 Сейчас он закончит генерировать.

195
00:27:53,740 --> 00:27:58,060
 И даже нарисовал красивую схемку в ASCII-арте.

196
00:27:58,300 --> 00:28:00,960
 В целом мог бы и в чем-нибудь другом нарисовать,

197
00:28:01,040 --> 00:28:01,860
 но я его не просил.

198
00:28:03,060 --> 00:28:06,060
 Это один из кейсов, так что ура!

199
00:28:06,220 --> 00:28:07,820
 Те, кто очень хотел искать документацию,

200
00:28:07,900 --> 00:28:10,340
 теперь могут пользоваться просто нативным веб-поиском.

201
00:28:11,520 --> 00:28:16,880
 И теперь давайте перейдем немножечко к следующей информации.

202
00:28:18,180 --> 00:28:20,680
 Тут, кажется, где-то должно быть еще одно видео.

203
00:28:22,020 --> 00:28:23,960
 Но его, видимо, нет.

204
00:28:25,460 --> 00:28:29,200
 В чем? Что еще можно делать при помощи, соответственно, кодекса?

205
00:28:29,900 --> 00:28:35,520
 Если вы подключите MCP к кодексу абсолютно нативным способом,

206
00:28:36,060 --> 00:28:41,520
 то кодекс, естественно, научится работать с EA Studio целиком.

207
00:28:42,240 --> 00:28:46,700
 Он может искать логи, смотреть, он может запускать клауд-функции,

208
00:28:46,880 --> 00:28:50,640
 создавать MCP workflows, он может пытаться понять,

209
00:28:50,640 --> 00:28:55,680
 почему у него что-то не запустилось, он может, ко всему прочему,

210
00:28:55,800 --> 00:28:57,020
 пытаться что-то дебажить.

211
00:28:58,720 --> 00:29:01,680
 Соответственно, таким образом вы получаете полноценного агента,

212
00:29:01,840 --> 00:29:04,920
 который работает поверх EA Studio, поверх кодекса,

213
00:29:05,000 --> 00:29:09,100
 вы пользуетесь всеми наработками OpenAI, но поверх нас.

214
00:29:09,560 --> 00:29:13,760
 Это достаточно выгодно, достаточно хорошо.

215
00:29:14,100 --> 00:29:18,500
 Вы получаете полную здесь изоляцию, работу внутри России,

216
00:29:18,500 --> 00:29:21,740
 но при этом вы можете пользоваться нативным инструментом.

217
00:29:21,960 --> 00:29:27,140
 Как раз это одна из целей, почему, в принципе, мы работаем в режиме OpenAI Compatible.

218
00:29:27,300 --> 00:29:30,340
 Вы не только можете писать свой код, просто подменяя endpoints,

219
00:29:30,440 --> 00:29:32,420
 но вы можете использовать готовых агентов,

220
00:29:33,140 --> 00:29:35,540
 которые представляют вам и целые агентские циклы,

221
00:29:35,880 --> 00:29:37,600
 полностью harness, веб-поиск.

222
00:29:37,820 --> 00:29:39,180
 Все это можно делать через нас.

223
00:29:39,660 --> 00:29:44,020
 Поэтому советую пользоваться, советую попробовать профиль подключения

224
00:29:44,020 --> 00:29:47,060
 и советую подключить, собственно, MCP.

225
00:29:47,180 --> 00:29:51,020
 Возможно, даже чуть позже, может быть, я сделаю и выложу плагин

226
00:29:51,020 --> 00:29:54,840
 для подключения всего Яндекс.Облака к агенту.

227
00:29:55,460 --> 00:29:56,700
 Получается достаточно хорошо.

228
00:29:57,360 --> 00:30:00,220
 Вот, было бы видео, но его, видимо, украли гномы.

229
00:30:01,260 --> 00:30:01,580
 Спасибо.

230
00:30:09,580 --> 00:30:11,940
 Так, Сереж, верните, пожалуйста.

231
00:30:12,980 --> 00:30:16,260
 Так, пару слов перед вопросами.

232
00:30:16,260 --> 00:30:23,620
 Во-первых, если у вас появляются какие-то вопросы, у вас будет те, кто в зале, задать возможность их спикеру прямо здесь.

233
00:30:23,980 --> 00:30:29,780
 Те, кто смотрит трансляцию онлайн, пожалуйста, оставляйте вопросы в чате в iStudio Community в Телеграме.

234
00:30:30,280 --> 00:30:33,320
 Мы их будем отбирать и зачитывать спикером.

235
00:30:33,760 --> 00:30:35,540
 Вот, пока вопрос от меня.

236
00:30:36,060 --> 00:30:37,440
 Ну, как бы ты рассказал про кодекс.

237
00:30:37,580 --> 00:30:42,300
 Можешь рассказать вообще про те среды для разработки, которые ты используешь?

238
00:30:42,440 --> 00:30:45,280
 Может быть, если есть что-то кроме кодекса, как ты их настраиваешь?

239
00:30:45,360 --> 00:30:47,220
 Вообще какие-то там заветы, практики?

240
00:30:47,300 --> 00:30:49,100
 Я использую достаточно много агентов.

241
00:30:49,300 --> 00:30:50,940
 Преимущественно я сейчас использую кодекс.

242
00:30:51,060 --> 00:30:55,680
 Мне нравится то, как он взаимодействует, собственно, с моделями,

243
00:30:55,760 --> 00:30:57,400
 как он взаимодействует с файловой системой.

244
00:30:57,460 --> 00:30:58,600
 Достаточно безопасно.

245
00:30:59,360 --> 00:31:03,780
 У кодекса есть различные профили защиты, режим подтверждения.

246
00:31:03,780 --> 00:31:07,860
 Например, он заблокирует сам автоматически вызов странных команд.

247
00:31:08,020 --> 00:31:11,240
 Потому что все мы знаем, что модели, запущенные на реальном железе,

248
00:31:11,300 --> 00:31:15,640
 иногда могут делать несколько странные вещи, пытаясь решить поставленную задачу.

249
00:31:16,260 --> 00:31:18,840
 Также я еще использую OpenCode.

250
00:31:19,100 --> 00:31:24,060
 OpenCode более гиковская штука, преимущественно предназначена именно для написания кода.

251
00:31:25,140 --> 00:31:28,820
 Тоже использую поверх нас, поверх уже Accompletion SAP,

252
00:31:28,820 --> 00:31:31,900
 потому что поддержка Responses в принципе можно запустить,

253
00:31:32,060 --> 00:31:35,020
 но в AppSearch, например, там из коробки не заработает.

254
00:31:35,600 --> 00:31:40,400
 Если кто-нибудь, конечно, не пойдет и не сделает полноценную поддержку Responses в OpenCode.

255
00:31:40,400 --> 00:31:44,320
 А раньше я еще пользовался VS-кодом с подключенным RU-кодом.

256
00:31:44,360 --> 00:31:50,340
 Но, как мы знаем, и RU-код закрыли свой плагин, потому что они тоже идут в полноценных агентов.

257
00:31:50,820 --> 00:31:59,420
 Как раз важно понимать то, что если всего пару месяцев назад мы все работали и писали код внутри EDE,

258
00:32:00,000 --> 00:32:03,640
 и агенты — это было, по сути, достаточно продвинутое автодополнение,

259
00:32:04,000 --> 00:32:07,880
 иногда их запускали целиком в написание кода, но все равно мы смотрелись от VDE,

260
00:32:07,880 --> 00:32:13,380
 то сейчас мир трансформируется к тому, что мы все больше и больше доверяем агентам

261
00:32:13,380 --> 00:32:17,980
 и встроенным скиллам на ревью, например, у кодекса есть встроенный скилл на ревью кода.

262
00:32:19,300 --> 00:32:25,380
 Так что нам уже, по сути, не нужно смотреть прямо непосредственно в VDE на то, что напишет агент.

263
00:32:25,820 --> 00:32:28,700
 Это, я понимаю, может быть вначале очень непривычно,

264
00:32:29,300 --> 00:32:31,620
 там страшно, что напишет агент, что он сделает,

265
00:32:31,760 --> 00:32:35,860
 но качественные модели вместе с качественным харнесом вокруг них,

266
00:32:35,860 --> 00:32:41,620
 поэтому важно харнес выбирать, позволяет решать эту проблему и писать код условно.

267
00:32:42,500 --> 00:32:45,220
 У меня, например, сейчас агент пишет код, пока я выступаю здесь.

268
00:32:46,300 --> 00:32:49,940
 Да, очень удобно. Может быть есть какие-то вопросы из аудитории?

269
00:32:51,780 --> 00:32:53,120
 Вот, да.

270
00:32:59,380 --> 00:33:00,740
 Там нужно нажимать.

271
00:33:05,860 --> 00:33:12,600
 Вы упомянули про агентов разных, но ни разу не сказали про SourceCraft Assistant, который яндексовский как раз.

272
00:33:13,480 --> 00:33:21,760
 То, что вы сейчас про кодекс рассказывали, там это идет уже из коробки, там оно есть или точно так же нужно это все подключать, чтобы оно поверх работало?

273
00:33:21,760 --> 00:33:26,560
 Смотрите, в SourceCraft, насколько я помню, сейчас нет веб-поиска.

274
00:33:27,500 --> 00:33:31,940
 Появится ли он там или нет, я сейчас не знаю, но кодекс это уже дает из коробки.

275
00:33:32,480 --> 00:33:36,760
 То есть, соответственно, если вы используете кодекс или хотите попробовать, я очень советую.

276
00:33:36,840 --> 00:33:38,420
 Это действительно прикольная штука.

277
00:33:41,640 --> 00:33:48,500
 Так, тут в онлайн появился, наверное, немножко вопрос не совсем по теме твоего доклада,

278
00:33:48,580 --> 00:33:54,260
 но тем не менее, Яндекс и студия крутая штука, и в то же самое время он выглядит как убийца стартапов,

279
00:33:54,640 --> 00:33:58,060
 потому что чем проще создавать ей продукты, тем больше конкуренции и меньше прибыли.

280
00:33:58,540 --> 00:34:02,040
 Думали ли вы про это, и как, на ваш взгляд, выжить вашим клиентам и стать лидерами в нише?

281
00:34:03,440 --> 00:34:07,000
 Придумывать прикольные идеи, делать их быстрее других и класснее других.

282
00:34:07,560 --> 00:34:10,180
 Это все такой же бизнес, как и раньше, только теперь он быстрее стал.

283
00:34:11,500 --> 00:34:13,260
 Да, в целом присоединюсь.

284
00:34:13,760 --> 00:34:15,920
 Да, спасибо большое, Сереж. Давайте поаплодируем.

285
00:34:18,420 --> 00:34:23,000
 Теперь пора перейти к части именно прикладных решений.

286
00:34:23,000 --> 00:34:26,460
 И, как я уже ранее сказал, у нас будет здесь два доклада.

287
00:34:26,940 --> 00:34:30,720
 Первый будет от Михаила из компании Demiland.

288
00:34:31,380 --> 00:34:33,780
 Мы часто видим в комьюнити, опять же, вопросы.

289
00:34:33,960 --> 00:34:41,840
 А как можно подключить моего бота, который я сделал на базе студии в Telegram или в другие мессенджеры?

290
00:34:42,160 --> 00:34:44,420
 Как может выглядеть архитектура такого решения?

291
00:34:44,820 --> 00:34:47,200
 И поэтому как раз мы решили подробнее про это рассказать.

292
00:34:47,620 --> 00:34:49,220
 Миш, приглашаю тебя. Тебя слово.

293
00:34:56,740 --> 00:34:59,840
 Всем привет. Меня зовут Миша Михайлов.

294
00:35:00,180 --> 00:35:03,660
 Я руководитель продукта Domiland в проптех направлении Яндекса.

295
00:35:04,260 --> 00:35:05,220
 В Яндексе 10 лет.

296
00:35:05,860 --> 00:35:10,140
 И я сделал и построил и ассистента для жителя в нашем решении.

297
00:35:10,460 --> 00:35:11,260
 И проект мой доклад.

298
00:35:12,400 --> 00:35:14,620
 Немного про проптех направлений Яндекса.

299
00:35:14,720 --> 00:35:18,380
 Проптех направлений Яндекса – это несколько важных историй.

300
00:35:18,880 --> 00:35:24,160
 Это приложение для жителей, которое помогает им взаимодействовать с домом и сервисами вокруг него.

301
00:35:24,680 --> 00:35:27,340
 И у нас уже больше полутора миллионов пользователей.

302
00:35:27,340 --> 00:35:31,940
 Это сервисы для управляющих компаний, которые помогают оптимизировать их работу.

303
00:35:32,460 --> 00:35:37,620
 И сервисы умных зданий, которые объединяют это в единую экосистему.

304
00:35:37,840 --> 00:35:43,040
 И пользователям, жителям становится возможность делать такие сценарии или решать такие задачи.

305
00:35:43,100 --> 00:35:48,200
 Не знаю, как будто вы идете по делам, говорите в Яндекс.Дроп, заказать пропуск гостю,

306
00:35:48,320 --> 00:35:53,540
 и он создается и автоматически падает на ресепшн вашего ЖК, если у вас закрытая территория.

307
00:35:54,500 --> 00:35:59,760
 Или пока вы готовите принятие, открыть домофон через колонку Яндекса.

308
00:36:01,400 --> 00:36:07,980
 Зачем нам и ассистент? Это несколько пунктов, и они очень важны.

309
00:36:08,360 --> 00:36:12,880
 В первую очередь мы стараемся позиционировать себя как лидеров решений,

310
00:36:12,940 --> 00:36:19,420
 лидеров решений для жителей, и в целом мы изначально всегда дискаверим такого рода направления.

311
00:36:19,980 --> 00:36:23,940
 Второе, естественным является запрос сейчас в современном мире,

312
00:36:23,940 --> 00:36:28,060
 как от наших партнеров, управляющих компаний или наших жителей,

313
00:36:28,220 --> 00:36:32,320
 потому что для всех уже привычные текстовые интерфейсы,

314
00:36:32,480 --> 00:36:35,080
 допустим, Alisa.ai или какие-то другие чаты, которые есть.

315
00:36:35,220 --> 00:36:38,840
 Соответственно, у наших всех пользователей растет запрос на то,

316
00:36:38,920 --> 00:36:43,340
 каким должен выглядеть продукт, то, как должны с продуктом взаимодействовать пользователи.

317
00:36:43,500 --> 00:36:46,820
 Их уже не устраивает простой обычный интерфейс мобильного приложения.

318
00:36:46,820 --> 00:36:52,700
 Они хотят взаимодействовать с продуктом там, где им удобно и максимально быстро и просто.

319
00:36:53,380 --> 00:36:57,640
 Ну и так как у нас продукт, который end-to-end вообще взаимодействует с пользователем,

320
00:36:58,060 --> 00:37:01,860
 мы видим сценарий, который мы можем просто оптимизировать,

321
00:37:02,040 --> 00:37:06,480
 используя какие-то базовые технологии, технологии агентские, не агентские, любые,

322
00:37:06,920 --> 00:37:09,260
 и дать пользователям простой вход.

323
00:37:09,640 --> 00:37:14,520
 Не знаю, если у вас прорвало трубу, вы просто можете написать,

324
00:37:14,520 --> 00:37:19,960
 у меня авария прорвала трубу, и большая языковая модель, агентский сценарий

325
00:37:19,960 --> 00:37:23,920
 может запросто заполнить любую форму в УК и создать эту заявку

326
00:37:23,920 --> 00:37:27,100
 или передать показания по фотографии счетчика и распознать их.

327
00:37:28,840 --> 00:37:31,800
 Что умеет сейчас наш e-ассистент?

328
00:37:32,040 --> 00:37:34,720
 e-ассистент обладает несколькими функциями.

329
00:37:34,840 --> 00:37:37,100
 Он может работать с показаниями.

330
00:37:37,500 --> 00:37:40,700
 Самая популярная из этой истории – это передача по фотографии.

331
00:37:40,700 --> 00:37:43,680
 Если вы сейчас куда-то отсылаете эту фотографию по почте,

332
00:37:44,040 --> 00:37:48,420
 сидит оператор, который глазами смотрит на цифры и заполняет за вас данные,

333
00:37:48,480 --> 00:37:50,540
 то теперь ассистент прекрасно это понимает.

334
00:37:50,900 --> 00:37:55,680
 Также ассистент может видеть ваш расход, вы сможете с ним пообщаться на тему,

335
00:37:56,000 --> 00:38:01,660
 а когда будет окно передачи показаний или когда отключат холодную воду и так далее и тому подобное.

336
00:38:02,100 --> 00:38:07,700
 Также у него есть контекст по событиям, которые вокруг дома вашего происходят,

337
00:38:07,700 --> 00:38:14,860
 или он прекрасно может найти вашу заявку, а когда же у вас свершится наконец-то помывка окон в вашем ЖК и так далее.

338
00:38:14,940 --> 00:38:17,960
 Он найдет это в информации от управляющей компании.

339
00:38:17,960 --> 00:38:27,820
 Это пример, не пример, а реальный скриншот нашего интерфейса, который интегрирован в наше приложение.

340
00:38:28,040 --> 00:38:32,720
 Это полностью чатовый интерфейс, которым пользователь может взаимодействовать как голосом, текстом

341
00:38:32,720 --> 00:38:35,580
 или прикрепить несколько фотографий счетчиков.

342
00:38:35,660 --> 00:38:39,940
 Можно сразу четыре, можно газовый, счетчик воды, что угодно.

343
00:38:40,120 --> 00:38:44,880
 Ассистент автоматически найдет его серийный номер, автоматически поймет, к какой квартире он относится.

344
00:38:45,400 --> 00:38:50,440
 И вам ничего не нужно делать, буквально просто подтвердить то ваше намерение.

345
00:38:52,520 --> 00:38:55,940
 Наш проект находится в стадии продакшена.

346
00:38:56,380 --> 00:38:59,400
 Уже больше 20 тысяч жителей им регулярно пользуются.

347
00:39:00,500 --> 00:39:04,400
 Сейчас пилот раскатан на Москву и Санкт-Петербург.

348
00:39:05,520 --> 00:39:08,960
 И пользователи регулярно взаимодействуют с ним.

349
00:39:09,060 --> 00:39:13,400
 И самый важный инсайт, который у нас сейчас есть, что порядка уже 15 обращений,

350
00:39:13,400 --> 00:39:19,360
 которые поступают в адрес управляющих компаний, используются и их выхватывает наш ассистент.

351
00:39:19,500 --> 00:39:25,100
 То есть сценарий реально работает. Это удобнее, чем дозвониться до УК

352
00:39:25,100 --> 00:39:29,120
 или создавать какую-то заявку или показания через приложение.

353
00:39:30,100 --> 00:39:37,220
 Но основные вещи, которые я вам хочу сейчас рассказать про то, не про сам продукт,

354
00:39:37,280 --> 00:39:41,400
 а как он создавался, как быстро прийти, как у меня получилось быстро прийти

355
00:39:41,400 --> 00:39:48,480
 и его продакшн-версии, может быть, для кого-то это будет известна информация,

356
00:39:48,580 --> 00:39:51,800
 но, в общем, это важные инсайты, которые точно нужно учитывать.

357
00:39:53,060 --> 00:39:56,880
 Примерно так выглядел первый пилот проекта.

358
00:39:57,040 --> 00:40:00,000
 Наверное, такой пилот выглядит абсолютно у каждого человека,

359
00:40:00,120 --> 00:40:02,780
 который пытается создать какое-то агентское решение.

360
00:40:03,140 --> 00:40:08,780
 Это агентский цикл, MCP-сервер, API какой-то, который у вас есть,

361
00:40:08,780 --> 00:40:11,600
 ну и, в общем, клиент, допустим, в нашем случае это Telegram-бот.

362
00:40:12,160 --> 00:40:16,920
 В большинстве случаев такое решение можно поднять с любой, наверное,

363
00:40:16,980 --> 00:40:21,680
 языковой моделью за пару дней, особенно на AI-студию,

364
00:40:21,760 --> 00:40:24,680
 но самая важная вещь, что это решение абсолютно не будет работать,

365
00:40:25,180 --> 00:40:29,220
 потому что такие сервисы, как, допустим, передача показаний по счетчикам,

366
00:40:29,340 --> 00:40:31,080
 создание заявок УК, они очень важные.

367
00:40:31,620 --> 00:40:35,120
 Пользователи могут, если агент будет ошибаться или передаст не то,

368
00:40:35,180 --> 00:40:38,340
 или не передаст показания, это влечет за увеличением расходов,

369
00:40:38,340 --> 00:40:39,280
 тех же самых жителей.

370
00:40:39,780 --> 00:40:41,940
 И на самом деле продакшн-версия выглядит примерно так.

371
00:40:42,100 --> 00:40:46,100
 Это только часть истории, которую я хотел показать.

372
00:40:46,260 --> 00:40:49,060
 Это большая работа на уровне цикла тулов,

373
00:40:49,160 --> 00:40:53,500
 это большая работа с MCP-сервером и с API именно конкретного сервиса,

374
00:40:53,660 --> 00:40:54,780
 который вы хотите подключить.

375
00:40:55,160 --> 00:40:57,760
 И это большой кусок, который связан с контролем качества,

376
00:40:57,860 --> 00:41:01,960
 который очень важен вообще в развитии любого агента.

377
00:41:02,660 --> 00:41:08,040
 По сути, я создал своего рода harness ЖКХ или harness для жителя,

378
00:41:08,040 --> 00:41:15,080
 который обладает набором решений и который фокусирует модели или агенток на задачи,

379
00:41:15,180 --> 00:41:23,500
 чтобы задачи пользователей решались качественно и гарантированно были безопасными.

380
00:41:25,700 --> 00:41:28,900
 Две важные вещи, которые нужно сделать в первую очередь,

381
00:41:29,000 --> 00:41:30,880
 и которые мне нужно было сделать в первую очередь,

382
00:41:31,000 --> 00:41:33,660
 это первое – решить проблему с авторизацией.

383
00:41:33,660 --> 00:41:38,520
 Очень важно, чтобы любой житель, который контактирует с ассистентом,

384
00:41:38,580 --> 00:41:44,340
 не смог запросить какие-то данные по соседней квартире,

385
00:41:44,420 --> 00:41:45,980
 по соседнему жилью.

386
00:41:46,860 --> 00:41:50,560
 И важные моменты, которые нужно было решить,

387
00:41:50,740 --> 00:41:54,660
 это то, чтобы, во-первых, не передавать креды пользователя через модель,

388
00:41:54,880 --> 00:41:57,780
 и они никаким образом не должны проходить через стек,

389
00:41:57,840 --> 00:42:01,220
 респонс, сапи, мсп и так далее и тому подобное.

390
00:42:02,020 --> 00:42:06,060
 Важно, чтобы эти креды постоянно ресетились и не были доступны,

391
00:42:06,160 --> 00:42:10,400
 и даже не были доступны в рамках, если у вас вдруг есть какие-то теплые коннекты mcp,

392
00:42:10,500 --> 00:42:14,560
 вас ждут неприятные сюрпризы, что этот теплый коннект может в какой-то степени взять

393
00:42:14,560 --> 00:42:18,140
 и использовать кред другого пользователя, сходить в API и создать заявку,

394
00:42:18,540 --> 00:42:19,940
 не знаю, под вами, например.

395
00:42:20,820 --> 00:42:24,860
 Второй шаг, очень важный на ранней стадии, и чем раньше вы это сделаете,

396
00:42:25,400 --> 00:42:31,540
 тем скорее вы запустите продукт, потому что вы на самых первых этапах поймете,

397
00:42:31,540 --> 00:42:35,460
 что то, что отвечает ваш агент на те запросы, которые вы пытаетесь ему сказать,

398
00:42:35,580 --> 00:42:38,600
 и вы думаете, что он классно отвечает, на самом деле это не так.

399
00:42:39,340 --> 00:42:43,000
 Нужно построить инфраструктуру или использовать какую-то инфраструктуру

400
00:42:43,000 --> 00:42:47,940
 для прогона и составления вал корпусов или корзин, как мы называем,

401
00:42:48,340 --> 00:42:52,540
 и чем раньше вы создадите и наберете корзины синтетические, полусинтетические,

402
00:42:53,220 --> 00:42:57,920
 которые будут отвечать какому-то срезу ваших запросов, тем лучше.

403
00:42:57,920 --> 00:43:05,860
 И еще один важный момент. Инфраструктура прогона всегда должна поддерживаться полным стэком логирования

404
00:43:05,860 --> 00:43:09,500
 от того, что пользователь пишет в чате, до полных ответов API.

405
00:43:09,620 --> 00:43:14,260
 Это позволит вам очень быстро итерировать на любом этапе развития продукта.

406
00:43:14,360 --> 00:43:18,540
 В моем случае у меня был реализован специальный так называемый LLM-судья,

407
00:43:18,760 --> 00:43:21,740
 помимо моего, допустим, личных разметок, как мы их называем, D-SAT,

408
00:43:24,160 --> 00:43:29,100
 который я загружал, какой-то оперативный срез с какого-то этапа теста.

409
00:43:29,460 --> 00:43:33,060
 Он тут же сверял именно, как отвечает модель с точки зрения ожидаемых ответов,

410
00:43:33,140 --> 00:43:38,600
 но также на проблемах, которые он видел, у него был полный доступ к полному стеку логирования

411
00:43:38,600 --> 00:43:46,740
 и выдавал зачастую абсолютно полные рекомендации, как решить ту или иную проблему.

412
00:43:46,740 --> 00:43:52,320
 И на самом деле, отматываясь назад, тот стек решений, который в итоге привел к проду,

413
00:43:52,460 --> 00:43:56,740
 и благодаря этой истории полностью свершился.

414
00:43:56,960 --> 00:44:00,260
 Это просто база, никогда не надо делать…

415
00:44:00,260 --> 00:44:03,780
 Всегда нужна инфраструктура, всегда нужны вал корпуса,

416
00:44:04,180 --> 00:44:06,000
 и вам всегда нужно контролировать качество.

417
00:44:06,100 --> 00:44:09,400
 Вы всегда будете думать, что вы подключили самую мощную модель,

418
00:44:09,480 --> 00:44:11,140
 и она не врет, на самом деле это не так.

419
00:44:12,760 --> 00:44:19,320
 После двух шагов, которые вы будете делать, особенно в текстовых решениях,

420
00:44:19,320 --> 00:44:22,740
 вы столкнетесь с тем, что вам нужна память и контекст.

421
00:44:23,180 --> 00:44:27,300
 Это очень важная вещь, потому что если у вас решение в рамках Telegram-бота

422
00:44:27,300 --> 00:44:30,100
 или ваш собственный чат интегрирован в приложение,

423
00:44:30,420 --> 00:44:34,200
 в любом случае пользователь общается, уже привык общаться в виде диалога,

424
00:44:34,260 --> 00:44:37,920
 он будет спрашивать, что у меня с показаниями холодной воды,

425
00:44:38,080 --> 00:44:41,080
 узнает, что срок поверки вашего счетчика истек,

426
00:44:41,160 --> 00:44:43,880
 предложится дать заявку, и во всем этом пути вам нужно,

427
00:44:44,460 --> 00:44:46,080
 чтобы агент не терял контекст.

428
00:44:46,080 --> 00:44:50,200
 И в моем случае важные вещи, которые приходилось делать,

429
00:44:50,320 --> 00:44:53,420
 и пришлось делать, и архитектурно продумывать историю,

430
00:44:53,500 --> 00:44:58,980
 это, по сути, держать, инжектить в контекст агента

431
00:44:58,980 --> 00:45:04,960
 всегда ID, квартиры, метаданные, необходимые для текущего диалога,

432
00:45:05,040 --> 00:45:10,160
 чтобы агент не эволюционировал и не выдумывал,

433
00:45:10,220 --> 00:45:12,700
 не переспрашивал, для какой квартиры все-таки идет речь,

434
00:45:12,700 --> 00:45:16,700
 и без этих вещей вы просто будете неожиданно встречать вопросы,

435
00:45:16,840 --> 00:45:21,720
 а как же вы почти создали заявку, он просит вас подтверждение,

436
00:45:21,800 --> 00:45:26,840
 вы говорите да, и вдруг он решает спросить, для какой же квартиры вы создаете заявку.

437
00:45:26,920 --> 00:45:30,900
 Или реальная история, когда агент вдруг решает несколько раз уточнить,

438
00:45:30,980 --> 00:45:33,560
 а какой же все-таки ID-шник у вашей одной квартиры,

439
00:45:33,660 --> 00:45:36,820
 а у нас больше 20 пользователей имеют несколько квартир,

440
00:45:36,880 --> 00:45:39,160
 которые они обслуживают через одно приложение.

441
00:45:39,160 --> 00:45:44,720
 И как это сделать? Это инъекция, это контроль контекста по той квартире,

442
00:45:44,900 --> 00:45:52,320
 с которой вы ведете диалог, и самое важное, это дает вам экономию тулколов,

443
00:45:52,460 --> 00:45:57,900
 которые очень важны, они дорогие, и, в общем, это непременная история, которая должна быть.

444
00:46:00,140 --> 00:46:04,500
 После того, как вы разоберетесь с историей, у вас начинает всплывать еще больше проблем.

445
00:46:05,060 --> 00:46:06,780
 Это достоверность ответов.

446
00:46:06,780 --> 00:46:12,760
 Мне кажется, каждый начинает на это натыкаться, какая бы у вас модель была или не была.

447
00:46:12,880 --> 00:46:18,420
 Вы думаете, вы сейчас поставите самую дорогую модель, доступную в AI-студию, и точно она не ошибется.

448
00:46:18,520 --> 00:46:24,180
 А вы готовы дать хотя бы одному проценту пользователю возможность отправить неправильные показания?

449
00:46:24,300 --> 00:46:27,140
 Наверное, нет. В таких критичных сервисах это очень важно.

450
00:46:28,480 --> 00:46:36,200
 И у меня есть несколько примеров вещей, которые не пришлось делать, которые необходимо сделать для контроля агента.

451
00:46:36,200 --> 00:46:44,240
 Это иерархия доверия фактам. На самом деле контекст строится из нескольких слоев.

452
00:46:44,440 --> 00:46:55,480
 Ответ Тула, контекст текущего диалога, который содержит какой-то ID, ID текущего дома, информацию, доступные показания, недоступные показания, все что угодно и так далее и тому подобное.

453
00:46:55,480 --> 00:47:21,140
 И сверху история диалога. И забавные на eval прогонах, которые мы делаем, забавные истории, когда модель может взять какой-то прошлый ответ из предыдущего диалога пользователя, он подавал какую-то заявку другую, создает новую, и он просто при белом свете начинает врать и говорить, что я ее создал, и вы абсолютно не понимаете, правда это или нет, это очень критичная история.

454
00:47:21,140 --> 00:47:40,740
 И как раз вот создание иерархии доверия, иерархии приоритетов, это важная история, которая действительно может быть и в System Prompt, она хорошо эффективно работает, но это нужно сделать, и System Prompt тоже должен выглядеть так, чтобы модель понимала саму по себе иерархию инструкций, которые дают.

455
00:47:42,260 --> 00:48:08,140
 Вторая история – это детерминизм ответов. Вообще детерминизм – это важные вещи, включая иденпатентность, которая касается вообще операции записи, но детерминизм ответов здесь важно делать в том, что, представьте, вы отправляете показания холодной воды, отправляете показания электрических счетчиков, модель принимает эти показания, неважно откуда, распознает, формирует запрос в тул записи,

456
00:48:08,140 --> 00:48:18,760
 и тут приходит ответ, что, допустим, по электрическим показаниям окно закрыто, они не принимаются, но холодную воду мы можем передать.

457
00:48:18,860 --> 00:48:27,420
 Ну, так работает реальный IP, и модель может просто сказать, что все хорошо завершилось, я все передала, но на самом деле это не так.

458
00:48:27,420 --> 00:48:45,240
 И вообще, когда вы работаете с операциями записи, не стоит обольщаться, что то, что пишет модель, действительно случилось, поэтому во всех операциях записи, форматирование и подачу результата нужно забирать на себя, и в этом самый главный детерминизм.

459
00:48:45,240 --> 00:48:54,700
 У меня все ответы шаблонизированы, это очень важно, особенно в таких чувствительных историях, как ЖКХ и, может, любых других, которые у нас есть.

460
00:48:55,400 --> 00:48:59,680
 И еще один такой небольшой инсайт, который всплыл не совсем давно.

461
00:49:00,620 --> 00:49:08,640
 Вы можете, ну, допустим, у меня порядка 20 тулов подключено к агенту, и важный инсайт в том, что есть и достаточно хорошее описание их,

462
00:49:08,640 --> 00:49:16,820
 но если вы не записали, что какие-то функции явно недоступны или не указали в них, что все, что тут не проговорено, запрещено,

463
00:49:17,280 --> 00:49:23,580
 то модель будет очень легко выдумывать, что, допустим, можно отправлять сообщения в заявке в УК, хотя это нельзя,

464
00:49:23,800 --> 00:49:29,300
 но в описании модели, допустим, описано, что да, ты можешь передать заявку в УК,

465
00:49:29,560 --> 00:49:33,100
 даже ты можешь, чтобы прочитать сообщение, можешь пойти и сходить в другой тул,

466
00:49:33,160 --> 00:49:40,940
 но если вы будете забывать описывать то, что нельзя, вы точно наткнетесь на такие случаи.

467
00:49:40,940 --> 00:49:46,600
 Важный момент, что эти все случаи вы можете просто при каком-то своем ручном тесте вообще просто даже не видеть.

468
00:49:46,980 --> 00:49:51,380
 Это важно учесть, и вам очень нужно эволюционировать, тестировать корзину, прогонять,

469
00:49:51,500 --> 00:49:54,820
 и вы увидите, насколько вариативные ответы вы получаете.

470
00:49:56,940 --> 00:50:03,980
 И третий слой, с которым вы уже начнете сталкиваться, и с которым сталкиваюсь я, это реальные API, которые у вас есть.

471
00:50:04,540 --> 00:50:12,340
 API могут быть разные. Время на MVP небольшое. Хочется запустить за два месяца, чтобы проверить концепцию.

472
00:50:12,780 --> 00:50:18,800
 И нет времени давать команду разработчикам, давайте перепишем API, особенно если оно, допустим, написано на PHP.

473
00:50:19,200 --> 00:50:28,960
 И здесь тоже есть несколько важных моментов. В первую очередь хотел подчеркнуть про операции записи.

474
00:50:30,620 --> 00:50:41,920
 Важно, чтобы никогда в модели не было инструкции и никогда вы не пытались подвергать себя сомнению, что стоит модели давать такую важную историю и писать,

475
00:50:41,920 --> 00:50:47,580
 что точно контролируя каждый этап записи, спрашивая пользователя подтверждения.

476
00:50:47,900 --> 00:50:57,460
 Если вы прикрутите историю к своему боту и, допустим, у вас есть диалог и в предыдущем диалоге есть окей от пользователя и он создает новую заявку,

477
00:50:58,840 --> 00:51:05,660
 агент любая модель легко загаллюцинирует и просто прогонит новую отправку показаний, не спросив у пользователя.

478
00:51:05,660 --> 00:51:16,980
 Поэтому в нашем решении реализованы обязательные коллбеки и все операции записи требуют сигнала прожатого пользователям именно от кода, а не от модели.

479
00:51:17,380 --> 00:51:24,020
 Это важная вещь именно в контексте взаимодействия уже с реальными API, как и с авторизацией.

480
00:51:25,400 --> 00:51:30,680
 Еще интересная история, которая касается именно особенностей нашего продукта.

481
00:51:31,360 --> 00:51:37,020
 Заявки любая управляющая компания, любой партнер может сформировать с помощью специального конструктора.

482
00:51:37,460 --> 00:51:41,880
 И у одного партнера вызов сантехника может выглядеть в виде простой формы,

483
00:51:41,940 --> 00:51:46,860
 у другого партнера это будет выбор времени, выбор слота, нужно обязательно пройти несколько этапов.

484
00:51:46,860 --> 00:51:54,380
 И в общем в моем случае формат, агент ходил за форматом любой формы,

485
00:51:54,460 --> 00:51:57,560
 но этот формат предоставлялся в виде такой html-разметки,

486
00:51:57,700 --> 00:52:01,800
 условно подготовленной под верстку в мобильном приложении.

487
00:52:01,980 --> 00:52:06,900
 И была большая проблема, что разный набор этих данных, допустим какие-то радио баттоны,

488
00:52:07,340 --> 00:52:12,700
 модель видела, но не могла правильно упаковать их в тул записи,

489
00:52:12,800 --> 00:52:15,520
 чтобы дать форме записи нужный формат.

490
00:52:16,340 --> 00:52:23,640
 И писать прям такой адаптер, который разные типы вот этих заявок в УК транслирует уже в нормализованный формат.

491
00:52:24,160 --> 00:52:31,240
 И это буквально заняло день, если честно, с помощью других моделей, которыми я пишу программы.

492
00:52:31,240 --> 00:52:38,780
 И после этого решения теперь любая заявка, какой только у нас в любом жилом комплексе, который есть,

493
00:52:39,060 --> 00:52:42,640
 и стенд прекрасно справляется, он может сделать все в один заход.

494
00:52:45,820 --> 00:52:48,460
 Важная история про верификацию.

495
00:52:49,180 --> 00:52:54,660
 Если, допустим, как у нас есть возможность у пользователя как-то ошибиться,

496
00:52:54,660 --> 00:52:59,120
 допустим, показания счетчика, он ошибится, неправильно напишет точку,

497
00:52:59,200 --> 00:53:07,980
 или вдруг, допустим, какую-то ошибку, верификация тоже нужна только на API интерфейсах.

498
00:53:08,640 --> 00:53:14,580
 В первых версиях, которые MCP понимали, было реализовано System Prompt,

499
00:53:14,700 --> 00:53:16,860
 но сразу понимал, что это не финальная картина,

500
00:53:16,940 --> 00:53:20,780
 но было просто забавно наблюдать, как эти guardrails работают.

501
00:53:20,880 --> 00:53:21,980
 Ну, в общем, абсолютно никак.

502
00:53:22,300 --> 00:53:24,660
 Конечно, на более старших моделях работает понадежнее,

503
00:53:24,780 --> 00:53:33,320
 но опять же вернусь к тому, что 10% ошибок тоже в таком случае достаточно критично,

504
00:53:33,320 --> 00:53:39,720
 и любые операции записи и верификации нужно делать все-таки на API.

505
00:53:41,400 --> 00:53:46,920
 И самая финальная история, которая была сделана, это вообще свой функцион луп,

506
00:53:47,340 --> 00:53:55,560
 который служит для того, чтобы контролировать вообще работу агента как решения,

507
00:53:56,080 --> 00:54:01,840
 который контролирует затраты на токены, который контролирует работу авторизации,

508
00:54:01,840 --> 00:54:09,620
 если нужно минтить новые токены, вдруг они у вас протухнут посреди диалога и вообще контролирует порядок вызова-улов,

509
00:54:09,740 --> 00:54:15,960
 потому что если, допустим, у вас какая-то сложная заявка, вы, допустим, закажите сантехника на ближайшее время,

510
00:54:16,060 --> 00:54:22,820
 на самом деле под капотом он может сходить узнать какое время, какой сантехник доступен, вообще какой тип заявки есть,

511
00:54:22,820 --> 00:54:31,320
 и результаты этих тулов в рамках раунда могут быть вообще перемешаны, и модель может выполнить совершенно не то.

512
00:54:31,440 --> 00:54:37,780
 Здесь идет строгий контроль последовательности. В общем, свой фанкшн луп, обязательно история, и больше скажу,

513
00:54:38,080 --> 00:54:44,000
 из последних вещей, которые делали для того, чтобы вообще лучше контролировать ответ модели,

514
00:54:44,120 --> 00:54:50,540
 это инъекция именно в ответ тулов. Когда тул отвечает, мы инъектим нужный контекст,

515
00:54:50,940 --> 00:54:54,040
 который лучше считывается, чем расположенный в System Prime T.

516
00:54:54,040 --> 00:54:59,400
 Это 100% проверенный факт. Это один из таких приемов, которые я использовал.

517
00:55:00,560 --> 00:55:07,460
 Ну и подводя итог вообще к той истории, которая у меня получилась, самая важная вещь.

518
00:55:07,620 --> 00:55:09,640
 Все-таки агент — это не просто LM-тулы.

519
00:55:10,180 --> 00:55:16,720
 Весь мир идет в то направление, что нужны четкие какие-то hardness, которые решают конкретную задачу.

520
00:55:16,720 --> 00:55:23,040
 И модель действительно важна только когда понимать запрос пользователей, выбрать, какое действие сделать.

521
00:55:23,140 --> 00:55:31,480
 Все остальное, если вы хотите, если вы работаете с чувствительными сервисами, не стоит отдавать на откуп модели,

522
00:55:31,560 --> 00:55:37,020
 даже если она у вас, как вы считаете, самая мощная и дорогая, но все-таки нужна и экономика.

523
00:55:37,160 --> 00:55:45,700
 Что по итогу? У меня получилось разработать полностью продовое решение, которое сейчас эксплуатируется и которое мы вообще продаем нашим партнерам.

524
00:55:46,860 --> 00:55:54,820
 Заняло время, ну, календарно это два месяца, но на самом деле у меня большой скоуп обязанностей, и я делал, можно сказать, это не фулл-тайм.

525
00:55:55,360 --> 00:56:03,140
 Мне помогал мой подход, ну, и как у многих подход. Я не люблю слово вайп-код, потому что вайп-код это когда ты написал какой-то промпт,

526
00:56:03,140 --> 00:56:11,920
 и вдруг создалось что-то большое. Здесь это планомерная работа, архитектурная работа, и я лучше люблю называть это AI-driven development.

527
00:56:12,800 --> 00:56:17,960
 Помогла инфраструктура облака, развернуть быстрые решения, собрать быстрый прототип.

528
00:56:18,020 --> 00:56:23,880
 И самое важное, что нужно выносить все равно из модели больше, чем вам кажется.

529
00:56:24,160 --> 00:56:31,880
 На первом этапе собрать прототип, поиграться хорошо, но 90% времени вам придется заниматься теми вещами,

530
00:56:31,880 --> 00:56:36,300
 про которые я вам рассказывал. Это очень важно. Спасибо.

531
00:56:41,920 --> 00:56:46,340
 Миш, спасибо тебе большое за рассказ. Может быть появились какие-то вопросы?

532
00:57:00,620 --> 00:57:10,180
 Что-то не очень. Спасибо большое за доклад. У меня, наверное, вопрос, какого процента ошибки вам удалось добиться.

533
00:57:10,740 --> 00:57:13,860
 Понятно, что это не может быть совсем без ошибок.

534
00:57:14,740 --> 00:57:19,360
 На самом деле в операциях записи у нас стопроцентная точность.

535
00:57:20,300 --> 00:57:21,880
 Больше с ошибками боремся.

536
00:57:22,300 --> 00:57:26,060
 Это вокруг семантики того, что может ответить модель.

537
00:57:26,440 --> 00:57:31,260
 Потому что пользователи могут спросить тот домен, который они не знают.

538
00:57:31,340 --> 00:57:36,040
 Но, допустим, часть функций, которые, допустим, покажи счета, он не отвечает.

539
00:57:36,040 --> 00:57:40,860
 Он просто дает нативную ссылку на нужный экран приложения, что тоже как бы удобно.

540
00:57:41,280 --> 00:57:44,840
 Но, в общем, весь спектр запросов пользователя очень сложно охватить.

541
00:57:45,180 --> 00:57:52,020
 Поэтому мы регулярно пополняем live корзинки, чтобы именно корректировать именно эти ответы.

542
00:57:52,140 --> 00:58:03,140
 Но нам очень важно, чтобы все заявки, которые создавались, все показания, которые отправлялись, были полностью правильными.

543
00:58:03,460 --> 00:58:05,700
 Единственные могут быть неточности.

544
00:58:05,860 --> 00:58:08,120
 Это показания, которые передаются с помощью счетчиков.

545
00:58:09,320 --> 00:58:13,840
 И это больше касается того, что счетчики расположены неудобно.

546
00:58:14,080 --> 00:58:16,220
 Присылают фотографии, где блики, закрывают цифры.

547
00:58:16,280 --> 00:58:17,600
 Там никакая модель не справится.

548
00:58:17,600 --> 00:58:22,120
 Но, тем не менее, у нас есть специальная корзина таких кривых показаний счетчиков.

549
00:58:22,140 --> 00:58:24,400
 У нас больше 80% в этом качества.

550
00:58:24,740 --> 00:58:28,960
 Но нам помогает в этом механизм сверки с текущими показаниями пользователя в модели.

551
00:58:29,480 --> 00:58:32,660
 И в любом случае, любое подтверждение пользователя идет,

552
00:58:33,240 --> 00:58:35,200
 то есть модель сама ничего не запишет.

553
00:58:36,100 --> 00:58:40,140
 То есть здесь все-таки пользователя мы, естественно, не убираем, да?

554
00:58:40,260 --> 00:58:42,300
 То есть он в итоге верифицирует.

555
00:58:42,300 --> 00:58:44,760
 Нет, пользователь должен быть обязательно,

556
00:58:46,020 --> 00:58:48,180
 особенно в таких каких-то чувствительных сервисах.

557
00:58:48,760 --> 00:58:52,680
 Ну, на самом деле, ассистент сделан и спроектирован так,

558
00:58:52,840 --> 00:58:55,720
 что если вы дали в запросе максимальное количество информации,

559
00:58:55,960 --> 00:58:57,240
 не знаю, для какой-то сложной заявки,

560
00:58:57,640 --> 00:59:00,200
 запиши меня, не знаю, закажи пропуск на завтра

561
00:59:00,200 --> 00:59:04,900
 и на послезавтра, на через неделю для такого-то номера автомобиля,

562
00:59:05,020 --> 00:59:08,120
 он обязательно это создаст, не будет спрашивать у вас ничего,

563
00:59:08,120 --> 00:59:11,100
 если ему хватает данных, но итоговый результат он сформирует.

564
00:59:12,320 --> 00:59:16,380
 И подтверждение идет обязательно через явный пользовательский аппрув.

565
00:59:16,780 --> 00:59:19,860
 И вообще это было и требование в целом партнеров зачастую,

566
00:59:20,020 --> 00:59:25,940
 потому что все-таки я не считаю, что сейчас прям качество моделей такое,

567
00:59:26,740 --> 00:59:30,100
 что стоит вообще доверять особенно запись критичных данных.

568
00:59:30,200 --> 00:59:33,600
 А показания — это очень важная история, которая может привлечь к тому,

569
00:59:33,600 --> 00:59:37,800
 что у вас вообще как бы вам пересчитают, вы заплатили больше и так далее.

570
00:59:38,480 --> 00:59:42,640
 А у вас есть какая-то оценка именно от пользователей?

571
00:59:43,720 --> 00:59:47,140
 То есть они выставляют там оценку качества ответа?

572
00:59:47,420 --> 00:59:49,140
 У нас сейчас такой истории нет.

573
00:59:49,280 --> 00:59:51,660
 Мы на этапе MVP, который запускали, не предусмотрели,

574
00:59:51,740 --> 00:59:53,760
 но у нас есть это в ближайшем бэклоге.

575
00:59:53,980 --> 00:59:55,460
 Но в рамках пилота мы пока не оценим.

576
00:59:55,520 --> 01:00:00,760
 Мы регулярно снимаем снимки и прогоняем их по LM-ассистенту

577
01:00:00,760 --> 01:00:02,240
 и смотрим, есть ли какие-то проблемы.

578
01:00:02,700 --> 01:00:02,940
 Спасибо.

579
01:00:02,940 --> 01:00:06,580
 Но, если честно, больше проблем бывают каких-то архитектурных зачастую.

580
01:00:13,580 --> 01:00:15,680
 Благодарю вас за доклад.

581
01:00:16,340 --> 01:00:18,060
 У меня вопрос насчет разработки.

582
01:00:18,200 --> 01:00:25,560
 Получается, вы обошлись без разработчиков, но при этом пилот подразумевает под собой,

583
01:00:25,900 --> 01:00:30,220
 что нужно еще очень много отлаживать и дебажить то, что написано.

584
01:00:30,220 --> 01:00:32,820
 Вы понимаете то, что написано в коде?

585
01:00:33,100 --> 01:00:37,580
 И если возникнут какие-то баги, как вы их чините тоже через нейронку?

586
01:00:37,740 --> 01:00:39,000
 Ну, я же как-то написал.

587
01:00:39,120 --> 01:00:42,200
 Ну, то есть изначальный продукт был написан, правда, без разработки.

588
01:00:42,680 --> 01:00:47,140
 И даже та небольшая помощь, которая нужна была от мобильной разработки,

589
01:00:47,140 --> 01:00:50,500
 был подготовлен прототип, который, не знаю, правильно показывал,

590
01:00:50,600 --> 01:00:54,960
 как по GSMOS2 общаться с мобильным приложением и так далее.

591
01:00:55,660 --> 01:01:00,100
 И, соответственно, корректировку я тоже делаю с помощью языковых моделей.

592
01:01:00,260 --> 01:01:03,180
 Но у меня вообще образование разработчик, программист, инженер.

593
01:01:03,700 --> 01:01:06,140
 Но я как бы не на таком уровне владею.

594
01:01:06,900 --> 01:01:08,880
 Моя основная специальность – это управление продуктами.

595
01:01:09,440 --> 01:01:14,980
 Но, тем не менее, мне позволило разработать его без вообще разработки и за короткий срок.

596
01:01:16,240 --> 01:01:18,880
 Спасибо. Можно я дополню свой вопрос?

597
01:01:19,440 --> 01:01:23,200
 А при масштабировании предполагается поддержка разработчиками?

598
01:01:23,480 --> 01:01:26,700
 Обязательно. Ну, в любом случае было код-ревью еще внутреннее.

599
01:01:26,840 --> 01:01:29,720
 Но в любом случае это очень важный момент.

600
01:01:29,720 --> 01:01:34,440
 То есть очень хорошо получается MVP в любом случае.

601
01:01:34,740 --> 01:01:37,060
 Но MVP хороший, можно их назвать MLV.

602
01:01:37,520 --> 01:01:40,820
 То есть продукт, который я запустил, он полностью функционален.

603
01:01:41,280 --> 01:01:42,500
 Он решает задачи.

604
01:01:43,040 --> 01:01:48,060
 Вопрос доказать, что он действительно важен, он работает, он продается.

605
01:01:48,780 --> 01:01:50,000
 И на это не ушло.

606
01:01:50,120 --> 01:01:52,860
 Два бэкэндера, один фронтэндер, тестировщик и так далее.

607
01:01:53,220 --> 01:01:54,340
 И это очень важно.

608
01:01:54,340 --> 01:01:56,900
 И за короткий срок мы можем тестить идеи.

609
01:01:58,800 --> 01:02:02,700
 Мне кажется, это залог современного успеха любого бизнеса.

610
01:02:04,020 --> 01:02:04,780
 Спасибо.

611
01:02:06,340 --> 01:02:07,060
 Здравствуйте.

612
01:02:07,060 --> 01:02:10,100
 Спасибо за доклад.

613
01:02:10,300 --> 01:02:12,260
 Достаточно перспективная, интересная штука.

614
01:02:13,540 --> 01:02:15,980
 Понятно, что два месяца MVP у вас сейчас,

615
01:02:16,100 --> 01:02:17,480
 но наверняка у вас есть уже понимание

616
01:02:17,480 --> 01:02:21,140
 о технологической зрелости всех структур,

617
01:02:21,460 --> 01:02:23,760
 ЖКХ, к кому вы коннектитесь.

618
01:02:23,860 --> 01:02:25,100
 По сути, это ваш набор скиллов,

619
01:02:25,200 --> 01:02:26,340
 которыми вы будете управлять.

620
01:02:26,680 --> 01:02:28,760
 Как вы оценили сейчас технологическую зрелость

621
01:02:28,760 --> 01:02:30,400
 вот этих всех структур?

622
01:02:31,160 --> 01:02:33,040
 Вы там упомянули, что много форм,

623
01:02:33,180 --> 01:02:35,200
 различного формата, вы их адаптируете.

624
01:02:35,200 --> 01:02:36,760
 По сути, костыли какие-то делаете,

625
01:02:36,820 --> 01:02:37,880
 для того, чтобы трансформировать

626
01:02:37,880 --> 01:02:39,080
 в удобный формат.

627
01:02:39,380 --> 01:02:40,500
 Вот по десятибальной шкале

628
01:02:40,500 --> 01:02:41,980
 как бы оценили технологическую зрелость?

629
01:02:42,060 --> 01:02:43,160
 Есть ли куда-то расти еще?

630
01:02:43,760 --> 01:02:45,360
 И будет ли улучшаться этот прогресс,

631
01:02:45,500 --> 01:02:47,460
 улучшаться их технологическая зрелость,

632
01:02:47,560 --> 01:02:48,360
 к которой вы будете канатиться?

633
01:02:48,460 --> 01:02:50,100
 Ну, тут важная ремарка в том,

634
01:02:50,180 --> 01:02:53,740
 что и ассистент, про который я говорю,

635
01:02:53,860 --> 01:02:56,500
 он работает условным таком

636
01:02:56,500 --> 01:02:58,520
 заменителем мобильного приложения.

637
01:02:58,700 --> 01:03:03,040
 То есть функции, которые он выполняет,

638
01:03:03,040 --> 01:03:04,940
 может сделать и просто через мобильное приложение.

639
01:03:05,180 --> 01:03:06,980
 Потому что это может быть уже не так удобно.

640
01:03:07,980 --> 01:03:11,620
 Второе, подключение партнеров и взаимодействие с партнерами

641
01:03:11,620 --> 01:03:14,060
 проходит на более низком уровне на самом деле.

642
01:03:14,800 --> 01:03:17,360
 И все зависит вообще от региона, от партнера.

643
01:03:17,740 --> 01:03:21,300
 Есть прям партнеры, которые заряжены и хорошо развивают IT.

644
01:03:21,800 --> 01:03:23,800
 Есть те, которые не развивают IT.

645
01:03:23,960 --> 01:03:27,660
 Но в целом, наверное, это мое неэкспертное мнение,

646
01:03:27,800 --> 01:03:29,960
 потому что я не так много с ними общаюсь.

647
01:03:30,520 --> 01:03:33,700
 Наверное, все-таки большинство старого жилого фонда

648
01:03:33,700 --> 01:03:38,860
 можно… там достаточно низкая база для улучшения, скажем так.

649
01:03:40,420 --> 01:03:40,940
 Понятно, спасибо.

650
01:03:40,940 --> 01:03:45,100
 Ну, такие сценарии умные, как проход по BLE, допустим,

651
01:03:45,300 --> 01:03:48,240
 реализовать может быть достаточно сложно сразу.

652
01:03:48,360 --> 01:03:50,260
 Просто есть ощущение, что… извините, дополню,

653
01:03:50,400 --> 01:03:53,500
 что сейчас большинство ЖКХ – это некая такая бумажная волокита,

654
01:03:53,600 --> 01:03:55,500
 куда принести подписанный какой-то документ,

655
01:03:55,540 --> 01:03:58,100
 а вы говорите, там, отправить показания, какие-то данные.

656
01:03:58,240 --> 01:04:02,240
 То есть вот насколько интересно, готовы, собственно, взаимодействовать.

657
01:04:02,420 --> 01:04:03,180
 Приходится ли вам…

658
01:04:03,180 --> 01:04:07,020
 Самостоятельно приходить туда к ним и говорить,

659
01:04:07,100 --> 01:04:08,380
 давайте подключать их к нам в систему,

660
01:04:08,480 --> 01:04:09,900
 или они как-то сами напрашиваются?

661
01:04:10,120 --> 01:04:13,800
 Слушайте, ну у нас уже как бы большой интерес от наших партнеров.

662
01:04:14,580 --> 01:04:17,600
 У нас недавно была пиар-акция про эту историю,

663
01:04:17,740 --> 01:04:21,860
 вот поэтому интерес есть и, я бы сказал, очередь.

664
01:04:22,580 --> 01:04:23,380
 Последний момент можно?

665
01:04:23,680 --> 01:04:26,020
 То есть вы как-то аргументируете, что вы снимаете нагрузку на них,

666
01:04:26,100 --> 01:04:27,280
 то есть у них уже какой-то должен быть интерес?

667
01:04:27,280 --> 01:04:32,360
 Смотрите, в первую очередь это B2C-продукт, он нужен, чтобы сделать,

668
01:04:32,660 --> 01:04:36,880
 взаимодействие пользователя с таким сложным миром удобнее.

669
01:04:37,560 --> 01:04:40,620
 Это только начало те истории, которые мы реализовали,

670
01:04:40,740 --> 01:04:42,820
 это, наверное, наиболее такие частые сценарии.

671
01:04:43,620 --> 01:04:48,600
 И обязательным эффектом этого является то, что обращение,

672
01:04:48,940 --> 01:04:51,860
 и, как я сказал, уже 15% обращений выхватывает,

673
01:04:51,860 --> 01:04:57,800
 и обращение, нагрузка на управляющие компании, на обработку их становится меньше

674
01:04:57,800 --> 01:05:01,660
 и будет только больше с подключением каких-то других модулей.

675
01:05:02,140 --> 01:05:04,980
 Маленький момент еще добавляем.

676
01:05:05,400 --> 01:05:10,400
 Такое ощущение, наоборот, что через B2B вам было бы быстрее выйти на большее количество пользователей,

677
01:05:10,500 --> 01:05:14,800
 потому что если вы продадите свой продукт организациям, управляющим компаниям,

678
01:05:15,020 --> 01:05:16,120
 то они быстрее…

679
01:05:16,120 --> 01:05:18,880
 Мы этот продукт продаем нашим партнерам и организациям.

680
01:05:18,880 --> 01:05:19,540
 Все хорошо.

681
01:05:27,420 --> 01:05:28,380
 Почти разобрался.

682
01:05:29,260 --> 01:05:34,620
 Подскажите, на самом деле я уже услышал часть ответа на свой вопрос.

683
01:05:35,080 --> 01:05:39,580
 В целом просто интересно, а вы с точки зрения какой-то некоторой экономики подсчитывали этот проект?

684
01:05:39,720 --> 01:05:45,340
 Потому что, с одной стороны, у вас написан продукт, который упрощает жизнь простым жителям,

685
01:05:45,340 --> 01:05:48,100
 таким как я, которые хотят решить вопросы с домом.

686
01:05:48,500 --> 01:05:55,520
 С другой стороны, вы подсчитывали, стало ли больше обращений в те же самые компании, обслуживающие.

687
01:05:55,620 --> 01:06:03,360
 Почему? Потому что раньше, например, захожу через телефон, ничего там не понимаю, да и хрен с ним, раз в полгода зайду, раз в полгода напишу о своих проблемах.

688
01:06:03,460 --> 01:06:11,480
 Теперь я могу это делать каждые пять минут, при этом выглядит так, как будто бы обслуживающая компания может засыпать некоторым полезным спамом, назовем это так.

689
01:06:11,840 --> 01:06:17,280
 И с одной стороны, да, то есть как будто бы мы все автоматизировали, а с другой стороны, как будто бы работа стала больше.

690
01:06:17,420 --> 01:06:22,060
 Тогда в чем выгода для вот таких компаний?

691
01:06:23,020 --> 01:06:31,980
 Спасибо, хороший вопрос. На самом деле мы про это думали. На самом деле на пилоте, который идет уже почти месяц, мы вообще спресска не видим.

692
01:06:31,980 --> 01:06:38,920
 То есть на самом деле количество тоталей обращений не меняется, но эти обращения перетекают в и ассистента.

693
01:06:40,260 --> 01:06:47,600
 И на старте реально были такие опасения. Допустим, я лично постоянно пользуюсь, я вот иду, у меня не работает замок.

694
01:06:47,680 --> 01:06:58,120
 Я сразу надиктовал, не работает замок. Это стало делать реально проще, тем более у нас есть еще бот, который работает в Telegram Max, и тебе даже не обязательно приложение запускать.

695
01:06:59,200 --> 01:07:08,200
 Такие описания были, но на самом деле, что я вижу на реальных запросах, пользователи, вместо того, чтобы тыкаться в нашем интерфейсе, дозваниваться до оператора,

696
01:07:08,200 --> 01:07:16,700
 если он не дозвонится, просто пишут, не знаю, пожарная тревога, отключили воду, и ассистент чаще предиктивно отвечает,

697
01:07:16,780 --> 01:07:20,160
 потому что он знает, что сейчас, допустим, сезон отключения горячей воды,

698
01:07:20,300 --> 01:07:21,980
 и он такие заявки просто даже не доводит.

699
01:07:22,280 --> 01:07:25,860
 То есть да, может быть, какой-то абьюз в каких-то тематиках есть,

700
01:07:25,960 --> 01:07:29,660
 но он работает в любом случае обратно, потому что он владеет контекстом,

701
01:07:30,080 --> 01:07:34,420
 который есть про твой дом, про твою квартиру, и он может заранее сказать,

702
01:07:34,420 --> 01:07:40,160
 что ну вообще-то уже показания нельзя передавать, а в этом случае пользователь звонит,

703
01:07:40,240 --> 01:07:42,880
 дозванивает, спрашивает, а можно ли передать показания или нет.

704
01:07:43,260 --> 01:07:45,420
 Ну я понял. То есть решается самая главная проблема.

705
01:07:45,560 --> 01:07:47,900
 Ваша проблема не остается без внимания.

706
01:07:48,320 --> 01:07:53,980
 Конечно, да. Ну, если кто-то звонил в управляющую компанию, понимают.

707
01:07:54,340 --> 01:07:58,260
 Миш, и, наверное, заключительный вопрос от онлайн-аудитории.

708
01:07:58,260 --> 01:08:01,600
 Ты рассказывал про eval-наборы и асессоров.

709
01:08:01,760 --> 01:08:05,740
 И вот вопрос, используешь ли ты ручной труд асессоров или это генерится автоматически?

710
01:08:05,840 --> 01:08:06,480
 Как у тебя устроено?

711
01:08:07,340 --> 01:08:11,580
 На самом деле ручной труд асессоров я не использую.

712
01:08:12,100 --> 01:08:17,740
 На первых этапах это была ручная разметка нашей команды, когда запросов было немного.

713
01:08:17,740 --> 01:08:23,300
 Но я калибровался по поводу работы LLM-суд, которая у меня есть.

714
01:08:24,000 --> 01:08:29,040
 И после нескольких итераций мне просто как бы надобности нет делать это руками.

715
01:08:29,260 --> 01:08:31,800
 Он прекрасно находит большинство проблем сам.

716
01:08:33,180 --> 01:08:34,140
 Спасибо большое.

717
01:08:37,320 --> 01:08:38,040
 Спасибо.

718
01:08:39,900 --> 01:08:41,380
 Мы двигаемся дальше.

719
01:08:42,180 --> 01:08:45,920
 Как и анонсировали ранее, мы хотели рассказать про текстовых.

720
01:08:46,040 --> 01:08:47,880
 Теперь переходим к голосовым агентам.

721
01:08:48,420 --> 01:08:53,340
 Напомню, что в iStudio за направление голосовых агентов отвечает real-time API и все вокруг него.

722
01:08:54,220 --> 01:08:59,840
 И про то, как можно построить масштабируемый контакт-центр на базе искусственного интеллекта,

723
01:08:59,840 --> 01:09:06,840
 на базе real-time API, расскажут Дмитрий Митин и Марат Гасанян из компании StroyEnergo.com.

724
01:09:06,840 --> 01:09:07,100
 Хорошо.

725
01:09:07,700 --> 01:09:21,020
 Всем добрый день. Меня зовут Марат. Моего коллегу зовут Дмитрий.

726
01:09:21,200 --> 01:09:23,500
 Как вы уже слышали, мы работаем в компании StroyEnergo.com.

727
01:09:24,000 --> 01:09:27,040
 И сегодня будем рассказывать вам о том, как мы внедрили iCall Center.

728
01:09:28,020 --> 01:09:30,920
 Для начала давайте расскажем о том, кто мы и чем мы занимаемся.

729
01:09:31,360 --> 01:09:35,380
 Наша компания занимается ASCU, это интеллектуальные приборы учета, которые передают показания в сеть.

730
01:09:35,380 --> 01:09:38,800
 Если у вас еще нет интеллектуального прибора учета, скоро мы вам его поставим.

731
01:09:39,220 --> 01:09:44,920
 Мы делаем это в 18 регионах страны и в среднем в сутки устанавливаем от 2 до 5 тысяч приборов учета.

732
01:09:45,480 --> 01:09:53,360
 Для того, чтобы проводить такой бизнес-процесс, нам нужно согласовать огромное количество дат и управлять посещением наших мастеров.

733
01:09:53,500 --> 01:09:57,780
 Для этого мы осуществляем десятки тысяч звонков в сутки и отправляем сотни тысяч смс в месяц.

734
01:09:59,220 --> 01:10:01,460
 Как мы это делали до внедрения iCall Center?

735
01:10:01,460 --> 01:10:08,500
 У нас была AVR-система, которую мы называли звонобот. Она осуществляла сотни тысяч звонков в месяц и снимала холодный контакт.

736
01:10:09,180 --> 01:10:15,840
 Далее у нас было в внештатном колл-центре порядка 15 операторов, которые работали с 12-часовым рабочим днем.

737
01:10:16,000 --> 01:10:19,160
 Они принимали порядка 800-1000 входящих звонков.

738
01:10:19,940 --> 01:10:28,600
 Приблизительно в пиковой нагрузке до 20 человек тоже с графиком 12 часов в день осуществляли 2500 результативных исходящих звонков.

739
01:10:28,600 --> 01:10:31,820
 Для результативных они, конечно, осуществляли гораздо больше звонков.

740
01:10:32,480 --> 01:10:41,620
 И приблизительно полторы-две тысячи звонков осуществляли операторы наших подрядных организаций для каких-нибудь пересогласований дат или уточнений.

741
01:10:42,180 --> 01:10:45,740
 Еще у нас есть штатный колл-центр из пяти человек для сложных кейсов.

742
01:10:47,500 --> 01:10:50,120
 Почему мы хотели внедрить AI-колл-центр?

743
01:10:50,420 --> 01:10:57,220
 Во-первых, система VR, насколько вы с ней знакомы, она способна решать только какие-то очень бинарные задачи.

744
01:10:57,220 --> 01:11:00,620
 Позвонить абоненту и ответить на вопрос, да или нет.

745
01:11:01,100 --> 01:11:06,340
 По сути, она может снимать холодный контакт и закрывать очень какие-то примитивные задачи.

746
01:11:07,240 --> 01:11:13,900
 Вне штатный колл-центр, к сожалению, терял порядка 20% входящего трафика во время всплеска входящих звонков.

747
01:11:14,580 --> 01:11:19,460
 Для того, чтобы не терять входящий трафик, необходимо всегда в резерве иметь какое-то количество операторов,

748
01:11:19,600 --> 01:11:22,320
 которые в нужную минуту можно подключить к работе.

749
01:11:22,380 --> 01:11:23,300
 Это достаточно сложно.

750
01:11:23,580 --> 01:11:31,940
 Естественно, дорого обслуживать, сложно работать более 12 часов, потому что выстраивать схемы, рабочие графики крайне сложно.

751
01:11:32,600 --> 01:11:33,920
 Невероятно сложно масштабировать.

752
01:11:34,020 --> 01:11:43,020
 Если у вас возникает какое-то событие, допустим, вы знаете, что в следующий понедельник или вторник у вас будет большая нагрузка на колл-центр,

753
01:11:43,080 --> 01:11:45,720
 вам необходимо вывести на работу плюс 10 человек.

754
01:11:45,720 --> 01:11:51,640
 Крайне сложно их где-то найти, потому что все это время они должны получать зарплату, все вытекающие последствия отсюда.

755
01:11:52,800 --> 01:11:57,280
 И как бы удивительно это ни звучало, достаточно сложно внедрять новые скрипты.

756
01:11:57,900 --> 01:12:01,920
 Конечно, все операторы колл-центра работают по скриптам в каких-нибудь CRM-системах,

757
01:12:02,520 --> 01:12:08,020
 но в эту CRM-систему прилетает новый скрипт, где человек должен отжать галочку о том, что он с ним ознакомился,

758
01:12:08,080 --> 01:12:09,620
 но дальше включается человеческий фактор.

759
01:12:10,000 --> 01:12:12,500
 Забыл прочитать, не прочитал, прочитал и забыл.

760
01:12:13,420 --> 01:12:17,220
 Оператор полгода говорит о том, что у нас график работает до 8 часов вечера,

761
01:12:17,300 --> 01:12:22,020
 теперь у нас график работает до 9 часов вечера, он прочитал, запомнил, но на автомате говорит до 8 часов вечера.

762
01:12:22,020 --> 01:12:27,880
 Значит, какие задачи стояли перед нашим AI-агентом?

763
01:12:29,240 --> 01:12:32,760
 Самая первая его задача – это идентифицировать звонившего абонента.

764
01:12:33,340 --> 01:12:37,100
 Идентифицировать он мог разными способами, но самый популярный – по адресу.

765
01:12:37,460 --> 01:12:40,200
 И здесь возникает вся прелесть идентификации по адресу.

766
01:12:40,420 --> 01:12:45,020
 Человек может называть улицу, которая фигурирует в разных населенных пунктах,

767
01:12:45,120 --> 01:12:47,840
 может называть населенный пункт, который фигурирует в разных городах,

768
01:12:48,500 --> 01:12:50,120
 может называть это в разном порядке.

769
01:12:50,120 --> 01:12:52,140
 Была такая достаточно сложная задача.

770
01:12:53,200 --> 01:12:56,840
 Далее ему необходимо принять решение, что он делает с этим абонентом.

771
01:12:56,900 --> 01:13:01,480
 Он согласовывает визит, согласовывает дату, удобную для нас и для абонента,

772
01:13:02,060 --> 01:13:04,720
 или он выслушивает жалобу от этого абонента,

773
01:13:04,820 --> 01:13:07,300
 или он выслушивает жалобу от абонента и согласовывает дату.

774
01:13:08,040 --> 01:13:10,940
 И, конечно же, ответить на все вопросы, которые беспокоят абонента.

775
01:13:12,300 --> 01:13:16,460
 Теперь я передам слово коллеге Дмитрию, и Дмитрий расскажет о том, как нам удалось это сделать.

776
01:13:16,800 --> 01:13:18,640
 Спасибо. Всем добрый день.

777
01:13:19,760 --> 01:13:22,840
 Что же у нас получилось? Очень верхний уровень по архитектуре.

778
01:13:23,040 --> 01:13:24,720
 В центре у нас находится и агент.

779
01:13:24,980 --> 01:13:27,780
 С одной стороны в него входит поток данных от Real Time Map,

780
01:13:27,860 --> 01:13:32,260
 с другой стороны это Telecom Provider, то есть это звонок от абонента, входящий либо исходящий.

781
01:13:32,800 --> 01:13:36,160
 Как видите, Telecom Provider мы напрямую с агентом интегрировать не стали.

782
01:13:36,280 --> 01:13:38,620
 Для этого взяли готовый Asterisk ATS.

783
01:13:38,620 --> 01:13:41,560
 Он прекрасно интегрируется с Telecom с одной стороны,

784
01:13:42,160 --> 01:13:48,800
 и с другой у него очень хороший развитый REST API и поддержка WebSocket для взаимодействия с агентом.

785
01:13:49,240 --> 01:13:53,240
 Сам по себе агент не является владельцем никаких бизнесовых данных,

786
01:13:53,360 --> 01:13:57,480
 поэтому, естественно, у него есть очень много интеграций с другими сервисами,

787
01:13:58,520 --> 01:14:02,780
 где он в процессе диалога с абонентом либо какие-то данные получает,

788
01:14:02,780 --> 01:14:06,800
 либо туда отправляет какие-либо результаты, исходы звонка.

789
01:14:07,820 --> 01:14:11,280
 С точки зрения ресурсов и масштабирования,

790
01:14:11,420 --> 01:14:17,180
 сейчас мы ведем до 70 параллельных диалогов одновременно

791
01:14:17,180 --> 01:14:19,820
 и делаем до 3000 звонков в час.

792
01:14:20,460 --> 01:14:28,360
 Астериск один инстанс, 16 ядер, 16 гигабайт оперативной памяти.

793
01:14:28,780 --> 01:14:33,460
 Утилизация даже в пиковые моменты не превышает 10% по обеим метрикам.

794
01:14:33,700 --> 01:14:37,640
 Аналогично и агент, это 8 ядер и 8 гигабайт.

795
01:14:37,740 --> 01:14:40,300
 Утилизация также не превышает 10%.

796
01:14:40,300 --> 01:14:42,300
 Отсюда простое следствие.

797
01:14:42,440 --> 01:14:45,020
 У нас не будет слайда со сложной архитектурой,

798
01:14:45,300 --> 01:14:48,200
 с кластером астерисков и кластером и агентов.

799
01:14:48,200 --> 01:14:50,720
 Это все действительно работает по одному экземпляру,

800
01:14:50,800 --> 01:14:54,960
 и мы понимаем, что на все наши будущие хотелки у нас есть запас,

801
01:14:55,060 --> 01:14:56,900
 который мы никогда не исчерпаем.

802
01:14:59,620 --> 01:15:02,200
 Теперь хотелось бы поговорить с позицией,

803
01:15:02,480 --> 01:15:09,060
 что, например, вы тоже пытаетесь пройти тот путь, который мы прошли,

804
01:15:09,240 --> 01:15:11,160
 и с какими сложностями вы столкнетесь.

805
01:15:11,240 --> 01:15:13,420
 Потому что некоторые довольно неочевидные.

806
01:15:13,420 --> 01:15:16,980
 Возможно, на первых этапах они могли бы дезморалить.

807
01:15:17,100 --> 01:15:20,420
 Поэтому давайте рассмотрим некоторые моменты.

808
01:15:21,500 --> 01:15:27,420
 Перед нами фрагмент JSON, который отправляет конфигурацию в real-time API.

809
01:15:27,960 --> 01:15:29,760
 И есть два важных параметра.

810
01:15:30,160 --> 01:15:31,000
 Первый — это threshold.

811
01:15:31,280 --> 01:15:33,100
 Сейчас там значение 0,5.

812
01:15:33,360 --> 01:15:35,100
 Он принимает значение от 0 до 1.

813
01:15:35,440 --> 01:15:37,680
 У нас есть две полярные ситуации.

814
01:15:37,860 --> 01:15:42,120
 Первая — это когда агент прекрасно слышит тихий голос,

815
01:15:42,120 --> 01:15:43,720
 можно проглатывать окончание,

816
01:15:43,860 --> 01:15:45,760
 но при этом он будет слышать чужой голос,

817
01:15:45,900 --> 01:15:48,080
 он будет, возможно, реагировать на шум.

818
01:15:48,880 --> 01:15:52,700
 А другая ситуация — когда он прекрасно слышит абонента,

819
01:15:52,780 --> 01:15:55,200
 но абонент должен очень четко разговаривать,

820
01:15:55,600 --> 01:15:58,560
 его громкость голоса должна быть абсолютно монотонной,

821
01:15:58,640 --> 01:16:00,160
 нельзя проглатывать окончание.

822
01:16:00,540 --> 01:16:02,340
 А когда начинаешь в этой теме разбираться,

823
01:16:02,440 --> 01:16:04,060
 оказывается, что мы все это делаем.

824
01:16:06,060 --> 01:16:08,900
 Опытным путем пришли, как это ни странно,

825
01:16:08,900 --> 01:16:11,400
 обратно к дефолтному значению 0,5.

826
01:16:11,920 --> 01:16:13,400
 Получилась золотая середина.

827
01:16:13,540 --> 01:16:16,960
 Второй параметр — это особенность реал-таймапи,

828
01:16:17,200 --> 01:16:20,680
 когда модель считает, что ход абонента завершен

829
01:16:20,680 --> 01:16:22,380
 и начинает на него реагировать.

830
01:16:22,820 --> 01:16:24,940
 По умолчанию полсекунды — это крайне мало.

831
01:16:25,060 --> 01:16:26,380
 Так быстро никто не думает,

832
01:16:26,540 --> 01:16:28,860
 так быстро никто не говорит предложение.

833
01:16:29,300 --> 01:16:32,120
 Опять же, опытным путем, АБ-тестированием

834
01:16:32,120 --> 01:16:36,180
 пришли к 1,6 секунды.

835
01:16:36,180 --> 01:16:39,140
 И, возможно, я тут сразу отвечу на вопрос,

836
01:16:39,280 --> 01:16:40,380
 который может поступить,

837
01:16:40,580 --> 01:16:42,740
 как быстро отвечает real-time API,

838
01:16:43,100 --> 01:16:44,580
 нет ли задержек в диалоге.

839
01:16:44,840 --> 01:16:48,760
 С учетом того, что у нас silence duration 1,6 секунды,

840
01:16:48,840 --> 01:16:51,360
 те миллисекунды, которые реагирует модель,

841
01:16:51,940 --> 01:16:54,820
 они, в принципе, тут по сути никак не участвуют.

842
01:16:54,960 --> 01:16:56,120
 Они в рамках погрешности.

843
01:16:56,620 --> 01:16:58,720
 Диалог выглядит абсолютно человеческим.

844
01:16:59,260 --> 01:17:00,620
 Никаких проблем с этим нет.

845
01:17:02,660 --> 01:17:05,600
 Следующий момент, который тоже может сбивать с толку.

846
01:17:05,600 --> 01:17:08,780
 Мы все привыкли, что и ассистенты уже плотно вошли в нашу жизнь.

847
01:17:09,140 --> 01:17:12,620
 С той же Алисой можно поговорить, она прекрасно держит диалог.

848
01:17:13,240 --> 01:17:19,000
 Кажется, напишу промпт, запущу это решение, оно будет выполнять мои бизнес-задачи.

849
01:17:19,420 --> 01:17:22,160
 По факту вообще не будет, даже близко.

850
01:17:22,760 --> 01:17:25,880
 Как мы маркдаун документ не писали с системным промптом,

851
01:17:27,020 --> 01:17:33,460
 даже если ты знаешь все, что будет происходить и пытаешься подыгрывать ей ассистенту,

852
01:17:33,460 --> 01:17:36,400
 с точки зрения бизнес-метрик получалось ужасно.

853
01:17:36,860 --> 01:17:43,140
 Решение тоже изобрели не мы, оно нашлось на буквально всех сайтах известных и вендоров западных.

854
01:17:43,680 --> 01:17:48,900
 Оказывается, можно делать не XML, извиняюсь, можно брать не Markdown, а делать XML.

855
01:17:49,080 --> 01:17:51,720
 И с XML мы продвинулись немножко дальше.

856
01:17:52,260 --> 01:17:58,420
 Мы в нашем кастомном DSL описываем state machine, по которому происходит диалог агента.

857
01:18:00,080 --> 01:18:06,780
 Естественно, LLM все еще остается собой, и этот state machine, он носит рекомендательный характер для нее.

858
01:18:07,000 --> 01:18:11,300
 Но она этих рекомендаций придерживается очень и очень неплохо.

859
01:18:13,600 --> 01:18:19,000
 Следующий момент. Мы, как уже поняли, и агент — это стык детерминированного кода,

860
01:18:19,180 --> 01:18:22,660
 всеми нам привычного, и недетерминированного — это LLM.

861
01:18:22,660 --> 01:18:29,140
 И иногда очень сложно версионировать промпты или переносить промпт с одной модели на более новую,

862
01:18:29,220 --> 01:18:33,160
 потому что каждый раз его поведение может меняться, даже изменив одну строку.

863
01:18:33,600 --> 01:18:39,140
 Поэтому важно перед началом работы потратить время, потратить ресурсы на то,

864
01:18:39,200 --> 01:18:42,980
 чтобы выделить какие-то ключевые бизнес-метрики и, грубо говоря,

865
01:18:43,080 --> 01:18:46,840
 смотреть немножко на расстояние и на то, как агент закрывает задачи.

866
01:18:46,840 --> 01:18:52,760
 Естественно, это не отменяет того, что какие-то конкретные диалоги нужно слушать и там проблемы решать.

867
01:18:53,240 --> 01:19:01,240
 Но основной подход тут в том, что скорее надо оперировать какой-то верхнеуровневой статистикой и бизнес-метриками.

868
01:19:01,780 --> 01:19:08,140
 Теперь пара слайдов о том, на что время тратить не нужно и за что беспокоиться не нужно.

869
01:19:08,760 --> 01:19:10,960
 Не нужно пытаться очеловечивать робота.

870
01:19:11,600 --> 01:19:14,760
 Конечно, у живого собеседника, несомненно, есть свои плюсы.

871
01:19:14,940 --> 01:19:18,460
 И главное, мы к этим плюсам привыкли, и когда мы звоним, мы их ожидаем.

872
01:19:18,840 --> 01:19:20,140
 Но у робота они тоже есть.

873
01:19:20,140 --> 01:19:24,820
 Например, робот никогда не будет переспрашивать, он прекрасно слышит с первого раза.

874
01:19:25,460 --> 01:19:31,820
 Если вы ему даете какой-то ввод, который подлежит валидации или отправке в тулы, он опять же его мгновенно принимает.

875
01:19:32,420 --> 01:19:35,420
 Тулы опросил, получил себе новую информацию в контекст.

876
01:19:35,540 --> 01:19:38,900
 В это время живой оператор еще третью букву набирает.

877
01:19:40,480 --> 01:19:45,340
 Не стоит бояться за качество транскрибации речи, с этим тоже все прекрасно.

878
01:19:45,340 --> 01:19:49,360
 Даже если в этой речи есть какие-нибудь сложные адреса, сложные номера,

879
01:19:49,860 --> 01:19:54,960
 это все может еще отягощаться акцентом, либо дефектами речи, либо шумными местами.

880
01:19:55,460 --> 01:20:00,960
 Иногда, когда мы разбираем какие-то проблемные кейсы, с которыми приходит поддержка либо бизнес,

881
01:20:01,620 --> 01:20:06,700
 ты действительно слушаешь абонента, и эффект, когда ты смотришь сериал на иностранном языке,

882
01:20:06,920 --> 01:20:08,480
 что-то сказали, ты такой, я не понял.

883
01:20:08,980 --> 01:20:10,600
 Еще раз переслушиваешь, я не понял.

884
01:20:10,920 --> 01:20:15,720
 Отматываешь назад, включаешь субтитры, а, так я же знаю все эти слова.

885
01:20:16,080 --> 01:20:19,520
 Вот абсолютно так же бывает, агент прекрасно справляется.

886
01:20:21,740 --> 01:20:23,380
 Еще из сложностей промпта.

887
01:20:24,160 --> 01:20:28,520
 Например, у вас есть какой-то тул, который называется validate date,

888
01:20:28,620 --> 01:20:29,560
 валидация даты.

889
01:20:29,980 --> 01:20:34,620
 И, например, вы назвали этап, потому что мы же все читали чистый код,

890
01:20:34,720 --> 01:20:35,920
 знаем лучшие практики.

891
01:20:36,020 --> 01:20:37,980
 Мы, конечно, называем этап правильно.

892
01:20:38,080 --> 01:20:40,720
 Мы его тоже называем validate date, это же его смысл.

893
01:20:41,620 --> 01:20:45,840
 И вроде бы мы все делаем правильно, но для модели мы, наоборот,

894
01:20:46,020 --> 01:20:49,700
 делаем место, где она гарантирована в какой-то степени,

895
01:20:49,700 --> 01:20:51,860
 мало или много, но будет ошибаться.

896
01:20:52,180 --> 01:20:55,960
 У нас реально были случаи, когда модель в тестировании работает хорошо,

897
01:20:56,060 --> 01:20:59,160
 мы запускаем в prompt, и она вместо того, чтобы вызвать тул,

898
01:20:59,260 --> 01:21:02,600
 пытается вызвать какой-то кусок текста, который просто на это похож,

899
01:21:02,740 --> 01:21:03,800
 ну вот, например, stage.

900
01:21:04,620 --> 01:21:09,960
 Соответственно, рекомендация, все, что в prompt не должно иметь осмысленных названий,

901
01:21:10,240 --> 01:21:11,840
 оно и не должно иметь.

902
01:21:11,960 --> 01:21:14,600
 То есть у нас, например, stage ID и прочие моменты,

903
01:21:14,600 --> 01:21:17,940
 это просто сгенерированные рандомные последовательности букв.

904
01:21:18,480 --> 01:21:21,500
 Для LLM это прекрасно, для пользователя не очень удобно,

905
01:21:21,620 --> 01:21:24,420
 но зато сильно повышает надежность.

906
01:21:25,260 --> 01:21:28,120
 Что касается надежности, в целом старайтесь использовать

907
01:21:28,120 --> 01:21:30,960
 короткие понятные формулировки, недвусмысленные.

908
01:21:31,160 --> 01:21:33,140
 Не перегружайте stage функциями.

909
01:21:33,220 --> 01:21:35,820
 То есть один stage, одна какая-то маленькая функция.

910
01:21:36,360 --> 01:21:39,040
 И особенность real-time-апи обязывает нас к тому,

911
01:21:39,160 --> 01:21:42,440
 что спич должен заканчиваться вопросом, чтобы абонент не молчал.

912
01:21:42,440 --> 01:21:47,260
 То есть по умолчанию у LLM, у real-time-апи нет возможности поддерживать диалог.

913
01:21:47,780 --> 01:21:49,600
 Но вот мы с коллегами из Яндекса общались,

914
01:21:49,760 --> 01:21:53,040
 что сейчас в разработке фича по активному слушанию.

915
01:21:53,200 --> 01:21:56,060
 То есть у LLM, грубо говоря, появляется понятие времени,

916
01:21:56,280 --> 01:21:58,660
 и она может говорить, да-да-да, продолжайте,

917
01:21:59,060 --> 01:22:01,080
 почему вы замолчали, вот что-то такое,

918
01:22:01,200 --> 01:22:03,200
 но пока не пробовали, пока этого нет.

919
01:22:03,640 --> 01:22:06,300
 То есть сейчас, если абонент вдруг замолчит,

920
01:22:06,560 --> 01:22:07,820
 LLM тоже замолчит.

921
01:22:11,080 --> 01:22:14,660
 Когда абонент не молчит, это тоже бывает плохо и тяжело.

922
01:22:14,980 --> 01:22:15,860
 Это перебивание.

923
01:22:17,360 --> 01:22:18,160
 Проблема в чем?

924
01:22:18,320 --> 01:22:22,580
 LLM в общем случае не знает, когда абонент перебил модуль,

925
01:22:22,680 --> 01:22:24,120
 который озвучивает речь.

926
01:22:24,480 --> 01:22:27,280
 То есть если под дебагом запустить приложение агента

927
01:22:27,280 --> 01:22:30,160
 и посмотреть, мы видим, что текстовые токены,

928
01:22:30,280 --> 01:22:33,220
 все, что потом будет озвучено, они вылетают мгновенно.

929
01:22:34,040 --> 01:22:36,120
 А когда абонент перебил, мы не знаем.

930
01:22:37,120 --> 01:22:39,240
 В этой связи было принято несколько мер.

931
01:22:39,520 --> 01:22:41,780
 Первая мера — это обязательные этапы промпта.

932
01:22:41,780 --> 01:22:47,460
 То есть мы через хинт, так называемый, на этапе промпта

933
01:22:47,460 --> 01:22:50,600
 объясняем очень жестко, что смотри, тут ты должен добиться

934
01:22:50,600 --> 01:22:53,500
 какого-то ответа, например, явного согласия,

935
01:22:53,620 --> 01:22:55,840
 явного отказа, явно получить вот это.

936
01:22:56,500 --> 01:23:00,400
 Но, естественно, LLM остается собой и может это тоже

937
01:23:00,400 --> 01:23:01,800
 где-то проигнорировать.

938
01:23:03,260 --> 01:23:06,060
 Следующий момент — это игнорирование в начале диалога.

939
01:23:06,140 --> 01:23:08,520
 Начало диалога — это всегда та точка времени,

940
01:23:08,520 --> 01:23:10,800
 когда мы понимаем, где мы находимся,

941
01:23:10,920 --> 01:23:15,480
 где у нас есть вот этот стык детерминированного с недетерминированным,

942
01:23:15,560 --> 01:23:20,300
 что мы сделали. У нас есть тайм-аут для начала звонка.

943
01:23:20,980 --> 01:23:25,120
 И в рамках этого тайм-аута аудио дельты от абонента мы принимаем,

944
01:23:25,360 --> 01:23:28,720
 но в LLM не отдаем. Мы их буферизируем в рамках сессии.

945
01:23:29,680 --> 01:23:33,440
 И, например, мы поняли, что наша фраза при исходящем обзвоне,

946
01:23:33,440 --> 01:23:36,480
 когда мы представляемся, кто мы, и быстро должны объяснить цель,

947
01:23:36,560 --> 01:23:40,960
 зачем мы звоним, что мы не спам, например, занимает 8 секунд.

948
01:23:41,080 --> 01:23:43,600
 Соответственно, 8 секунд аудио дельты мы придерживаем,

949
01:23:43,700 --> 01:23:45,320
 а потом уже прокидываем в LLM.

950
01:23:45,780 --> 01:23:48,060
 Ну и начало диалога — это, как правило, то место,

951
01:23:48,200 --> 01:23:49,980
 где сконцентрированы все перебивания,

952
01:23:50,120 --> 01:23:52,020
 потому что банально связь может быть не очень.

953
01:23:52,500 --> 01:23:55,800
 Пока абонент кричит «Алло», LLM начинает это воспринимать,

954
01:23:55,900 --> 01:23:58,700
 прыгать по стейджам и пытаться интерпретировать эти «Алло»,

955
01:23:58,700 --> 01:23:59,320
 хотя не нужно.

956
01:23:59,960 --> 01:24:02,140
 Опять же, общались с коллегами из Яндекса,

957
01:24:02,880 --> 01:24:08,880
 появился Truncate API — это возможность давать обратную связь LLM

958
01:24:08,880 --> 01:24:12,900
 и вырезать из ее контекста те токены, тот текст,

959
01:24:12,900 --> 01:24:16,300
 который модуль озвучивания просто не успел проговорить.

960
01:24:16,680 --> 01:24:19,420
 Мы пока не пробовали, поэтому прокомментировать не могу,

961
01:24:19,580 --> 01:24:25,100
 но в теории вещь очень полезная и должна сильно упростить нам жизнь.

962
01:24:26,400 --> 01:24:31,040
 Следующий прием отчасти тоже дублируется с предыдущим докладом.

963
01:24:31,120 --> 01:24:34,000
 Забавно, что мы пришли к одним и тем же выводам.

964
01:24:34,180 --> 01:24:36,460
 Это контроль состояния.

965
01:24:36,860 --> 01:24:42,080
 То есть LLM, в принципе, я всегда могу убедить, например, по закрытой заявке,

966
01:24:42,100 --> 01:24:46,440
 по которой была замена счетчика, я ее могу убедить, что нужно оформить еще раз заявку.

967
01:24:46,680 --> 01:24:49,840
 С точки зрения бизнеса ситуация невозможная, невалидная,

968
01:24:50,120 --> 01:24:52,780
 и никогда бы мы в нее не пришли с живым оператором.

969
01:24:53,240 --> 01:24:54,300
 Тут так сделать можно.

970
01:24:54,440 --> 01:24:59,280
 Поэтому все важные критические моменты, они проверяются на уровне кода.

971
01:24:59,420 --> 01:25:04,000
 То есть LLM Durgate Tool, у меня в приложении есть весь необходимый контекст,

972
01:25:04,100 --> 01:25:07,980
 я вижу, какая заявка у этого абонента, что с ней можно делать, что нельзя.

973
01:25:07,980 --> 01:25:15,320
 И если состояние невалидное, то в коде генерируется текстовая подсказка релевантная,

974
01:25:15,480 --> 01:25:18,000
 которая улетает обратно в LLM как ответ на Tool,

975
01:25:18,180 --> 01:25:23,780
 объясняет ему, что ты зашел куда-то ни туда, ни в ту часть диалога,

976
01:25:24,620 --> 01:25:30,300
 и LLM на лету перестраивается, понимает эту подсказку и дальше выводит диалог в нужное русло.

977
01:25:30,720 --> 01:25:35,940
 Более того, мы стали использовать Tool как точки синхронизации LLM с кодом,

978
01:25:35,940 --> 01:25:39,640
 то есть, например, у меня есть какая-то логическая развилка, первый исход, второй исход.

979
01:25:40,580 --> 01:25:44,640
 При заходе в первый исход я могу дернуть Tool, ничего туда не передавая,

980
01:25:44,820 --> 01:25:49,460
 но этот Tool, он опять же будет обработан в коде, и в коде я могу посмотреть,

981
01:25:49,560 --> 01:25:51,260
 мог ли я вообще в эту ветку провалиться.

982
01:25:51,420 --> 01:25:55,520
 То есть это такое раннее предупреждение, что LLM пошла не туда.

983
01:25:55,700 --> 01:26:00,440
 Опять же, я отправляю подсказку, и она возвращается куда мне нужно.

984
01:26:01,620 --> 01:26:04,180
 Также следует максимально избегать открытых вопросов.

985
01:26:04,180 --> 01:26:09,060
 Ну, например, абонент, он же не знает и знать не может о том,

986
01:26:09,160 --> 01:26:11,260
 как у нас устроена классификация намерений.

987
01:26:11,720 --> 01:26:14,500
 Если он нам звонит, и мы его сразу спрашиваем, что вы хотели,

988
01:26:14,580 --> 01:26:17,800
 но он вроде как звонит в организацию, которая занимается заменой счетчиков.

989
01:26:17,900 --> 01:26:19,520
 Он говорит, я звоню по замене счетчиков.

990
01:26:19,820 --> 01:26:24,000
 По факту он может хотеть пожаловаться, он может хотеть перенести дату, еще что-то.

991
01:26:25,340 --> 01:26:30,560
 Максимально откладывайте принятие вот таких каких-то сложных решений,

992
01:26:30,560 --> 01:26:32,280
 задания открытых вопросов.

993
01:26:32,420 --> 01:26:39,400
 Старайтесь, чтобы вопросы были «да», «нет» и максимально подтягивайте контекст необходимый в LLM,

994
01:26:39,520 --> 01:26:41,980
 чтобы она сама в этом тоже ориентировалась хорошо.

995
01:26:43,740 --> 01:26:47,280
 Промпт по возможности держите простым, держите минимальным.

996
01:26:47,380 --> 01:26:52,760
 Если есть разные, но похожие задачи и хочется, опять же, исходя из лучших практик,

997
01:26:52,840 --> 01:26:55,860
 переиспользовать один и тот же промпт и чуть-чуть его накрутить,

998
01:26:55,860 --> 01:26:59,160
 лучше не надо, лучше пусть будет два отдельных, но поменьше.

999
01:26:59,780 --> 01:27:02,840
 И опять-таки все, что можно решить кодом, решайте кодом.

1000
01:27:02,980 --> 01:27:07,720
 Не надо пытаться, например, валидировать доступные даты внутри LLM,

1001
01:27:07,860 --> 01:27:10,060
 хотя оно это делает довольно неплохо.

1002
01:27:10,540 --> 01:27:14,600
 LLM прекрасно может принять вообще в любом формате от абонента дату,

1003
01:27:14,920 --> 01:27:17,360
 нормализовать ее, как мы ее попросили в промпте,

1004
01:27:17,660 --> 01:27:21,860
 но потом лучше отдать в код и в коде уже проверить, доступна эта дата или нет.

1005
01:27:26,600 --> 01:27:34,280
 Примерно в ту же степь мы, когда все это дело развивали, у нас появились тулы, которые были полиморфными.

1006
01:27:34,420 --> 01:27:39,260
 Мы тоже привыкли, зачем дублировать код, если можно переиспользовать одну и ту же функцию.

1007
01:27:40,200 --> 01:27:42,800
 Здесь ровно наоборот все работает.

1008
01:27:43,300 --> 01:27:46,100
 Есть у вас, например, фиксация двух исходов звонка.

1009
01:27:46,100 --> 01:27:50,140
 Это успешное назначение даты монтажа и это принятие жалобы.

1010
01:27:50,920 --> 01:27:55,820
 У них у обоих два аргумента, но в первом случае первый обязателен, второй нет, у другого наоборот.

1011
01:27:55,940 --> 01:27:57,860
 Все это тоже можно объяснить LLM.

1012
01:27:58,060 --> 01:28:02,480
 В большинстве случаев будет хорошо, но будут случаи, когда точно нет.

1013
01:28:03,580 --> 01:28:08,380
 Максимум используете разных тулов, просто не даете ей шанса ошибиться.

1014
01:28:11,100 --> 01:28:12,460
 Еще моментик.

1015
01:28:16,680 --> 01:28:21,040
 Например, у нас есть какая-то логическая развилка, и мы как человек понимаем,

1016
01:28:21,180 --> 01:28:23,040
 что тут может быть либо да, либо нет.

1017
01:28:23,160 --> 01:28:24,700
 То есть это все множество исходов.

1018
01:28:25,280 --> 01:28:31,200
 Для LLM, как оказалось, это не очевидно, и в таких случаях лучше не описывать оба исхода,

1019
01:28:31,260 --> 01:28:35,260
 лучше выбрать наиболее очевидный и легко формализуемый, мы его описываем.

1020
01:28:35,340 --> 01:28:36,140
 Например, это да.

1021
01:28:37,200 --> 01:28:40,780
 А второй исход мы не описываем вообще никак, мы говорим, что это фоллбэк.

1022
01:28:40,980 --> 01:28:45,680
 Тогда для LLM понятно, что у меня всего есть два исхода.

1023
01:28:45,780 --> 01:28:49,260
 Один да, второй это все остальное, это либо явное нет,

1024
01:28:49,380 --> 01:28:52,280
 либо все, что я вообще не поняла и не было предусмотрено.

1025
01:28:54,620 --> 01:28:59,320
 Финальный слайд с моей стороны это то, что я полностью отказался

1026
01:28:59,320 --> 01:29:05,920
 от написания промпта при помощи своих рук, потому что промпт довольно большой

1027
01:29:05,920 --> 01:29:10,300
 и LLM, она, так скажем, ищет всегда в нем какие-то скрытые смыслы.

1028
01:29:10,400 --> 01:29:14,400
 Можно случайно туда занести что-то неконсистентное, этого не понять,

1029
01:29:15,180 --> 01:29:18,280
 и LLM начинает вести себя совсем неадекватно.

1030
01:29:18,360 --> 01:29:22,580
 Тут, знаете, будет правильная аналогия, когда мы хотим с одного промпта закрыть фичу,

1031
01:29:22,580 --> 01:29:27,160
 потому что, если мы, например, разрабатываем что-то, мы закидываем ТЗ,

1032
01:29:27,860 --> 01:29:29,780
 и LLM начинает уточнять.

1033
01:29:29,980 --> 01:29:32,200
 А вот здесь, смотрите, например, есть противоречие.

1034
01:29:32,280 --> 01:29:36,720
 У вас написано, где-то нельзя согласовать дату, а где-то нужно согласовать дату,

1035
01:29:36,800 --> 01:29:39,740
 и плохо формализован контекст, когда можно, а когда нет.

1036
01:29:40,980 --> 01:29:45,680
 При разработке, да, LLM будет спрашивать, но реал-таймапе спросить не у кого.

1037
01:29:45,920 --> 01:29:51,280
 И вот если вы создаете подобные моменты, то тоже может вести себя неадекватно,

1038
01:29:51,280 --> 01:29:55,540
 и эти моменты очень хорошо вылавливают другие большие языковые модели,

1039
01:29:55,700 --> 01:29:58,500
 которые скажут, смотри, тут может быть другая трактовка,

1040
01:29:59,700 --> 01:30:01,800
 лучше их в этом моменте, конечно, послушаться.

1041
01:30:02,420 --> 01:30:05,340
 По моей части все, Марат, передаю тебе слово обратно. Спасибо.

1042
01:30:06,400 --> 01:30:10,400
 Спасибо. Теперь давайте немного поговорим про защиту чувствительных данных.

1043
01:30:10,520 --> 01:30:16,360
 Это такая очень щепетильная тема, и эту мысль гораздо легче будет объяснить на конкретном примере.

1044
01:30:16,420 --> 01:30:20,980
 Давайте предположим, что наш ассистент в какой-то момент должен провалидировать номер счета,

1045
01:30:20,980 --> 01:30:26,600
 но мы пытаемся объяснить ассистенту о том, что номер счета — это суперсекретные данные,

1046
01:30:26,720 --> 01:30:29,800
 которые ни при каких обстоятельствах нельзя произнести абоненту.

1047
01:30:29,860 --> 01:30:31,260
 Ты должен запросить их у абонента.

1048
01:30:31,420 --> 01:30:35,520
 Это очень плохая идея, потому что, как бы строго вы ни говорили ему не делать этого,

1049
01:30:36,080 --> 01:30:40,220
 на 100 звонков найдется какой-то кейс, при котором человек выводит из него эту информацию.

1050
01:30:41,060 --> 01:30:43,600
 В связи с этим вы можете поступить очень просто.

1051
01:30:43,680 --> 01:30:46,900
 Вы можете не передавать эти секретные данные агенту,

1052
01:30:47,000 --> 01:30:49,440
 а попросить агента спросить их у абонента.

1053
01:30:49,440 --> 01:30:52,780
 И воспользоваться преимуществом агента по отношению к человеку.

1054
01:30:53,220 --> 01:30:57,840
 Агент с скоростью речи транскрибирует и передает эту фразу в функцию.

1055
01:30:59,180 --> 01:31:04,440
 Передает эту фразу в функцию, вы ее внутри функции валидируете и возвращаете ответ, истинный или ложь.

1056
01:31:05,320 --> 01:31:09,040
 И здесь хотелось бы отметить, что у агента есть даже преимущества по отношению к человеку,

1057
01:31:09,100 --> 01:31:14,120
 потому что если бы мы работали с человеком, то нам приходилось бы просто верить в то,

1058
01:31:14,120 --> 01:31:18,300
 что человек не будет иметь никакого злого умысла и, увидев эти секретные данные,

1059
01:31:18,460 --> 01:31:21,180
 не воспользуется ими как-то плохо на стороне.

1060
01:31:23,240 --> 01:31:26,100
 Следующая неочевидная сложность, о которой хотелось бы рассказать,

1061
01:31:26,160 --> 01:31:28,020
 это война с другими ассистентами.

1062
01:31:28,820 --> 01:31:32,760
 Наш горький опыт показал, что агенты прекрасно общаются с агентами.

1063
01:31:33,260 --> 01:31:35,040
 И это общение, к сожалению, очень дорого стоит.

1064
01:31:35,160 --> 01:31:40,600
 У нас было несколько дней, когда мы сожгли очень много токенов на вот эту болтовню между агентами.

1065
01:31:41,420 --> 01:31:45,660
 И здесь мы потихоньку подходим к значению статуса недозвон.

1066
01:31:45,800 --> 01:31:51,180
 Вообще, это очень емкое слово, это очень емкий статус, который достоин, наверное, отдельного доклада.

1067
01:31:51,500 --> 01:31:54,660
 Но если пройтись по поверхности, то выглядит это приблизительно так.

1068
01:31:54,760 --> 01:31:59,360
 Когда вы получаете статус недозвонились, вы не понимаете причину, по которой вы недозвонились.

1069
01:31:59,700 --> 01:32:05,320
 Человек мог спуститься в метро, у него мог разрядиться телефон, он мог уехать за границу, у него вообще больше нет этого телефона.

1070
01:32:06,060 --> 01:32:09,880
 Какие-то агенты блокируют звонок, он даже не поступает к человеку в телефон.

1071
01:32:09,880 --> 01:32:15,940
 Или человек видит, что вы ему звоните, сбрасывает, и вам отвечают не короткие гудки, а вам отвечает какой-то агент.

1072
01:32:16,660 --> 01:32:22,620
 И на каждый из этих кейсов вы должны реагировать уникально, для того, чтобы повысить свою конверсию дозваниваемости.

1073
01:32:22,980 --> 01:32:24,940
 И при этом не задолбать абонента, конечно.

1074
01:32:27,240 --> 01:32:34,900
 Одно из решений, которое мы применили, это в первые секунды звонка у нас включается маленький промпт, который сжигает маленькое количество токенов.

1075
01:32:34,900 --> 01:32:38,340
 Этот маленький промпт определяет, с кем он разговаривает, с ассистентом или с человеком.

1076
01:32:38,860 --> 01:32:44,360
 Если он понимает, что он разговаривает с человеком, он вызывает большой промпт и передает ему весь контекст, который он получил там.

1077
01:32:45,020 --> 01:32:48,520
 Если он понимает, что он разговаривает с ассистентом, он завершает диалог.

1078
01:32:48,700 --> 01:32:54,980
 Дальше у вас уже есть вариативность, допустим, отправить смс-ку человеку, сказать о том, что вот мы звонили вам по поводу счетчика.

1079
01:32:57,140 --> 01:32:59,700
 Теперь хотелось бы рассказать о итогах внедрения.

1080
01:32:59,700 --> 01:33:06,080
 С июня 26 года мы полностью запустили на прот всю нашу систему, все наши решения.

1081
01:33:06,760 --> 01:33:11,880
 Мы полностью отключили AVR-систему звонобот, мы полностью отказались от внештатного колл-центра.

1082
01:33:12,420 --> 01:33:19,080
 Как итог, у нас 0% непринятых входящих звонков, наш колл-центр 24 на 7 на связи.

1083
01:33:19,080 --> 01:33:26,920
 Мы масштабируемся нажатием в два клика и в два раза сократили количество звонков подрядных организаций.

1084
01:33:27,040 --> 01:33:29,760
 Себестоимость затрат упала более чем в три раза.

1085
01:33:31,020 --> 01:33:33,780
 Всем спасибо за внимание, готовы ответить на ваши вопросы.

1086
01:33:36,760 --> 01:33:44,080
 Дима Марац, большое вам спасибо. Первый вопрос появился в онлайне и вопрос звучит так.

1087
01:33:44,520 --> 01:33:51,380
 Какие-то изменения в систему вносят только программисты или есть кейсы, которые решаются админками и обученными менеджерами?

1088
01:33:51,800 --> 01:33:56,340
 Может быть, заливка скриптов и тому подобное. Насколько нагружает IT-персонал поддержка системы?

1089
01:33:58,540 --> 01:34:02,880
 Ну, как бы удивительно это не звучало. У нас работает один программист над этим.

1090
01:34:03,480 --> 01:34:06,460
 Вы его видите, и пока он прекрасно с этим справляется.

1091
01:34:08,100 --> 01:34:12,900
 Тут надо упомянуть тот момент, что я не могу это делегировать кому-то.

1092
01:34:13,160 --> 01:34:17,300
 Любая одна строчка безобидная, она может по смыслу интерферировать с чем-то еще,

1093
01:34:17,660 --> 01:34:21,280
 и prompt начнет сходить с ума. Поэтому тут, к сожалению, все завязано в одного.

1094
01:34:21,280 --> 01:34:25,660
 Это очень ответственные мероприятия, и после добавления любого микроизменения

1095
01:34:25,660 --> 01:34:26,980
 нужно делать регрессы, к сожалению.

1096
01:34:27,760 --> 01:34:28,360
 Спасибо.

1097
01:34:32,040 --> 01:34:36,200
 Прошу прощения. Давайте, я передам микрофон.

1098
01:34:41,820 --> 01:34:45,200
 Коллеги, добрый день. Скажите, а как бот определяет, что он с ботом разговаривает?

1099
01:34:45,280 --> 01:34:47,540
 По каким критериям вы выработали механизм такой?

1100
01:34:49,720 --> 01:34:52,380
 Смотрите, тут можно классифицировать этих ботов.

1101
01:34:52,620 --> 01:34:55,440
 Есть те, которые не пытаются мимикрировать по человеку.

1102
01:34:55,500 --> 01:34:57,420
 С ними все очень просто. Они представляются.

1103
01:34:57,420 --> 01:35:00,660
 Они говорят с вами, говорит автоответчик, или оставьте голосовое сообщение.

1104
01:35:00,760 --> 01:35:02,820
 По этим фразам они очень быстро отсекаются.

1105
01:35:03,520 --> 01:35:09,520
 Есть более зловредные, типа Олега, которые мимикрируют по человеку и очень долго готовы разговаривать.

1106
01:35:10,100 --> 01:35:11,940
 С ними сложнее уже.

1107
01:35:12,200 --> 01:35:16,760
 Там нужно постоянно следить за тем, какие фразы они используют, какие приемчики.

1108
01:35:17,120 --> 01:35:21,860
 И сейчас еще в разработке у нас использование отдельной небольшой модели,

1109
01:35:21,860 --> 01:35:29,100
 которая будет использоваться параллельно, которая будет анализировать аудиодельты, тональность, как оно разговаривает.

1110
01:35:29,480 --> 01:35:37,240
 Наверное, Олег это тоже сможет когда-то победить, но сейчас в перспективе хотим еще отдельной моделью анализировать голос.

1111
01:35:53,420 --> 01:36:02,340
 Здравствуйте. Денис Эксли, подскажите, я вот увидел в конце бизнес-метрики ваши, 0% неотвеченных звонков и так далее.

1112
01:36:02,460 --> 01:36:04,700
 Все классно, супер, как бы трава зеленая.

1113
01:36:05,420 --> 01:36:12,720
 В чем бизнес-метрики неуспеха? Очевидно же, что не все довольны разговаривать с и ассистентом.

1114
01:36:13,380 --> 01:36:17,440
 Я вот не увидел обратной стороны медали. Вы это как-то меряете? Спасибо.

1115
01:36:18,580 --> 01:36:25,500
 Да, есть, конечно, люди, которые неохотно разговаривают с роботом.

1116
01:36:25,500 --> 01:36:39,140
 Но вот что показывает наш опыт. Где-то приблизительно 10-20% людей, которые начинают разговор с нашим агентом, неустанно повторяют оператор, оператор, оператор.

1117
01:36:40,400 --> 01:36:47,180
 Некоторые из них, некоторые кладут трубку. Некоторых мы начинаем цеплять тем, что начинаем закидывать немножко больше контекста.

1118
01:36:47,180 --> 01:36:54,120
 Мы видим его номер телефона, мы видим историю взаимодействия с ним и начинаем говорить о том, что в рамках данного звонка мы не можем позвать человека,

1119
01:36:54,180 --> 01:37:01,300
 но мы можем вам помочь, вот мы видим вашу заявку, у вас согласованная дата монтажа тогда-то и человек начинает уже располагаться к нему.

1120
01:37:01,420 --> 01:37:07,120
 Он все еще говорит с очень неприятной интонацией, иногда грубит, иногда оскорбляет, но закрывает свою задачу.

1121
01:37:08,100 --> 01:37:13,540
 Все-таки состоятся люди, которые кладут трубку, приблизительно половина из них перезванивает минут через пять.

1122
01:37:13,540 --> 01:37:21,660
 Опять начинают говорить человек, человек, человек, потом понимают, что безвыходная ситуация и начинают решать задачу с агентом.

1123
01:37:22,520 --> 01:37:29,720
 Какой-то процент людей не перезванивает, но у вас остался их номер телефона, и вы можете перезвонить этому человеку или направить ему смс.

1124
01:37:29,860 --> 01:37:31,220
 Это очень маленький процент людей.

1125
01:37:31,860 --> 01:37:35,940
 То есть 20-30% от всех звонящих?

1126
01:37:35,940 --> 01:37:46,400
 10-20% из них, где-то 50%, которые все-таки в итоге решают свою задачу или сейчас, или в течение пяти минут, еще какая-то часть перезванивает на следующий день.

1127
01:37:49,020 --> 01:37:49,540
 Спасибо.

1128
01:37:50,860 --> 01:37:55,860
 Я тут. Левее.

1129
01:37:59,140 --> 01:38:00,900
 Большое спасибо за доклад.

1130
01:38:02,300 --> 01:38:12,840
 Подскажите, пожалуйста, я правильно услышал, что у вас в итоге, грубо говоря, один бот, который общается с клиентами, и он периодически мог выдать какую-то секретную информацию, назовем это так.

1131
01:38:13,820 --> 01:38:18,520
 Ну, он не то, чтобы мог выдать какую-то секретную информацию, потому что у нас нет какой-то секретной информации.

1132
01:38:19,200 --> 01:38:39,500
 Когда мы его разрабатывали, мы тестировали все эти кейсы, и на этапе тестирования мы поняли, что невозможно передать какую-то чувствительную информацию агенту и сказать ему, не озвучивая эту чувствительную информацию, и он рано или поздно ее озвучит.

1133
01:38:40,720 --> 01:38:44,640
 Возникнет какой-то кейс, когда человек с другой стороны зайдет, и он ему ответит на это.

1134
01:38:44,640 --> 01:39:00,780
 А вот у меня, да, тут вопрос, просто в том же программировании есть там понятие компсуляции, да, то есть в той же Java, когда ты делаешь всяческие getter и setter к классу, ну то есть ты можешь получить только ответ, но не знаешь, что происходит внутри этого класса.

1135
01:39:00,780 --> 01:39:12,720
 Как будто бы можно было бы сделать два бота, а один бот общается с клиентом и никогда не может в принципе рассказывать чувствительную информацию, а второй обладает чувствительной информацией, но выдает всегда только результат.

1136
01:39:13,260 --> 01:39:20,960
 Да, можно. Мы тоже как-то думали на такую тему, но это более сложный какой-то кейс, где…

1137
01:39:20,960 --> 01:39:25,460
 Ну да, да. Вот мне просто было интересно, если думали, потому что мне тоже кажется, что это сложно.

1138
01:39:26,140 --> 01:39:29,100
 Это более сложный кейс, но это выглядит как вполне рабочая схема.

1139
01:39:29,180 --> 01:39:30,040
 А, все понял. Спасибо.

1140
01:39:34,540 --> 01:39:35,400
 Можно вопрос, да?

1141
01:39:36,660 --> 01:39:39,160
 У меня тоже вопрос про чувствительность данных.

1142
01:39:40,420 --> 01:39:43,620
 Вы привели пример с номером банковской карты,

1143
01:39:43,660 --> 01:39:45,940
 которое ушло агенту, и он как-то ее обрабатывает.

1144
01:39:45,940 --> 01:39:48,940
 Но есть ряд кейсов, в основном банковских,

1145
01:39:49,640 --> 01:39:54,640
 где установка в клаудные модели вообще запрещено отправлять любые данные,

1146
01:39:54,780 --> 01:39:57,280
 которые хоть как-то относятся к разряду чувствительных.

1147
01:39:57,780 --> 01:39:58,960
 И здесь встает вопрос.

1148
01:39:59,580 --> 01:40:01,360
 Либо рассматривать он прям решение,

1149
01:40:01,760 --> 01:40:05,380
 либо какой-то деананимайзер и использовать клаудную версию,

1150
01:40:05,480 --> 01:40:08,840
 чтобы уходило там в квадратных скобках номер банковской карты,

1151
01:40:09,080 --> 01:40:13,200
 но не ее физическая, да, там, карта, адрес и так далее.

1152
01:40:13,300 --> 01:40:17,340
 Вот подскажите, возможно ли использовать такой промежуточный шаг до модели?

1153
01:40:19,040 --> 01:40:20,900
 А мне кажется…

1154
01:40:20,900 --> 01:40:23,360
 Ну, с точки зрения туллов ничего не мешает это делать.

1155
01:40:26,060 --> 01:40:29,300
 Ну, то есть это, ну, некий там будет отдельный агент,

1156
01:40:29,300 --> 01:40:35,060
 который будет там скрывать что-то и после этого отправлять в основную модель уже некие данные.

1157
01:40:35,080 --> 01:40:38,340
 Мне кажется, вот молодой человек только что такую же идею озвучил две минуты назад, да.

1158
01:40:39,080 --> 01:40:42,900
 Ну да, молодой человек две минуты назад озвучил такой же вопрос,

1159
01:40:43,020 --> 01:40:46,160
 и мы говорим о том, что это выглядит как действительно рабочий кейс,

1160
01:40:46,260 --> 01:40:49,480
 просто это более сложное решение, чем то, которое я озвучил,

1161
01:40:50,020 --> 01:40:52,320
 и, ну, наверное, оба варианта жизнеспособны.

1162
01:40:52,900 --> 01:40:54,860
 Да, все, понял, спасибо. С разных сторон зашли.

1163
01:41:00,500 --> 01:41:02,260
 Хороший доклад, мне понравился.

1164
01:41:02,260 --> 01:41:05,760
 Тоже занимался время голосовым управлением.

1165
01:41:07,060 --> 01:41:10,960
 Подскажите, пожалуйста, вот эти сценарии, как я понимаю,

1166
01:41:11,100 --> 01:41:15,460
 они уже были изначально сделаны в какой-то CRM-системе.

1167
01:41:16,260 --> 01:41:19,600
 То есть вы, получается, взяли эти сценарии оттуда

1168
01:41:19,600 --> 01:41:24,640
 и переписали их в виде промта? Как это происходило?

1169
01:41:25,140 --> 01:41:28,760
 Да, именно так, но с тех пор на самом деле эти сценарии сильно разрослись.

1170
01:41:28,760 --> 01:41:33,680
 То есть бизнесу понравилось, они приходят и пытаются постоянно усложнить скрипты

1171
01:41:33,680 --> 01:41:37,560
 и усложнить их настолько, что в принципе какой-то живой оператор,

1172
01:41:37,580 --> 01:41:41,240
 он бы с этой сложностью, с этим ветвлением всем уже не мог бы работать.

1173
01:41:42,060 --> 01:41:44,820
 Но да, вот мы прошли путь, сначала пробовали маркдаун,

1174
01:41:45,080 --> 01:41:49,720
 потом перешли к кастомному DSL в рамках XML, и эта тема уже взлетела.

1175
01:41:49,860 --> 01:41:52,300
 То есть DSL у вас спас в этом.

1176
01:41:52,300 --> 01:41:57,740
 Тут еще хотелось бы добавить, что помимо того, что скрипт стал кратно сложнее,

1177
01:41:57,860 --> 01:42:01,200
 чем он был у человека, так еще и бизнес-кейсов выросло,

1178
01:42:01,360 --> 01:42:06,420
 потому что раньше человеческим операторам мы согласовали дату в конце недели.

1179
01:42:06,780 --> 01:42:10,740
 И бывает такое, что мастер приезжает, абонент забыл, уехал куда-то на дачу.

1180
01:42:10,800 --> 01:42:13,000
 Отправлять смс-ку предупреждать достаточно дорого.

1181
01:42:13,420 --> 01:42:17,580
 Человеческим операторам звонить, говорить о том, что помните, мы к вам завтра придем, тоже дорого.

1182
01:42:17,580 --> 01:42:21,160
 А вот с появлением агентов появляются новые возможности.

1183
01:42:21,580 --> 01:42:21,900
 Спасибо.

1184
01:42:25,720 --> 01:42:27,320
 Дима Барат, спасибо большое.

1185
01:42:27,960 --> 01:42:28,200
 Спасибо.

1186
01:42:28,320 --> 01:42:29,120
 А мы двигаемся дальше.

1187
01:42:29,420 --> 01:42:30,300
 Еще вопрос.

1188
01:42:31,240 --> 01:42:32,420
 Еще много вопросов.

1189
01:42:33,160 --> 01:42:44,300
 Предлагаю, у нас остался один доклад первой части и после общих докладов можно будет с коллегами пообщаться уже кулуарно.

1190
01:42:44,300 --> 01:42:49,480
 А мы переходим к докладу от Юры Ласкина.

1191
01:42:49,880 --> 01:42:57,140
 Юра архитектор Яндекс.Клауд и расскажет про паттерны проектирования и типовые ошибки при создании продуктов.

1192
01:42:57,480 --> 01:42:59,480
 Все.

1193
01:43:12,500 --> 01:43:14,500
 Приготовлюсь.

1194
01:43:25,540 --> 01:43:39,760
 Так, всем привет. Я Юра Ласкин. Сейчас с вами расскажу про типовые паттерны проектирования и типовые ошибки при создании продуктов.

1195
01:43:40,540 --> 01:43:41,680
 Немножко о себе.

1196
01:43:48,540 --> 01:43:53,520
 Я архитектор с 2004… Я в IT с 2004 года.

1197
01:43:54,020 --> 01:44:00,720
 Уже долгое время архитектор. Последние 12 лет я в разработке хайлот-проектов.

1198
01:44:00,900 --> 01:44:04,580
 Наверняка вы все так или иначе пользовались моими продуктами.

1199
01:44:04,580 --> 01:44:11,580
 Сейчас я в Яндекс.Клауде, помогаю крупным клиентам адоптить облако и технологии.

1200
01:44:12,700 --> 01:44:17,320
 О чем будет мой доклад? О чем я вам сегодня расскажу?

1201
01:44:17,820 --> 01:44:21,960
 Я расскажу про выбор подхода и решение для задачи.

1202
01:44:21,960 --> 01:44:26,300
 Когда использовать детерминированные алгоритмы, когда использовать недетерминированные.

1203
01:44:26,740 --> 01:44:32,340
 Я расскажу о том, как обеспечить безопасность при использовании агентов,

1204
01:44:32,680 --> 01:44:37,060
 как сделать мониторинг и наблюдаемость агентов.

1205
01:44:37,800 --> 01:44:41,620
 Доклад примерно на 25-30 минут будет.

1206
01:44:41,820 --> 01:44:47,360
 Формат доклада – ошибка и как ее митигировать, как ее решать в виде паттерна

1207
01:44:47,360 --> 01:44:49,820
 либо какой-то концепции решения.

1208
01:44:49,900 --> 01:44:55,900
 Начну с более простых тем, когда LLM используется в один проход.

1209
01:44:56,260 --> 01:45:01,560
 Закончу мультиагентскими системами и сложными паттернами.

1210
01:45:04,040 --> 01:45:05,700
 Начнем первый раздел.

1211
01:45:05,880 --> 01:45:08,860
 Это у нас выбор способа решения задач.

1212
01:45:09,280 --> 01:45:13,100
 В целом мы все задачи можем классифицировать.

1213
01:45:13,520 --> 01:45:15,580
 Четыре основных блока я выделил.

1214
01:45:15,580 --> 01:45:19,020
 Первый класс задач – это детерминированные алгоритмы

1215
01:45:19,020 --> 01:45:20,720
 со строгой бизнес-логикой.

1216
01:45:20,820 --> 01:45:23,380
 То есть мы идем в базу, идем в API,

1217
01:45:23,540 --> 01:45:26,780
 мы что-то получаем по явному какому-то идентификатору.

1218
01:45:27,420 --> 01:45:33,000
 Дальше мы внутри этого алгоритма наполняем эти данные

1219
01:45:33,000 --> 01:45:34,740
 вызовом каких-то микросервисов.

1220
01:45:35,620 --> 01:45:38,580
 Таким образом мы получаем четкий сценарий детерминированным.

1221
01:45:38,660 --> 01:45:42,300
 Здесь мы должны использовать всегда классический код,

1222
01:45:42,400 --> 01:45:44,440
 классическую разработку, классические алгоритмы.

1223
01:45:44,440 --> 01:45:48,440
 Второй класс задач, который мы решаем периодически,

1224
01:45:48,520 --> 01:45:53,440
 это прогнозирование некое по объему накопленных данных.

1225
01:45:53,780 --> 01:45:56,720
 Это не обязательно текст, это скорее всего где-то что-то куплено,

1226
01:45:56,760 --> 01:45:58,720
 в какой-то локации и так далее.

1227
01:45:59,220 --> 01:46:02,540
 Здесь мы используем уже классические алгоритмы,

1228
01:46:02,600 --> 01:46:05,000
 мы не используем код либо LLM.

1229
01:46:05,100 --> 01:46:10,040
 LLM нам помогает только писать что-то, что проанализирует эти данные.

1230
01:46:10,640 --> 01:46:17,800
 Дальше следующий класс задач уже более похож для того, чтобы использовать LLM.

1231
01:46:17,900 --> 01:46:23,160
 Анализ текста, суммаризация текста, наоборот, раскрытие текста,

1232
01:46:23,280 --> 01:46:24,900
 то есть написать текст на основе чего-то.

1233
01:46:25,380 --> 01:46:28,640
 Это уже хорошая задача для LLM, и здесь нужно использовать.

1234
01:46:28,640 --> 01:46:36,320
 И дальше особый класс задач, где уже используется сложный сценарий,

1235
01:46:36,440 --> 01:46:39,260
 где мы не можем писать явного алгоритма,

1236
01:46:39,320 --> 01:46:43,100
 мы просто используем какой-то набор инструментов внешних

1237
01:46:43,100 --> 01:46:49,360
 и в каком-то цикле, например, проверки, крутим их, пока не добьемся результата.

1238
01:46:49,440 --> 01:46:52,300
 При этом этот результат не всегда гарантирован,

1239
01:46:52,300 --> 01:46:55,920
 но в целом мы как будто бы приближаемся к его решению.

1240
01:46:57,580 --> 01:47:02,700
 Дальше немножко расскажу, где именно потенциал LLM раскрывается.

1241
01:47:03,200 --> 01:47:06,440
 То есть суммаризируя все, это все-таки работа с текстом.

1242
01:47:06,800 --> 01:47:12,160
 То есть излечение информации, генерация какого-то ответа на основе большого объема статьи.

1243
01:47:12,240 --> 01:47:18,620
 Например, как мы раньше использовали вики, делали какой-то вики, конфликс, неважно.

1244
01:47:19,040 --> 01:47:24,300
 Поиск, видели пачку статей, как-то глазами и головой анализировали все.

1245
01:47:24,400 --> 01:47:25,600
 Сейчас это работает по-другому.

1246
01:47:26,060 --> 01:47:31,640
 Мы вроде вводим какой-то текст, вводим запрос, получаем сразу смысл на основе этой пачки статей.

1247
01:47:31,640 --> 01:47:35,280
 И вот как раз шестой пункт, очень интересный и важный.

1248
01:47:35,380 --> 01:47:41,380
 Это создание рекомендаций с помощью LLM на основе, я назвал это жизненного опыта, но на самом деле это опыт обучения.

1249
01:47:41,380 --> 01:47:45,380
 Это как раз движок наш для агентских сценариев.

1250
01:47:53,240 --> 01:48:03,820
 Дальше второй момент, который надо отметить, я назвал это второй ошибкой в работе с агентами с LLM в первую очередь.

1251
01:48:03,940 --> 01:48:05,720
 Это перегрузка контекста.

1252
01:48:06,120 --> 01:48:10,380
 То есть здесь важно что понимать, как работает inference.

1253
01:48:10,520 --> 01:48:15,760
 У нас есть некое окно контекста, у нас весь этот контекст попадает на inference.

1254
01:48:15,900 --> 01:48:19,520
 Причем этот контекст неравномерен по вниманию.

1255
01:48:20,020 --> 01:48:25,580
 Вначале у нас есть большое внимание, высокое, потом в конце тоже высокое внимание.

1256
01:48:25,820 --> 01:48:34,920
 Посередине у нас провал полный, где LLM может забыть то, о чем шла речь, какие документы мы накидывали или какой диалог вообще был с пользователем.

1257
01:48:34,980 --> 01:48:37,980
 Это так называемое U-образное внимание в начале и в конце.

1258
01:48:37,980 --> 01:48:45,940
 Это в целом хорошо отражает то, как мы используем LLM, то есть мы используем агента, мы говорим, какая у него роль, это основа всего, начало.

1259
01:48:46,060 --> 01:48:49,520
 Вот ты технический саппорт или ты помощник чего-то.

1260
01:48:49,840 --> 01:48:53,480
 Он это помнит, LLM это всегда помнит и поддерживает.

1261
01:48:53,540 --> 01:48:59,040
 И в конце мы получаем последние инструкции, которые мы хотим, чтобы LLM сделала, и их тоже выполняют.

1262
01:48:59,140 --> 01:49:00,720
 Соответственно, центр у нас проваливается.

1263
01:49:01,920 --> 01:49:03,580
 Вообще, чем мы можем забить контекст?

1264
01:49:03,580 --> 01:49:10,460
 Мы можем забить контекст большим системным промтом, большим набором инструментов.

1265
01:49:10,560 --> 01:49:14,120
 То есть каждый инструмент валится в контекст и занимает какое-то место.

1266
01:49:15,360 --> 01:49:23,820
 Инструменты из MCP погружены, они тоже могут быть прогружены, например, все, и тогда мы забьем весь контекст.

1267
01:49:24,080 --> 01:49:28,260
 Любые ответы инструментов, запросы, reasoning токены и так далее, они все забивают контекст.

1268
01:49:28,380 --> 01:49:39,600
 Помимо этого у нас еще есть долговременная память, которая рядом находится, и она потенциально тоже может подняться в контекст, когда агент подумает, что ему какая-то информация нужна.

1269
01:49:40,020 --> 01:49:47,440
 При этом наша задача, как я отметил, это сократить вот этот контекст, не перегружать его.

1270
01:49:47,440 --> 01:49:51,400
 И дальше чуть-чуть расскажу про память агента.

1271
01:49:53,040 --> 01:49:59,000
 То есть у нас наверху на этой пирамиде краткосрочная память, контекст, чем мы сейчас работаем.

1272
01:49:59,960 --> 01:50:06,700
 Чуть ниже информация, которая сейчас не находится в контексте, но может быть легко подгружена.

1273
01:50:06,800 --> 01:50:11,960
 Это, например, скиллы какие-то, это информация о проекте, о пользователе, где-то сохраненная.

1274
01:50:11,960 --> 01:50:17,100
 Если агент локально где-то в файле у нас лежит, если агент как-то в облаке крутится,

1275
01:50:17,180 --> 01:50:23,540
 то тоже может как-то там либо в виде файла лежать, либо дополнительными инструкциями прогружена.

1276
01:50:23,660 --> 01:50:28,440
 Ну и у нас есть еще долговременная память, это вся та память, которая доступна агенту.

1277
01:50:28,480 --> 01:50:33,380
 Не вся память в мире, вся информация в мире, которая есть, а именно то, что агент может подгрузить.

1278
01:50:33,380 --> 01:50:41,260
 И мы должны все-таки сохранять в виде пирамиды, минимально загонять наверх, но минимально, чтобы сохранить качество.

1279
01:50:43,040 --> 01:50:51,180
 И самая для начала простая техника, как контекст уменьшить, это сделать оптимизацию промота.

1280
01:50:51,180 --> 01:50:58,680
 Коллеги уже повторялись, принцип keep it simple, либо keep it short and simple по-другому.

1281
01:50:59,680 --> 01:51:05,560
 Здесь суть в чем, что контекст, он достаточен, должен быть для системы промота,

1282
01:51:05,740 --> 01:51:08,740
 достаточен для того, чтобы выполнить задачу, но не перегружен.

1283
01:51:08,860 --> 01:51:14,360
 Туда не нужно добавлять все сценарии возможные, базу знаний, документы, все подряд инструкции.

1284
01:51:14,820 --> 01:51:17,860
 Он должен быть минимально достаточен для того, чтобы выполнить задачу.

1285
01:51:18,260 --> 01:51:22,940
 Должна быть предварительная информация о проекте какая-то в системном промоте,

1286
01:51:22,940 --> 01:51:31,360
 то есть над чем мы работаем, в какой компании, в каком отделе, кто я как агент, кому я помогаю.

1287
01:51:32,480 --> 01:51:39,040
 Как еще можно ограничить системный промт и базовый набор инструментов?

1288
01:51:39,160 --> 01:51:43,440
 То есть я предлагаю использовать не больше 10 инструментов, 10, максимум 15.

1289
01:51:43,640 --> 01:51:45,120
 Больше начинают путаться, как правило.

1290
01:51:45,120 --> 01:51:50,740
 Ну и в целом, если инструментов больше, имеет смысл их выносить в какого-то уже субагента.

1291
01:51:51,360 --> 01:51:55,480
 Ну и по возможности, то, с чем мы сталкиваемся, новая задача в новом диалоге.

1292
01:51:55,540 --> 01:51:58,900
 Не нужно пытаться до упора забивать контекст.

1293
01:51:59,000 --> 01:52:02,220
 Кто-то говорит, там миллион поддержка контекста.

1294
01:52:02,300 --> 01:52:03,200
 Но на самом деле это не так.

1295
01:52:03,200 --> 01:52:06,520
 Это 100 тысяч в начале и 100 тысяч в конце.

1296
01:52:06,680 --> 01:52:10,860
 А посередине какая-то вероятность, что LLM об этом не забудет.

1297
01:52:11,500 --> 01:52:14,420
 Ну и QM, соответственно, там 250 тысяч.

1298
01:52:14,600 --> 01:52:18,920
 И получается 30-40 тысяч где-то в начале, в конце и посередине.

1299
01:52:19,940 --> 01:52:21,300
 Чуть-чуть остается, чтобы не забыть.

1300
01:52:22,560 --> 01:52:22,960
 Дальше.

1301
01:52:23,820 --> 01:52:25,460
 Ну, общее правило всегда.

1302
01:52:25,780 --> 01:52:27,540
 Общий prompt, общий ответ.

1303
01:52:28,000 --> 01:52:30,020
 Специализированный prompt, детерминированный ответ.

1304
01:52:30,020 --> 01:52:34,780
 То есть, если мы явно хотим получить не какую-то вводу и явную информацию,

1305
01:52:34,820 --> 01:52:39,400
 мы должны максимально много сообщить о нашей задаче.

1306
01:52:39,560 --> 01:52:43,340
 То есть, айтичные задачи, мы работаем, например, какой-то в облаке.

1307
01:52:43,600 --> 01:52:45,260
 Мы используем облачный кубернетис.

1308
01:52:45,360 --> 01:52:50,060
 Мы используем проект с наименованием таким, чтобы у нас не было вот этого цикла,

1309
01:52:50,320 --> 01:52:55,780
 когда LM и агент куда-то ходят, что-то дополнительное запрашивают и тем самым забивают.

1310
01:52:55,780 --> 01:53:01,500
 Надо стараться максимально сформировать специализированный промпт с самого начала.

1311
01:53:03,220 --> 01:53:08,100
 Дальше. У нас про системный промпт на сайте очень хорошо написано.

1312
01:53:09,080 --> 01:53:14,080
 Здесь прям ключевые вещи, которые всегда нужно писать и стараться не забывать.

1313
01:53:14,280 --> 01:53:18,900
 Это роль. Обязательно это всегда задается с самого начала.

1314
01:53:18,900 --> 01:53:23,860
 Помним максимальное внимание. Агент всегда это исполняет.

1315
01:53:24,400 --> 01:53:27,480
 Твоя задача – формат ответа, контекст проекта.

1316
01:53:27,640 --> 01:53:31,820
 Немного, но минимально необходимое для того, чтобы все заработало.

1317
01:53:32,480 --> 01:53:33,640
 Правила и ограничения.

1318
01:53:34,700 --> 01:53:37,640
 Сложный вопрос. 10-15 правил и ограничений.

1319
01:53:37,780 --> 01:53:40,080
 Дальше мы можем начать путаться.

1320
01:53:40,700 --> 01:53:44,380
 Будет запрещено то, что в целом не должно быть запрещено.

1321
01:53:44,380 --> 01:53:48,200
 Поэтому с этим тоже можно пробовать, но быть осторожными.

1322
01:53:49,400 --> 01:53:57,860
 Дальше. Как еще в контексте уменьшения наполнения контекста и работы с качеством?

1323
01:53:57,940 --> 01:53:58,860
 Что можно еще сделать?

1324
01:54:00,160 --> 01:54:05,080
 Это из опыта, который мы через себя проводим в общении с заказчиком.

1325
01:54:05,600 --> 01:54:07,520
 Чаще всего забывают про фьюшот.

1326
01:54:07,520 --> 01:54:10,880
 Все-таки 1, 2, 3, 4 примера.

1327
01:54:11,220 --> 01:54:12,720
 Не нужно описывать все примеры.

1328
01:54:12,800 --> 01:54:15,480
 Нужно сообщить, в каком формате мы ожидаем ответ.

1329
01:54:15,920 --> 01:54:20,660
 Это в тех сценариях, когда агент у нас работает в качестве какого-то ассистента,

1330
01:54:20,780 --> 01:54:21,740
 какого-то пользователя.

1331
01:54:24,040 --> 01:54:28,420
 Интересный пункт у нас есть в индексном поиске.

1332
01:54:28,620 --> 01:54:30,420
 Это кастом чанкин.

1333
01:54:30,420 --> 01:54:41,140
 То есть это возможность нарезать изначально какой-то текст по явным чанкам вариативного формата.

1334
01:54:41,240 --> 01:54:49,460
 Когда мы сами задаем конец и начало чанка, и мы тем самым полностью закрываем смысл в этом чанке.

1335
01:54:50,080 --> 01:54:57,380
 Если мы берем стандартный подход, как чанкование происходит, то мы нарезаем, например, по 500, по 1000 токенов с неким оверлапом.

1336
01:54:57,380 --> 01:55:01,880
 И у нас по бокам может быть что-то срезано, какая-то важная информация.

1337
01:55:01,980 --> 01:55:07,200
 В случае кастомного чанкинга мы подаем в индекс этот чанк.

1338
01:55:07,500 --> 01:55:13,420
 Он может быть сформирован как руками, как по маркдауну, так и LLM вообще это хорошо генерирует тоже.

1339
01:55:13,740 --> 01:55:17,780
 То есть прошла в один проход, создала нам основу для наполнения индекса.

1340
01:55:17,840 --> 01:55:18,540
 Индекс мы забили.

1341
01:55:19,040 --> 01:55:20,360
 Дальше структурированный вывод.

1342
01:55:21,140 --> 01:55:22,320
 Тоже важная информация.

1343
01:55:22,320 --> 01:55:27,600
 Если мы работаем от агента к агенту, какая-то информация передается,

1344
01:55:27,740 --> 01:55:32,920
 либо мы в интерпрайзе, нам важно, чтобы формат был строгий JSON.

1345
01:55:33,440 --> 01:55:44,720
 Здесь что важно и интересно, что структурированный вывод – это не просто попытка в каком-то проходе дополнительном суммаризировать информацию в structured output.

1346
01:55:44,720 --> 01:55:52,260
 Это LLM проходит и отбрасывает токены, которые не относятся к задаче, к теме.

1347
01:55:52,320 --> 01:55:58,680
 Например, мы ищем какое-то местоположение, LLM по умолчанию может нам, а вот как пройти или какая будет погода.

1348
01:55:59,120 --> 01:56:07,040
 Используя структурированный вывод и ограничивая в целом этот вывод, рекомендации по тому, как одеться, надо писать не будет.

1349
01:56:07,180 --> 01:56:10,000
 Хотя без структурированного вывода может.

1350
01:56:10,560 --> 01:56:13,920
 Дальше немного расскажу про то, как тоже…

1351
01:56:16,020 --> 01:56:16,820
 Микрофон, да?

1352
01:56:22,320 --> 01:56:26,960
 Дальше отдельно про Eval и LLM as a judge.

1353
01:56:28,560 --> 01:56:31,840
 Позволяет улучшить качество вывода,

1354
01:56:31,900 --> 01:56:35,380
 при этом не используя какие-то дополнительные инструменты

1355
01:56:35,380 --> 01:56:38,600
 в виде как раз агентских циклов.

1356
01:56:38,820 --> 01:56:42,560
 Можно, в принципе, доработать промп так,

1357
01:56:42,560 --> 01:56:46,500
 чтобы он выдавал либо в режиме reasoning LLM,

1358
01:56:46,740 --> 01:56:48,220
 либо за один проход что-то отдавал.

1359
01:56:48,620 --> 01:56:52,180
 Важно сразу определять цель оценки качества,

1360
01:56:53,540 --> 01:56:55,060
 проработать метрики критерий,

1361
01:56:55,460 --> 01:56:57,740
 классический релевантность, точность, полнота,

1362
01:56:58,000 --> 01:57:01,200
 какие-то бинарные метрики могут быть тоже изначально обозначены.

1363
01:57:01,200 --> 01:57:05,480
 И что важно в работе LLM as a judge,

1364
01:57:05,740 --> 01:57:09,920
 нам LLM может разъяснить, почему она такую оценку поставила.

1365
01:57:10,000 --> 01:57:14,260
 В отличие от классических алгоритмов оценки,

1366
01:57:14,820 --> 01:57:15,600
 которые мы используем,

1367
01:57:16,260 --> 01:57:19,140
 LLM все-таки может нам сделать какое-то пояснение.

1368
01:57:19,640 --> 01:57:23,640
 Как нам работать вообще с первичными данными,

1369
01:57:23,820 --> 01:57:26,280
 которые мы в LLM направим?

1370
01:57:27,440 --> 01:57:30,360
 То есть мы набираем либо уже существующее

1371
01:57:30,360 --> 01:57:32,800
 какое-то взаимодействие с пользователями,

1372
01:57:32,980 --> 01:57:35,320
 и тогда мы можем прогнать через наш промпт,

1373
01:57:35,680 --> 01:57:38,260
 понять, как агент отвечает,

1374
01:57:39,300 --> 01:57:41,220
 насколько это совпадает с нашими ожиданиями,

1375
01:57:41,280 --> 01:57:43,340
 либо мы можем на основе этих данных

1376
01:57:43,340 --> 01:57:44,480
 сгенерировать синтетику,

1377
01:57:44,520 --> 01:57:45,900
 либо вообще сгенерировать синтетику

1378
01:57:45,900 --> 01:57:47,200
 с помощью какой-то мощной LLM.

1379
01:57:48,520 --> 01:57:50,920
 Что еще важно и можно использовать?

1380
01:57:51,060 --> 01:57:52,760
 То есть можно использовать эту технику

1381
01:57:52,760 --> 01:57:56,880
 PerRequest, то есть когда мы в конце запроса

1382
01:57:56,880 --> 01:58:00,580
 валидируем ответ, передаем на новый цикл.

1383
01:58:01,100 --> 01:58:02,720
 Если ответ нас не устраивает,

1384
01:58:02,900 --> 01:58:05,000
 можно использовать PerChange,

1385
01:58:05,100 --> 01:58:05,760
 я это назвал.

1386
01:58:06,140 --> 01:58:08,180
 То есть изменения совершенно любые.

1387
01:58:08,480 --> 01:58:11,860
 Мы изменили версию модели 3.5 на 3.6.

1388
01:58:12,860 --> 01:58:15,300
 Пробуем, проверяем, насколько это влияет.

1389
01:58:15,680 --> 01:58:17,360
 Мы изменили сам Prompt.

1390
01:58:18,180 --> 01:58:20,260
 Дальше мы также смотрим,

1391
01:58:20,260 --> 01:58:23,340
 насколько у нас качество улучшилось или ухудшилось.

1392
01:58:23,840 --> 01:58:26,260
 Или, например, можно использовать это PerReview,

1393
01:58:26,320 --> 01:58:28,580
 то есть мы делаем какое-то квартальное ревью

1394
01:58:28,580 --> 01:58:33,260
 либо ежегодное ревью, прогоняем все ответы.

1395
01:58:33,380 --> 01:58:34,360
 Да, это может быть дорого,

1396
01:58:34,720 --> 01:58:41,820
 но для этого у нас есть как раз батч вызовы LLM в Яндексе.

1397
01:58:42,020 --> 01:58:44,860
 То есть это такой режим асинхронного использования,

1398
01:58:44,860 --> 01:58:48,240
 когда вы даете задачу, она через какое-то время отработается.

1399
01:58:50,080 --> 01:58:50,740
 Так, дальше.

1400
01:58:51,380 --> 01:58:55,720
 Как нам правильно в части контекста работать

1401
01:58:55,760 --> 01:58:56,760
 с инструментами?

1402
01:58:58,820 --> 01:58:59,960
 Векторный поиск.

1403
01:59:00,500 --> 01:59:03,380
 Что сюда важно и нужно заносить?

1404
01:59:04,080 --> 01:59:06,080
 Сюда мы заносим текстовую информацию

1405
01:59:06,080 --> 01:59:06,880
 либо инструкции.

1406
01:59:07,180 --> 01:59:09,020
 То есть это не какая-то информация

1407
01:59:09,020 --> 01:59:10,480
 с идентификаторами пользователя,

1408
01:59:10,480 --> 01:59:13,580
 которую мы можем получить с помощью tool calling, например.

1409
01:59:14,080 --> 01:59:16,220
 Это текст, по которому мы выполняем поиск.

1410
01:59:17,840 --> 01:59:19,960
 Дальше мы получили текст в контекст.

1411
01:59:20,260 --> 01:59:24,760
 У нас несколько вариантов ответов из векторного поиска

1412
01:59:24,760 --> 01:59:25,920
 попал в контекст.

1413
01:59:26,020 --> 01:59:29,980
 Дальше LLM его анализирует и пытается что-то сделать.

1414
01:59:30,400 --> 01:59:30,640
 Дальше.

1415
01:59:30,740 --> 01:59:34,400
 Если мы хотим получить явную статью, текст,

1416
01:59:34,740 --> 01:59:37,520
 либо описание какого-то, например, товара,

1417
01:59:37,880 --> 01:59:39,360
 то здесь мы используем tool calling.

1418
01:59:39,500 --> 01:59:43,940
 Мы не используем набор данных как раз в векторном поиске.

1419
01:59:44,300 --> 01:59:47,420
 Мы явно по какому-то идентификатору достаем эти данные точечно.

1420
01:59:47,900 --> 01:59:48,980
 Они попадают в контекст.

1421
01:59:50,140 --> 01:59:50,540
 Дальше.

1422
01:59:50,980 --> 01:59:51,520
 Websearch.

1423
01:59:52,460 --> 01:59:53,760
 В целом можно не ограничивать его,

1424
01:59:53,760 --> 01:59:56,220
 если мы какое-то исследование проводим.

1425
01:59:56,660 --> 02:00:00,080
 Все данные из веба, которые только, возможно, по максимуму сгрузили,

1426
02:00:00,500 --> 02:00:04,080
 доработали в LLM, положили в контекст, переварили в LLM.

1427
02:00:04,220 --> 02:00:04,940
 Что-то она отдаст.

1428
02:00:05,260 --> 02:00:08,740
 Но если мы хотим как-то сократить содержимое,

1429
02:00:08,840 --> 02:00:12,220
 нам нужно использовать ограничения по домену,

1430
02:00:12,300 --> 02:00:14,960
 ограничения по региону, ограничения по количеству ответов.

1431
02:00:15,180 --> 02:00:17,600
 Это все есть в Websearch.

1432
02:00:18,500 --> 02:00:20,700
 И вот еще один интересный кейс.

1433
02:00:20,700 --> 02:00:24,540
 Еще раз про глубину контекста.

1434
02:00:24,780 --> 02:00:28,940
 Мы в LLM, например, или в агента грузим большой документ.

1435
02:00:29,040 --> 02:00:29,940
 Он у нас парсится.

1436
02:00:30,440 --> 02:00:31,760
 Мы забиваем весь контекст,

1437
02:00:32,640 --> 02:00:34,800
 но хотим каким-то образом документ проанализировать.

1438
02:00:34,900 --> 02:00:39,120
 В этом случае, скорее всего, LLM много из этого документа потеряет.

1439
02:00:39,620 --> 02:00:43,100
 Чтобы она не потеряла, используем tool-interpreter.

1440
02:00:43,480 --> 02:00:45,380
 Она делает скрипт, пишет код.

1441
02:00:45,800 --> 02:00:48,320
 У нас есть sandbox, который запускает этот код.

1442
02:00:48,320 --> 02:00:51,400
 И она уже этот файл сама парсит, сама анализирует.

1443
02:00:52,900 --> 02:00:57,980
 Не забивая при этом контекст, а то, что нужно после анализа, она в контекст как раз добавит.

1444
02:01:05,340 --> 02:01:08,580
 Третья ошибка или антипаттерн, который мы увидели,

1445
02:01:09,120 --> 02:01:12,380
 использование одной мощной модели для всех случаев жизни.

1446
02:01:12,660 --> 02:01:20,340
 То есть я здесь рассказываю, например, про одно окошко, которое есть в организации,

1447
02:01:20,440 --> 02:01:25,620
 куда сотрудники направляют свои запросы, и задачи могут быть у сотрудников совершенно разные.

1448
02:01:26,340 --> 02:01:31,980
 Кто-то ищет что-то по внутренней базе знаний, административные какие-то вопросы,

1449
02:01:32,100 --> 02:01:36,140
 как уйти в отпуск, что нужно сделать, какой документ подписать.

1450
02:01:36,140 --> 02:01:42,880
 Кто-то занимается конкурентным анализом в интернете с очень агрессивным использованием веб-сеуча.

1451
02:01:43,260 --> 02:01:50,020
 Кто-то может какой-то анализ внутренней документации или внешней документации загружать LLM.

1452
02:01:50,080 --> 02:01:55,160
 Это все задачи разного класса, и они могут быть решены одной сильной моделью,

1453
02:01:55,260 --> 02:01:59,000
 но можно это делать иначе.

1454
02:01:59,000 --> 02:02:06,560
 Также сильные модели у нас, как правило, дают недетерминированный способ решения задачи.

1455
02:02:06,620 --> 02:02:09,080
 Они каждый раз могут выбрать какой-то новый способ.

1456
02:02:09,940 --> 02:02:14,800
 Скиллы-то немного решают этот вопрос, но тем не менее проблема остается.

1457
02:02:15,020 --> 02:02:22,280
 Еще в контексте использования зарубежных моделей могут быть проблемы с ограничениями как внешними, так и внутренними.

1458
02:02:22,400 --> 02:02:25,080
 То есть нам безопасность запрещает передавать какие-то данные.

1459
02:02:25,480 --> 02:02:27,940
 Да, они могут быть не персональны, но они все равно чувствительны.

1460
02:02:27,940 --> 02:02:29,340
 Просто так их передавать нельзя.

1461
02:02:29,620 --> 02:02:32,860
 Нужно что-то делать, работать на базе того, что мы имеем.

1462
02:02:32,980 --> 02:02:35,620
 Какой-нибудь дипсик, либо индексовые модели.

1463
02:02:38,040 --> 02:02:41,980
 Дальше важный момент с мощными моделями.

1464
02:02:42,280 --> 02:02:46,020
 Модели у нас хорошие, дорогие, которые много всего умеют.

1465
02:02:46,120 --> 02:02:48,220
 Они, к сожалению, не дешевеют.

1466
02:02:49,340 --> 02:02:51,940
 И есть проблема с тем, что…

1467
02:02:51,940 --> 02:02:56,880
 Ну, не проблема, это хорошая вещь, что сейчас LLM-агенты

1468
02:02:56,880 --> 02:02:58,960
 прорастают вообще во все отделы организации.

1469
02:02:59,060 --> 02:03:02,000
 Раньше у нас только внутри IT-отдела как-то более-менее использовали.

1470
02:03:02,080 --> 02:03:06,680
 Сейчас прорастают во все отделы, и совершенно разные запросы и задачи идут.

1471
02:03:06,780 --> 02:03:10,140
 Соответственно, здесь мы повышаем стоимость,

1472
02:03:11,200 --> 02:03:14,340
 используя дорогие модели западные.

1473
02:03:15,680 --> 02:03:17,640
 Повышаем общую стоимость владения этими моделями.

1474
02:03:19,000 --> 02:03:21,680
 Что мы предлагаем здесь использовать,

1475
02:03:21,680 --> 02:03:24,920
 это на инфраструктурном уровне маршрутизацию,

1476
02:03:25,820 --> 02:03:28,580
 паттерн называется LLM или Agent Router.

1477
02:03:29,720 --> 02:03:32,720
 Суть здесь в использовании классификаторов

1478
02:03:32,720 --> 02:03:36,320
 для определения целевой LLM либо агента.

1479
02:03:37,700 --> 02:03:39,620
 Что здесь интересно,

1480
02:03:39,960 --> 02:03:42,200
 можно использовать как LLM классификатор,

1481
02:03:42,360 --> 02:03:45,460
 так и классификатор на базе каких-то регэкспов.

1482
02:03:45,700 --> 02:03:49,740
 LLM понимает суть тематических запросов,

1483
02:03:49,740 --> 02:03:52,080
 дальше переводит его на субагента.

1484
02:03:52,240 --> 02:03:54,760
 Субагент уже работает с

1485
02:03:54,760 --> 02:03:56,760
 ограниченным количеством инструментов.

1486
02:03:57,040 --> 02:03:59,780
 У него есть какой-то свой собственный промп,

1487
02:03:59,800 --> 02:04:03,080
 что ты помощник сотрудников для работы

1488
02:04:03,080 --> 02:04:05,120
 с внутренней базой знаний и так далее.

1489
02:04:05,620 --> 02:04:08,720
 Понятно, промп системный должен быть больше.

1490
02:04:10,180 --> 02:04:11,960
 Какие-то субагенты, например,

1491
02:04:12,940 --> 02:04:15,520
 работают у нас с чувствительной информацией,

1492
02:04:15,600 --> 02:04:17,360
 с персональной информацией, то же самое.

1493
02:04:17,360 --> 02:04:18,980
 LLM их классифицирует, говорит,

1494
02:04:19,560 --> 02:04:23,040
 вот только этому агенту можно передать,

1495
02:04:23,600 --> 02:04:26,320
 передает запрос какому-то агенту

1496
02:04:26,320 --> 02:04:28,700
 для работы с чувствительной информацией,

1497
02:04:28,780 --> 02:04:30,560
 с чувствительным доступом, и все,

1498
02:04:30,700 --> 02:04:31,660
 она с ним работает.

1499
02:04:32,060 --> 02:04:34,400
 Как итог мы получаем маршрутизацию запросов,

1500
02:04:35,060 --> 02:04:35,940
 снижение стоимости.

1501
02:04:36,940 --> 02:04:39,540
 Параллельно этот паттерн нам закрывает вопросы

1502
02:04:39,540 --> 02:04:41,120
 как раз проверки разных гипотез.

1503
02:04:41,540 --> 02:04:43,780
 То есть мы изменили какой-то промпт,

1504
02:04:43,780 --> 02:04:48,460
 изменили тулы, выкатили какой-то процент запросов

1505
02:04:48,460 --> 02:04:53,600
 на вторую версию модели или агента,

1506
02:04:53,940 --> 02:04:55,000
 направили туда часть рафика,

1507
02:04:55,080 --> 02:04:56,360
 посмотрели, что с ним происходит.

1508
02:04:56,960 --> 02:04:59,140
 Туда же так называемый фуллбэк,

1509
02:04:59,300 --> 02:05:02,160
 когда какая-то модель сильная,

1510
02:05:02,220 --> 02:05:03,160
 может быть недоступна,

1511
02:05:03,860 --> 02:05:05,780
 может фуллбэчиться на слабую модель.

1512
02:05:06,700 --> 02:05:09,200
 Обязательно, я считаю, на инфраструктурном уровне

1513
02:05:09,200 --> 02:05:11,800
 паттерный компонент LLM роутера.

1514
02:05:12,800 --> 02:05:13,440
 Дальше.

1515
02:05:14,840 --> 02:05:16,940
 Здесь пример на базе LightLM,

1516
02:05:16,940 --> 02:05:19,120
 как это сделано. Можно сделать на базе LightLM,

1517
02:05:19,240 --> 02:05:21,160
 можно на базе наших workflows.

1518
02:05:21,760 --> 02:05:25,760
 Здесь наверху мы определили две модели,

1519
02:05:26,440 --> 02:05:31,020
 как бы субагента, либо субмодели для разных запросов.

1520
02:05:31,160 --> 02:05:36,500
 Ниже определенно классификатор и стратегию маршрутизации.

1521
02:05:37,140 --> 02:05:40,480
 Определили, что классификатором у нас будет легкая Яндекс.Лайд.ГПТ.

1522
02:05:40,980 --> 02:05:44,420
 Она быстро отрабатывает и возвращает два слова.

1523
02:05:44,420 --> 02:05:46,880
 Либо AgentCoder, либо AgentTrackExpert.

1524
02:05:46,980 --> 02:05:47,580
 Это как пример.

1525
02:05:48,020 --> 02:05:52,160
 Мы пишем некую инструкцию, некий промпт, классифицируй этот запрос и передай кому нужно.

1526
02:05:52,980 --> 02:05:58,540
 Классифицируй, дальше запрос полностью передается ниже стоящей какой-то модели.

1527
02:06:00,180 --> 02:06:02,680
 И вот теперь уже к интересному.

1528
02:06:06,020 --> 02:06:10,660
 В случае, когда у нас наша модель какая-то не справляется,

1529
02:06:10,780 --> 02:06:13,000
 или наш агент не справляется с большой сложной задачей,

1530
02:06:13,000 --> 02:06:18,540
 здесь уже можно использовать паттерн или серию паттернов оркестратор.

1531
02:06:19,420 --> 02:06:23,340
 То есть мы попробовали все решения, убедились, что они точно не работают.

1532
02:06:23,560 --> 02:06:28,200
 Ни корректировка промтов, ни какой-то LLM в режиме резинга,

1533
02:06:28,280 --> 02:06:33,200
 небольшая модель, ни какой-то агентский цикл не сработал.

1534
02:06:33,800 --> 02:06:37,020
 В этом случае мы уже используем паттерн оркестратор.

1535
02:06:38,340 --> 02:06:41,500
 Он принимает задачу, одна какая-то моделька, например,

1536
02:06:41,580 --> 02:06:45,260
 и передает задачи субагентам специализированного ОЛМ.

1537
02:06:45,640 --> 02:06:50,580
 Они могут быть как дообученные, как специализированные со своими тулами,

1538
02:06:51,580 --> 02:06:55,760
 так и агенты на базе ВЛМ.

1539
02:06:56,560 --> 02:06:59,920
 И немножко расскажу про паттерны оркестрации,

1540
02:07:00,060 --> 02:07:04,820
 которые мы встречаем в виде неких решений,

1541
02:07:04,900 --> 02:07:07,520
 но мы уже их выделяем в виде паттернов.

1542
02:07:08,140 --> 02:07:10,800
 Первый паттерн тут у нас последовательная цепочка выполнения.

1543
02:07:10,800 --> 02:07:13,140
 Очень интересный паттерн.

1544
02:07:13,320 --> 02:07:18,180
 Например, мы собираемся сгенерить какую-то статью в маркетинге.

1545
02:07:18,280 --> 02:07:20,920
 То есть мы сначала занимаемся поиском информации,

1546
02:07:21,080 --> 02:07:23,740
 потом агент занимается поиском информации,

1547
02:07:23,820 --> 02:07:27,960
 второй агент у нас занимается, например, написанием черновика,

1548
02:07:28,360 --> 02:07:30,040
 третий агент у нас проверяет.

1549
02:07:30,200 --> 02:07:32,800
 Он такой строгий судья и проверяет,

1550
02:07:33,620 --> 02:07:36,060
 насколько мы попадаем в ожидание компании,

1551
02:07:36,180 --> 02:07:38,720
 в ожидание изначального промта, который был,

1552
02:07:38,720 --> 02:07:41,800
 насколько мы вообще по тексту проходим,

1553
02:07:41,920 --> 02:07:46,420
 не нарушает ли этот текст каких-то там ограничений внешних.

1554
02:07:47,540 --> 02:07:50,220
 Дальше паттерн мультиплексирования можно использовать.

1555
02:07:51,000 --> 02:07:54,620
 Это когда у нас задача либо независимая,

1556
02:07:55,080 --> 02:07:57,840
 то есть мы, например, имеем агента финансиста,

1557
02:07:57,980 --> 02:08:01,000
 агента какого-то айтишного по предметам

1558
02:08:01,000 --> 02:08:04,960
 и дальше агентов каких-то по предметным областям.

1559
02:08:04,960 --> 02:08:07,780
 Мы, в принципе, эту задачу можем на несколько агентов распределить

1560
02:08:07,780 --> 02:08:13,900
 и каждый из этих агентов, либо потом мы соберем с них общий результат,

1561
02:08:14,060 --> 02:08:16,820
 как-то его суммаризируем и уже отдаем пользователю,

1562
02:08:16,940 --> 02:08:18,160
 либо еще на цикл загоняем,

1563
02:08:18,720 --> 02:08:23,180
 либо мы можем работать несколькими агентами в параллели.

1564
02:08:23,320 --> 02:08:26,240
 То есть мы сразу запускаем несколько задач и смотрим,

1565
02:08:26,340 --> 02:08:30,060
 какой агент из них лучше справится, выбираем лучший результат.

1566
02:08:30,060 --> 02:08:37,060
 На практике у нас такое использование было при сканировании документов,

1567
02:08:37,960 --> 02:08:43,680
 то есть передавали большую пачку документов на исследования,

1568
02:08:44,640 --> 02:08:47,880
 и мы хотели получить наиболее лучший результат

1569
02:08:47,880 --> 02:08:50,940
 от сканирования, поиска истины в этом документе.

1570
02:08:51,080 --> 02:08:55,680
 Соответственно, отдавали их подряд на все модели на несколько

1571
02:08:55,680 --> 02:08:57,680
 и просто получали лучший результат.

1572
02:08:57,680 --> 02:09:01,480
 Дальше паттерн, который сейчас пока не так активно используется,

1573
02:09:01,600 --> 02:09:04,120
 но тоже возможен в каких-то исследованиях, групповой чат.

1574
02:09:05,300 --> 02:09:09,420
 Задача передается на какое-то количество агентов.

1575
02:09:10,080 --> 02:09:14,500
 Задача звучит для всех одинаковая, но у каждого агента есть своя специализированная

1576
02:09:14,500 --> 02:09:16,900
 системная предметная область.

1577
02:09:17,320 --> 02:09:24,420
 Например, агент-юрист или агент техпис, агент по тот же самый IT, какой-то эксперт.

1578
02:09:24,420 --> 02:09:30,460
 Они совместно пытаются закрыть какую-то задачу, анализируя этот документ

1579
02:09:30,460 --> 02:09:32,500
 и придя к какому-то решению, выводу.

1580
02:09:33,280 --> 02:09:36,620
 Агент, дальше паттерн делегирования.

1581
02:09:37,160 --> 02:09:43,220
 Как раз в SDK OpenAI он присутствует, сделанный очень похож на предыдущий паттерн роутер,

1582
02:09:43,320 --> 02:09:48,180
 но роутер работает на инфраструктурном уровне, а это паттерн на прикладном, hand-off.

1583
02:09:48,180 --> 02:09:52,180
 То есть агент-оркестратор получает задачу, выбирает нужного субагента

1584
02:09:52,820 --> 02:09:56,400
 и передает ему полностью делегируя задачу.

1585
02:09:56,500 --> 02:10:01,060
 Именно субагент отвечает на изначальный запрос пользователя.

1586
02:10:01,260 --> 02:10:05,480
 И вот тоже интересно для решения задач исследовательских

1587
02:10:05,480 --> 02:10:07,440
 паттерн-динамическая оркестрация,

1588
02:10:07,640 --> 02:10:15,820
 когда агент-оркестратор не знает, как ему решить конечную задачу,

1589
02:10:15,920 --> 02:10:20,540
 но он понимает, что у него есть какое-то количество субагентов специализированных,

1590
02:10:20,540 --> 02:10:24,580
 он создает список задач и субагенты эти задачи разбирают.

1591
02:10:24,920 --> 02:10:27,640
 В целом это то, что мы видим в инструментах,

1592
02:10:27,740 --> 02:10:31,180
 либо кодекс, либо какие-то среды разработки,

1593
02:10:31,340 --> 02:10:33,340
 когда агент сначала напиливает,

1594
02:10:34,000 --> 02:10:36,380
 примерно прообраз результата какой-то рисует

1595
02:10:36,380 --> 02:10:37,620
 и дальше пытается их выполнить.

1596
02:10:37,900 --> 02:10:40,880
 Очень хорошо подходит как раз для исследовательских работ.

1597
02:10:42,240 --> 02:10:42,980
 Дальше.

1598
02:10:44,060 --> 02:10:49,760
 Что мы видим еще у наших клиентов,

1599
02:10:49,940 --> 02:10:55,980
 что много кто использует агентов с разным уровнем автономности.

1600
02:10:55,980 --> 02:11:00,420
 Это уже стандартная индустрия становятся эти наименования.

1601
02:11:01,400 --> 02:11:02,520
 То есть human in the loop.

1602
02:11:02,740 --> 02:11:07,560
 Человек явно в процессе и периодически призывается в агентском цикле.

1603
02:11:08,000 --> 02:11:10,600
 Human on the loop, когда человек присматривает.

1604
02:11:11,960 --> 02:11:13,040
 Третий момент.

1605
02:11:13,340 --> 02:11:17,380
 Human out of the loop, когда агент работает полностью автономно,

1606
02:11:17,660 --> 02:11:19,120
 человек не присоединяется.

1607
02:11:19,120 --> 02:11:23,340
 И вот интересный кейс из жизни.

1608
02:11:23,760 --> 02:11:28,700
 I am the loop, когда агент консультирует человека,

1609
02:11:28,800 --> 02:11:30,320
 а человек работает руками.

1610
02:11:30,400 --> 02:11:32,340
 У меня как раз был заказчик.

1611
02:11:35,040 --> 02:11:39,440
 Задача была в том, чтобы собрать базу обслуживания,

1612
02:11:39,580 --> 02:11:44,660
 техническую документацию для порядка сотни единиц оборудования разного.

1613
02:11:44,660 --> 02:11:47,860
 Ни один человек не может эту сотню единиц держать

1614
02:11:47,860 --> 02:11:50,440
 либо в документах, либо в голове.

1615
02:11:51,540 --> 02:11:56,800
 И здесь уже мы сообщаем АИ, смотри, я хочу провести регламентные работы

1616
02:11:56,800 --> 02:12:00,960
 над таким-то оборудованием, что мне нужно сделать.

1617
02:12:01,040 --> 02:12:04,960
 И он ему уже говорит, какой нужно взять инструмент,

1618
02:12:05,320 --> 02:12:07,820
 какие расходные материалы, либо еще лучше,

1619
02:12:07,920 --> 02:12:11,440
 эти расходные материалы изначально должны попасть на какой-то склад.

1620
02:12:16,080 --> 02:12:20,720
 По поводу использования оркестраторов, еще и человека в цикле.

1621
02:12:21,320 --> 02:12:27,440
 Например, мы можем заниматься каким-то анализом предложений на какой-то ТЗ.

1622
02:12:27,600 --> 02:12:30,960
 Мы в виде заказчика хотим проанализировать пачку документов.

1623
02:12:31,040 --> 02:12:35,420
 Мы хотим эти документы проанализировать с разных сторон.

1624
02:12:35,640 --> 02:12:40,480
 Если мы все эти аспекты сообщим в одной ЛМ, она, скорее всего, запутается.

1625
02:12:40,600 --> 02:12:47,560
 То есть нам нужен агент-юрист, агент-технарь, агент-сотрудник тендерного отдела.

1626
02:12:47,560 --> 02:12:56,300
 Если мы просто возьмем и скоруем эти все документы в одного агента ЛМ, он с большой вероятностью разные предложения от разных компаний все перепутает.

1627
02:12:57,120 --> 02:13:03,900
 Если мы, соответственно, используем оркестратор, какие-то паттерны оркестрирования, то эту задачу будет выполнить гораздо легче.

1628
02:13:06,280 --> 02:13:09,100
 Дальше у нас большой блок про безопасность.

1629
02:13:16,060 --> 02:13:17,360
 Касательно безопасности.

1630
02:13:18,020 --> 02:13:23,140
 У меня коллеги на вебинарах рассказывали про инфраструктурный слой безопасности,

1631
02:13:23,340 --> 02:13:32,120
 то есть как обеспечить сетевую безопасность, как обеспечить безопасность через сервисные аккаунты.

1632
02:13:32,120 --> 02:13:39,560
 Я разберу безопасность на прикладном уровне, когда уже непосредственно попадает запрос в агента.

1633
02:13:40,740 --> 02:13:46,860
 И здесь в первую очередь мы используем паттерн контекст изолейшн.

1634
02:13:46,940 --> 02:13:50,640
 Это очень древний паттерн безопасности.

1635
02:13:51,480 --> 02:13:56,740
 То есть что мы предлагаем использовать для изоляции областей работы.

1636
02:13:56,740 --> 02:14:02,820
 Мы все-таки делаем агентов с как можно наименьшими доступными привилегиями.

1637
02:14:03,200 --> 02:14:08,220
 То есть когда мы его тестируем, да, мы можем использовать какие-то админские права,

1638
02:14:08,260 --> 02:14:12,400
 либо права на редактирование, но в продакшене обязательно мы ограничиваем его работу.

1639
02:14:13,600 --> 02:14:22,480
 Мы делаем субагентов, у которых самих по себе ограничен набор инструментов и системного промта.

1640
02:14:22,480 --> 02:14:29,480
 Мы также в векторном поиске используем метод данных для фильтрации контента.

1641
02:14:30,360 --> 02:14:35,900
 То есть у нас возможность в векторном поиске есть пометить файлы тегами,

1642
02:14:36,280 --> 02:14:40,180
 например, это финансовая информация, это IT-шная информация, это административная информация.

1643
02:14:40,680 --> 02:14:44,420
 Это мы можем использовать для того, чтобы изолировать скоуп того,

1644
02:14:44,560 --> 02:14:46,200
 что может этот агент забрать, получить.

1645
02:14:46,700 --> 02:14:50,700
 Дальше вопросы касательно инструментов, которые у нас доступны,

1646
02:14:51,200 --> 02:14:55,840
 ну и может быть не только у нас, в целом в работе с агентами LLM.

1647
02:14:56,860 --> 02:15:01,780
 Как я уже на предыдущем слайде говорил, мы должны запрашивать только необходимое.

1648
02:15:01,920 --> 02:15:07,560
 Мы не запрашиваем какие-то функции по виду get all,

1649
02:15:07,660 --> 02:15:15,520
 когда мы там получили 100 единиц каких-то элементов из базы данных,

1650
02:15:15,640 --> 02:15:17,680
 потом внутри контекста их отфильтровали.

1651
02:15:17,740 --> 02:15:18,840
 Нет, это абсолютно неправильно.

1652
02:15:18,840 --> 02:15:24,640
 Мы должны принимать какой-то либо набор массив элементов,

1653
02:15:24,800 --> 02:15:27,760
 которые мы хотим, массив идентификаторов,

1654
02:15:27,940 --> 02:15:30,160
 исходить в них какой-то tool, их получить.

1655
02:15:30,920 --> 02:15:33,820
 Либо мы вообще используем один какой-то идентификатор

1656
02:15:33,820 --> 02:15:35,260
 и по нему получаем эту информацию.

1657
02:15:35,980 --> 02:15:37,180
 Дальше важный момент.

1658
02:15:38,080 --> 02:15:40,900
 Не должны мы ходить под какой-то административной

1659
02:15:40,900 --> 02:15:42,300
 учетной записью в tool.

1660
02:15:42,300 --> 02:15:45,420
 Сейчас уже можно пробрасывать идентификатор

1661
02:15:45,420 --> 02:15:47,280
 сессионной пользователя, например,

1662
02:15:47,540 --> 02:15:52,720
 либо использовать уже сформированный тоже паттерн

1663
02:15:52,720 --> 02:15:56,360
 on behalf token, когда мы выдаем под агента

1664
02:15:56,360 --> 02:15:59,540
 какого-то от имени пользователя токен,

1665
02:15:59,920 --> 02:16:03,100
 то есть этот токен передается в агента

1666
02:16:03,100 --> 02:16:05,080
 и уже в какую-то конечную систему с помощью

1667
02:16:05,080 --> 02:16:07,560
 этого токена ходят и агенты получают

1668
02:16:07,560 --> 02:16:09,840
 информацию и он ограничен скоупом того,

1669
02:16:09,980 --> 02:16:11,660
 что доступно конкретно этому пользователю.

1670
02:16:12,740 --> 02:16:15,840
 И важная еще деталь, отдельный агент

1671
02:16:15,840 --> 02:16:18,200
 с ограниченным доступом к персональной

1672
02:16:18,200 --> 02:16:19,860
 чувствительной информации. Тоже наша

1673
02:16:19,860 --> 02:16:23,120
 рекомендация, все остальные агенты там

1674
02:16:23,120 --> 02:16:27,140
 можно как-то группировать, делать вместе,

1675
02:16:27,240 --> 02:16:28,920
 но вот тот, что работает с персональной

1676
02:16:28,920 --> 02:16:31,700
 информацией, мы рекомендуем его

1677
02:16:31,700 --> 02:16:35,640
 выделить отдельно. Что еще есть у нас?

1678
02:16:36,920 --> 02:16:38,880
 Guardrails и правила модерации, как

1679
02:16:38,880 --> 02:16:44,580
 использовать. Здесь важно, что проверяем

1680
02:16:44,580 --> 02:16:46,800
 обязательно информацию на входе,

1681
02:16:46,880 --> 02:16:49,140
 проверяем информацию на выходе. На входе

1682
02:16:49,140 --> 02:16:51,480
 релевантность допроса, скрытые личные

1683
02:16:51,480 --> 02:16:54,300
 данные, попытки взлома, инструкции вида,

1684
02:16:54,460 --> 02:16:56,460
 игнорируя системный промпт. Все еще все

1685
02:16:56,460 --> 02:16:59,040
 модели практически на это ведутся,

1686
02:16:59,140 --> 02:17:00,340
 проигнорируя системный промпт,

1687
02:17:00,400 --> 02:17:03,340
 сделая что-то другое. Работает, если мы

1688
02:17:03,340 --> 02:17:05,420
 это явно определяем в гардрейлах, как

1689
02:17:05,420 --> 02:17:07,920
 правило, это не проскальзывает. На

1690
02:17:07,920 --> 02:17:12,220
 выходе что важно пометить, что проверяем

1691
02:17:12,220 --> 02:17:14,700
 токсичность, какую-то утечку данных, если

1692
02:17:14,700 --> 02:17:16,920
 агент не должен с этим работать, пишем,

1693
02:17:17,080 --> 02:17:18,840
 что нет доступа к персональной

1694
02:17:18,840 --> 02:17:21,000
 информации, блокируя любой вывод, который

1695
02:17:21,000 --> 02:17:23,520
 выходит из агента, если в нем есть

1696
02:17:23,520 --> 02:17:25,800
 персональная информация. Ну и релевантность

1697
02:17:25,800 --> 02:17:28,520
 запроса, насколько вообще мы отдали то, что

1698
02:17:28,520 --> 02:17:33,780
 нужно. Здесь важно, что в какой-то момент

1699
02:17:33,780 --> 02:17:35,980
 мы можем подключить человека для

1700
02:17:35,980 --> 02:17:38,440
 проверки, выполнения подозрительных

1701
02:17:38,440 --> 02:17:42,300
 действий, тоже как реакция на какое-то

1702
02:17:42,300 --> 02:17:46,620
 срабатывание. Так, и коротко и быстро

1703
02:17:46,620 --> 02:17:50,880
 про LM observability расскажу. Новая

1704
02:17:50,880 --> 02:17:53,460
 достаточно тема, она появилась и у нас,

1705
02:17:53,460 --> 02:17:56,840
 и вообще в мире. То есть на какие вопросы

1706
02:17:56,840 --> 02:18:01,180
 закрывает LM observability сейчас?

1707
02:18:01,780 --> 02:18:03,840
 Токены и юнит-экономика. То есть мы

1708
02:18:03,840 --> 02:18:07,060
 каждый запрос, который в LM вошел,

1709
02:18:08,220 --> 02:18:11,240
 обработал с этого лзой, отправляем в виде

1710
02:18:11,240 --> 02:18:14,300
 трейсов на коллектор. Запрос имеет

1711
02:18:14,300 --> 02:18:18,260
 маркировку, что он выполнен с таким-то,

1712
02:18:18,340 --> 02:18:20,040
 используем таким-то количеством токенов,

1713
02:18:20,040 --> 02:18:22,580
 все это фиксируется. Дальше мы можем

1714
02:18:22,580 --> 02:18:25,940
 использовать накопленные данные, не

1715
02:18:25,940 --> 02:18:27,960
 у себя логируя где-то, а используя

1716
02:18:27,960 --> 02:18:32,300
 LLM observability, накапливать какое-то

1717
02:18:32,300 --> 02:18:34,240
 количество данных, которые вошли в

1718
02:18:34,240 --> 02:18:35,540
 агента и вышли из агента. Далее

1719
02:18:35,540 --> 02:18:36,940
 использовать эту информацию для того,

1720
02:18:37,020 --> 02:18:40,400
 чтобы измерять качество выдачи с

1721
02:18:40,400 --> 02:18:43,580
 помощью как раз техник Eval и LLM

1722
02:18:43,580 --> 02:18:46,320
 as a judge. Ну и третье, что важно,

1723
02:18:46,320 --> 02:18:48,900
 интересно, у нас появилась

1724
02:18:48,900 --> 02:18:52,260
 Authentic Observability, то есть это

1725
02:18:52,260 --> 02:18:53,900
 возможность проследить каждый шаг

1726
02:18:53,900 --> 02:18:55,940
 агента, какие тулы были вызваны, по

1727
02:18:55,940 --> 02:18:58,240
 какой причине, почему LLM решила, что

1728
02:18:58,240 --> 02:19:01,400
 какого-то агента либо в базу нужно

1729
02:19:01,400 --> 02:19:04,740
 пойти. Дальше это все как раз можно

1730
02:19:04,740 --> 02:19:07,620
 анализировать, понимать, что как-то

1731
02:19:07,620 --> 02:19:09,960
 System Prompt надо подкорректировать,

1732
02:19:10,040 --> 02:19:11,920
 чтобы мы использовали нужные тулзы,

1733
02:19:11,920 --> 02:19:13,320
 либо вообще какие-то тулзы, например,

1734
02:19:13,760 --> 02:19:14,420
 не используем.

1735
02:19:17,320 --> 02:19:19,400
 Как базово это все реализуется?

1736
02:19:19,640 --> 02:19:20,880
 То есть два варианта у нас.

1737
02:19:23,200 --> 02:19:25,280
 Используем LongFuse, разворачиваем,

1738
02:19:25,400 --> 02:19:26,460
 инструментируем наш код.

1739
02:19:27,340 --> 02:19:29,840
 OpenAge на SDK инструментируется как будто бы

1740
02:19:29,840 --> 02:19:30,580
 автоматически.

1741
02:19:31,400 --> 02:19:35,500
 Кастомные какие-то функции мы можем

1742
02:19:35,500 --> 02:19:37,800
 аннотировать для того, чтобы они также

1743
02:19:37,800 --> 02:19:38,600
 попадали в коллектор.

1744
02:19:39,200 --> 02:19:41,460
 Или второй вариант есть использовать у нас

1745
02:19:41,460 --> 02:19:42,540
 возможности iStudio.

1746
02:19:42,640 --> 02:19:44,060
 У нас как раз появилась Observability.

1747
02:19:45,060 --> 02:19:47,300
 По умолчанию все данные вызовов,

1748
02:19:47,320 --> 02:19:49,580
 агентов, они попадают в коллектор.

1749
02:19:49,840 --> 02:19:51,900
 Можно заходить в удобном интерфейсе,

1750
02:19:52,560 --> 02:19:53,360
 смотреть, использовать.

1751
02:19:55,720 --> 02:20:00,380
 И подводим итоги по пунктам.

1752
02:20:01,120 --> 02:20:02,420
 Первое, с чего мы начинаем, это

1753
02:20:02,420 --> 02:20:04,740
 правильный выбор инструмента.

1754
02:20:04,820 --> 02:20:06,400
 То есть мы используем код, когда нужно

1755
02:20:06,400 --> 02:20:08,180
 использовать код, инструкции в коде,

1756
02:20:08,260 --> 02:20:09,540
 когда нужно их использовать.

1757
02:20:10,400 --> 02:20:13,320
 LLM для задач недотерминированных

1758
02:20:14,140 --> 02:20:16,380
 либо задач анализа текста.

1759
02:20:16,620 --> 02:20:19,740
 Дальше мы маршрутизируем нагрузку

1760
02:20:19,740 --> 02:20:22,040
 под конкретную задачу, выбираем агента

1761
02:20:22,040 --> 02:20:23,660
 либо LLM под задачу.

1762
02:20:24,700 --> 02:20:28,620
 Оптимизируя контекст, мы руководствуемся

1763
02:20:29,320 --> 02:20:31,120
 принципом KISS, keep it simple.

1764
02:20:31,900 --> 02:20:34,020
 Дальше мы должны обязательно измерять

1765
02:20:34,020 --> 02:20:37,520
 качество и стоимость наших вызовов.

1766
02:20:38,320 --> 02:20:41,120
 И также мы закладываем безопасность

1767
02:20:41,120 --> 02:20:42,940
 и наблюдаемость с самого начала.

1768
02:20:43,340 --> 02:20:44,600
 Это сейчас делается довольно просто.

1769
02:20:44,600 --> 02:20:46,760
 Либо аннотируя наш код,

1770
02:20:46,860 --> 02:20:50,000
 либо просто используя тулзы наши.

1771
02:20:50,800 --> 02:20:51,320
 У меня все.

1772
02:20:52,100 --> 02:20:52,840
 Всем спасибо.

1773
02:20:53,700 --> 02:20:54,540
 Отвечаем на вопросы.

1774
02:21:01,420 --> 02:21:02,860
 Юр, спасибо большое.

1775
02:21:03,540 --> 02:21:04,360
 Есть какие-нибудь вопросы?

1776
02:21:08,180 --> 02:21:09,160
 Так, вижу.

1777
02:21:10,240 --> 02:21:11,260
 Добрый день, спасибо.

1778
02:21:12,060 --> 02:21:13,540
 Такой вопрос вы проводили.

1779
02:21:13,540 --> 02:21:16,280
 Может быть, какие-то тесты по замеру доли,

1780
02:21:16,940 --> 02:21:19,540
 эффективной доли контекстного окна у моделей различных.

1781
02:21:23,520 --> 02:21:24,800
 Еще раз вопрос.

1782
02:21:25,940 --> 02:21:28,040
 Когда механизм внимания, какой у них?

1783
02:21:28,480 --> 02:21:31,100
 Ну да, просто мы много внимания как раз в докладе

1784
02:21:31,100 --> 02:21:32,860
 уделяли контекстному инжинирингу.

1785
02:21:33,720 --> 02:21:36,340
 И интересно, вот именно практические тесты

1786
02:21:36,340 --> 02:21:40,020
 на эффективную долю контекстного окна у модели.

1787
02:21:40,140 --> 02:21:42,300
 То есть понятно, что у них есть миллион доступный,

1788
02:21:42,480 --> 02:21:45,400
 заявленный, но эффективно мы можем использовать

1789
02:21:45,400 --> 02:21:49,300
 в основном 30% или 20% или вот это было бы интересно.

1790
02:21:49,400 --> 02:21:50,020
 Сейчас расскажу.

1791
02:21:50,300 --> 02:21:56,020
 От 250 тысяч контекстное окно до 100 тысяч

1792
02:21:56,020 --> 02:21:59,100
 работа еще какая-то адекватная.

1793
02:21:59,260 --> 02:22:00,520
 Дальше начинаются потери.

1794
02:22:00,960 --> 02:22:04,020
 То есть это порядка 30-40%, но опять же это зависит.

1795
02:22:04,720 --> 02:22:07,340
 Потому что мы имеем контекст, внимание в начале,

1796
02:22:07,340 --> 02:22:09,300
 внимание в конце, посередине провал.

1797
02:22:10,300 --> 02:22:13,320
 Где провал, там 10% где-то.

1798
02:22:13,880 --> 02:22:16,240
 То есть он там практически забывает про это все.

1799
02:22:17,360 --> 02:22:21,020
 По крайней мере рекламент, других может быть по-другому.

1800
02:22:35,840 --> 02:22:37,840
 Добрый день, спасибо за интересный доклад.

1801
02:22:38,940 --> 02:22:43,680
 Где-то грани, когда нужна задача выделять в отдельного агента,

1802
02:22:43,680 --> 02:22:46,420
 а не в отдельный tool или в отдельную функцию.

1803
02:22:46,900 --> 02:22:47,440
 Почему спрашиваю?

1804
02:22:47,500 --> 02:22:52,020
 Потому что на практике тоже пробовал, чтобы оркестратор работал с агентами.

1805
02:22:52,180 --> 02:22:55,760
 Часто возникает проблема, что у субагента свой промпт.

1806
02:22:56,360 --> 02:23:00,500
 И этот системный промпт часто построен на других правилах,

1807
02:23:00,640 --> 02:23:03,560
 чем основной промпт у основного агента-оркестратора.

1808
02:23:04,140 --> 02:23:09,260
 И здесь вот приходится, он выполняет по своим правилам,

1809
02:23:09,720 --> 02:23:11,800
 что не устраивает уже агента-оркестратора.

1810
02:23:13,460 --> 02:23:16,100
 Где та грань, когда нужно использовать агента.

1811
02:23:16,820 --> 02:23:21,260
 Но вот как раз важный пункт, когда один агент все-таки не справляется.

1812
02:23:21,260 --> 02:23:25,220
 То есть здесь надо понимать, что мы ограничены еще дополнительными ограничениями

1813
02:23:25,220 --> 02:23:28,320
 не просто одним агентом, мы можем быть ограничены

1814
02:23:28,320 --> 02:23:30,640
 использованием какой-то определенной модели,

1815
02:23:30,760 --> 02:23:32,400
 которая у нас, например, развернута в организации

1816
02:23:32,400 --> 02:23:35,140
 или которая у нас развернута в клауде.

1817
02:23:35,760 --> 02:23:40,080
 То есть модель побольше, она справится, конечно, получше.

1818
02:23:40,960 --> 02:23:42,480
 Если используем какой-нибудь дипсик,

1819
02:23:42,620 --> 02:23:46,580
 то у него перечень задач, которым он справится один,

1820
02:23:47,140 --> 02:23:48,280
 довольно уже ограничен.

1821
02:23:48,720 --> 02:23:53,280
 То есть граница, когда одного агента уже не хватает в любом режиме

1822
02:23:53,280 --> 02:23:55,140
 и с любыми оптимизациями пронтов,

1823
02:23:55,300 --> 02:23:57,480
 и с любыми агентскими циклами,

1824
02:23:57,560 --> 02:23:58,760
 когда мы уже их используем.

1825
02:23:58,760 --> 02:24:00,440
 Здесь больше вопрос про то,

1826
02:24:00,660 --> 02:24:03,280
 когда системный промпт агента

1827
02:24:03,280 --> 02:24:07,040
 может отличаться по правилам выполнения

1828
02:24:07,040 --> 02:24:09,600
 от системного промпта оркестратора.

1829
02:24:09,760 --> 02:24:11,540
 То есть, например, пишем программный код,

1830
02:24:12,140 --> 02:24:15,820
 у нас в системном промпте оркестратора

1831
02:24:15,820 --> 02:24:17,860
 заданы определенные правила,

1832
02:24:18,220 --> 02:24:19,500
 как в том числе писать код,

1833
02:24:19,800 --> 02:24:22,520
 а мы отправляем, например, код на JavaScript

1834
02:24:22,520 --> 02:24:25,780
 агенту по написанию кода на JavaScript.

1835
02:24:25,780 --> 02:24:27,300
 А у него там свои правила.

1836
02:24:28,220 --> 02:24:29,940
 И вот получается такой конфликт.

1837
02:24:30,060 --> 02:24:30,700
 Как с этим быть?

1838
02:24:30,880 --> 02:24:33,120
 Мне кажется, что они не должны пересекаться.

1839
02:24:33,280 --> 02:24:34,920
 То есть правило агента-оркестратора,

1840
02:24:34,940 --> 02:24:37,240
 он должен правильно перераспределить

1841
02:24:37,240 --> 02:24:38,200
 на нужного субагента.

1842
02:24:38,340 --> 02:24:41,000
 И тут принять решение должен вот уже

1843
02:24:41,000 --> 02:24:42,660
 конечный агент, субагент,

1844
02:24:42,780 --> 02:24:43,660
 которому все передали.

1845
02:24:44,020 --> 02:24:45,000
 Они не должны, мне кажется,

1846
02:24:45,080 --> 02:24:46,180
 противоречить друг другу.

1847
02:24:52,100 --> 02:24:54,280
 Что ж, Юр, спасибо еще раз большое

1848
02:24:54,280 --> 02:24:55,700
 за интересный мастер-класс.

1849
02:24:59,460 --> 02:25:04,440
 Да, на этом у нас онлайн-часть

1850
02:25:04,440 --> 02:25:05,540
 подходит к концу.

1851
02:25:05,940 --> 02:25:07,740
 Еще раз спасибо большое за внимание,

1852
02:25:07,860 --> 02:25:09,680
 что подключились, за интерес к AI-студию.

1853
02:25:10,140 --> 02:25:11,220
 Если остались какие-то вопросы,

1854
02:25:11,420 --> 02:25:12,840
 приходите в чат, задавайте.

1855
02:25:13,340 --> 02:25:15,680
 Мы с коллегами с удовольствием на них ответим

1856
02:25:15,680 --> 02:25:18,860
 и ждем вас на следующих встречах

1857
02:25:18,860 --> 02:25:20,200
 по AI-студию-сириас,

1858
02:25:20,500 --> 02:25:23,380
 которые, надеюсь, случатся уже в конце осени.

1859
02:25:23,720 --> 02:25:24,060
 Спасибо.

1860
02:25:28,860 --> 02:25:58,840
 Субтитры сделал DimaTorzok

1861
02:25:58,860 --> 02:26:28,840
 Субтитры сделал DimaTorzok

1862
02:26:28,860 --> 02:26:58,840
 Субтитры сделал DimaTorzok

1863
02:26:58,860 --> 02:27:05,000
 Субтитры сделал DimaTorzok