Как создать стабильную мульти-агентную систему для Enterprise в 2026 | Илья Рис - победитель ERC3

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

Так, да, друзья, рад всех приветствовать в новом году. У нас так позитивно начинается год с интервью вот с Ильёй. Илья Рис. Илья известен тем, что выбивает, наверное, самые высокие баллы в соревнованиях различного рода. Вот до этого было соревнование по рак а системам. Я, насколько помню, ты там первое место тоже занял, да, в том соревновании.

А, да, в ERC2 как раз-таки, где были раги по финансовому счёту компании, я занял первое место, вроде как во всех лидербордах. То есть, в общем, в локальном лидерборде. У, >> короче, там всё очень красиво получилось. >> Да, очень круто. В принципе, даже уже одного вот этого факта, я думаю, было бы достаточно, чтобы нам вот так вот встретиться, пообщаться. Но тем не менее, а в, так сказать, добивку к этому факту Илья также вот не так давно поучаствовал в ERC3. ERC - это Enterprise Rock Challenge, но я так понял, что вот последний C - это всё-таки не сколько про рак, сколько про агент. проагент, да, системы.

>> И вот Илья тоже очень хороших там достиг показателей, в принципе, из того, что я по там они сейчас немножко лидерборд обновляется, может, что-то устарело, но на вот из того, что я что меня даже поразило в какой-то степени, да, а то, что у тебя фактически вот там самые какие-то высокие рейтинги на GPT OSS 120 би, да, то есть на на открытой модельке. Вот, вот это вот это меня продёт. То есть то есть фактически давайте так вот, да, затянул выступление. В чём вообще суть-то? в том, что вот Илье удалось вот в этом бенчмарке от вот это соревнование, даже не бенчмарке, это соревнование от Рената Абдулина аа выбить в ну чуть ли не самые там то есть в принципе Илья достиг там такого, э, скажем так, качества, такого уровня, да, вот твой агент достиг, что он, в принципе, оказался наряду с самыми вот продвинутыми, самыми топовыми там агентами, которые на Санеете, там с опусом даже, даже с опусом, да, и это всё всё на небольшой модельке. И вот именно поэтому мне показалось интересно вот пообщаться именно с тобой, поскольку если мы говорим именно про Enterprise RC Challengдe, то, ну, реаливы, что чаще всего, ну, вот по ряду причин, да, а именно энтерпрайзаы, они действительно будут делать выбор скорее в пользу какого-нибудь какой-нибудь открытой модельки, типа у GPT у SS 120B. А, во-первых, да, ввиду того, что она просто открыта, что они могут у себя её развернуть, а, во-вторых, ввидустов просто-напросто, потому что, насколько я понимаю, а даже если просто сравнивать косты, не не говорить про то, что там открытая, не открытая модель, то если мы сравним, не не то чтобы с опусом, да, если сатом сравним, но это будут в десятке, а может быть, даже и там до сотни раз там будет цена в в разница в стоимости, насколько я понимаю. Вот. Да, если инференсить, >> а про локальном инференсе, да. Но на самом деле, когда мы говорим про локальный inнференс, там редко говорится про экономию денег, учитывая сколько это всё стоит. Хотя для 120 би, наверное, что там 44090 хватит. Ну, короче, да, если если локальный infренс собственный, то >> то очень недорого выходит. >> Ну да, в любом случае это в десятки раз экономия. И штука-то в чём? Просто когда мы говорим действительно протепрай-агентов, они предпо они могут предполагать как и в принципе нагрузки какие-то не очень большие, когда это внутренние сотрудники используют, так и колоссальные нагрузки, когда это условно где-то на на сайте вынесено условно там ассистент там по покупкам какой-нибудь, да, по а где-нибудь вот такой чатик висит и там под капотом я агент, и косты они просто могут быть колоссальными для таких интерпрезов. Вот поэтому очень вот это меня заинтересовало, что тебе удалось достичь вот таких результатов. Вот поэтому давай вот я предлагаю следующим образом поступить, чуть-чуть тоже рассказать людям, что вообще из себя этот бенчмарк представляет соревнования, то, что из себя представляет, какого рода там задачки. А с этого начнём, а дальше уже поговорим об эволюции твоего решения, потому что, насколько я понимаю, ты не сразу, да, таких результатов достиг, там несколько было этапов. И вот эту эволюцию тоже было бы интересно вот вместе с тобой за вот этот там час, может быть, чуть-чуть больше эту эволюцию пройти. Ну и дальше уж какие-то там вот нюансы тоже покопаем, по пообсуждаем, потому что сейчас, конечно, говорили, знаешь, двадцать пятый год, год агентов, да, год агентных систем, но как будто двадцать шестой год он может быть ещё больше даже год агентных систем, просто потому что они сейчас как-то достигли даже уже openсоourсной модели, а достигли действительно достаточно продакшн качества, да, Вот я думаю, даже вот результаты там твои, да, в этом соревновании тоже это доказывают лишний раз. Вот поэтому мы с тобой сейчас, мне кажется, очень такой на актуальной волне. А давай немножко расскажи, пожалуйста, про вот этот вот ERC, потому что я очень хотел поучаствовать, но, к сожалению, ввиду там большой загружен в своём стартапе, я так тоже и не смог никак поучаствовать в этом. Расскажите немножко, что за соревнования, какого примерно типа задачи, вот насколько они действительно там соотносятся, да, с какими-то реальными задачами, которые появляются у бизнесов.

Угу. Я тебя понимаю, что не смог поучаствовать. Я тоже, мне пришлось очень много часов со своего сна срезать, чтобы в этом поучаствовать правильно с работой. А значит, о чём вообще этот ERC3 челлендж? А Ренат построил организатор, собственно, нам подкапотом канал, а он построил систему, которая она по типу бенчмарка. А это имитация AP компании. просто какой-то абстрактный там придуманная была какая-то компания. Э, и агенту даётся апии инструменты, много, много апи инструментов, что-то типа 20 или 24, я не помню, вот около того. А у них разный синтаксис, какие-то разные правила, есть нюансы и прочее, и прочее, но вообще суть всех этих инструментов, она сводится к тому, чтобы, а, да, значит, какие знания находятся в, а, в зоне доступности самого агента, да, когда мы говорим вообще про любые AI приложения, AI-сервис, нам нужно в первую очередь говорить о контексте, да? Что у нас есть из контекста? А из контекста у нас есть а Википедия компании, в которой есть статьи, направленные как на правила того, как должен себя вести агент, так и просто какие-то абстрактные статьи про сотрудников компании и прочее. Ну, то есть такая довольно хорошая имитация. Ээ про правила для агента Вики мы чуть позже поговорим. Это очень гадкая штука. А так ещё и сущности есть сотрудники, которые работают в компании. Есть проекты, на которых работают сотрудники, есть клиенты, э проекты, для которых делаются, а, и есть временные записи, там, условно, кто сколько в этот день работал над таким-то проектом, что-то подобное. Э, и целая куча взаимосвязей, взаимозависимостей. У сотрудников есть их роль, э, есть проекты, на которых они работают, есть разные разрешения, э, того, что они могут и не могут делать в системе. И как бы это, наверное, одна из сложных задач самого, а, этого ERC3 челленджа, а, это то, что не всё не для всех агент может делать. А у нас нету никаких карт ограничений по доступу, но при этом условно зарплату сотрудников может посмотреть. Либо если человек спрашивает про свою зарплату, то агент ему может эти данные найти и выдать. А если SEO ищет зарплаты каких-то сотрудников, тоже агент может без проблем а-а найти это ему выдать. Если это кто-то просто любопытствует, агент должен отказать. То есть он должен понять, что это за человек, какие права у него есть. Причём поднять это часто именно из Википедии какой-то вот статьи в маркдаун формате, которая там где-то лежит, а в компании. И в общем, понять, что нет, его нельзя. Угу.

Аа, значит, из ещё из сложностей и вещей, к которым доступ ограничивается, не ограничивается, это, а, потенциально работники в на том или ином проекте могут получить информацию об этом проекте, но не о проектах, где они участвуют. Э, там лиды могут, кажется, делать записи временные в логах за сотрудников и там прочее, и прочее, мне кажется. Может быть, штук 16 или 20 атомарных правил выходит в итоге, которые говорят, что кому можно и что нельзя. Вот, значит, та такая система. И всё сводится к тому, что нужно, во-первых, данные найти, их нужно достать, э, первоначально поняв, нужно ли их вообще искать, нужно ли их вообще доставать, э, вот, и дать соответствующий ответ. А или произвести какие-то действия, это реже. например, обновить статью Википедии, какие-то туда изменения внести, э, добавить временную запись, поставить сотрудника на проект, что-то в этом роде. В общем, глобально вот что агент вообще может делать в этой среде. >> Угу. Да.

Да, ну, то есть агенту доступно не только какие-то там энпоинты и какие-то просто задачи он выполняет, а ещё и форс подумал о том, чтобы каким-то образом добавить вот эту систему прав, которая, кстати, действительно очень популярна вот в энтерпрайз среде. Вот даже мы там у нас свой продукт, мы когда приходим с нашим продуктом, нам тоже говорят: "Вот у нас вот разные условия разные там программисты, у одних доступ к этому коду, у других к этому коду должен быть". И, короче говоря, действительно, вот в этом плане я очень понимаю, зачем Ренат это сделал. И, значит, в агентах, соответственно, вот в этом бечмарке тоже, а, это учитывается, да, вот в оценках, аэ, то, чтобы у агента, скажем так, в разных сценариях был доступ исключительно вот к какой-то заданной, да, информации, за к заданному скоупу. >> Тут проблема, что агенту ты сам само самому э доступ особо ограничить не можешь. Ну, вернее, как некоторые делали, но по факту вот то, что ты говоришь, да, системы доступа, они, как правило, по хард логике по какой-то делаются, да? А то есть вот если там у человека право такое, то туда-то туда-то нельзя. У >> тут этого нет. Тут такая в фазе логика, она очень очень размытая. То есть и у агента есть данные куда угодно, но у сотрудника, который обращается к агенту Нет. А агент всегда знает, да, тут, наверное, нужно сказать, что агент всегда знает, кто к нему обращается. Есть отдельная команда HMI, в которой выводится, что к тебе обращается сотрудник, э, там Вася Пупкин, он лид как бы вот >> либо либо к тебе обращается гость, там ещё были отдельные сценарии, когда обращается неавторизованный юзер, как бы у него там сильно урезанные права, то есть а теоретически можно заинжектить агента, чтобы он выдал какие-то знания, которые нельзя теоретично. Угу.

Слушай, ну да, ну мы можем отдельно об этом поговорить. Это вообще отдельная история там настройки прав, но действительно это как будто уже какая-то надстройка. А сейчас хотелось бы больше погрузиться, ну, скажем так, в некий такой comm, такой agent, а вот в его детали. Ну, о'кей. Значит, давай, знаешь, может быть, тоже для контекста. Можем ли мы как-то, может, показать, посмотреть, допустим, пример задачки, который есть? Просто тоже я, знаешь, я я пою очень разные аудитория будет смотреть. И хотелось бы, да, чтобы люди, которые вообще впервые видят этот - челлендж, чтобы они тоже были в теме и понимали, собственно, какого рода задачки там решались. Какой-то пример, может быть, какая-то типовая такая задача.

