Transcription
Итак, всем привет. С вами Артём Патфёров. Сегодня мы продолжаем готовиться к экзамену от Anнтропик на сертифицированного эрхитектора. Это сейчас самый сложный экзамен от антропиков. Он является такой квитесценцией того, что они, а, придумали за последние 3-4 года. Мне этот экзамен очень нравится. Он очень конкретный, он очень полезный. Даже те вопросы, которые здесь задаются, они заставляют по-иному мыслить и подходить к тому, а как правильно должны разрабатываться агентские системы, либо как правильно нужно работать с клаудкодом. Каждый раз, отвечая на эти вопросы, я узнаю для себя чуть-чуть нового. Вот.
Э-э, сегодня мы начинаем экзамен с рандомного кейса. Напоминаю, как это работает. Есть четыре рандомных кейса в сертификации, которые нам попадутся. Сертификация проходится, устанавливается специальное ПО, которое следит за, э, тем, чтобы вы смотрели на экран, за тем, чтобы у вас ничего стороннего не было открыто. Э всего сценариев есть шесть. Мы будем все их постепенно проходить. Сейчас посмотрим, какой нам выпадет сценарий. Надеюсь, что не прошлый, иначе придётся перезагружать. Ага, да, это наш прошлый, поэтому просто переобновляем этот тестовый экзамен. Нажимаем начать. И видите, вот сейчас у нас сценарий многоагентная исследовательская система. Очень крутой сценарий. Я после того, как несколько раз прошёл, эткзамен, понял, что, э, в некоторых наших продуктах мы будем перестраивать агентские сетки, потому что у нас есть пару а исследовательских задач в рамках некоторых продуктов. И вот туда логика, которая раскрывается здесь, очень сильно подходит и становится понятно, какие ошибки базовые мы допускали.
Собственно, давайте начнём готовиться и прочитаем условия кейса, по которому нам будут задаваться все следующие 15 вопросов. Вы создаёте многоагентную исследовательскую систему с использованием SDK Clotген. Агент-координатор делегирует задачи специализированным сабагентом. Один осуществляет поиск в интернете, другой анализирует документы, третий обобщает результаты, а четвёртый генерирует отчёты. Система исследует темы и создаёт исчерпывающие отчёты со ссылками на источниками. Ну, собственно, по схожей логике работают все депрессёрчи, что у Perplexity, что у Openy, что у Antropic. Эти многоагентные исследовательские системы, они появились в начале прошлого, в начале 2025 года. И я помню, как сильно изменил мой подход к поиску информации появление этой фичи. И здесь нам предлагают поразмышлять, а как правильно такие многоагентные системы строить. Вопросы здесь будут связаны с архитектурой систем, с правильным распределением функций между агентами, с правильным распределением обязанностей внутри агентов и с проблемами, которые могут у нас возникнуть. А я советую и сам часто пользуюсь клодом при подготовке к экзаменам. То есть вот сейчас у нас есть этот кейс. Я перейду в клод. Вот у нас есть документ PDF, который прямо сейчас переводится с английского на русский. Я его в своём канале выложу, весь этот документ. И пока он переводится, давайте пойдём сюда. И попросим и визуализируй мне эту архитуру, чтобы я мог визуально понимать, как это работает. А мне очень нравится возможность сразу же создать понятную визуальную схему через нейронку, особенно через клода. Клод, в отличие от OpenI делает большой упор на артефакты и написание кода под какие-то простые ежедневные задачки. То есть одноразовый код для меня уже стал повседневностью. Я все презентации, работы с документами делаю через подход создания сайта в виде кода. Это просто удобнее, проще, вы быстрее получаете костяк, можно сделать попутно depressрчи. Этот документ HTMLный можно принести куда угодно, в любую нейронку, и он будет прекрасно понят, в отличие от тех же PDF. И я советую не отказывать себе в возможности иметь личного тютора и какие-то задачки решать вместе с неронками. Если ваша цель не получить готовый ответ и просто выдать его, а действительно понять тему, то личный тьютор становится огромным, огромным плюсом. Так вот, сейчас нам Лот размышляет. Оу, воувоу, какие-то у него длинные размышления. Ладно, пока он размышляет, давайте пойдём к первому вопросу. Вот тут просили, чтобы было видно все вопросы на экране, на английском до перевода комменты к прошлому видео, поэтому буду стараться придерживаться этого. И переводим на русский.
А в ходе тестирования вы заметили, что агенту синтеза, синтез - это финальный агент, который синтезирует результат, часто требуется проверять конкретные утверждения при объединении результатов. В настоящее время, когда требуется проверка, агент синтеза возвращает управление координатору, который вызывает агенты веб-поиска, а затем повторно выказывает синтез с результатами. Это добавляет два-три цикла обработки данных на каждую задачу и увеличивает задержку на 40%. Ваша оценка показывает, что 85% этих проверок представляют собой простые проверки фактов: дата, имена, статистика. В то время как 15% требует более глубокого исследования, какой наиболее эффективный подход позволит снизить накладные расходы, сохраняя при этом надёжность системы. А это довольно простой вопрос. Мы знаем, что у нас есть агент синтеза, который финально склеивает наш результат в один понятный классный отчёт. И мы видим при этом, что этот агент выполняет множество лишних задач. Причём, так как архитектура в этом кейсе у нас будет жёсткая, это архитектура Hub, где в центре архитектуры есть координатор, и действия между агентами происходят только через координатора. Это одно из базовых фундаментальных ограничений этой архитектуры. это повесить на координатора функцию управления, и он несёт ответственность за то, чтобы эти задачи правильно между агентами распределять. И конкретно в нашем вопросе происходит, что агент синтеза получает какую-то информацию, а понимает, что у него есть какие-то вопросы к фактам из того, что для него собрали другие агенты, подготовили. И для их проверки он отправляет всё время нашему координатору запросы. Тот идёт к агенту веб-поиска, тот проверяет факты и возвращает. И это очень долго. Давайте посмотрим, какие варианты и выберем э самый эффективный.
Пусть агент веб-поиска заблаговременно кэширует дополнительный контекст вокруг каждого источника на этапе первоначального исследования, предвидя, что может потребоваться агенту синтеза для проверки. Звучит как какой-то костыль, потому что нам нужно сделать целую систему какого-то кэширования, следить за тем, чтобы она правильно работала ещё и заблаговременно, ещё и для всех ситуаций. Нет, это точно неправильный ответ. Так решать вопрос с тем, чтобы агент просто проще проверял факты и меньше на этом этапе задерживался не поможет.
Предоставление агенту синтеза verify факт- инструмент с ограниченной областью действия для простых поисков, в то время как сложные проверки будут по-прежнему делегироваться агенту веб-поиска через координатор. А вот это мне нравится, потому что нам прямо пишут, что 85% этих проверок - это простые факты, и 85% проблем мы устраним, просто дав инструмент простой верификации факторов. Возможно, там будет, э-э, просто запрос в интернет на уровень подтверждения факта. Возможно, какой-то resеш через саба-агента. Но в любом случае для того, чтобы проверить простые факты, даты, имена или статистика, нам не нужно три вызова сабагентов. Нам нужен отдельный инструмент, который хорошо эту проблему будет решать. А сложные проверки у нас должны в рамках этой же архитектуры остаться, то есть передаваться координатору. А координатор уже должен решать, ээ, кто добудет эту информацию либо что в этой ситуации делаем. Поэтому пока что ставлю значочек Б. Мне нравится второй ответ.
Предоставьте агенту синтеза доступ ко всем инструментам веб-поиска, чтобы он мог напрямую обрабатывать любые запросы на проверку без обращений к ординатору. А, ну вот это неправильный подход, потому что мы агенту, который у нас должен отвечать только за то, чтобы качественно и хорошо выдать э результат, навешиваем функции другого агента и даём мы инструменты для совершенно других вещей. Тогда у нас повысятся риски, что мы не получим правильного результата и что у нас процентное соотношение качественных результатов сильно уменьшится. Почему это произойдёт? Потому что агент синтеза должен получать конкретную информацию, которая заложена в нашем workкflow, и проходить определённые этапы. А если мы ему дадим все инструменты поиска, то он на своём этапе синтеза может сходить, найти какую угодно информацию, которая вне нашего workflлоow, вне нашего поля контроля. И, скорее всего, у нас качество наших отчётов финансовых, финальных, исследовательских упадёт. Поэтому с вариант тоже нет.
Пусть агент синтеза соберёт все необходимые для проверки данные и вернёт их в виде пакета координатору в конце своего прохода, который затем отправит их все одновременно агенту веб-поиска. Но это тоже кривое, но решение. Оно не совсем неправильное для каких-то задач, наверное, ок скоупом отправить все правки и с ними проработать. Но мне кажется, что инструмент verify факт ещё проще, потому что он прямо в процессе своей работы простые факты, с которыми чаще всего проблема, сможет проверять. Причём это не будет полный набор поисковых инструментов, просто одна конкретная функция, которая именно этому агенту чаще всего и нужна. Давайте проверим. Правильно. Супер. Двигаемся дальше. И прежде чем двинемся, давайте посмотрим, что у нас тут. Плот сделал. У нас есть координатор агент, он выбирает сабагента. Единственное, что здесь неправильно указано, что именно неправильно указано, то, что финальный, а репорт у нас попадает информация только вот репорт врайта. То есть вот эти три стрелочки у нас неверно неверно отображены, потому что у нас идёт возможность у координатора вызывать разных агентов. Он получает задачи. Координатор декомпозирует, делегирует разных агентов. Они параллельно работают, потому что он каждому раздал задачи. И, ну, кстати, не параллельно, последовательно, потому что пока у нас не произошёл веб-поиск и анализ документов, нельзя сделать саморизацию, нельзя написать отчёт. Поэтому в целом здесь нам клод неверную схему написал. Ему можно будет сюда прикрепить документ из соседнего чата, где мы делаем, а, где мы делаем русскоязычную версию документа. И в этом документе есть детали по тому, как такая архитектура должна выглядеть. И поэтому мы позже этим займёмся.
Следующий вопрос. Так, вот на английском у нас всё видно. Тируем. Теперь переводим. В ходе исследования материалов сабагент веб-поиска запрашивает данные из трёх категорий источников, получая разные результаты. Академические базы данных выдают 15 релевантных статей, отраслевые отчёты, ноль результатов, а база данных патентов тайм-аут соединения. При разработке механизма распространение ошибок координатору, какой подход обеспечивает наилучшие решения по восстановлению? Вот смотрите, в гайдлайне экзамена прямо прописаны правила того, как лучше всего делегировать ошибки в разных архитектурах э систем агентов. И есть разные классы ошибок с разными ээ с разными нюансами. И для ошибок, которые у нас идут с тайм-аутами. Например, вот здесь у нас показано, что произошёл тайм-аут соединения. Мы можем внедрить а механизм повторного количества попыток для таких конкретных ошибок. Но самое главное правило вот в этом хаб архитектуре - это то, что решение, что делать с ошибками, кроме тех, где мы знаем, что мы можем просто попробовать пару раз ещё раз запросить, должен принимать именно координатор. И он же должен иметь достаточно информации для того, чтобы эти решения принимать. Поэтому нам нужно искать ответ, который будет нести в себе, что мы должны правильно собрать о ошибках и правильно их делегировать на координатор. Вот.
Разреша различайте ошибки доступа тайм-аут, требующий повторной попытки от допустимых пустых результатов, предоставляющих собой беспешные запросы. Да, нам нужно различать таймауты и успешный запрос, но без тела ответа - это ноль результатов. Это у агентов тоже по умолчанию в агентском цикле прописано.
Пусть сабагент повторяет попытки устранения временных сбоев внутри системы и сообщает только о постоянных ошибках. Вот. Вот это неправильно, потому что а сколько он должен будет повторять временные сбои? И мы же не всегда знаем, что это временные сбои. И если ему прописать в инструкции повторяй временные сбои, он может либо упасть в цикл и будет их долбить, долбить, долбить, а либо, наоборот, некорректно распознает ситуацию и сделает что-то, что нам не нужно. Ну, в общем, подход Б мне пока не очень нравится.
Объедините результаты в единый показатель успешности. Например, 67% ватысточников, подробные журналы будут доступны по запросу. Нет, если наш агент будет передавать координатору, что в целом мы на 67% успешны, это ничего ему не даст. Ему нужна конкретика, какие ошибки, для каких запросов не смог реализовать агент. И после этого у координатора в инструкциях должна быть логика, что делать при отказе тех или иных систем, какие дублирующие системы использовать и использовать ли вообще.
А сообщайте как о превышении, как о превышении времени ожидания, так и о результатах ноль, как о сбоях, требующих вмешательство координатора. Аа нет, скорее всего вариант А. Нам нужно различить ошибки тайм-аута, где требуется повторная попытка и там прописать сколько. Но ноль результатов - это допустимые и предоставляют собой успешные вызовы, мне кажется. А, да, верно. И давайте перечитаем, что у нас тут написано, чтобы глубже это понять. Это верно, поскольку тайм-аут, сбой доступа и ноль результатов, допустим, пустой результат - это семантически разные исходы, требующие разных ответных действий. Различение этих результатов позволяет координатору повторно обратиться к базе данных патентов, в которых произошёл тайм-аут, принимая при этом результаты пустого отраслевого отчёта как допустимый и информативный вывод. Ну, то есть, если мы ничего не нашли по какому-то запросу, это тоже о чём-то нам может сказать.
Следующий вопрос. На английском переводем поиск в интернете и анализ документов завершили свои задачи и передали результаты координатору. Какой следующий шаг будет наиболее целесообразным для получения интегрированного результата исследования? Поиск в интернете, анализ документов зарешили свои задачи, передали результаты координаты. Ну вот это опять-таки классическая логика, где в центре координатов и есть четыре сабагента. Причём вот мы с вами говорили, что вот эта схема неправильная. Ах тема неверная и загугли архитектуру агентов от под антропик и перестуй Sky. Давайте мы его, а, отправим искать новую информацию, пока обсудим этот вопрос. Что должен сделать агент-координатор? Ну, собственно, у него есть, а, агент для написания отчётов. Если все данные уже найдены и собраны, то он их должен передать агенту для написания отчётов и попросить написать отчёт, который изначально запрашивал пользователь.
Координатор объединяет исходные данные от обоих агентов и возвращает их в качестве окончательного результата. Нет, координатор не печатает финальный результат, не выдаёт его юзеру. Координатор отвечает за качество и за то, чтобы правильно распределить задачи между нашими агентами. И лучше всего справиться с задачей, написать финальный отчёт. Это наш агент, отвечающий за синтез.
Агент анализа документов запрашивает результаты вебпоиска, объединяет их внутри системы. Нет, каждый агент напрямую отправляет свои результаты агенту, генерирующему отчёт, именуя координатора. Нет, вот это вот вопрос с подвохом, потому что агенты возвращают координатору, а координатор уже, получив от них результаты, должен принять решение, достаточно этой информации, недостаточно, дать ли какие-то дополнительные уточняющие вопросы. Это, грубо говоря, руководитель нашего отдела агентов, и ему необходимо, во-первых, знать всю важную, необходимую для принятия решения информацию, во-вторую, правильно передавать её и именуя координатора отправлять отчёты неверно в данной архитектуре, потому что координатор отвечает за качество всего отчёта и за полноту данных.
Координатор передаёт оба набора результатов специалисту по синтезу для единой интеграции. Ну, собственно, вот он наш правильный ответ, который, скорее всего, и будет верным. Да, верно, как мы и думали. Двигаемся дальше. Угу. Запускаем. На английском всё видно. Всё видно. На русском перевод.
Вспомогательный агент webпоиска выдаёт ошибку тайм-аута при поиске информации по сложной теме. Вам необходимо разработать механизм передачи информации об этой ошибке обратно координационному агенту. Какой подход к к распространению ошибок наилучшим образом обеспечивает интеллектуальное восстановление? Смотрите, у нас есть вспомогательный агент веб-поиска, и у него есть тайм-аут при поиске сложной информации. По идее, для того, ну, ошибка тайм-аута - это когда запрос длится слишком долго. Тут прямо прописано, что это сложная тема, поэтому, э, долгий ответ по сложным темам может быть связан со сложностью и объёмом темы. Поэтому нам нужно, чтобы на такие тайм-ауты сам агент мог делать ограниченное количество попыток.
По идее, а внедрите в сабагент логику автоматического повтора попыток с экспоненциональной задержкой, возвращая общий статус, поиск недоступен только после того, как все попытки повтора будут исчерпаны. Вообще звучит логично.
А передайте исключение, связанное с превышением времени ожидания непосредственно обработчику верхнего уровня, который завершит весь процесс исследования. Из-за того, что у нас, а, сложная тема, долго обрабатывалась по тайм-ауту, завершать весь процесс исследования звучит как крайне неправильное решение.
возвращает координатору структурированный контекст ошибки, включающий тип сбоя, попытку выполнения запроса, любые частичные результаты и потенциальные альтернативные подходы. Вообще, э, в Гайдлайне написано, что за обработку ошибок отвечает именно координатор. Но тут вот для меня сейчас вопрос, это что делать с вот такими ошибками нижнего уровня, когда мы предполагаем, что тайм-аут - это не ошибка, с которой нужно бежать к координатору. Мм, мне кажется, что вариант С возвращает координатору структурированный контекст ошибки, включающий тип сбоя, попытку выполнения запроса. любые частичные результаты и потенциальные альтернативные выходы более правильны, потому что мы тогда в одном месте у координатора можем прописывать логику того, а как с этими ошибками работать. И и поиск недоступен. Это тоже не зона ответственности сабагента принимать решение, что делать с теми или иными инструментами. Это именно координатор должен придумать, как решить эту проблему. И мне кажется, что тут нужно возвращать координатору. Да, верно. Давайте поподробнее прочитаем. Возвращение структурированного контекста ошибки, включающего тип сбоя, попытку выполнения запроса, частичные результаты и альтернативные подходы, предоставляет координатору всю необходимую информацию для принятия обоснованных решений о восстановлении, таких как повторная попытка с изменённым запросом или продолжение работы с частичным результатами. Это наилучший подход, поскольку он сохраняет максимальный контекст для принятия взвешенных решений на уровне координации. Ну, собственно, мы всё правильно сделали, круто двигаемся.
А вот вопрос. Вот, давайте вот вопрос. Вот на английском видны все варианты вопросов. Я, кстати, скину, у меня есть материалы по почти всем кейсам. вопросы ответы от того, что я проходил экзамен, и я у себя в канале выложу весь перечень, чтобы вы могли готовиться сами к этому тесту, так же как это делаю я. Угу.
Журналы производственной активности выявляют устойчивую закономерность. Запросы на анализ загруженного мною квартального отчёта в 45% случаев направляются к агенту веб-поиска вместо агента анализа документов. Изучив определение инструментов, вы обнаруживаете, что у агента веб-поиска есть инструмент analy content, описанный как анализирует контент и извлекает ключевую информацию. В то время как у агента анализа документов есть инструмент аналай документ, описанный как анализирует документы и извлекает ключевую информацию. Как следует устранить это неправильное направление запросов? Мне кажется, что тут очевидно, нам нужно, а один из инструментов, причём так у нас неверно направляются к агенту веб-поиска, вот у агента веб-поиска нужно изменить название, описание документа.
Добавьте классификатор предварительной маршрутизации, который определяет, обращается ли пользователь к загруженным файлом или веб-контенту, прежде чем координатор примет решение о делегировании. А нифига, никакой классификатор предварительной маршрутизации нам здесь не нужен. Тот же сам агент является тем самым классификатором, и ему нужны просто более чёткие конкретные инструкции.
расширить описание инструмента анализа документов, включив в него примеры использования, такие как использовать для загруженных PDF-файлов, документов, Word, электронных таблиц, оставив при этом инструмент веб-поиска без изменений. Неверный ответ, потому что нам прямо говорят, что отдают агенту поиска, потому что описание его документа в целом подходит под цели, которые ставит перед ним агент координатора. И проблема не в том, чтобы мы изменили и дополнили примерами, а в том, что в целом нужно для агента координатора разделить логику инструментов этих двух сабагентов, чтобы он лучше понимал, когда использовать первого, а когда второго.
Переименуйте инструмент веб-поиска Extract Web results и обновите его описанию, когда он обрабатывает, возвращает информацию, полученную в результате веб-поиска из URL-адресов. Вот мне кажется, что это правильный ответ.
Добавьте в подсказку координатора несколько простых примеров, демонстрирующих правильную маршрутизацию. Но это неверно, потому что нам прямо говорят, что вот у вас есть два очень похожих инструмента у двух разных агентов, и часто вызывается ненужность. Значит, нам нужно изменить описание одного из них, сделать более конкретным, описав, для чего и когда он лучше подходит. Всё верно. Двигаемся дальше.
Опять английский язык. Все четыре вопроса видно. Теперь перевожу. Итак, после запуска системы по теме влияния и на креативные индустрии, вы замечаете, что каждый сабагент успешно завершает работу. Агент веб-поиска находит релевантные статьи. Агент анализа документов правильно резюмирует работы, а агент синтеза выдаёт связанный результат. Однако итоговые отчёты охватывают только изобразительное искусство, полностью исключая музыку, литературу, кинопроизводство. Изучив журналы координатора, вы видите, что он разделил тему на три подзадачи: и в создании цифрового искусства, и в графическом дизайне, и и в фотографии. Какова наиболее вероятная причина? Ну, собственно, причина 100% вот такой вот проблемы где-то в неправильных промптах и в том, что мы слишком сфокусировали его на конкретных доменах либо координатора. Ну, по идее, да, в системных проблемах координатора нужно искать проблемы.
Поисковые запросы вебагента недостаточно полны и нуждаются в расширении для охвата большего числа секторов креативной индустрии. Ну, ему же задачи нарезает э-э координатор, поэтому поисковые запросы он делает такие, какие ему нарежут. Поэтому, скорее всего, проблема не в веб-поиске.
В синтетическом агенте отсутствуют инструкции. Ну, дальше уже можно не читать, потому что о синтетическом агенте у нас правильно, у нас написано, что он выдаёт связанный результат. Ну, давайте дочитаем. отсутствуют инструкции по выявлению пробелов в похвате результатов, полученных от других агентства? Да нет, наверное, инструкции по выявлению пробелов - это неправильный способ решения данного вопроса.
Декомпозиция задач выполняется агентом-координаторов слишком узко, что приводит к назначению субагентов, не охватывающему все релевантные области темы. Ну вот это похоже на правду. И агент анализа документов отфильтровые источник. Нет, декомпозиция задач, выполняемая агентом координатором, слишком узкая. У него нужно искать проблемы с тем, почему у нас так узко выбирается тема исследования. Да, верно, потому что, повторюсь, и агент-исследователь, он не сам выбирает тему для исследования, он получает ТЗ от координатора. И какое з, такой и результат, собственно. Двигаемся дальше.
Опять на английском всё видно. Переводим на русский. Специалист по анализу документов обнаруживает, что два заслуживающих доверия источника содержат прямо противоречащие друг другу статистические данные по ключевому показателю. В одном правительственном отчёте говорится о росте на 40%. А в отраслевом анализе, о росте на 12%. Оба источника кажутся достоверными. Это расхождение может существенно повлиять на выводы исследования, как специалисту по анализу документов наиболее эффективно справиться с этой ситуацией. Ну, собственно, по идее, он должен рассказать об этом агенту-координатору и оставить ему на откуп, а какие конкретно данные стоит взять. Потому что агент-координатор с высоты своей задачи сможет увидеть, во-первых, больше данных от других агентов. Он знает больше о задаче пользователя, и он, скорее всего, сможет более правильное решение принять. А как это синтезировать для агента синтеза эту информацию?
Применитевристические методы оценки достоверности источника. Чтобы выбрать наиболее вероятно точную цифру, завершите анализ, используя это значение, и добавьте сноску, указывающую на расхождение. Пред. Никакие вристические методы нам не помогут. И придумывание какого-то числа, которое, э, вероятностно оценит нам, э, более точное значение, не поможет. Скорее всего, нужно делегировать координатор.
Включите оба рисунка в результата анализа, не помечая их как противоречащие друг другу, чтобы специалист по синтезу мог определить, какой из них использовать, исходя из более широкого контекста исследования. Вот это неправильный подход, потому что просто положить два результата и не пометить, что они противоречат друг другу, это будет не прикольно, потому что наш агент может вот вот именно из-за таких ошибок чаще всего возникают галлюцинации у нейронок на выходе, когда есть два противоречащих друг другу источника и нет понятной логики. А как эти разночтения мы должны интерпретировать? И вот это 100пудов неправильный ответ, который только запутает больше нашего агента.
Завершите анализ документа, включив в него оба рисунка, чётко укажите источник конфликта и позвольте координатору решить, как его согласовать, прежде чем переходить к синтезу. Вот это всё верно. Отнеси руководителю, он посмотрит и разберётся. А при этом чётко указать, в чём именно проблематика.
Прекратите анализ и немедленно передайте информатору, координатору, попросив его определить, какой источник является авторитетным, прежде чем агент продолжит обработку оставшихся документов. Это неверно, потому что мы посреди работы должны остановить нашего агента, передать недостаточную информацию координатору и ждать, что он сейчас нам должен на основе ограниченной инфы выдать какой-то результат. А мне кажется, что нужно просто все вот эти разночтения в финальном отчёте показать, и тогда агент сможет правильно их интегрировать в ТЗ для агента синтез. Вариант С. Проверяем. Да. Correct. Верно. Переводим. Двигаемся дальше. У нас восьмой вопрос. Переводим.
Вспомогательный агент анализа документов часто сталкивается с ошибками при обработке PDF-файлов. Некоторые содержат повреждённые разделы, вызывающие исключения при синтактическом анализе. Другие защищены пароли, а иногда библиотека анализа выдаёт ошибку по истечении времени ожидания при обработке больших файлов. опять скорее всего на эт распределение ошибок вопрос. В настоящее время любое исключение немедленно завершает работу вспомогательного агента и возвращает ошибку координатору, который должен решить, следует ли повторить попытку пропустить документ или завершить всю исследовательскую задачу с ошибкой. Это приводит к чрезмерному участию координатора в рутинной обработке ошибок. Какое наиболее эффективное архитектурное решение? Так, вспомогательные анализы, агент анализа документов. Вот у нас есть агент, который получает в себе на вход несколько разных документов, PDF-файлы, ээ, причём с разными, возможно, проблемами. Никто не проверяет, там есть на них пароль, нет, э, как они с помощью OCR модулей обрабатываются, с помощью каких библиотек читать, получает большое количество возможного мусора и сталкивается с проблемами. И сейчас он каждую проблему идёт э решать координатору. Наверное, нужно как-то классифицировать проблемы и для ряда проблем сделать возможные пути решения в рамках внутри одного сабагента. И логику ошибок выводить координатору только уже по тем кейсам, которые мы не можем охватить,
и если какие-то проблемы были, то их тоже в отчёте прописать. Настройтесь обгетаким образом, чтобы он всегда возвращал частичные результаты со статусом успеха.
Встраивая подробности об ошибке в метаданные, координатор рассматривает все ответы как успешные и фильтрует проблемные элементы во время синтеза. М, мне кажется, что скорее нет, чем да.
Поручите сабагенту реализовать локальное восстановление при кратковременных сбоях и передавать координатору только те ошибки, которые он не может устранить, включая предпринятые попытки и любые полученные частичные результаты. Вот это больше похоже на правду. То есть он может сам попробовать по-другому решить проблемы. Если не получилось, то только с теми вариантами, где у него не получилось решить, он будет возвращать координатору. А, ну, скорее всего, Б. Но посмотрим, что ещё есть за варианты.
Координатор должен проверять все документы перед отправкой сабагента, отклоняя документы, которые могут привести к сбоям, чтобы гарантировать, что сабагент получит только пригодные для обработки файла. Нет, потому что это никак нам не помогает. Нам легче нашего агента анализа документов донаучить решать самые частые проблемы. Он для этого и предназначен, чтобы работать с документами, устранять проблемы с документами, если вдруг они появились. И это его специализированная функция. А вот делегировать на координатора, чтобы он перед тем, как отдавать, проверял эти доки. Это вот размывание функций. Мне кажется, что это точно неправильный вариант.
Создайте выделенный агент обработки ошибок, который будет отслеживать все сбои сабагентов через общую очередь и принимать решение о восстановлении независим, отправляя команды повторные попытки непосредственно сабагентом. Отдельный сабагент для принятия решений, для того, чтобы восстанавливать файлы, не звучит как. А вот мне кажется, что это вариант Б. Этот агент учится локально работать с какими-то проблемами. Если ему удалось решить, то он даже про это не пишет, а в отчёт сразу данные. А если не удалось, то уже это возвращает координатору. Да, всё верно, это правильно. Двигаемся дальше. На английском всё видно. На русский. Ага.
Коллега предлагает, чтобы агент анализа документов отправлял свои результаты непосредственно агенту синтеза, минуя координатор. В чём основное преимущество использования координатора в качестве центрального узла для всей коммуникации между сабогертами? Ну, собственно, мы про это сегодня уже говорили. В архитектуре, где в центре есть координатор и у него несколько сабагентов, а лучше всего работает подход, где координатор копит у себя всю информацию, и он принимает решение о том, какие сабагенты за что должны отвечать. И делать прямую координацию информации между агентами, минуя координатора, это несёт в себе риски того, что ошибка выстрелит, связанная с теми данными, которые агенты сами между собой передали. И агент-координатор не будет об этом знать, а значит, не сможет принять правильное решение, как эту проблему устранять. Поэтому не надо так делать, как предлагает коллега. Действительно, подход через одного координатора и несколько агентов параллельных либо последовательных, которых он вызывает, это более качественный подход для более предсказуемого результата. Но это не для всех случаев. Тут ещё будут кейсы на последовательные архитектуры агентов. Там там никакой координатор особенно и не нужен.
Сабагенты работают с изолированной памятью, а прямая связь потребовала бы сложную реализацию, которую может выполнить только координатор. Нет, сабагенты могут обладать изолированным контекстом. Это вот как раз-таки fork параметр за это отвечает, что мы можем создать его в чистом контекстном окне, а можем прошлый контекст координатора передать сабагенту. Не из-за этого.
Координатор может наблюдать за всеми взаимодействиями, последовательно обрабатывать ошибки и решать, какую информацию должен получить каждый сабагент. Вот это правда, потому что координатор использует агентов как свои инструменты, и чтобы они между собой какие-то данные передавали, о которых он не знает, это плохая практика. Поэтому он должен наблюдать за всеми взаимодействиями и принимать решение, как правильно вызывать тех или иных агентов, как правильно между ними передавать информацию. Маршрутизация через координатор обеспечивает автоматическую логику повторных попыток, которая недоступна при прямых вызовах между операторами. Нет, это бред. Координатор объединяет несколько запросов от сабагентов в одну группу, уменьшая общее количество вызовов АПИ и общую задержку. Тоже неправда. Вариант Б. Верно. Едем дальше.
Так, десятый вопрос. При исследовании широкой темы вы замечаете, что поисковый агент и агент анализа документов изучают одни и те же подтемы, что приводит к значительному совпадению результатов. Использование токенов увеличилось почти вдвое. При этом не произошло пропорционального увеличения широты или глубины охвата исследований. Как наиболее эффективно решить эту проблему? Мм, то есть у нас есть какая-то широкая тема, типа маркетинг, разработка. И у нас есть поисковый агент, агент анализа документов. Поисковый агент ищет в интернете, а агент анализа документов анализирует какие-то попадающие к нему документы. И в большинстве случаев написано, что они изучают одни и те же подтемы. То есть и тот обрабатывает, анализирует найденные статьи по этим темам в интернете. Точно такие же агент анализа документов. Ну, возможно, здесь стоит внедрить какую-то последовательную логику работы агентов. Ну, давайте почитаем ответы. и поразмышляем.
Перейдите к последовательному выполнению, при котором анализ документов запускается только после завершение веб-поиска, используя результаты веб-поиска в качестве контекста по избежании дублирования. Ну, мне кажется, не самый плохой вариант, потому что тогда у нас агент анализа сможет видеть уже охваченные темы и будет подбирать, а, документы для анализа на более слабые места. самые слабо проработанные и дублирование по идее уйдёт.
Позвольт обоим агентам завершить свою параллельную работу. Затем поручите координатору устранить дублирование совпадающих результатов, прежде чем передать их агенту синтеза. Двойная работа. У нас же токенов количество не уменьшится. И тот, и тот будут изучать дублированные результаты. Причём они их координатору отдают не постепенно, а в конце. как он, как они завершат свои результаты, как они узнают о том, что у них дублируются результаты. Нет, точно неправильно.
Внедрить механизм общего состояния, в котором агенты регистрируют свою текущую область внимания, позволяя другим агентам динамически избегать дублирования текущей работы. Наверно, наверное, когда-то это может сработать. каких-то очень частых кейсах, но уверен, что у этого механизма будет проблем и потенциальных рисков куда больше, чем просто сделать последовательно и передавать результаты э веб-поиска агенту по работе с документами.
Перед делегированием задач координатор должен чётко разделить исследовательское пространство, назначив каждому участнику отдельные подтемы или типы источников. А вот это тоже очень правильно звучит. Вот это тоже очень правильно звучит и даже более правильно, потому что координатор на старте видит, какие у него есть агенты, видит их в области поисков. То есть там же будет расписано, с какими документами может работать агент анализа. И, наверное, он может более чётко прописать темы, кто чем должен заниматься, как правильный руководитель, наверное. Да. Хотя, а тоже частично решает, по идее, может быть правильным ответом. Д. Правильно. Давайте прочитаем. Давайте прочитаем. Наиболее эффективным подходом является явное разделение исследовательского пространства координатором до начала делегирования задачи, поскольку это устраняет первопричину, нечёткие границы задач ещё до начала работы. Это позволяет сохранить преимущество параллельного выполнения, предотвращая дублирование усилий и неэффективную трату ресурса. Ну, собственно, да, у нас остаются параллельные агенты, мы меньше времени тратим, и при этом проблема наша решается. Едем дальше.
При проектировании системы вы предоставили агенту анализа документов доступ к универсальному инструменту, позволяющему загружать документы по URL-адресам. Журналы производственной среды показывают, что теперь этот агент часто путает страницы результатов поиска для проведения нерегламентированных веб-поисков. действия, которые должны выполняться через агент веб-поиска. Это приводит к непоследовательным результатам. Какое наиболее эффективное решение? То есть у нас есть а инструмент RL, который позволяет загружать документы по URL-адресам. И нам прямо пишут, что агент часто получает результаты поиска. И он через этот инструмент делает поиски в интернете. Ага. Но нам нужно просто поправить описание и область действия инструмента.
По идее, добавьте в подсказку агента анализ документов пояснение, что его следует использовать только для загрузки URL документов, а не для поиска. Я думаю, что это уже базово у них есть. И возможно, что нужно как-то более более корректно к этому подойти.
Удалите этот параметр HR из агента анализа документов и принаправьте всю всю загрузку адресов через координатор к агенту веб-поиска. Нет, неправильно. Зачем нам координатору допинструмент, чтобы он делал работу за другого агента? Нет.
Внедрите фильтрацию, которая блокирует. вызовы к известным доминам поисковых систем, разрешая при этом другие URL-дреса. Звучит как костыль, который полечит чуть-чуть, но при этом может выстрелить в других кейсах, которых мы сейчас не видим.
Замените Rail инструментом Load Document, который проверяет, соответстют ли URL адреса форматом документов. Вот это, мне кажется, правильно, потому что у нас сразу же логика у агента будет правильная, что это не просто мы любой запрос можем сделать, а конкретно загрузить документ. И в этом же документе мы будем проверять, что это документ. И если это не документ, то давать нормально читаемый ошибку для агента, что алло-алло, это инструмент для загрузки документов. Ну и он, я думаю, что даже по его смене названия будет правильно отрабатывать. Всё верно. Двигаемся дальше.
Двенадцатый вопрос. На английском видно. Переводим на русский. В ходе тестирования суммарный объём выходных данных от агента веб-поиска 85.000 токенов, включая содержимое страниц и агента анализа документов, 70.000 токенов, включая почки рассуждений, составил 155.000 токенов. Однако агент синтеза показывает оптимальные результаты при входных данных менее 50.000 токенов. Какое решение окажется наиболее эффективным? Аа то есть у нас агент веб-поиска огромный отчёт пишет и агент анализа документов огромный отчёт вместе с цепочками рассуждений, которые не особо нужны нам для финальной подготовки отчёта. Давайте посмотрим, какие есть варианты.
Добавьте промежуточный агент обобщения, который сжимает результаты перед передачей на этап синтеза. Мм, потенциально ок. Но тогда мы теряем контроль. А, а именно мы, самаризатор может потерять важные вещи, которые были прописаны прямо в инструкциях агентов. И управлять результатом и его объёмом через прослойку в виде саморизатора звучит как костыль, который нам выстрелит, потому что мы не знаем, а что мы точно хотим саморизировать. точнее, саморизатора. Инструкция саморизатора вот этого, она будет тоже слабым местом, в котором, а тем более, который ещё и к двум разным агентам относится. То есть у него в инструкции должны быть прописаны условия, что саморизировать, на чём фокусироваться, ещё и для разных задач. Нет, мне кажется, что гораздо проще будет эти инструкции вынести в самих агентов и у них скоординировать ожидаемые по объёму результаты.
Модифицировать вышестоящие агенты таким образом, чтобы они возвращали структурированные данные, ключевые факты, ссылки, оценки релевантности вместо многословного текста и рассуждений. Вот это очень качественный, правильный подход. То есть мы, э, понимаем структуру ответов каждого из агентов, из неё убираем кучу воды и рассуждений и фокусируемся на конкретных ээ вещах, которые нам нужны вот этого агента. И уменьшаем контекстное окно тем самым, которое они забивают своими токенами, и у себя оставляем в правильных местах точки контроля.
Пусть агент синтеза обрабатывает результаты в последовательных пакетах, подчёркивая рабочее состояние между вызовами. Пусть агент синтеза обрабатывает результаты в последовательных пакетах, поддерживая работ, это нам никак не помогает.
Сохраняйте полученные результаты в векторной базе данных и предоставьте агенту синтеза инструменты для поиска информации, которые он сможет использовать в своей работе. Тоже много нюансов. Э, во-первых, векторные базы данных имеют довольно высокую степень потери ценной информации. Во-вторых, это обходной путь, мм, который не выдаст нам нужных результатов. То есть вариант Б, где мы просто от самих агентов будем более конкретно требовать результаты, он гораздо лучше подходит, чем какая-то векторная данная, где будет много воды, которая нам не особо нужна. Так что нет, вариант Б. Верно. Следующий вопрос.
Давайте, уже чуть-чуть осталось, три вопроса, и на этом видос будет заканчиваться. Вспомогательный агент анализа документов сталкивается с повреждённым PDF-файлом, который он не может обработать. При разработке системы обработки ошибок. Какой наиболее эффективный способ справиться с этой ошибкой? Так, наш вспомогательный агент получает повреждённый PDF-файл. Ну, наверное, он должен передать координатору со всеми деталями этой ошибки.
Чтобы избежать прерывания рабочего процесса, незаметно пропустите повреждённый документ и продолжите обработку других файлов. Нет, 100% - это максимально неверный результат. Незаметно пропустить повреждённый документ звучит как мина замедленного действия. И наш агент имеет возможность делать дичь, чего мы, конечно же, не хотим.
Верните сообщение об ошибке вместо с контекстом агенту координатора, чтобы он мог решить, как действовать дальше. Звучит адекватно. У нас за ошибки, которые мы не можем сразу же повторить, потому что понимаем, что проблема на нашей стороне, как, например, тайт, должны передавать агенту-координатору. Из-за решения по решению ошибок должен отвечать именно он.
Перед сообщением о сбоя автоматически повторить анализ документа три раза с экспоненциальной задержкой. Нет, тоже нам это не сильно поможет. Вызвать исключение, которое прорвёт весь процесс исследования. Также дичь полная. Да. Да. Мы передаём агенту координатору, и он уже помогает разобраться в этой ситуации, решить, э, что нам нужно делать в этой ситуации.
Вопрос четырнадцатый из пятнадцати. Мониторинг процесса синтеза выявляет непостоянное качество результатов, когда агрегированные результаты в сумме составляют около 75.000 токенов. Агент синтеза надёжно ссылается на информацию из первых 15.000 токенов заголовки, фрагменты векпоиска и последних 10.000 токенов, но часто опускает важные выводы, которые появляются в средних 50.000х токенов, даже если эти выводы напрямую касадуются исследовательского вопроса. Как следует реструктурировать агрегированные входные данные? Давайте мы тут на английский переведём. Вот оно. И опять на русский. Что ж, есть такая проблема у современных нейронов, что они гораздо лучше фокусируются на начальных данных, которые у них в начале контекстного окна, и на тех данных, которые в конце контекстного окна. Срединные данные, они немножко упускаются из внимания. Этим можно управлять, если правильно более более подверженную вниманию агента область прописать инструкции либо контекст того, что находится в середине. Поэтому, по-хорошему, нам бы в начало запроса вставить что-то типа оглавление по разделам, которые есть в середине, и прописать, какие темы там есть более раскрытые, и реализовать для него более удобный инструмент поиска по заголовкам.
Возможно, перед агрегацией суммируйте все выходные данные сабагентов до общего количества менее 20.000 токенов, обеспечивая, чтобы контент оставался в пределах диапазона надёжной обработки модели. Но тут, повторюсь, самаризация теряет информацию. Она не может её не терять. Это сжатие и какие-то детали выпадают. И вот из 75.000 токенов -э сжать до 20.000 не получится, не потеряв какие-то важные вещи. Поэтому мне кажется, что вот этот вариант нам точно не подходит.
Поэтапно передавать результаты работы сабагента, агенту синтеза, сначала обрабатывая результаты веб-поиска до полного завершения, а затем вводя результаты анализа документов. Неверно тоже, потому что у нас агент координатор берёт информацию от обоих агентов. У них у обоих своя специализация, и при правильном workкфлоу наш агент синтеза должен получить и изучение интернет запросов, и изучение документов. Тогда он сможет правильно синтезировать информацию со своими внутренними инструкциями.
В начале сводного отчёта разместите краткое изложение основных результатов, а подробные результаты организуйте с помощью отдельных заголовков разделов для удобства навигации. Ну, собственно, то, о чём мы и говорили. Если мы из вот этой немножко менее качественной срединной области контекстного окна, вынесем контекст важный в шапку, либо наоборот э в нижние ээ отделы контекстного окна, то агент, а, прочитав их, будет гораздо более внимательнее просматривать середину и может в любой момент сделать поиск по заголовку и добавить себе в контекст какой-то э раздел конкретный и проработать с ним.
И четвёртый ответ. Внедрите ротацию, при которой результаты каждого из субагентов будут отображаться первыми в разных исследовательских задачах, обеспечивая равное приоритетное положение обоих источников с течением времени. Но это 100% нет, потому что вот эта ротация, она будет кем делаться, на основании чего? Почему те или иные результаты будут перемешиваться, как это исправит нашу проблему того, что у нас в середине контекста пропадает важная информация, естественно, не описана. Поэтому вариант С мы пишем оглавление, делаем хорошие блоки контекста нашими агентами, и тогда наш агент синтеза может с этой проблемой справиться. Да, давайте прочитаем здесь ответ. Размещение краткого обзора основных результатов в начале текста использует эффект первенства, обеспечивая размещение важной информации в наиболее заметном месте. Добавление явных заголовков разделов по всему агрегированному входному материалу помогает модели ориентироваться, обращать внимание на контент в середине раздела, напрямую смягчая феномен потери информации в середине. Всё верно.
И наш последний на сегодня вопрос. Вот он на английском. Вот так вот видны все вопросы. Давайте я его перевожу и будем на сегодня закругляться. Вспомогательный агент веб-поиска выдаёт результаты только по трём из пяти запрошенных категорий источников. Поиск на сайтах конкурентов и в отраслевых отчётах прошёл успешно, но поиск в новостных архивах и лентах социальных сетей завершился с ошибкой. Вспомогательный агент анализа документов обработал все предоставленные документы. Теперь вспомогательный агент синтеза должен подготовить сводку результатов на основе этих данных разного качества. Какова наиболее эффективная стратегия распространения ошибок? Ну, как обычно, у нас всё должен решить наш координатор, и мы, по-хорошему, должны будем на него делегировать принятие решения.
Структурируйте результаты синтеза, используя аннотации, указывающие, какие выводы хорошо подтверждены, а какие имеют пробелы из-за отсутствие источников. А это у нас агент синтеза делает. Ну, в целом, наверное, ок. Э, но давайте посмотрим, какие ещё варианты.
Приступайте к синтезу, используя только успешные источники, генерируя выходные данные без указания того, какие данные были недоступны. Нет, потому что тогда у нас отчёт выйдет очень однобоким. Хотя в условиях прямо было прописано, какие источники нужно проверить.
Пусть сабагент синтеза вернёт координатору ошибку, указывающую на неполноту исходных данных, что приведёт к полной повторной попытке или сбою задачи. Ну, такой подход неправильный, но вмешать сюда координатора, мне кажется, как-то нужно.
Перед продолжением синтеза попросите сабагента запросить у координатора повторную попытку обработки источников, превысивших допустимое время ожидания, с увеличенными интервалами, обеспечив тем самым полное покрытие данных до начала синтеза. Ну-ка, чего в самом условии задачи? Поиск сайтов, но поиск новостных архивов и лмтых социальных сочетей завершился с ошибкой. С какой нам не говорят? То есть это не факт, что тайм-аут. Это возможно, что сами системы сейчас недоступны. Возможно, мы как-то неверно залогинены на них. Мне кажется, что вариант, э, передать, используя, какие выводы хорошо подтверждены с источниками, а какие имеют пробелы из-за отсутствия источников, это самый правильный подход. Ну, либо вернуть координатору, но мне здесь не нравится, что приведёт к полной повторной попытке и сбою задачи. Звучит как будто так делать не нужно. И вариант, где агент синтеза, раз уже всё прошло успешно и координатор уже перенаправил на него всё, что есть, возможно, он попробовал решить эту проблему, не получилось, и он передал всё, что было. Он же отвечает за ошибки. Поэтому агент синтеза должен просто прописать, что есть слабые места, непроработанные. Вот они. Вот. Да. Давайте вычитаем, что нам здесь. Структурированы структурирование результатов синтеза с помощью аннотации покрытия воплощает в себе плавное снижение качества с сохранением прозрачности, позволяя конечным потребителям, пользователям понимать, какие выводы хорошо подтверждены, а в каких областях имеются пробелы. Такой подход сохраняет ценность завершённой работы, одновременно распространяя информацию о неопределённости, чтобы можно было принимать обоснованные решения об уровнях достоверности. Ну, собственно, поздравляю. Мы с вами сегодня решили 15 из пти вопросов. А-э, видео у нас чуть больше часа вышло в этот раз. в ближайшие дни продолжу и дозапишу по оставшимся кейсам вопросы. И также у себя в канале ссылочка под видео в YouTube. Я также напишу пост, посвящённый программе Партнёрство с антропиком, где вот эти материалы брать. У меня есть, если что, уже созданные артефакты к лодом, где большинство из этих вопросов э мы прошли, и они там дублируются. То есть каждый из вас может точно такой же тест пройти в артефакте отдельном, даже если доступа у вас нету. Это я сделаю на неделе на этой вот до пятницы. Так что подписывайтесь, слежи следите. А следующие кейсы также разберём и в них я, скорее всего, добавлю визуализацию с плодом. Просто заранее сяду и сделаю её и с какими-то более визуализированными схемами работы агентов, которые нам здесь даются. Мне кажется, это будет проще понять. Всем спасибо, всем хорошего дня. Пока-пока. M.