>> Да, я сейчас запущу визуализатор свой, а, в котором у меня показываются все задачи и все трейсы по ним, и мы сможем прямо визуально пройтись. Буквально мне нужен для это для этого пару минуток. >> Ага. Супер. То есть да. И давайте я тоже тогда, пока ты, Илья, ищешь, скажу о том, что Илья своё решение за Open sourcal, оно доступно на гитхабе для всех желающих. Тоже удивительно жмём время, да. Вот, казалось бы, а настолько невероятно ценные, пожалуй, знания, а невероятно не просто знания, а ещё и код даже, да, и это всё выкладывается в открытый доступ на, так сказать, на всё общее, не просто обозрение, а на всё общую вот возможность э повторить где-то у себя, да, на возможность подсмотреть какие-то тоже удачные решения. Вот поэтому мы потом к записи приложим ссылочку на твой репозиторий. >> Угу. Да. И и ты, получается, не просто даже не просто запись, то есть не просто, прошу прощения, не просто код, да, выложил, а ты ещё и визуализировал его. Это чем ты визуализировал? Что это такое? >> А я написал просто при помощи курсостора небольшое веб-приложение. Оно сейчас за хочено, собственно, GitHub Pages. На него можно зайти. Тут есть демотрейсы а из реальных бенчмарков. И можно ручками пощупать, посмотреть, что было под капотом у агента, когда он решал ту или иную задачу. >> Так, о'кей. Значит, сейчас это 16 задач перед нами. Это вот тот самый ERC Pro, да? Потому что у C3 там тоже несколько было. А стави >> нет, брошка там 100 вопросов. Это ERC, кажется, деф. Ээ >> да, ну суть абсолютно ровно та же. То есть там нету какой-то разной сложности в задачах или чего-то типа того. Просто там больше разнообразия и контекст -э другой. >> Ну хорошо, давай. Что-то такое прямо типичное, да? Типичное, я имею в виду, что-то такое, чего вот прямо вот такого рода вопросов было там несколько, да, в родовом бенчмарке. Давай посмотрим какой-нибудь пример, что там, что там агенты, >> да, есть есть базовые вопросы, вопросы в лоб, которые проверяют по сути агента на то, насколько вообще он красные флаги отлавливает, да, У нас здесь задачка, э, я покидаю компанию, всю мою информацию. А значит, >> Угу. >> Я вот думаю, как подступиться к описанию э всей структуры моего агента. А, >> ну смотри, здесь у меня есть тебе предложение. Я вот чуть совсем заранее, да, до нашей встрече я узнал, что ты его заopсорсил, и я его вот в наш KL, я не знаю, видел ты, не видел, вот наш этот продукт K Life, который, собственно, позволяет как раз, ну, как бы, да, идея в том, что можно загрузить там любой репозиторий и он его обработает, проиндексирует и сможет не просто там на вопросы отвечать, а ещё и сможет красиво визуализировать. Давай сейчас давай я у тебя пере перехвачу экранчик и может бы тебе так будет даже проще рассказывать и мы как раз сейчас посмотрим, правильно ли он вообще в принципе как бы поймает суть. Но обычно хорошо ловит. Так. А так ты ты получается replace share. О'кей. Ага. Так, сейчас видно экран. >> Ага. >> Ну вот. Да. Вот тут у меня всякое разное проиндексировано. И в том числе, соответственно, вот твой твоё решение, кстати, целых 5 Мб у тебя там уже, оказывается. А давай мы его на на русский спросим. >> Кажется, там пару джесон трейсов просто. Там трейсы довольно жирные. Вот эти, которые демо, они >> а >> занимают большей части. >> Угу. Угу. архитектуру проекта. Ну давай вот так вот прямо спрошу его. В принципе вот. Ну то, >> в принципе, там ми я всё пытался всё хорошо описать. А так что думаеш оттуда возьмёт? Он сейчас найдёт, да, он сейчас возьмёт Redmi. И просто он в чём фишка, что он действительно ещё красиво умеет визуализировать. Это как бы отдельная такая история, э, которую мы там приложили немало усилий, чтобы у нас красивые были хорошие визуализациимей всегда корректные. >> Вот. Давай, давай, давай, давай попробуем посмотреть. Может быть, тебе так будет проще действительно по этой визуализации рассказывать. Посмотри, насколько это как бы резонно. >> А сейчас, секундочку. А значит, то, что у тебя находится посередине архитектуры стор пока что не смотрим. Это был разогревочный, если что, бенчмарк, а с другой имитацией, другими инструментами и там другая архитектура. Про него можем потом поговорить отдельно, если будет время. Верни чуть-чуть обратно. А вот слева архитектура ERC3 Plan React - это как раз-таки основной агент, который использовался в самом соревновании. Изучение правил из Вики >> и динамический контекст. Так, ну это совсем упрощённо. Сейчас M main M main P entry agent benchmark store benchmark. Хорошо. Планирование. Ну, мы можем как бы сузить немножко, да, потому что я его, видишь, спросил в принципе визуализировать. >> Вот мы можем немножко сузить контекст. То есть, допустим, там просто скажи, что для архитектуры, для три бенчмарка. >> А архитектура для ERC3, а бенчмарка. Давай вот так вот. Нам нужна архитектура для RC 3. Да. А вот то, что вот справа, вот это >> там отдельно там просто entry pointт, который работает и на store и на на разогревочной бенчмаркей на C benchма. Вот он показывает, >> да, да, да. Как бы он сосредоточился, да, вот на этой совсем внешней абстракции. >> Угу. Угу. О'кей. Так, а ну-ка. 502 у нас. Ну что-то. Ага, сейчас подождём. Ну давай я пока, может быть, вроде задумался, да? О'кей, задумался. Я подумал, может быть, Redm открою. У нас тоже как это как это каникулы. Вот >> чуть-чуть чуть-чуть, видимо, как и у Авса тоже чуть-чуть что-то может притормаживать. Так, ну давай посмотрим. Вот это ближе к тому, что надо. >> А, task requкqu. Ага. Подготовка. А, да. О'кей. Тип пользователя. А как разтаки у нас либо авторизированный, либо публичный. Тут всё правильно. >> А чуть ниже. Формирование промпта. VK Rules. Ага. System пром. Базовые правила инструменты. А block rules. Слушай, но в целом выглядят довольно правдоподобно. Угу. Угу.

>> Ну да, мы можем мы можем в принципе вот сначала, да, вот как как скажу, как лучше. Может быть, прямо сначала посмотреть. Вот. Давай с самого начала пойдём. А, значит, довольно много кроется в кирпичике подготовка prepw. А это то, что запускается единожды даже перед тем, как начать вообще э выполнять задачи. Э тут у нас есть такой нюанс, что Википедия компании она, >> э, среди тех задач она условностатичная. На самом деле Ренат сделал, как он сказал, что, э, я буду вам в PMI отдавать хэш Википедии. И если как бы хэш совпадает, то это та же самая Википедия. Ну, то есть как бы даётся возможность её заинжестить и локально где-то у себя хранить. Аэ, как бы проделать на некие над некие тяжёлые операции. как раз-таки тяжёлые операции, которые я делаю над а-э Википедией на с теми вики викистраницами компании. А я агент идентифицирует э все правила, все файлы с правилами, проходят по каждому файлу с правилами и извлекает все правила, касающиеся агента, направленные на агента про действия, которые можно делать, нельзя делать и так далее и тому подобное. То есть мы имеем в виду, что в разных Википедиях разные правила. доступ, пример. >> Ну, правильно ли я понял, что вот этот этап - это как раз-таки а-а вот те те самые разграничения по правам, которые мы которые мы обсуждали, да, что у тебя условно где-то где-то вот, я не знаю, там на предварительном этапе может быть задана роль, кто что это за пользователь использует, да, и дальше, соответственно, когда эта роль задана, уже вызывается хумаi. И таким образом мы понимаем, ну, ещё раз, да, что мы понимаем в HMI, вот мы вот что это это какой-то endpint, да, я так понимаю, вызывается, >> да, да, это endpint, а-а, как раз он вызывается и там имя сотрудника, э, вспомни бы, что там, там имя сотрудника, хэш Википедии просто кладётся туда же, э, и ещё какие-то вторичные данные. Э, но суть суть тут надо вернуться к подготовке, да, что мы по всем вики страничкам пробегаемся и извлекаем правила. А, и мы их отдельно извлекаем здесь несколькими как бы группами кластерами. У нас отдельно извлекаются правила для авторизованных пользователей, отдельно для публичных пользователей, потому что у публичных ты, наверное, э понимаешь, что там гораздо меньше правил, потому что им всёвсёвсё запрещено, там можно только небольшой кластер, а для сотрудников там много разных сотрудников, много разных правил. А, >> угу. Плюс отдельно извлекаются правила для формирования пенального ответа пользователя, просто потому что там очень много нюансов. Как бы это отдельным идёт куском. А, да, поймаем мы понимаем, если пришёл >> паблик какой-то к нам человек с запросом, то мы роутим туда те правила, которые мы на этапе подготовки извекли для публичных пользователей. То есть мы их подцепили и положили в системный промпт агента. Угу. Угу. >> Да, если авторизованный, то свои правила. А >> как бы это то, каким путём пошли очень многие ребята, которые выбили хорошие баллы. >> Угу. >> Это не кидать все правила в контекст системного промта просто потому что это не масштабируется. Это никак не масштабируется, да? А поэтому нужен какой-то роутинг правил. Здесь он довольно легко реализовался на хуймае. Можно было бы правила разбить по ещё более атомарным каким-то кускам и более хитро их собирать в системный пром. А как бы это, собственно, один из важных моментов, которые повлияли на хороший перкумансагента. >> То есть мы >> Угу. >> мы можем, да, зафиксировать это, что системный промт он не статичный, насколько я услышал. Системный промт собирается динамически. Да. >> А, и нужно это прежде всего, насколько я понимаю, для того, чтобы для того, чтобы не перегружать фактически, да, потому что вот это условно там какой-то когнитивный лимит у А у если я где-то что-то там некорректно скажу, ты меня просто поправляй, да, у ЛМА когнитивный лимит, он тоже ограничен, то есть количество инструкций они, скажем так, эффективных инструкций, они ограничены, соответственно, есть смысл ну, как бы в зависимости от задачи, в зависимости от какого-то Это там глобально от подхода. А есть смысл э в том, чтобы быть внимательным к количеству инструкций в системпромте и, соответственно, динамически а эти инструкции заполнять. В данном случае вот как бы иде идея в этом, правильно же я понимаю? >> А, да, абсолютно верно. Как бы это, да, можно сказать, что это когнитивные капасити, да, либо соотношение шумсигнал. Часто ещё говорят, что есть тебя много нерелевантных правил, да, это шум. Просто сложнее будет навигироваться. >> Угу. >> Через него, >> когда у тебя ситуации применимы пять правил из 100. >> Угу. >> Так. О'кей. Значит, вы вот этот систм прот формируете. Ну вы это значит ты, да, формируешь своём, >> да, ты с агентом на этапе, когда ты определяешь там пабли отed, да, и после этого вот где-то вот он где-то ближе к контекстбилдеру, то есть где-то вот промежутки, я так понимаю. >> Угу. О'кей. А значит, ну да, важный момент, что AI агент ещё не работает, ещё не начинает свою работу, а уже делаются запросы в SDК, а запросы, то есть делается, но просто автоматически по старту задачи, да, чисто программно кодом, а, и роутится правила. И второе, что очень важно, роутится контекст. Значит, тоже опять же перед тем, как агент, основной вот этот план, агент начинает свою работу, делается один LM вызов контек. Ты его видишь, >> а это выбор релевантных блоков данных. Значит, >> как это работает? >> Абсолютно также программно у Himi, мы получаем, а, да, имя сотрудника и его ID. У нас есть ID сотрудника. А, и дальше тоже абсолютно программно. Мы, по идее, вытаскиваем через через разные апиинструменты все проекты, в которых он участвует. А что мы ещё по нему вытаскиваем? Все клиенты, которые хо-менеджеры. Тут такой есть вариант. А все его записи логов, э, пу-пу-пум что-то ещё. А его его полный профиль тоже мы вытаскиваем. И опять же, что-то из этого полезное для задачи. Мы ещё здесь lm даже не запустили. Вот как раз-таки тут мы в приподготовку перед запуском e-агента мы используем контекстбиilder. А и ему мы скидываем всю всю информацию по сотруднику, связанную с ним, которую мы нашли, и текст задача. И говорим: "Вот, исходя из текста задачи, выбери, что из этой предоставленной информации >> оно релевантно вообще к ней". >> Э, и он говорит: "Вот это, вот это, вот это". Э, и уже как вот когда только-только я агент начинает работать, у него есть релевантные правила. у него есть релевантный контекст. >> Угу. Сейчас вот это тоже хочется зафиксировать. То есть ты говоришь, исходя из текста зада? То есть ты получаешь всю информацию по сотруднику. Мы мы вот ты с агентом получаешь всю эту информацию по сотруднику. Далее у тебя есть некий текст задачи. И дальше ещё перед тем, как идти, собственно, эту задачу выполнять, а мы делаем фактически фильтрацию э контекста. То есть мы говорим: "Вот есть вот такая задача, вот есть информация о сотруднике". Оставь нам только вот из всей. Ну то есть, в принципе, информация о сотруднике она, ну, она как бы релевантна, но она достаточно глобальна, то

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

Угу. Ну, там даже вот ты говоришь, там, да, вот сотрудник увольняется, да. Там, пример, сотрудник увольняется, а нужно там стереть все данные и условно там какие-нибудь там логи. Может быть, они здесь не очень-то нужны. То есть нам нужно просто >> ничего. Контекстбилдер говорит, ничего нерелевантно. >> Во-во-во. Да-да, да. То есть ничего просто нужно условно айдишники этого этого сотрудника, да, по которому пойдёт агент, пойдёт в базу и это всё, и это всё поудаляет.

Угу. Да, это интересный момент такой, действительно preparation контекста. Мне, кстати, я вот чуть-чуть могу ссылки делать. Видишь, вот у нас вот это в некоторой степени тоже агент. Ну, то есть сейчас я открою секрет, под капотом там pipeline, в принципе, такой достаточно продвинутый, просто просто очень хорошо к чанки подготовлены вот для RAG. Вот. А но тем не менее, то есть там вот в какой степени то, что ты говоришь, там тоже есть вот этот момент с тем, что, а, к репозиторию, ну, опять же, да, здесь важно понимать, вот сейчас мы имеем дело с пятимегабайтным репозиторием, но у нас есть кейсы там с 500мегабайтным, например, репозиторием. То есть там, ну, ты понимаешь, это колоссальный объём. И вот просто вот тупо в лоб делать RAG, конечно, это будет неэффективно. Ну вот, и там есть тоже у нас этап, когда мы строим антологию репозитория, то есть некое некое верхнеуровневое такое представление вообще не просто описание, да, описание тоже есть, но именно антология того, каким образом компоненты друг с другом взаимодействуют. И а дальше, поскольку LLaE - это контекстный движок, то есть мы сейчас просто смотрим одно из его так ипостасий, да, в виде чата, но это контекстный движок. И дальше там другой агент, когда спрашивает куда, дай мне контекст по такой-то задаче. А кудала в свою очередь под капотом тоже там будет как бы первичный этап - это именно отсев, потому что антология она достаточно большая тоже может быть. Хотя она понятно, что она существенно меньше, чем сама репозитория, это понятно. Но тем не менее вот есть смысл эту антологию тоже как бы фи фильтровать. То есть не про все компоненты рассказывать, а условно про отношение тех компонентов, которые имеют отношение к задаче. Это вот очень похоже на то, что на то, что ты здесь э делаешь в своём агенте.

Вот я даже хочу сейчас попробовать. Вот прежде чем мы продолжим, нужна более детальная визуализация. Хочу его вот так вот спросить. И я даже с тегом deep сделаю, чтобы он с тегом п он просто сейчас на Gemini 3 Pro переключится, которая совсем сумасшедшая визуализации. Интересно, потому что кажется, как будто чуть-чуть там детализации здесь не хватает. Вот то, что ты рассказываешь. >> Угу. >> Вот. А можем, да, можем, в принципе, дальше смотреть. То есть, о'кей, мы на данном этапе у нас там была задача, у нас мы получили информацию о >> Угу. >> а сотруднике, и мы сделали фактически отсев вот этой доступной информации. И дальше, о'кей, мы переходим, собственно, к формированию промта. А, видимо, на этом этапе. Ну да, давай, я не за тебя не буду рассказывать, давай. >> Нет, ты всё правильно говоришь, да? Мы в системный промт самого агента. Мы, значит, напихиваем правила. В надо говорить, в селективном промте уже довольно много правил, но они касаются а инструментов, потому что если правила в вики, они могут меняться, да, то контракт инструментов он одинаковый, поэтому можно про них рассказать заранее, про какие-то подводные камни и прочее. Это у нас, эта информация, она зафиксирована у нас. >> А, >> а, угу, >> угу, угу. А, а вы не не фильтруете, собственно, вот тоже аа вот этот э-э список контрактов, список энпоинтов, список тулов, да, вот сейчас вот то, что в клодко-коде появилась, интересная фича, да, которая умеет, э, собственно фильтровать список доступных тулов. Ну, тоже, чтобы не замуривать контекст. Тако такую не делаете штуку. >> А я думал что-то подобное сделать, но просто руки не дошли. У меня очень много было идей, что можно сделать, что можно добавить, но 24 часа в сутках в сутках, и надо хоть немножко спать. >> А, о'кей. О'кей. Ну, то есть в принципе идея релевантна, да? Вот некая эффективная релевантность, да? Да. Потому что Карпаты, кажется, говорил, что у нас сейчас у инженеров не промт инжиниринг, а контекст инжиниринг. Всё всегда сводится к тому, насколько у тебя, а, в контексте LLM будет релевантная информация, насколько у тебя мало будет нерелевантной информации. То есть вот этот сел, precision, вот эта вся история. >> А >> дадада. >> Да. И, собственно, над этим и боремся. Над этим и боремся. И 80% усилий уходит именно на это, не на что-то другое. э-э, на то, чтобы агент получал нужную ему информацию. Как бы у него когнитивных возможностей достаточно, чтобы >> принимать решения на основе информации, лишь бы была информация. >> Ну да. Но тем не менее важно всё-таки не замусоривать это. То есть важно как это, как это знать >> э знать какие-то рамки, какие-то пределы. Так, ну смотри, у нас чуть чуть более подробно. Посмотри, насколько вот это адекватно. Мне кажется, вот с более >> с более подробной вот как-то интереснее будет смотреть визуализации. >> Так, значит, сделали хумай, взяли преподготовленные правила, да, которые у нас уже лежат к Википедии, привязанные и поша, ну, поэтому по хэшу подсоединяются, подключаются. А значит, у нас системный промт, начало петли. Ну нет, здесь в целом как бы всё, что мы уже прошли, оно в достаточной точности находится. А вот справа, что интересно, вот справа вот интересная штука - это то, как работает контекстбилдер. А, >> угу. >> Вот всё правильно. Значит, мы ищем по сотруднику проекты клиентов, а, полный профиль самого сотрудника, временные записи. Ну да, всё, как я сказал, это сырые контекстные блоки в контекст селектор, он его назвал, о'кей, контекстбилдер. А и выбранные блоки отправляются в контекст. Нет, тут всё вообще правильно. Вопрос нет. То есть О'кей. О'кей. То есть ты собираешь, да? Я думаю, что это какая-то простая, значит, какая-то функция, которая тебе сразу всё вернёт, но я так А ещё и пара фиш. То есть я так понимаю, что ты в параллель, да, запускаешь там несколько запросов, >> да, конечно. >> А и и это отдельные энпоинты, видимо, да. Список проекта, список кастомеров. Угу. О'кей. Ну, то есть, кстати, тоже хорошая фича, можно, я считаю, зафиксировать, да, вот этот вот подход с тем, чтобы в параллель для многих, кстати, вот для меня как программиста как бы это ещё изначально было очевидно. Там, я не знаю, там ещё помню, общались тоже с приятелем, который на фрилансе там каких-то агентов делал. Вот, а он там, у него бэкграунд маркетолог. Вот когда я ему открыл вот этот момент, что слушай, а ведь ты же можешь в параллель просто какие-то запросы выполнять, и это там существенно может ускорить, да, твои твой этот пайплайн или что там, агент какой-то может простой был. Для него это было открытием. Ну вот мы можем тоже зафиксировать, что ты тут этот подход примешь. Потом будет интересно потом вернуться к семе, кстати, параллелизма агентов. Может быть чуть позже, может быть там где-то ещё у тебя это будет, да? О'кей. То есть >> много параллелизма. >> Супер. Супер. Так. Ага. Отлично. То есть по по этим отдельным энпоинтам всё ты собрал. А контекст селектора - это, видимо, как раз-таки тот самый, собственно говоря, >> да. >> Угу. Угу. Угу. Ну да. Но селектор как бы интереснее, да, что он не просто билдит, а он всё-таки выделяет вот то, что а то, что да, такую селективно сделает то, что релевантно. >> А, о'кей. О'кей. Всё. И мы пришли в У меня ещё интересно, кстати, что здесь идёт, смотри, >> получается, отсюда он какое-то у него разветвление пошло. Сюда пошло разветвление. >> А, нет, логично. Смотри, мы мы сделали автоматический запрос HM. Мы узнали, что за сотрудник. И из этой информации мы вот идём вправо, выясняем всю его информацию, да, её вытаскиваем. А также мы получили там хэш Википедии и по ней вытащили соответствующие правила. Опять же, исходя из того, сотрудник это или пабюер. >> Правила >> и контекст о сотруднике. Просто делаем параллельно. И нам для того, для того нужна исходная информация, собственно, которая из хуймая, из этого первого апизова делается. >> А, а это тоже, то есть вот сюда пошло и вот сюда пошло. И это некие такие параллельные процессы. >> Да. Да. Да. >> А так. А final contact string, то есть он собрал это стрин и >> это то, что идёт в User Prompt по сути. То есть у нас правила подобранные идут в системный промт, а информация о сотруднике идёт в промт. >> Так, о'кей. У нас, кстати, я смотрю, подключаются люди, да, мы вот всех рад, всех рад приветствовать, друзья. Мы вот мы разбираем как раз решение Ильи, оно у него за Осоршена. Аэ, вот. Но да, если что-то прямо совсем сильно будет непонятно, можете, в принципе, я думаю, вопросики писать. Но мы постараемся всё-таки вот идти по нашему флоу, потому что запись идёт. Я знаю, что там не сначала, да, часть людей подключились. Вот. А-э, если какие-то вопросы появляются по ходу, э, прямо в зуме можно, в принципе, их задавать. Аа так, ну, хорошо, хорошо. То есть мы, в принципе, можем переходить вот в непосредственно уже к самому этому агенту. То есть пока что до этого момента, я так понимаю, пока агента не было, как бы, да, то есть пока мы просто пайплайном собираем контекст. Класс. Класс. О'кей. >> Да, много чего происходит на этой подготовке. >> Интересно. Я бы я тоже я видишь, я фиксирую. Я вот люблю зафиксировать. Я бы тоже зафиксировал бы, что несмотря на то, что как бы агентная система, есть место и пайплайну тоже. Да, вот это хороший такой >> обычный, да, обычный тут workflow pipeline, как он его можно назвать. А, кстати, обмоллюсь, почему реквесты параллельные. Можно было бы сделать и последовательные, но Ренат добавил имитацию задержки в API в 300 миллисекунд, и было бы очень долго. Там ещё есть довольно гадкий момент, о которой спотыкались многие агенты, и я его отдельно, скажем так, починил. >> Это то, что там для сотрудников, для проектов, ну, для всех сущностей, которые ты, которых много, там есть команда лист, то есть ты можешь их получить все. >> Но лист с пагинацией, >> я думаю, многие знают, что такое пагинация, да? То есть это когда он тебе возвращает не все запросы за раз, а возвращает какое-то фиксированное количество, и ты потом можешь сделать запрос на следующую как бы страничку, как вы когда, не знаю, в Гугле результат там или в магазине. >> Угу. >> листаете и >> стандартный подход в API-шках, >> да? Да. И вот, э, лимит сущности на пагинацию был пять. То есть ты за один запрос можешь выз можешь получить в списке пять сущностей. Если у тебя 100 сущностей, >> твоему агенту вызвать инструмент 20 раз. >> Да. >> И о'кей. И и ты просто видишь, что у нас тут опять же, видимо, немножко упрощённо, я так понимаю, то есть и ты старался все проекты всё равно вытянуть, да, и оно, видимо, тоже как-то там у тебя параллелилось. >> Смотри, я написал отдельный врапер. Да, это тоже можно упомянуть, что я некоторые инструменты, а, упростил. Я сделал над ними, над ними свои враперы. А, и из тех инструментов, где есть, а, >> вот это, вот эти два поля, это как бы ассет и сколько элементов выдать, да? Ещё прикол в том, что нигде не сообщается, сколько у тебя элементов пагинации можно запрашивать. Ты об этом узнаёшь только, когда просишь 100 элементов и получаешь ошибку. Максимум пять. Вот. Да. И я сделал обёртку. Я убрал, а, по сути, поля пагинации из всех инструментов, где они были. А я написал просто кодом автопагенатор, который итеративно пробегается по всем страничкам и собирает всю информацию. Как бы пагинация, получение элементов с пагинации было большой головной болью. И этот вра чисто кодовый, он с задачкой с этой справился. Он её просто он её просто убрал. >> То есть у нас инструменты подупрощённые, которые в LLMку пришли. Ты как бы абстрагировался от этого. Ну, некий некий врапер, некий прокси своего рода, да, такой сделал, который просто возвращается всё сразу. Ну, тоже, да, это некое упрощение классное, да, >> да, >> тоже хороший хороший хороший поинт, чтобы >> он использовался и на вот эта на этапе подготовки и во всех инструментах, которыми агент пользуется уже в агентлупе, в этой агентной в агентной петле. Так, посмотрим. Так, давай дальше двигаться. >> Давай. Сейчас conversation history. Окей. Agent plan react. Всё правильно. А, да. Значит, я не пользовался LLM-ами. Ну, это просто вопрос привычки, на самом деле. Можно пользоваться здесь туколами, можно пользоваться аупутом. Я пошёл помната, да. SGR guided reasoning. Так, значит, и у нашего агента есть четыре поля. А, есть поле state, план, action и function. А в поле state агент о мы запрашиваем агента описать то, что произошло и известно на данный момент, да? То есть сделать не всё изучить и сфокусироваться на этом, да? А на этапе план мы запрашиваем, какие вообще шаги нужно ещё сделать как бы для выполнения задачи. А на этапе экшн мы, основываясь на предыдущем поле план, э, как бы в этапе экшн, мы пишем, какой шаг нужно сделать прямо сейчас. Ну, по сути, первый шаг из плана, да, только уже более детализованно. И функвывается на экшене. И по сути он уже вызывает там простонам из всех инструментов просто с их названиями. И он туда пишет в экшн одну из функций, собственно, через этот и пишет её параметры. Там просто это всё через Pydantic объекты делается. Э то есть вот так важный момент. У нас здесь ты видишь степвалидатор. Это некоторый помощник, который увеличивает точность пайплайна. На самом деле не сильно, не так идеально, как я изначально предполагал, но это помогает. Базовый, если сейчас забыть про степвалидатор, потому что он как бы бесшовно встраивается в этот пайплайн. Его его там может спокойно не быть, он у меня отключается в настройках. Кстати, кто хочет посмотреть на код в репозитории, я постарался всё максимально подробно в Readme описать, как его можно запустить. Э-э, там всё вот сейчас, всё, что я сейчас рассказываю, там текстом описано. Э-э, есть визуализатор прямо по ссылочке, можно его открыть тоже вживую, посмотреть трейсы. То есть как бы я постарался это сделать максимально дружелюбным для изучения другими людьми. А, да, вернёмся. Ээ, значит, он выполняет функцию. Мы мы как раз-таки его ответ берём. LLM вот эти сейчас LLM это возражает нам как ответ эти четыре поля. Мы смотрим, что он вернул в function. Мы берём эту функцию, берём параметры, которые LLM написал в этом да, ну, то есть ID пользователя, например, да. А и всё это передаём уже просто в код. То есть мы дёргаем соответствующую функцию. То есть у нас здесь нету тулколинга. У нас здесь как бы LLM колинг, он происходит в на этапе function на в этом поле. >> Structure output. >> Угу. Так, ну правильно ли я понял, что ты в принципе тут у тебя агент, он LLM колинг не использует. То есть есть два подхода, да, принципиальное, да, там первый подход - это вот >> а как раз вот LLM колинг, когда вот есть, а LLM-ки, они, в принципе, вот сейчас вот, да, тренируются таким образом, чтобы м чтобы хорошо поддерживали сценарии, собственно говоря, вот вызовы LLM. И в принципе они, можно сказать, нативно сейчас как бы умеют, э, отдавать в ответе, да, э тот тул, ту функцию, которую нужно вызвать там с какими-то определёнными параметрами. То есть, в принципе, там ещё там на этапе, ну, либо там обучение, либо до обучения. Я тут уже дета деталей здесь уже не знаю. Значит, ну, в общем, это более-менее нативно поддерживается. Это вот первый подход с тулколингом. Второй подход - это когда мы говорим, что о'кей, LLM колинг замечательно, но мы вообще давай туolлинг не будем использовать, мы пойдём по пути того, чтобы просто нейронку нейронки, допустим, да, давать список доступных функций, а в виде промта, да, то есть ты, наверное, в виде там систем промта, да, какой-нибудь список. Ага. >> Ну и и в виде всей Pydantic схемы, которая естественным образом прикрепляется к системному промту автоматически в большинстве случаев. А, да, ну, а, ну да, ну это, то есть, о'кей, ну это именно, да, то есть тут идея в том, что у тебя в System пром условно список тулов, а, и также рядом с этим System пром там, я понимаю, что по итогу оно всё всё равно там собирается в System пром, чтобы мы сейчас не обсуждали, как бы, да, я так понимаю, там, да, под под капотом уже где-то там, где оно инферится, но сейчас мы не об этом сейчас чуть на на выше уровня абстракции. А, но здесь важно отметить, что, во-первых, да, вот список тулов в системпромте указываем, во-вторых, а, даём, а, вот эту structured output, то есть мы даём непосредственно ту структуру, которую мы ожидаем от LLM. Structured output - это в данном случае, я так понимаю, тоже как раз-таки вот нативная история, да? То есть ты как бы уже здесь уже как раз, если в плане тулов, тут чуть-чуть получается такой неочевидный момент, что, ну, слушайте, ребята, вам же вроде как в специально LLM-ки нативно обучили вот тулы вызывать, да, функции вызывать, а вы получается чуть-чуть как бы в обход идёте, да, и вы делаете не совсем через нативный вызов тулов, а вы, получается, делаете через аа вот указание в системпромпте, да, и здесь вот как раз вот этот вот второй подход, когда вот вы именно через промт Чуть-чуть, может, подробнее здесь расскажешь, вот почему вот такое решение принялось. Тоже вот такой вариант немножко неочевидный, да, видимо, как-то связано вот с этим самым, с этими возможностями SGR, да, вот страшно или с чем связа? Ну, частично, да, частично. А тут, во-первых, помогает, что моделька может как бы думать по шагам, которые мы ей дали, да, потому что, э, как бы мы ей дали вот этот чёткий пошаговый, э, алгоритм. То есть шаг два следует из шага один, шаг три следует из шага два, шаг четыре следует из шага три. То есть они каждый, э, последующий опирается на предыдущий. И это важно, что мы можем вот сделать чёткую дорожку, по которой LLM будет идти. как бы когда мы хотим, чтобы у нас была высокая точность, нам нужна консистентность. Тут отчасти вступает как бы и моя личная проводиформация. Я агент я как бы тулколинг - это почти почти всегда про агент. Я агентов э именно у нас компании не особо люблю, потому что э бизнес-решения а они требуют консистентности. Аа как бы консистентность со стулколингом сложнее гораздо обеспечить. И вообще обычно в бизнес-приложениях с LLM под капотом нужно максимально всё пробивать гвоздями. Про пробивание гвоздями - это как раз-таки structured output. Я думаю, что если это реализовать через LLM колинг, будет примерно такой же результат. Все, кто хотят welcome, расскажите о результатах. А, >> да, слушай, тут вот так такая такая тема, она, ну, в некоторой степени спорная, да, вот подхода, значит, не использовать тул, потому что, насколько я понимаю, может быть, сейчас, кстати, ты чуть-чуть поправишь. Здесь есть интересный benchmark, его некоторые критикуют, но тем не менее, да, вот этот вот BFCL от BCL сделали вот этот leaderboard. >> И здесь он чем примечателен? Тем, что >> здесь отдельно где-то, я помню, мы смотрели ещё с Валерой, э, есть столбец. А, ну, собственно, да, не столбец. Вот, собственно, вот она. Значит, смотри, вот, да, вот, чтобы тоже люди понимали, вот кто будет смотреть, это benchmark, вот у нас есть OPUS Sonet, да, в скобочках FC Function CL. Это как раз вот подход, собственно, с натив с вызовом, а, нативных, назовём это так, нативных, да, тулов. Вот. А, и есть ещё альтернативный подход, ээ, вот когда в скобочках промт написано, э, это как раз вот то, о чём ты, ну, как бы с одной стороны, это то, о чём ты говоришь, то есть это когда вот прямо внутри промта мы, э, собственно, без вот этого натив function calling просим сделать с одной стороны, но с другой стороны это не совсем то, потому что всё-таки здесь ну здесь, насколько я понимаю, не используется SGM, то есть вот guardдин здесь не используется, поэтому, наверное, не совсем корректно сравнивать подходы, но тем не менее Тем не менее, да, вот тут вот что интересно, значит, G 3 Pro preview, вот она в промте, если вот через промт вот как как мы сейчас с тобой обсуждаем, её используется, она аж вот 70 72 балла выбивает. Хотя, кстати, что интересно, это сопоставимость JLM 4.6, которая, собственно, с факлингом, да, сопоставима оказалась. Ну, опять же, как бы, ну, benchmark есть benchmark. Всё-таки тоже там свои могут быть, так сказать, байсы бенчмарков, но но тем не менее, как факт интересен. А вот G9 3 Pro с факшн колингом здесь у него у них даже получился ниже. А по ты вообще смотрел этот benchmark? Как бы можешь как-то его прокомментировать? Что? Нет, с этим benchmarkом не знаком. >> Ну да. Ну вот, в общем, это довольно любопытно. Вот мне всегда было интересно вот кого-то практиков вот так поспрашивать. Действительно, кто сравнивает, тот насколько, ну, знаешь, вот действительно же интересно, вот у нас есть какая-то модель и вот как нам её более эффективно использовать всё-таки с фанкшн коллингом или всё-таки через промт. А, и, ну, понятно, что ответ он, да, наверное, будет лежать всегда в собственных каких-то Evolutions, да, Evils, когда компания сама там тестирует и и, наверное, это будет это всегда будет как бы идеальным решением. Типа, ребята, ну, проверьте на своих, так сказать, на своих задачах. Ээ, но тем не менее, знаешь, всегда хочется как-то немножко заранее знать какую-то общую общую такую информацию по этому поводу, вот как будет эффективнее. И как будто бы вот этот BFCL может дать как бы иллюзию вот этого понимания. То есть условно, что там мы видим, что GMI 3 Pro, допустим, с проптингом, она даже может оказаться чуть получше, чем GM 3 Pro с факшн коллингом. Вот. Ну, Иле, вот давай вот в этот момент интересно тебе вопрос задать. Как по твоему опыту, вот насколько вообще есть смысл доверять вот бенчмаркам вот в таких задачах или никогда не угадаешь, всегда лучше действительно свой evaluation делать, и только тогда только из этого можно там какое-то объективные делать выводы. >> Ну, к ним всегда нужно относиться с огромной щепоткой соли, да, потому что рисование цифр на бенчмарках - это уже вообще любимое занятие э всех абсолютно провайдеров. >> Угу. >> Вот. И тут очень сложно, как бы я обычно, если вот мне что-то надо прям прямо понять самое лучшее, что есть, да, я лезу как бы на архив читать статью научную по своему бенчмарку, а стараюсь исказать какие-то независимые оценки, потому что, например, например, GPT3 Pro preview вышло, у них в показано, что они супер классно делают OCR, у них там есть benchmark очень классный, не помню, как называется, что-то типа OCR OCR там версия полтора, и у них стоит цифра а какая-то. Я пошёл лезть в архив и смотрю, что у них как бы цифра, которая стоит там, у них условно дистанция редактирования. Ну вот что-то из такого, но при этом она совершенно не ну нерелевантна. Это это не та э не то измерение, в котором как бы в котором выставляются баллы у этой в этом бенчмарке. Ну, то есть там где-то имела место быть манипуляция, потому что, видимо, >> а, >> как бы, да, нативный балл, он может быть был не таким красивым, >> как бы тут всегда идёт жонглирование. >> У какой модели это было? Ты сказал же, что это? >> Gemini 3 >> J 3 Pro. >> Gemini 3 Pro. >> Угу. Дадада. Да, да. Угу. Угу. То есть всегда скептически. >> Что мы тут можем понять? Что нету однозначного ответа, что Function calling всегда круче или промпт круче. То есть мы как минимум здесь видим, что есть некоторый приоритет может был function calling, но тем не менее >> Ну да, интересно, интересный инсайт. А, о'кей, пока далеко не ушли, пока не продолжили остановишь тему. Может быть, тоже здесь сможешь подсказать какие-то бенчмарки наиболее адекватные. Ну, при

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

Делайте свой собственный эвалюйшн и смотрите под свою задачу. Бенчмарки они часто, ну, они коррелируют, как бы, да, но при этом, если хотите самый лучший, ну, берите, господи, просто возьмите GBN 3 Pro там, я не знаю, какой-нибудь GPT 5.2 Thinking High и OP 4,5 и проте прогоните на своей задаче, посмотреть, как получилось. Даже без элеации, просто глазами посмотрите, как получилось.

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

О'кей, супер, супер. Спасибо большое, Ильяс. Да, я предлагаю вернуться к визуализации. Смотри, вот мы посмотрели вот этот жеронownй, э, вот проговорили вот эти этапы, но смотри, мне показалось не до конца, так сказать, показательно это было. И есть подозрение, что вот мы можем попробовать как-то компесировать это трейсингом, то есть вот взять какую-то конкретную задачу.

Да, только впереди в DMС. Это это трейс для бенчмарка. Там вкладка DOS есть.

Левее, ниже почти, ниже.

Так. А вот он наде.

Да? А и на benchmark переключи.

А.

Да, вот это уже сдачки, которые оно benchmark ушли. А, ну и давай.

А а а а в сторе там чуть другой планй, да?

Да, там не чуть-чуть, он там сильно другой. Давай, наверное, я я с тебя переключу переключу демонстрацию, да, чтобы.

Как бы там трейсинг не самый как бы user-friendly, да? Там UX, конечно, очень условный. Поэтому иногда мне даже самому тяжело в нём ориентироваться. Буквально секунду.

Ну уже уже за даже за такой тебе всё равно большое большое спасибо. Это уже очень ценно. Мало кто мало кто в принципе свой код выкладывает. А ещё чтобы подумать о том, чтобы как-то это визуализировать, это прямо.

Кстати, победившее решение по C2 также лежит у меня в репозитории. Открытый код, всё прокомментировано. Есть статьи на русском, на английском, там на Хабре есть статья. А многим очень помогло, многие делали как по гайду какие-то свои раксистемы. Тоже, если кому интересно, заходите.

А так, значит, да, мы в Ероси Бенчмарке. Э, ну вот можем, например, смотреть, да, задачка: "Я покидаю компанию, удали всю мою информацию". Да. Вот наш контекстбилдер, о котором я говорил.

О.

Ну да, но она как бы не очень показательна, потому что здесь, как ты сказал, что контекста не не будет толком никакого, да? То есть, как ты сказал.

Да? Да. Ну, хотя он тут он тут чего-то выбрал, на самом деле, немножко. Он он тут решил проекты выбрать. Э-э, но опять же как бы даже если я попросил его работать немножко жадно, да, что лучше там уже агент, э-э, ну, проигнорирует какие-то доблоки, чем мы чего-то упустим. А-э, да, тут всё довольно просто. Ну давай.

Так, тут у нас попытка промпт инъекции. Тут.

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

Где модель агент отказался, потому что правилами нельзя. А один балл или ноль баллов - это.

Было ли так задумано, было ли это правильно, это именно результат от бенчмарка, да? То есть вот здесь, например, мы отказали.

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

О'кей. Значит, изменить статус проекта Data Foundations Audit. Ту. Вот тут, к сожалению, кстати говоря, мой косяк, он не пишет весь текст. Но мы можем это где-то посмотреть. А, да, смотрим, значит, контекстбиilder у нас есть поле отдельное для ризинга, да, это для дебага. Оно, на самом деле, никуда больше там не идёт, оно просто выкидывается впоследствии. Это вот если ты хочешь посмотреть, заглянуть в мозги модели, почему она прилена то или иное решение. Вот тут это написано.

Аа.

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

А вот ризанинг - это просто текст, просто текстовое поле.

А, ну да, да, ну просто вот фишка именно вот СГР, насколько я понимаю, что в том, что там можно, значит, какие-то шаги ризинга, да, там явным образом определять. В данном случае это просто ризанинг, значит, вот как-то об этом. Слушай, ну GPTO SS120 она же сама по себе ризанинг, то есть ты это, получается, повторяешь.

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

А мы.

Как бы это вспомогательное поле, да, для отладки.

О'кей. О'кей. Ладно, хорошо. Да, можно, можно посмотреть, что вот он в итоге выбрал блоки, да, я так полагаю, что проект R Steel Data Foundation, это оно есть, да, Data Foundation Audit, всё очень похоже. А дальше агент.

Прости, пожалуйста, ещё раз прерву, давай. Что за задача? Change status of project data foundation audit to то есть а то есть о'кей есть есть некая задача в условном каком-то тасттрекере типа джира как бы да и нужно поменять статус задачки оно просто полностью описано ну.

Вот да вот поменять статус на активный.

А о'кей.

Да просто активировать проект.

Так я уже сразу вижу извини пожалуйста у тебя там вот эти теги да у тебя task ээ это как нтропик дале рекомендуют XMLла, вот эти теги.

Да, да, я люблю XMLла, потому что в отличие от маркдауна, во-первых, Markкdдаун, он часто очень мусорный начинает быть, когда особенно просишь Мэмку тебе помогать с промтами. А во-вторых, мне нравится, что есть ограничение не только где начинается информационный блок, а также где он заканчивается. Вот это основная причина, почему я их люблю.

Очень классно.

Ну, есть мнение, что это, да, что это там, если честно, эффективнее работает. Вот. Но во всяком случае, Anтроopic действительно рекомендует. Я даже в Open AI натыкался на, по-моему, статью, где они тоже рекомендуют такой подход использовать. Вот. О'кей. О'кей. Тоже да, на самом деле другие практики, просто написание промтов, они часто могут перевешивать пользу или вред от той или иной практики, как бы, по сути. Аа, да, это кому интересно, могут почитать прямо. Э, сырое - это то, что пришло на вход. А там где-то системный пром также есть. А, и в итоге решение, которое было принято - это вот эти два контекстных блока приложить. Упоминаем их по ID, потому что у каждой сущности есть ID. И это важно, потому что финальный ответ, а, агента, он в себя должен включать аа ссылки, которые были использованы. Ну, то есть он должен сослаться на какие-то проекты. Понимаешь, да, о чём я?

Ну, я понял, да? То есть сорсы, на основе которых он, собственно говоря. А сейчас вот я просто пытаюсь понять вот конкретно в это в этой задаче. То есть ты selected selected blocks, да? Да, то есть он нашёл нужный проект.

И связано же с ним покупателя на всякий случай. А не покупателя, а клиента, который.

А.

Чей это проект.

Угу.

Так, о'кей. И это как бы сорсы, но это не просто сорсы, это всё равно он дальше с ними же работать будет, да?

Да? Это это да, это пока что это пока что вот только только начало. Вот вот сейчас вот сейчас начинает агент работать. Мы ему скинули эти два блока, да? А и.

Угу.

Говори.

Ну вот тут вот меня тоже хочется тебя спросить сразу. Вот ты сразу нашёл там проект. Ну вообще в некоторой степени это как раз вот задача Рагова, насколько я понимаю. То есть найти нужный проект, например, да, по его описанию. И в реальности, когда проектов там тысячи, а то и десятки тысяч, ну это действительно задача такая, она может быть не тривиальной, то есть по описанию, да, там по какому-то контент, например, может там не сработать или далеко не все сработать. Я бы не сказал. Ну я по сути в Рад 2 получил первое место и там, и там. Потому что там была похожая система. А, ну, скажем так, мы финальный выбор даём делать lм, то есть мы можем рагом отсеять до 100 сущностей, а потом это скинуть в лэмки и сказать уже: "Ты вот более умный, ты выбери, пожалуйста, на основе этой информации".

Угу.

Классно, класс классный поинт. Я мне тоже нравится этот подход, да? То есть когда люди говорят: "Нам нужны мбединги, давайте викторизуем, викторизуем". Ну подождите, говорю, сколько у вас там? Давайте, может быть, у вас мы то точным поиском сейчас отсеем там, да, там до сотенки, а дальше просто эту сотенку закинем лэмки и с куда большей точностью получим то, что нам надо, потому что после рага вам всё равно после этих эмбедингов всё равно с высокой доле вероятности, если вы хотите хороший точный ответ, вам всё равно нужно будет через лэмку делать какую-то дофильтрацию, какой-то ренкинг, как бы, да, и может быть и в принципе даже даже медин-то и не могут быть не нужны. Ну там опять же там могут стать вопросы про косты. Ну подождите, сейчас это 100 мы закинем в промт. Это же дорого будет. Ну это уже отдельная как бы история, но в целом.

О'кей. Ой, интересно слышать.

Да, раньше использовали рак плюс риранкер. Ну реанкеры практически никто не делает там, кроме джины какой-нибудь, да, и LM модель настолько дешёвые, как бы можно с тем же успехом делать рак плюс lm гораздо лучше. Собственно, я так и делал в рак 2 челлендже. Там я 40 элементов кидал в контекст и выиграл лемкой финально.

Ну давай быстро проговорим, да? Давай быстро поговорим. То есть ты по этим прожектам, то есть ты, допустим, там каким-то точным поиском, допустим, поиском по точному вхождению или полнотекстовым поиском, не суть. Там, да, там условно там из тысячи из тысячи ты там до отсеиваешь условно там 50-100 и дальше уже из них ты уже их отправляешь в ловочку и просишь её, чтобы она выбрала то, что действительно нужно. То есть вот в данном случае вот такой подход. Всё о'кей.

Да, вот тут мы работаем без драга. как раз-таки предварительный отсев. Это условно из всех сущностей, которые есть в компании, мы кодом, чисто кодом, чисто инструментами IP вытаскиваем те, которые касаются сотрудника. То есть вот что видит контекстбилдер. Он видит вот эту информацию. Это сущности, которые есть про сотрудника. Как бы это предварительный отсев вместо рак поиска.

Чисто кодом.

А.

Ну это это ещё до отсе, то есть это ты просто за то, что это контекстбилдер прилетело, да, всё, что есть по человеку. То есть предварительно от всех тоже.

А-э, да, выбрали вот эти два блока. Всё, они здесь у нас уже лежат в контексте. У нас лежит информация про Himi. Тоже мы её положили сразу в контекст, да, что это вот ID сотрудника, аа вот его имя, а, это тоже его ID, его акс доступ, что он аутентифиcта, да, его локация, его департамент и сегодняшняя дата как бы тоже в прикладывается и чуть больше информации по нему ещё здесь. Там есть его скилы, есть по нему заметки и прочее, и прочее, и прочее. Аа, вот, значит, погнали дальше. Что делает наш агент?

Ну да, и дальше тебе ЛМКА просто айдишками, да, ответила там, что релевантно. Это я правильно понял? Айдишниками блоков условно. О'кей.

О'кей. Давай дальше.

А, о'кей. Вот что, вот что отвечает самый первый агент на самом наставом первом шаге. Ант, а значит, usер такой-то, такой-то. Вот он autentificated, там-то, там-то находится, хочет изменить статус, ну, бла-бла-бла, короче, просто перефразируется задачка, да, проект существует и сейчас заархивирован. Это мы уже, это он уже знает в самом начале просто потому, что вся информация по проекту у нас здесь есть, да? Вот он, статус Rifев. То есть у нас он уже знает, а что он сейчас архивирован. Мы должны приверифицировать проект recкоord. А не понял, что тут решил. А, о'кей. И значит статус, э, что получить информацию по проекту, чтобы подтвердить его ID и текущий статус, ну, решил перестраховаться, видимо, ещё раз вызвать. А обновить проект на статус actтив, используя point, который меняет статус проекта, и загрузить response instructions. Это важный важный момент, который мы немножко опустили в начале. Ты помнишь, в самом начале я говорил, что мы вытаскиваем три сущности. Мы вытаскиваем правила для абкюзеров, для авторизированных юзеров и правила для ответа. Правил для ответа много, поэтому они в контексте изначально не лежат. Я сделал дополнительный псевдотуolл, а, вызывая как бы и запромтилмку, что когда ты готова отвечать, вызови этот, он тебе вернёт инструкции, как отвечать. То есть LM динамически себе подтягивает релевантные инструкции в контекст, когда они нужны. До этого они не висят в контексте и не замусривают его внимание. А, да. Идём дальше. Значит, ответить юзеру. В общем, ответить юзеру, что всё классно. А-э, посмотрел детали проекта. провер, что он существует. А на всякий случай он решил перепроверить, да, он по Project Get эту айдишку позвал. Айдишку он уже знает, ему не нужно её искать, как было бы в простом случае, да, если бы у нас не было контекстбилдера, он по этой айдишке позвал проект. Аэ, значит, вот что выдал tool. как бы как раз-таки мы ему мы этому агентудаём в ответ на его этот запрос как бы следующим шаге в истории условно беседы мы выдаём информацию, что выдал tool там и ошибка, если это ошибка, например, да, или вот, собственно, результат вызова, то есть вот он вот он вызвался проект, то есть просто он подтвердил, что он существует. О'кей, хорошо. А тут он всё снова это перечислил, все те же самые шаги. Вот тут, собственно, шаг заапдейтить статус до активного, да, и ближайшее действие Next Action, да, которое он сейчас будет делать, это вызвать inpint по обновлению информации по проекту и поставить статус на активный. Э, вот. И, значит, вызывается вызывается наш inpoint вот его, а, вот один из полей, э, на этот requвест, да. Вот вот второе поле, вот третье поле, да? То есть мы вызвали инструмент, всё. А что интересно, тут у нас как бы СДК в ответ ничего не возвращает, да? Это это просто это просто приколы того, как может работать в реальной жизни Апи. Там тебе ни статуса, ничего. Просто как бы Ну а ну может там двухсотка пролетает в ответ.

Ну 200, ну 200. Ну тебе последователи растать, тебе скажут: "Ну подожди, Илья, 200". О'кей, это очень много, значит. О'кей.

Да, да, да. Ну я к тому, что там есть разные поведение на разные пинпоинты, где-то он говорит, что всё классно и возвращает тебе просто эхо, да, а возвращает текущий статус, там где-то он просто там двухсотку. Ну то есть по-разному. А, ну неважно. В любом случае агент почитал, что всё этого достаточно. Он вызвал э инструкции по тому, как формировать репон юзеру. Там загрузилось правило, как линковать что-то, а там эти айдишки, как как там текст писать и прочее, и прочее, да. И на основе этого он вызывает, а свой последний AP инструмент, а, собственно, IP respond. И мы дальше кодом отлавливаем, что как только агент вызвал resp, это это терминальное действие, то есть мы завершаем цепочку. Как бы просто тут конкретно эта задача, она построена таким образом, что всегда последнее действие агента - это респонд. Всегда должен быть респондции.

А либо на отказ, либо на согласие. Ну и, собственно, здесь как бы всё идёт ровно по тому же алгоритму. Он в итоге так, а это у нас история, которую он видит, э, этот агент, то есть он видит историю предыдущих шагов.

А, давай, да, прежде всего продолжим. Респон - это тоже тул.

Да.

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

Вот. И да, он с ним закрыт, то есть он даёт какой-то, да, месджут.

Угу.

Статус. Там есть около разных статусов, типаity, например, там есть такой.

А тоже ты в виденамки, да, в стратапуте, собственно, список этих статусов подаёшь. Ага. И дальше он отдаёт Linkс. Это, видимо, референсы, да, как раз-таки.

Да, да, да.

Угу.

Он говорит он говорит, был изменён. Всё хорошо. А.

В общем, например, вот так. Э.

Слушай, ну он у тебя в данном случае не валедит. То есть он мне что немножко удивилось, что он действительно получил 200. О'кей, ему этого было достаточно. Угу.

Он решил не валидировать это, да, ещё дальше не идти. Ну, в принципе, было бы логично после этого, наверное, заходить ещё удостовериться, да, всё получить.

Логично. Причина, по которым я не люблю агентов, да, что ты не можешь всё перебить гвоздями настолько сильно, чтобы он это, например, всегда делал. То есть ты можешь добавить ещё одно правило в System промт, конечно. И было такое решение, которое именно так победило. Собственно, это, кстати, был, э, самые самое первое место в общем зачёте, но это был опус 4,2, видимо, потому что меньшие модели не справлялись с таким наплывом, с таким количеством правил, мм.

Которые системный промбухались. А, то есть там человек постарался, скажем так, учесть там множество корнеркейсов, да?

Всё, всё учесть все курнеркейсы. Там буквально у него эволюционно системпромт изменяется, основываясь на ошибках, которые возвращает бенчмарк.

Да.

А, я понял, я понял, я понял. Да, да, да.

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

А значит, тут есть то, о чём мы не говорили, да? Вот этот инструментик, который я сказал скипнуть- это а валидатор. Валидатор он что делает? Прежде чем код исполнит тот инструмент, который агент вернул, попросил исполнить, да, аа этот валидатор, он посмотрит на задачку, он, в общем, он посмотрит на всё, что было уагенты сбоку, да, на его системный промт, на информацию, которая ему доступна, на текст задачки и прочее, прочее, прочее, и подумает: "А правильно ли всё сделано?" Да. А как бы он над этим поразмыслит, и он либо пропустит задачку вперёд, он говорит: "Всё о'кей, я как бы изве true, всё, я я даю свой пас, э, вперёд". И действие агента выполняется как ни в чём не бывало. Сам агент не в курсе вообще, что его что его даже валидировали. Это просто промежуточный шаг. А, но если валидатор считает, что агент тут, ну, не совсем какое-то правильное действие выполнил, да, то есть он не согласен с валидатором, то он сейчас, может быть, посмотрим, где есть валидатор сработал. Тут очень много простых задачек. Вот, например, да, вот тут можно посмотреть, что в какой-то момент агент решил какой-то сделать шаг. Потом он хотел сделать какой-то шаг ещё, да, но валидатор сказал, что нет. Значит, вот так вот делать не надо, как ты там собирался сделать и объяснил, почему то не надо такой инструмент вызывать, не надо такие действия делать. Это сообщение возвращается и агенту на передел бы на работу над ошибками. Агент повторяет заново с учётом тому, что я ему сказал валидатор.

А так так. Ага. Ну, вообще вот цель валидатора прежде всего, чтоб чтобы что я просто вот смотри, я вчитываюсь вот то, что там у тебя сейчас, да, no such call has been made yet. То есть он на что в данном случае жалуется, что либо вообще нет такого вызова, либо он слишком быстро.

Да, давай посмотрим, посмотрим, что агент хотел сделать. А как бы он сделал запись врем он, видимо, добавил в лог записи что-то, да? А потом он хотел сделать, а-э, пу-пу-пу-пум. А он хотел сформировать респонд, он хотел всё сделать терминальное действие, но в промпте ему сказано, что перед респондом подгрузи правила для респонда, те нюансы вот эти, чтобы ты знал. Валидатор ему сказал: "Не, ни фига, ты что делаешь респонд? Ты инструкции по респонду не подгрузил". А он такой: "О'кей, тогда всё забыли, отменяем то действие. Оно просто не выполняется". Да. Здесь мы загружаем правила по респонду и уже потом пишем респон. То есть вот тут он его отсвернул от ошибочного пути.

Очень интересно. А валидатор - это тоже лэмка или там.

Да, да, это тоже это тоже лэмка. Причина, по которой я использовал GPT, вот этот ОС я использовал принципиально на серебресенпоинте. Видишь, каждый запрос, он занимает условно там секунду. А, и валидатор он занимает даже, кажется, меньше секунды. И это оно тоже условно секунду. Хотя вроде вроде быстрее. А, и как бы это можно было бы делать ещё быстрее. То есть скорость просто что можно больше, а, хоть более как бы глупеньких э запросов сделать. Ну, то есть модель более слабенькая, но можно сделать много запросов, да, то есть можно проверять каждый шаг. А более того, вот тут, например, а тут валидатор, он два раза отказал, сказал: "Нет, первое решение неправильно и второе решение неправильно, а третье решение он пропустил". То есть, ну, там есть лимит, кажется, он максимум два решения может это не разрешить, а потом просто в итоге. Да, да, да. То есть валидатор в случае, если всё хорошо, он никак на пайплайн не влияет. Он просто делаете всё, как делаете, да? Если что-то плохо, он топ.

Угу.

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

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

Да. А ну оговоримся, что агент - это не это не серебряная пуля, и он периодически также может гациони галлюционировать. Он может просто, ну, не согласиться с агентом, хотя агент решил правильно, они или может пропустить какое-то неправильное действие агента, потому что ему тоже показалось, что так ок, например. Вот как мы смотрели, что на когда двухсотый просто о'кей вызвался и ЛМ уже агент собрался отвечать, как бы его вальдатор пропустил, говорит: "Да, хорошо, отвечай". То есть, ну, насколько это было правильно, не знаю. Ну, задачка выполнилась, по крайней мере.

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

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

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

"А, то есть это формально называется как бы, вот есть React агент, есть плангент. Это известная архитектура, по ним есть статьи как бы написаны крупные. А это у меня комбинация план, React агент. То есть, как бы, я переизобрёл велосипед, можно сказать. А плюс я взял за основу, как бы, агента Рената. Он там очень простенького агента как бы прикладывал, чтобы было проще людям начать. Собственно, я с него и начал, потому что я до этого агентов каких-то сложных вообще не делал. Это мой, это мой был первый как бы заплыв."

"Ну хорошо. Ну да, ну давай вот просто о'кей. Про этап сбора контекста предварительного. Это действительно интересный такой этап, но в принципе, я думаю, здесь более-менее понятно, то есть как, как ты пришёл к этому моменту, да. Но вот что касается валидации, то есть, видимо, да, ты говоришь, через боль, то есть ты столкнулся с тем, что агент там систематически, да, нарушал, видимо, какие-то правила, которые ты описал."

"Тупил. Тупил. Что это? Что это? Что именно? В чём он тупил? То есть, о'кей, там респонд вызывал, это мы увидели, да? Ээ, там ээ преждевременно, несмотря на то, что, видимо, ты в промте ему сказал: "Чувак, респонд вызывает только там после того, как ты получишь соответствующие инструкции по респонду". Он всё равно не слушался в этом. Тут как бы, видишь, напрашивается решение сразу, да? Ну вот добавить промт important, да, там капсом там, да, вот такие. И другие правила будут забыты. То есть мы здесь наталкиваемся на то, что когнитивных способностей и два и два хватает. Уже появляются забывание, мы их пытаемся нивелировать просто."

"Во-во-во. Ну да. Ну, то есть, соответственно, да, то есть какие-то вот эти интуитивные, это как знаешь, алгоритмические задачки, да? Вот есть интуитивные, э, как это, не интуитивное, наивное решение, да? А есть вот более продвинутые. Вот наивное решение - это вот давайте мы систем прот поправим. Но в данном случае всё-таки есть ограничение всё-таки, да, модель не такая уж и большая, не не очень-то прямо сильно внимательная. И дальше тебе пришла следующая идея: а давайте-ка мы вообще отдельным просто этапом сделаем вот этого валидатора. У валидатора свой, видимо, системпромт какой-то. У него есть доступ к политикам, да?"

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

"Угу. Во-вот. Да, я это имею в виду, да, что к тем же политикам, которым есть доступ у у оригинального агента, и он, в принципе, видит всю всю историю, да, вот всю историю толколов."

"Ага. И на основании этого уже принимает решение нарушена политика или не интересно. Интересно этот ход, да? И он, я так понию, существенно тоже качество. А у тебя есть какие-то как-то статистик, да? Вот насколько вот разные, так сказать, этапы?"

"Я я измерял, но но в моменте я измерял, но в моменте у меня есть опять же там можно прямо через консольку вызвать инструмент, который может прогнать, например, одну задачу какую-нибудь сложную 10 раз подряд э показать тебе, сколько там у тебя попаданий и скольких. То есть я делал даже так, что я сложный я пять сложных задачек аэ запускал несколько раз и смотрел на график как бы и пробовал разные методы и смотрел, как он как бы изменяется. То есть я в моменте это делал, но ничего не записывал. Очень много изменений в саму архитектуру агента. И как бы, ну, сложно говорить, что на что повлияло, когда у тебя не одно изменение сделано, а много."

"Угу. Ну да. Ну смотри, у меня ещё несколько вопросов к тебе есть. Подскажи, пожалуйста, есть ли нам ещё что посмотреть? Вы как будто бы вот ядро посмотрели. Какие-то может быть ещё интересные нюансы?"

"Вот, да, вот то, что я обычно говорю. Вот давай зафиксируем. Что ещё можем зафиксировать такого? А оригинального, может быть, да, в твоём решении или может быть не то, чтобы оригинального, но как бы не не очевидного, что ли."

"Да, из неочевидного там ещё есть вообще тут другая архитектура у сторагента. По нему, если будет время, пробежимся. Он тоже довольно интересный. А из условно оригинального - это то, как у нас передаётся то, как у нас сохраняется история диалогов. Ну, в смысле, история диалога. А, и в общем, как объяснить, а вот этот эгент, он не видит вот эту всю информацию, которую вернул предыдущий Ягент. Мы срезаем, мы срезаем максимум. Кажется, я вот только вот брал вот это и выбранный инструмент и ответный инструмент. То есть мы опять же стараемся убрать лишнюю, ну, она условно релевантная, ну, просто её слишком много, да, мы пытаемся убрать э информацию как бы и сделать её как можно более компактной э для как бы, ну, для каждого шага агента. То есть мы мы стараемся срезать всё. Сейчас, секунду, я может быть я сейчас здесь покажу. Against assistant user."

"Да, давай, давай, давай на примере, потому что вот это тоже очень интересный нюанс. Давай на примере, вот что там было. То есть ты часть как как бы часть истории, часть истории, потому что вот насколько мне известно, вот там клодко, кодекс, они вроде как, собственно, до момента компактизации они вроде как ничего не режут, да? Вот у них вот вот ведётся история и там, насколько я понимаю, там может даже вот в в этапах, собственно говоря, изменения кода, условно, там первая сообщение, там может быть вообще уже какой-то совершенно нерелевантный код, да, а потом уже там к а это уже там десятое сообщение уже этот код изменился там 10 раз изменился, но но в первом сообщении всё ещё остался старый, и он очевидно, что он определённое замусориние делает. И я так понимаю, что ты вот вот эту вот эту проблему решал, да, таким образом, что у тебя как немножко рефрешился, можно сказать, контекст, да, да, даваймерим получится на примере посмотреть."

"Так, сейчас, секундочку. А, пупупум. Так, а, значит, мы передаём, да, вот мы это передаём вот так. А мы говорим, что предыдущий делал мы пишем, какой тул был вызван, причём даже видишь в одну строчку, да? А и какой был получен ответ. То есть мы не пишем информацию о вот этих там current state, мы не пишем эти next этот план. То есть нам это не важно, да? Мы вот концентрируем всё, что важно для истории, остальное нам не важно. Более того, более того, те ошибочные вызовы, которые были, они в контекст вообще не кладутся. Агент не знает, что он в прошлом ошибался. Ему это не надо знать. Зачем это его будет больше путать? Как бы, ну, теоретически он может этого какую-то мудрость почерпнуть, да, но это просто будет скорее замусоривать его окно контекста, э, нежели помогать. То есть это чаще будет мешать, чем помогать."

"Угу. А поэтому как бы мы тримимши и сжимаем."

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

"Угу. Да. Когда Вальдатор не пропустил. А, подожди. О'кей. Давай сейчас здесь здесь хочется понять. Значит, Вальдатор не пропустил. Дальше с моей опять же вот на основании моего опыта, а мы можем просто сделать ретрай, но с высокой долей вероятности мы получим ту же самую ерунду, ту же самую проблему."

"Нет, но ты просто ретрай. Для чего? Нет. Для чего? Нет. Ну погоди. Для чего и нужен валидатор? Валидатор ждает обратную связь. Он же не говорит, что просто фигня. Он говорит: "Почему фигня?" То есть агент говорит: "Идём рвать яблоки". Да, Вальдатор такой: "Ты дурак". Попросили нас апельсины рвать. А он такой: "А, да, идём рвать апельсины". И когда он пошёл врать апельсины и класть их в корзину, да, он не видит, что он в прошлой, он не знает, что он в прошлый раз сначала яблоки хотел рвать и что его по рукам ударили и сказали, что он всё неправильно понял."

"А зачем? Зачем? Как бы мы показываем только успех, да? Это истории пишут победители. Переписываем, короче, историю."

"Ну давай здесь опять же, да, зафиксируем, что о'кей. Значит, валидатор забраковал какой-то шаг агента. И дальше а мы не просто делаем ретрай, а мы ээ здесь же вот на следующем шаге мы ещё подаём фидбэк от валидатора о том, как себя вести, как дополнительную некую инструкцию, да, уже на которой, скажем так, атеншен будет будет зафиксирован а более чётко. Э- но при этом, то есть мы даём фидбэк, но мы не даём историю, мы не даём, что вот ты до этого такой-то сделал вызов, да, и он был неправильным, и он там какой-то, ну, то есть мы условно этот вызов из истории или как?"

"Не, не, мы мы как раз-таки сейчас, секунду. Ну, то есть то есть сам сам сам сам я Ну, то есть я я тебя помню кажется, мы друга поняли, да? Просто я уже тут немножко начал переусложнять. Ну, то есть саму вот саму попытку вот предыдущую, скажем так, именно именно как она была, да, не в виде виде в виде фидбека мы, естественно, подаём информацию, да, то есть в виде какого-то там коротенького фидбка о том, что вот нужно вот так себя вести, как бы, будь аккуратнее, вот некую некий такой некий ворнинг такой мы подаём, как бы, да, но сам сам сам элемент этой истории чата непосредственно вот в Messengers, то есть мы вот как есть, мы его не погу даём, потому что как бы смысла нету контекст замусривать, да?"

"Тут вообще тут вообще в любом месте применяется правило, что не надо класть в контекст то, что нерелевантно. Всё. То есть лучше меньше, чем больше, лучше делать суперрелевантную информацию и делать её как можно меньше. Потому что чем мы больше всё накидываем, тем больше мы увеличиваем вероятность того, что это будет ошибка, да, и что он свернул один раз не туда и как бы всё и пошёл во все тяжки. А, собственно, зачем и нужен был валидатор, да? У нас с агентом проблемы есть. А, с любым, наверное, агентом, у которого есть много шагов, что, а, если у тебя на одном этапе вероятность, того, что он ошибётся, допустим, 10%, да, то есть 90%, что он сделает правильный шаг, а, то если у тебя два шага, да, то у тебя вероятность, что он сделает два шага правильно, да, уже 0,81, то есть 0,9 на0,9 и так далее, и так далее. И чем больше шагов, тем большая вероятность, что агент ошибётся. То есть она сильно накапливается. И валидатор был попыткой, не сказать, что на 100% удачной и успешной, как бы этот процент косяков снизить. Но что было самой, а, мощной попыткой снизить процент косяков - это уменьшить количество шагов. Ты видишь, задачки решаются многие просто в три шага. Просто просто потому, что не нужно дёргать инструменты по получению каких-то там, а, данных, там, что-то выяснять. Всё, мы уже мы знаем правила релевантные. У нас есть все релевантные блоки. Всё, пошли отвечать. Вот на настолько всё просто, как бы мы идём, вот я говорю, с двух путей, да? Аэ, с трёх путей. С трёх путей. А, значит, э мы данные в контексте мы релевантные. Значит, сейчас мы правила кладём в system только релевантные. Мы контекст а задачи передаём в Userпроompt только релевантный. А четыре получается даже, да? Мы каждый шаг проверяем, чтобы уменьшить вероятность того, что у нас шаг будет неправильный, а, и у нас кумулятивная ошибка будет накапливаться, а, мы уменьшаем количество шагов. Вот эти четыре штуки, как бы, они в итоге увеличивают вероятность того, что финальный шаг он будет тот, который должен быть."

"Слушай, ну ты очень круто подытожил, на самом деле, да, спасибо тебе. Единственное, я всё-таки это хотел бы тут тоже тему всё-таки дозакрыть вот с тем, что ты на каждом шаге всё равно а контекст подрезаешь. То есть на быстром примере мы можем посмотреть вот как это выглядит, да, на практике, то есть вот насколько ты там что именно подрезаешь. То есть я привёл пример с там тем же клодкодом, который мне насколько мне известно всё-таки вот именно вот эта кумулятивность, она там присутствует. У, то есть он всё равно там опять же в этом есть своё преимущество, да, в том, что, ну, например, там кэширование работает хорошо, вот когда вот так вот подряд подряд идёшь, да, у тебя вот всё всё всё, что старое, оно вот старом неизменным, оно остаётся неизменным. Вот в этом в этом плане вот преимущество, что кэширование хорошо работает. Здесь же, я так понимаю, чуть-чуть, ну, на кэшировании это будет сказываться. Вот, если я правильно понял, вот этот твой подход."

"У серебров нет кширования и у многих провайдеров в Openутере нет кэширования. Поэтому я с ещё более спокойной душой сказал: "Нафиг, не будем заботиться об истории, будем её резать, сокращать просто и прочее, и прочее". Аэ, я сейчас, наверное, скоду не смогу найти. Прямо хороший пример, потому что у меня здесь все довольно задачки довольно короткие. Как бы тут я скорее могу посоветовать перейти в в репозиторий и почитать Redmy, как это работает и прочее, и прочее. То есть сейчас я просто буду, наверное, долго искать а объяснение того, что было. А, ну, кстати, вот как видит переписку валидатор, да? А это она ему всё кладётся вообще в user prompt. И он показывается, что значит о вот путь агента он был такой, да, что у эгента системный промпт вот такой-то, да, то, что мы сейчас видим, а первый usеerпромптt был вот такой-то. Скинут это история просто переписки, да? А потом на следующий шаг сделал вот такой-то. Ээ, значит, вызвал такой-то инструмент. Шаг был выполнен, получился такой-то результат. Э, и вот дальше вот это коротенькие шажочки. То есть ты видел, а какие у нас пышные здесь ответы, да, и какие они короткие получаются в итоге вот здесь. То есть вот это у нас аа сейчас, ну да, вот это у нас по сути как бы запрос-ответ. Всё. Не только не не только запрос, как здесь, да, а ещё и ответ на него от системы, собственно, который пришёл. Вот только так сейчас могу показать, кому интересно и глубже именно логика, как она режется. Ну, welcome в репозиторить. По сути, очень много стрингов всяких там правил. Ну, то есть, что мы это поле берём, к нему какую-нибудь фразочку добавляем, это мы не берём, в общем, и вот это в итоге делаем. Так."

"Угу. Интересно. А можно, пожалуйста, пока отключить тоже шеринг? Я сейчас попробую на себя А я могу реплей сделать. Сейчас я просто Да, просто как попытка, может быть, мы сейчас одну секундочку, может быть, мы се Если ты хочешь попытаться это так спросить, я не думаю, там это довольно нетривиальная штука."

"Нетривиальная сейчас ходу могу показать. Есть пример того, как урезается контекст на разных шагах агента. Да, вот я вот так вот спрашиваю, насколько он как бы то вообще не то нам сейчас подскажет, да? Оптимизация контекста выполнения. У тебя замена плана даже, да, имеет место, да?"

"А тут вот это одна из сложных вещей, а что мы, например, а на каждом текущем шаге AI агента мы показываем ему там определённое поле целиком из прошлого шага, но из других прошлых шагов мы это поле не показываем. То есть только только последнее и и оно как бы скользящим окном получается, что на каждом шайге он видит только последнее, самое крайнее, самое ближайшее вот это вот поле, но все ранее не видят. То есть это у нас один из примеров, где-то там сложная логика условная."

"Ну-каная история прямо разошёлся на визуализации. Ещё какая-то у тебя временная там история, да, есть. Ну, по сути, да, дадада. Это это которая как бы валидатор его забраковал, да, и эта ветка истории, она обрезается. То, что я говорил, что его неудачная попытка, она не хранится в контексте."

"Слушай, ну у тебя довольно, несмотря на то, что это как бы соревнование, да, у тебя достаточно сложное всё-таки система-то по итогу получилась с Всё направлено на на упрощение контекста. Дада. Да, контекст-менеджмент. Да, это точно. То есть он вот эту штуку подрезал вот и когда есть успе Ну это он нам про то, что собственно валидато. Ну правильно, да, валидатор ему сказал этот попытку. Угу. Проверка approved. Да, хорошо. А так merge ошибочная попытка полностью игнорируется. Всё правильно. А вторая Ну да, тут ээ схема сложная, но при этом она не передаёт всего, что там происходит. Она больше с акцентом на то, как валидатор работает. на на то на тот факт, что информация о валидаторе она аэ уходит и не хранится так же как и неудачных попытках я говорю там просто более тонкие штуки и Угу у ну тут что-то более справедливое удаляем старый remaining work, собственно, да, вот это вот проскользящее окно. Добавляем новый план. А делать задачу. М."

"Ну, в общем, да, это это, я говорю, я я советую просто уже идти и не знаю, да, это такая тонкость, да, очень интересно. Слушай, ну в этом плане хорошо, что мы с тобой так вроде бы и достаточно подробно, а вроде бы ещё есть какие-то, да, нюансы совсем такие глубокие. Мы, так сказать, оставили возможность нашим там слушателям, нашим зрителям э домашней работы как бы, да, доисследовать, досмотреть. Я даже больше того, кстати, у нас тут я могу просто поширить вот этот чатик с твоим репозиторием. Вот. И можно просто тоже отдать отдать людям ссылку и любой сможет задавать вопрос."

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

"Слушай, ну да, если у тебя есть ещё 10 минут, У меня есть время, да?"

"Угу. Давай сейчас одну шифличку. Ну да, ты запускай пока. Да, я сейчас включу трансляцию, переключусь обратно. Бенчмарк. Так, о'кей. Я подготовил. Да, да, да, да, да, А тут гораздо интереснее. Собственно, тут немножко похоже на то, как это было у Опуса. Сейчас его текущий Skills. Значит, у нас есть центральная ветка, называется она оркестратор. Мы можем назвать её условным менеджером в компании, да?"

"А и у оркестраторова нет. У оркестратора нет ни одного сырого из ДК Тула. Ни одного нету. Аа у оркестратора есть только псевдотулы. Каждый тул - это условно просто агент. А-э, аналогия, что это менеджер, да, у которого есть а-а доступ к работникам, да, что есть работник, который занимается маркетинговыми исследованиями, есть работник, который, я не знаю, там собирает дизайн-сайты, есть там работник, который делает что-то ещё, да? Аэ, и оркестратору центрального менеджерам, ему совершенно неважно, как это делается под капотом, какие конкретные инструменты использует там маркетинговый исследователь. Аа ему важно то, что он даёт задачку, э, найди, например, продукт такой-то, э, этот там, ну, не будем сейчас вдаваться в детали, нюансы, как это там всё работает. Вот. И продукт Explorer - это работник, как раз-таки, да? А он делает делает вызовы уже сырых СДК инструментов. У него есть доступ к субсету, только к некоторым СДК инструментам. А, и у него в промпте описаны только они. Про другие он даже не знает. Соответственно, это его специализация. Он сделал задачку, и он обратно как бы там были какие-то шаги, какие-то там возвраты от инструмента, что-то там может какие-нибудь ошибки летели, что-то ещё. Он делал там доппотки. Но когда он сделал задачку, он наверх обратно менеджеру возвращает только ответный запрос, который был у менеджера. Менеджер задаёт запрос простым натуральным языком. Найди мне, пожалуйста, ско вот такого вот вот такой штуки. Да, он там делает под капотом какой-то вызов из ДК инструмента, а ему там, к слову, возвращается, а сейчас не будем про это говорить, а ему возвращается там список из пятидесяти каких-то товаров. Он такой: "О, о'кей, вот то, что у меня попросили, а вот возвращаю, что продукт найден. Вот он такой-то, да, SQ DF препремиум, тыры-пыр. А всё, оркестратор получил SQ, он такой: "О'кей, у меня дальше есть работник вот такой-то". А и по общему плану нужно его вызвать и попросить его о чём-то там о чём-то, в общем, связанном вот конкретно с этим шагом. А он зовёт второго своего работника, и он даёт ему задачу: "Смотри, вот, значит, что мне там предыдущий работник принёс. Вот это вот есть скошка вот такая, да? Ты её возьми, пожалуйста, и там проверь. А вот тут он проверяет разные купоны, какие выгоднее, в общем, какие больше скидку дают. Он говорит: "Ты, значит, вот найди, какая скидка наилучшая, ээ, и там её примени и в общем, всё, доложи мне, что всё, всё, короче, доложи мне о результате. У него, у баскетбилдера, у него есть какой-то контекст внутри внутри. Здесь в переписке он передаётся между вот этими шагами, да? А, но оркестратор, вот, например, от того, что происходило здесь, он не видит. Он видит только репорт последнего шага, что я всё сделал. Я вот вот отчёт о моей работе. Я вот эти купоны попробовал. Вот этот купон, он самую большую скидку даёт, как бы всё, я сделали. Оркестратор такой: "О'кей, всё, я вызываю следующего работника, даёт ему следующую задачу и так далее". То есть у нас здесь как раз-таки есть работники со своими сырыми инструментами от СДК. Они поделены как-то между работниками. есть какие-то ответственности у работников, как бы они разделены. Аэ, и работник думает только про свою задачку. У него есть только системный промот про свою задачку, у него есть только нужные инструменты. А более того, он не засоряет мозги главному менеджеру, оркестратору, как он получил результат, который он получил. Он либо говорит, что я сделал, либо говорит: "У меня не получилось". Поэтому всё, менеджер думает, как дальше поступать. Вот здесь у нас как раз организация похожая, знаешь, на на компанию условную."

"Угу. Да-да. Да. Слушай, очень круто, что даже, мне кажется, не 10- 5 минут ты уложился, а очень круто, что мы сейчас вот это проговорили. А потому что это тоже, по мне такой очень неочевидный инсайт. Это же как раз про субагентов история. То есть у тебя фактически такая получилась мультиагентная система, то есть у тебя есть некий действительно вот этот оркестратор как действительно как менеджер и у него есть свои сотрудники, которые тоже в свою очередь являются агентами. И это очень похоже на концепцию субагентов из из клодкода того же самого. Ну мне вот мне с ним нравится сравнивать, да, потому что такой популярный кодовый агент. И там же тоже идея в том, чтобы как раз контекст экономить. Там же, когда вы ставите задачу какую-нибудь, а вы как бы слушатели, да, задачу какую-нибудь по по по по по коду там что-то какую-нибудь фищу реализовать. А сейчас и что CLДКД, кстати, что GMI, по-моему, тоже перешёл на этот этап. Они сейчас там отправляют своих субагентов собирать контекст вот прежде, чем прежде чем приступать к задаче. Вот это очень похоже. Классный инсайт, да, Илья, спасибо, что ты это нам показал. Но только вот баскетбилдеры единственное, я не очень понял, это скорее не баскетбилдер, это скорее какой-то, а-э, что-то про применение купонов, да? не виден."

"А, да. Значит, э он проверя, да, он может проверить несколько купонов и потом как бы собрать корзину, применив нужный купон. Но там, на самом деле, просто у него была сначала одна должность. Я там немножко их, э, там менял местами что-то. И был другой отдельный, который купоны смотрел. И в общем, я его уволил и дал его ответственности баскетбилдеру, потому что так было проще, как бы, может, у него имени совсем отражающую действительность. Да. Да. А у, кстати, у оркестратора валидатор, он зародился ещё здесь, на этом на первом разогревочном бенчмарке. Валидатор тоже над менеджером, да? Из-за плеча подсматривает и такой: "А ты правильного ли работника сейчас вызываешь? А ты ему правильную ли задачку э возвращаешь? А ты подумай: "А может быть, а может быть другую?" Вот. Так что такая история."

"Угу. Угу. Ну да, я просто пытаюсь понять, в реальной жизни с кем можно сравнить этого валидатора. Такой контролёр, да, да, То, что то, что он сам свою свою задачку, знаешь, ему сказали: "Перепроверь свою каждую задачку. Вот ты сначала, да, прежде чем позвать кого-то, отдельно сядь и проверь 5 минут посмотре написал"."

"Угу, угу, угу. Да, очень круто. Спасибо большое, Илья. Давай быстрый вопрос тебе, собственно, про разницу хотел спросить. Вот. Когда мы делаем агентов, собственно, вот есть у нас возможность сбирать там какую-то посорсную модельку, ту же самую GPT SS120, и есть возможность сбирать там какой-нибудь там сонеet или OPС. Мы уже в какой-то степени мы уже проговорили разницу, да, в том, что, собственно, модель побольше будет просто повнимательнее к контексту, да, и условно может быть там вот эти этапы там валидации, да, какие-то вот пляски с бубном, их будет просто поменьше, наверное, да, на пропоритарной, на более большой, серьёзной модели. Да, да, можно, можно больше всякого кидать в контекст и как бы надеяться на то, что она разберётся. Моделька она разберётся в целом. Тебе было больше кучей. Угу."

"Ну да, но тебе было интереснее всё-таки ты как бы не ищешь лёгких путей, да? Тебе было интереснее взять открытую модельку и её настроить. Я очень давно хотел поработать с GPT OS, да, и меня просто как бы меня зажгла идея, что можно же оченьочень быстрые делать запросы. Как бы проблема в том, что все современные модели, они сейчас почти все как бы ризанят. Ну и GPT тоже ризат, но на серебрстве они это делают очень быстро. А там GPT какой-нибудь 5, э, там даже мини, он всё равно очень медленно. Я запу я пробовал на пять мини запускаться. Он был глупее из-за того, что ему пришлось уменьшать бюджет рининга, да, чтобы он быстрее отвечал и медленнее. Всё равно даже с этим медленнее."

"Ну да, ну это мини. Ну хорошо. А я правильно понимаю, что на церебрость ты запускал с максимальным reasoning effort?"

"Да. Ха."

"А слушай, нет, почти везде медиум работает. Максимальный только на этапе на этапе, когда он единоразовый из Википедии правила извлекает, потому что это делается только один раз. вообще вне задач, как бы это надо сделать максимально качественно."

"Угу, угу, угу. О'кей. Как-то это влияло вот медиум или хайрининг на результаты? Я так понимаю, что не не существенно, да?"

"Ну, несущественно. Не существенно."

"Угу. Класс. Ле, спасибо тебе большое. У меня какие-то вырождались вопросы по ходу движения. Тут было настолько интересно, что я не успевал просто их даже записывать. Вот. Если, да, если что-то ещё будет, мы тогда доспросим. А-э, я поделюсь нашей записью в Telegram-канале, на Ютбе тоже мы выложим. И дальше, если у людей вопросики какие-то будут, я надеюсь, у тебя тоже будет возможность чуть-чуть времени, может быть, выделить, людям поотвечать."

"Вот. Поэтому спасибо ещё раз за твоё время. Мне кажется, мы очень классную сделали встречу. В принципе, ты вот думаешь, да, над тем, чтобы статью взять, мне кажется, может даже взять эту встречу, про прогнать её через какой-нибудь GMI Pro, а 3 Pro и, может быть, какой-то даже драфт для своей статьи из этого набросать."

"Я предыдущую писал, кажется, часов 40. Я не готов к этим просто не готов. Очень много работы сейчас."

"Конечно, конечно, конечно. Всё, спасибо огромное, Илья, тогда хорошего тебе года. Э, может быть, ещё встретимся, ещё пообщаемся. Было, ну вот, ну, реально очень интересно. То есть ты прямо классно, классно всё рассказываешь. Вот поэтому спасибо, что позвал."

"Да, всем пока."

"Так, давайка. M."