Transcription
Адей. Да. Всем привет. А-а, сегодня продолжаем разговаривать про AI агентов, а продолжаем, точнее, говорить про процессы и про знания, которыми эти агенты управляют.
А один из важных вопросов, о который, э, часто сегодня возникает, как, в принципе, люди своими знаниями управляют. То есть не просто где они там хранят свои заметки, а как происходит процесс того, как узнать, где у нас что важно, что можно выкинуть и забыть, чему можно, чему нельзя доверять, и самое главное, какую из этих информаций использовать в дальнейшем в работе. Естественно, когда у нас появляются и агенты где-то рядом, то ценность и важность этого вопроса, она взлетает невероятно, потому что агенту наш огромный поток мусора, он не очень полезен. Ему нужна, э, не просто память, ему нужна конкретная структурированная, формализованная среда, где любые знания можно проверять, обновлять, где можно проследить источник, где можно понять, что можно использовать повторно, ну и так далее.
А и сегодня мы поговорим про один из подходов, один из многих подходов, базирующийся на широко известной истории от Андрея Карпаттова про Илмвики. Но на самом деле эта идея идёт гораздо-гораздо шире, потому что весь контекст, с которым у нас взаимодействуют агенты, он так или иначе не, ну, его так или иначе необходимо как-то обрабатывать, сохранять и, э, использовать в дальнейшем для улучшения.
Аа, ну и, да, маленькое отступление. Я уже как бы несколько месяцев занимаюсь разработкой открытого Харнеса для иагентов, который как раз-таки делает одну простую цель. Он позволяет сделать их работу чуть более прозрачной, чуть более верифицированной и чуть более верифицируемой. Ну и, как следствие, чуть более аккуратный, превращая каждую задачу в такой удобный комит в Гите с документацией, пояснениями и тому подобное. Но самое главное, что он позволяет делать, он позволяет начинать смотреть на любую практически проблему как на инженерную задачу. То есть задачу, у которой можно выделить входные данные, сценарии исполнения и какие-то критерии проверки результата. И, соответственно, этот же самый подход можно применить и к построению базы знаний, потому что, по сути, это тоже инженерная задача. Проанализировать текст, извлечь основные сущности, прописать связи между этими сущностями, а, создать какие-то странички и так далее.
Аа и, соответственно, раз это инженерная задача, её тоже можно превратить в комит. А, итак, родилась идея развить этот, собственно, Харнес, который, напомню, выглядит как просто консольная утилита, которую вызывает агент и которая позволяет ему, а, получать необходимый контекст, не просто давая возможность там самому придумать, что ему делать дальше, а конкретно говоря: "Вот эти файлы, вот эта задача, вот так-то нужно эту задачу решать". И вот как раз на основе всего этого и родилась идея расширить функционал этой штуки и добавить туда по сути возможность через те же самые постановки задач, но экноз мм ту самую lмвики.
Так вот, про знания. Люди на самом деле как бы управляют знаниями совершенно по-разному. Кто-то папки строит, кто-то в виде там сплошного дневника пишет, у кого-то вообще частично всё в голове живёт. Ну и тому подобное. А, и проблема здесь в том, что эти знания существуют не как система, а как такие просто следы деятельности э информационной. И пока мы пользуемся этим сами, это, в принципе, терпимо. У нас достаточно большое количество памяти в голове, и мы, в принципе, можем, а, понять по контексту, почему этот вывод сделан, на основе какого источника эта информация появилась. И, очевидно, мы можем понять, где у нас там устаревшая и неустаревшая информация. Но как только у нас к этому подключается и агент, это всё ломается полностью, потому что агент видит только фрагменты. Он может там убедительно пересказать этот фрагмент, но он не понимает, откуда что взялось, откуда чему конкретно можно верить и тому подобное. Поэтому, э, когда мы говорим про память агентов, задача меняется. Нам не ну уже поздно проектировать, а, хранилище заметок. Вместо него нам необходима уже полноценная среда для управления знания.
А, и здесь давайте тоже разделим две вещи. Это, собственно, способность быстро найти или вспомнить какой-то фрагмент. А, назовём её recл. Это, в принципе, всё то же самое, что нам, например, позволяет делать рак. Рак позволяет вытаскивать информацию. Но проблемы рага, я думаю, тоже сегодня всем известны. Если у нас достаточно большой корпус текстов, э, при этом сами знания достаточно фрагментированные и неструктурированные, то, э, при запросе мы можем получить совсем не то, что нам на самом деле нужно, а потому что при больших объёмах многие какие-то вещи могут совпадать, но при этом они могут быть из совершенно разных вещей. [фыркает] Так как рак по сути режет наш текст на небольшие элементы, и это как раз-таки и приводит к тому, что эти элементы могут перепутаться. И поэтому нам нужно и и поэтому и здесь нам тоже нужен, нужно управление, нужна способность понимать, откуда это знание берётся, а понимать критерии и доверия к этому знанию, находить конфликты и тому подобное.
А, собственно, на базе этого и родилась родилось небольшое расширение пну. Ещё раз, абсолютно открытый код, бесплатное скачивание, доступно для всех и каждого прямо из Гитхаба. А родилась консольная утилитка, которая вот как раз превращает эту задачу экстракции знаний в максимально формализованную, трассируемую и документируемую задачу, где агент, то есть там ваш агент, любой агент, не суть важно, обязан не просто вот как это, собственно, описывал Карпатов Карпатой завести и наполнить эту вики, а в буквальном смысле превратить приходящее сверхузнание в набор локальных, проверяемых и версионируемых артефактов. И за счёт этого мы как раз и решаем вот эту проблему, э, ну, не того, что AI может мало помнить, а проблему того, что его память плохо организована.
Э, что мы будем собирать? Вот, собственно, на экране базовая модель. А, мы всегда отделяем сырой материал. Наши сырые исходники. Это может быть, опять же всё, что угодно. На это можно смотреть как на слой, например, для личного участия. На это можно смотреть как на корпоративный слой знаний. Так или иначе, в любом случае сырые источники у нас должны обязательно оставаться, потому что, имея доступ к сырым источникам, мы потом можем всё, что угодно, производное пересчитать заново.
Аа выше у него находится Вики, а, собственно, такой слой смысла, где из исходных данных были созданы уже отдельные страницы, отдельные определения, отдельная структура. Причём структура тоже индивидуальная, мы сами её можем выбирать. А, но самое главное, что происходит, а, это то, что агент, прежде чем эту Вики писать, он вытаскивает из нашей исходной информации, во-первых, наборы фактов, те самые сущности, из которых потом можно построить граф знаний, и, естественно, связи между этими сущностями. То есть, по сути, мы сначала строим карту этих знаний, что с чем соотносится, что от чего произошло, что с чем связано.
А-а, и на основе этого уже создаётся ээ целая сеть дополнительных страниц, связанных между собой, аа которые уже агент может использовать как источник истины для себя. При этом, опять же, почему это можно использовать как источник истины? Потому что мы можем чётко проследить, что вот эта вот страничка в Вики у нас укоренена вот в такой-то набор источников вот в такой-то набор, точнее, пардон, а фактов и связи между этими фактами, которые взяты вот напрямую из вот таких вот а и имеющихся а источников. И самое главное, на базе этого мы можем собирать практически любые проекции для решения, ну, практически любой задачи.
А как это работает? Собственно, всё, что нам нужно сделать - это установить простой командой [вздыхает] NPM Install G agent plane, начиная с версии 0614. По-моему, там эта версия появилась, текущая версия 0620. А, и сейчас можно как раз уже полноценно всей этой историей пользоваться. А особо никакие команды учить не надо. По-хорошему, нам нужна только одна команда Agent Plane Contit, которую нам и нужно ввести в нашей папке. Заходим, запускаем и через пару секунд получаем, аэ, запущенный и сделанный а-а конструктор для нашей будущей, а, Вики.
Посмотрим на то, как это выглядит в самом файндере. Это вот такая вот история. Это, по сути, файл Agenc MD, который даёт нам возможность управлять этим репозиторием как ну типа с помощью гитдисциплины. Здесь написано, как наш агент должен взаимодействовать с установленной утилитой для того, чтобы корректно управлять задачами. Но про это мы уже говорили. Если интересно подробнее узнать про Agent Plane, у нас есть на эту тему видео. Сейчас же нас интересует папочка с контекстом, которая здесь и появляется. А и вот она нам интересна следующим. В ней, э, есть две основные папки. А первая папка - это row, то есть сырые данные. А туда мы скидываем всё, что нам нужно ассимилировать в наш контекст. А и дальше непосредственно сама папка Вики. На старте она создаётся пустой. В ней есть только agent MT, которая описывает, собственно, как эта Виiки должна собираться. Не буду останавливаться на самом контенте. При желании просто скачайте, установите и прочитайте. Но логика этой истории в том, что здесь как раз описывается, каким образом агент должен осуществлять экстракцию знаний. Всё, что мы говорили выше. Сначала извлеки сущности, потом пропиши связи между этими сущностями, затем, используя полученные данные, составь статьи э для Вики и как бы свяжи их кросслками, создай гласарий, создай общий индекс, а, и тому подобное. При этом а структура этой Вики может быть произвольной. Если мы хотим, мы можем сами сообщить агенту, какие папки мы хотим в ней видеть. Например, если мы там управляем компанией, нам нужны один состав папок. Если мы там ведём собственный дневник и свои заметки всасываем, то это другой состав папок. По умолчанию это отдаётся на откуп агенту. То есть он сам оценивает тот объём информации, который мы хотим загрузить, и ээ получает а нужную структуру. Причём структуру, опять же, не железнозакреплённую, структуру, которую он может видоизменять по мере того, как туда добавляется новый контент.
Пожалуй, одна из самых классных фичей, которая здесь появилась - это то, что, э-э, викически может расти и расширяться как единая сущность. То есть, э, логично было бы предположить, что если мы кидаем туда там какие-то совершенно разные разрозненные документы, то в результате бы у нас появлялась такая же фрагментированная история. Здесь этого как раз-таки не происходит из-за того, что агенты стараются создавать её как, а, именно максимально связанную историю.
А-а что будет, если я вначале agent planт сделаю, а потом контекст? Ничего абсолютно не будет. Оно ровно так и будет работать. Сначала можно инициализировать просто сам agent plane. Сейчас давайте даже попробуем это сделать. Если просто запустить agent plane in, то он даст возможность более гибко настроить взаимодействие с самой папкой. А там можно будет выбрать уровень, собственно, жёсткости этого харнеса, насколько сам агент будет в жёстких рамках действовать, начиная там от самых простых вещей, которые когда, ну, в принципе, просто позволяют небольшую дисциплину привнести до режима full harness, где агент оказывается вот максимально зажатым, что типа ничего нельзя сделать без заведения задачи. Ну а дальше мы просто выбираем дополнительные опции. То есть можно работать с кодексом, можно работать с клодом, можно установить интеграцию в какой-то иде. А есть несколько режимов работы, например, режим работы напрямую или режим работы через ветки в гит. Можно не задумываться особо, на самом деле. Как бы это расширенные настройки. Я сейчас показываю самый максимум, если не выбирать в первом уровне режим fullхарness, настроек будет меньше. А режим бэкэнда можно работать локально, можно работать через сервис, который там работает у вас на хостинге. А режим исполнения, опять же, насколько автономен будет агент при выполнении задач? Либо он будет спрашивать вашего разрешения на любой ЧИХ, либо он скажет: "Один раз живём, буду работать, а как хочу сам". А новая фишка, кстати, да, тоже про неё будем говорить в одном из следующих воркшопов про эвалы. Это вообще огромная важная тема. Будем ей много внимания уделять. Как улучшать то, что мы сделали? А пока что сюда это добавлено в формате агента проверяющего, который даёт возможность любую задачу, которую мы создали. А-а того, как агент говорит, что задача готова, появляется новый другой агент, который не знает о проведённой работе, который получает на вход только результаты и должен проверить соответствие этих результатов изначально поставленной задачи. И здесь можно тоже выбрать режим работы его. Либо он просто проверяет формальные результаты, либо он смотрит на аа ситуацию чуть более а подробно, либо он включает режим параноик и, в принципе, как бы по умолчанию считает, что всё неправильно, и докажите мне, что всё работает. Выглядит это довольно забавно. Увеличивает время работы, увеличивает потребление токенов, но очень, опять же, к сожалению, пока без бенчмарков не могу сказать насколько, но субъективно, а, делает качество работы лучше. Ну и дальше набор настроек. Запрашивает разрешение на небезопасные действия, запрашивает разрешение на доступ к сети и возможность отправки анонимной обратной связи. Если вдруг какая-то ошибка у вас возникнет, то теперь можно автоматически отправить а бакрепорт, который сразу же будет подхвачен специальным серверным агентом, а и внесён в код. Тоже это всё прекрасно работает. По поводу рецептов блюпринтов сейчас даже не буду останавливаться. Там тоже появилось довольно много интересного функционала.
Но мы сегодня говорим про контекст. Собственно, если после этого применим, у нас в папке появится только база, только файлик agents MD. И дальше для того, чтобы слой контекста а здесь инициализировать, нам нужно снова повторить команду инициализации именно слоя контекста. Она сработает в автоматическом режиме. У тебя, ну, у тебя разве контекст инит не перезапишет базовый файл ENCM MD? >> А он сохранит настройки, которые мы в нём уже задали, поэтому, да, он его не он его не перезапишет, но сейчас покажу, что он с ним сделает. он добавит в, не помню конкретно куда, правда, но в общем это будет тот же самый AGM MD с дополнительным расширением, где как раз будет написано, что есть дополнительный слой контекста, и с этим контекстом нужно считаться сейчас, дабы не быть голословным. Блин, сорян, долго будет смотреться. В общем, а логика именно в том, что, э, файлики остаются, добавляется информация об использовании самого контекста, и после этого у нас становятся доступны, а, следующий набор команд. Сейчас там даже интеграция с Гермесом и с Open Clow теперь появилась. Вот. А, но самое интересное то, что там теперь появилось достаточно большое количество команд, собственно, по управлению самим контекстом, которые позволяют, по сути, просто создавать формализованные таски с достаточным набором документации, с достаточными объяснениями для того, чтобы любой агент, который дальше со всем этим может работать, он понимал, что вот у меня есть такая-то э задача на вход, вот такие-то правила извлечения, вот что у меня должно получиться на выходе. И дальше уже головная боль самого агента, чтобы эту задачу, а, взять и полноценно выполнить.
А сейчас через некоторое время покажу, э, что, ээ, получается в результате. При этом извлечение - это только одна из вещей. Она, естественно, как бы полезная, но, э, мы же создаём базу знаний. Скорее всего, эта база знаний нужна будет не только нам, она нужна ещё и агенту. И у агента появляется ещё и удобное а средство для того, чтобы по этой базе читать. у него есть средства поиска, примерно похоже на то, как работает MD. А тоже очень удобные утилиты для того, чтобы по ээ маркдау файлом искать. Но, в общем, этот слой контекста становится постоянно живущим, постоянно развивающимся. И при этом параллельно, а, непосредственно Вики у нас ещё идёт сохранение вот этих самых фактов, связей и построение по сути графа.
А-а сейчас есть два режима работы с контекстом. А, базовый и максимальный. Тот режим, который сейчас в тестовой версии, он по умолчанию работает как максимальный режим. А это означает то, что он старается вытащить максимальное количество информации, максимально, пардон, вытащить максимальное количество именно связанной информации, чтобы её можно было соединить между собой кросссылками, чтобы не было историй, когда у нас, например, один и тот же термин объясняется в разных местах по-разному. Большая проблема, кстати, рага, когда у нас вот такой неструктурированный контент. Здесь для того, чтобы таких проблем не возникало, есть режим гласария, который позволяет сначала, а если агент считает, что какой-то термин, э, ну, должен быть закреплён как канонический, он закрепляется в глосарии и при следующей интеграции, если что-то по смыслу подходит на этот термин, то используется термин уже канонический.
Аа, и в таком режиме есть ещё режим работы с конфликтами, потому что одно дело, когда у нас чуть-чуть по-разному описаны разные термины, и совсем другое дело, когда у нас одно и то же может быть описано совершенно разными вещами. Например, у нас есть документация, которая давно не обновлялась, и у нас внутри этой документации в старых данных написана одна вещь: "Там нужно делать так-то". А в новой документации это полностью переписано. А, и по-хорошему это большая проблема для баз знаний, потому что вот это разрешение конфликтов достаточно серьёзная проблема. А, и здесь она решается следующим образом. Мы, в принципе, как бы не отслеживаем конфликты. Если у нас попадаются два противоречащих друг другу э объекта, агент записывает в память об оба из них, но помимо самих объектов он записывает каждому из них так называемый confidence score, то есть уровень уверенности в том, что тот или иной вариант более правильный. Соответственно, если мы видим вот, например, в случае с документацией, если у нас есть старая документация и новая документация, новой документации он будет доверять чуть-чуть больше. И, соответственно, в будущем, когда агент будет обращаться, например, поиском к тем или иным данным, он увидит сразу всю картину, что вот были вот такие-то такие-то, э, вхождения, уверенность в этом там 70%, уверенность в этом- 30%, и дальше уже тот агент, который с этим работает, будет сам аэ выбирать, что конкретно он с этим будет а делать.
[тяжело вздыхает] А, [вздыхает] да, это то, что я уже говорил, что если мы добавляем несколько документов подряд, то это не три отдельных сари, это именно Вики, где контент контент каждого из документов проходит через, а, единый пайплайн. и в рамках этого пайплайна как раз ээ ассимилируется в единую общую базу знаний для того чтобы она была максимально консистентной [вздыхает] дальше аа важно сказать что как бы да звучит классно сейчас секунду есть настройки исключения папок или файлов создания контекста у меня есть нескольких файлов после обработки получается один, именно он должен пойти как источник. [вздыхает] А вообще, да, а в текущей версии это отключено. Вообще, э, вот эта логика построения файлов, тут должна row а подразделяться. Там в ней можно указать, как раз-таки будет вот, ну, в какой-то из релизных версий там будет отдельная подпапочка с private, а, и туда можно будет класть как раз-таки приватные данные, которые, ну, понятное дело, агент увидит, но которые он будет как раз-таки знать, что в Вики не должны попасть. Аа это мы немножко вперёд забегаем. Оно протестировано, оно есть, оно просто сейчас отключено, потому что, ну, вот в текущих версиях хочется протестировать именно режим максимальной ассимиляции, но в целом, да, вот, аа то, как работать с приватными файлами, оно, ну, то есть это достаточно важная задача, э, она она как бы висит. Вот.
А, но при этом, как бы это классно не выглядело, надо сказать то, что там далеко не все проблемы это решают. То есть, а что делает режим контекст? Он делает по сути знание управляемым, но управление не означает безошибочность. Он не следит за там риском устаревания. Аа он не следит за ложной нормализацией. Пока что это достаточно сложная штука. И если у нас есть две разные сущности, но которые, например, называются по оди одинаково, а, ну, опять же, если мы ошибочно назвали их, например, в документации, то это может не попасть в конфликты. И это ээ та вещь, которую ещё нужно сделать. Аа есть риск слишком мелкой гранулярности. Иногда при задаче, при специфических данных, которые мы туда добавляем, он должен, э, он может типа взять и раздробить этот корпус на огромное количество страниц. Чтобы этого не было, есть определённые как бы контрмеры в виде вот ссылок на исходники, в виде выделения жёсткого конфликтов, в виде отдельного гласария, который ведётся и так далее и тому подобное, в виде вот того же режима эвалуации, о которой я говорил раньше. А, в общем, это то, что ещё предстоит реализовать, но уже в текущем виде оно, а, позволяет, как это, перейти от вопроса, как заставить модель отвечать лучше к вопросу, как это, какая система ограничений сделает её работу более, а, проверяемой.
Что ещё здесь классно? то, что потенциально эта модель позволяет работать со всем этим знанием не одному человеку, а в команде. Аа это тоже небольшой ээ небольшой тизер будущего. Сейчас в текущей версии этого нету, но это может а-а это появится как там функционал в одной из следующих версий. Возможность синхронизировать несколько баз знаний между собой. А-а, потому что вот как раз возможность спустить сверху, например, набор каких-то сущностей. Например, у вас есть корпоративная база знаний, и вы чётко знаете набор канонических определений. У вас есть какой-нибудь там канонический гласарий, вот вы его можете спустить сверху на эту команду и таким образом заставить каждую из локальных Вики писаться в определённом а формате уже изначально. И дальше её можно будет легко присоединить к единой а общей базе знаний. То есть таким образом вот это вики, то есть ну база знаний может стать частью рабочего процесса.
Ещё вопрос из чата. На основе диалогов будет обновляться контекст или надо создать файл по итогу диалога и его обработать в знание? А это зависит от того, каким агентом мы пользуемся. А сейчас эта штука работает на уровне, собственно, Agent MD и, э-э, самого Cliки, а, и позволяет работать с ней любым агентом. Если мы работаем, например, через там кодекс, клодкод, курсор, ну, то есть таких через реактивных агентов, то тогда, да, надо будет написать отдельно, что вот я хочу, чтобы наш диалог добавился в контекст. добавь его, пожалуйста, добавь там какие-то новые знания и так далее. Аа в базе есть режим, который позволяет обращаться к истории задач. Так как мы по каждой задаче пишем документацию и сохраняем Redmi, то мы можем аа одной командой попросить его ассимилировать историю этих задач и потихоньку данные о нашем проекте туда засунуть.
А если же мы пользуемся проактивным агентом, то есть, например, Гермес, Open Clow и тому подобное, то, опять же, тема следующей, э, лекции, но у нас есть как раз-таки функционал уже предусмотренный, который позволяет как раз на уровне Agent Plan работать и с Гермесом, и с OpenClow. И там есть функционал, который позволяет, во-первых, а любой формат общения превращать в задачу, причём делать это не в, ну, типа в фонвом режиме. То есть мы общаемся с агентом точно так же, как и обычно, но он у себя включает режим сохранения. И все вот эти таскинплейна ведутся. И также там есть возможность включить а режим автоматической ассимиляции. То есть агент выполнил задачу и не может двинуться дальше, пока результаты не ассимилированы. А, и тогда вот, например, в паре с Гермесом можно делать автоматическую базу знаний. То есть мы с ним общаемся, а он параллельно ведёт Вики. Больше того, а-а, плагин к рабой версии плагин будет работать, ну, он уже сейчас работает, просто не не на 100%, но аа короче, в чём логика? Он подменяет чуть-чуть память самого агента. И если у нас в базе, например, там Open Clow пишет Memory каждого дня и сохраняет её себе в папку с Memory, то, э, в случае активации плагина он начинает синхронизировать свою память в сырые данные. И, соответственно, когда у него включается режим ассимиляции, а его можно включить, например, на каждую ночь, пока мы спим, агент, как и, собственно, мы сами, а, разбираем то, что у нас попало в оперативную память. Нужное сохраняем, ненужное выкидываем. соответственное ассимилируем в этой Вике. А, и больше того, самая классная фишка, которая будет, а, это то, что часть контекста самого агента, например, какой-нибудь файл SoumD может частично формироваться за счёт тех знаний, которые у нас появляются в Вике. То есть мы пообщались с агентом, у нас что-то произошло, у него остались какие-то знания, а, то, что важно из этих знаний, оказалось ассимилировано в LЛLM Вике. И в дальнейшем протекло ему в файлы контекстов, в оригинальные промты, делая его вот таким динамическим, постоянно самоулучшающимся. А, повторюсь, это, в принципе, уже работает. Э, правда, ну, как бы для продакшена я пока не рекомендую это использовать, но для экспериментов можно вполне себе. То есть у меня, например, Open Close этой штукой работает, и это прямо чудо какое-то. Очень прикольно получается.
А вот, собственно, сейчас покажу небольшую демку и уже можем закругляться. В общем, основная эта логика здесь в чём? Чтобы не нагружать агента а-а лишними знаниями, нам нужно изначально подходить к проектированию контекста как вот к инфраструктуре для знаний. То есть не просто создавать лучшие промты, не просто там надеяться на память модели или там, упаси Господь складывать просто документы в рак. Мы изначально должны думать именно рабочей средой, где у нас отдельно лежат источники, где отдельно лежат синтезированные знания, где у нас тут лежат факты, тут лежат гипотезы, где конфликты не затираются, а любой результат, который у нас появляется, всегда можно проверить и переиспользовать. Вот этот, собственно, режим контекста - это вот примерно один из практических вариантов такой среды. Он сразу, ну, я пытаюсь сразу все как бы минусы обрисовать. Он также требует дисциплины, он также требует проверок, но он как раз-таки позволяет перенести вот всю вот эту историю работы с базовыми с базой знаний в область максимально управляемой и проверяемой совместной работы. И повторюсь, дабы не быть голословным, давайте просто посмотрим, как это может работать на живом примере.
>> Вот, например, вариант документации, которая а была >> реализована. А ещё, кстати, важная вещь, о которой не сказал, когда мы инициализируем слой контекста, у нас ещё появляется третья пабочка capabilities. Это довольно важная штука. Мы все знаем, что в чём отличие openклоу от Гермеса. Гермес работает по принципу, что любое действие, которое ты делаешь больше двух раз, лучше оформить в skill. [кашель][откашливается] Здесь пока есть, а заделка под такой же режим, который позволяет нашу базу знаний использовать для того, чтобы улучшать не просто нашего агента, а улучшать весь рабочий процесс. Соответственно, то, что мы получаем Вики, может быть источником для того, чтобы создать новый новый функционал у нашего агента. И вот папка Cabilти, она со временем должна наполняться как раз-таки там дополнительными промтами, дополнительными рецептами, которые позволят агенту непосредственно работать лучше. Ну а дальше давайте как раз завершим это примером.
А вот у нас есть папочка row. в эту папочку роу было накидано там совсем какая-то базовая история. Я попросил на самом деле просто собрать мне аа несколько разрозненных документов на схожие, но чуть разные темы и попытаться их объединить. То есть одна у нас история. >> Да-дада. >> 15 максимум. >> А, ладно. А, в общем, это какие-то документы по поводу того, как Великобритания интегрирует в себе искусственный интеллект и пытается его, э, безопасно внедрить в госуправление, тамменеджментфреймворк какой-то на в пдфке, а ещё какие-то данные. И вот как раз-таки Government AI Playbook, кстати, довольно любопытное, э, чтение, довольно большое. А, но в общем я просил его вытаскивать не всю информацию, а наметить как раз-таки Вики на базе всей этой истории, которая бы позволила мне максимально эффективно понять, а что, собственно, происходит, куда, что это за етрансформация Великобритании и собрать из неё базу для того, чтобы в дальнейшем её изучать. При этом изначально я в настройках указал, что Вики мне нужна русскоязычная, поэтому видеть мы её как раз-таки будем на русском. А, ну и далее, опять же повторюсь, это не весь контент сознательно вытащенный не целиком, а только лишь для того, чтобы его показать. И в общем, что здесь важно? А, гласарий, который у нас появляется с каноническими терминами, которые были вытащены на основе этих текстов, исходники, на которые он каждый раз ссылается, и мы можем как бы посмотреть, ээ, где, когда и откуда у нас что-то взято. А, и есть, собственно, описание м [стон] с общей структуры нашей Вики с обоснованием, почему там мы взяли, [откашливается] а, с объяснением, почему была выбрана именно такая структура. Как мы видим, здесь она довольно специфическая. А у нас есть карта источников, у нас есть как раз сами источники, где у нас описано, а где у нас уже синтезированные документы. Ну и дальше, собственно, сама по себе Вики, где у нас разные странички, а где у нас есть связи между этими страничками и где мы можем в базовом режиме между ними перескакивать, определять, смотреть и и тому подобное. При этом у каждой сущности появляется отдельная страница, появляется отдельный список связей и появляются отдельная связка с источником. То есть, если мы переключимся в режим графа и посмотрим, что у нас получилось, то мы увидим, что у нас достаточно, а, высокий уровень связанности, и, соответственно, агент, который по этой базе будет искать теперь необходимую для нас информацию, сможет весьма легко и просто понять не только конкретную сущность, но и узнать, откуда эта сущность взялась, с чем она связана, а, и самое главное проследить, откуда она произошла. И то же самое как бы происходит со всем остальным, выделяя там отдельно, а что-то связанное с внедрением, отдельно говоря там про, а какие-то фичие способности, ну и так далее и тому подобное. А ещё раз повторюсь, а формат этой Вики - это именно попытка, а, показать, как в тестовом режиме сам агент может такие вещи вытаскивать. А сама по себе структура может быть совершенно разной. ээ и зависеть в большей степени непосредственно от вашего собственного проекта.
Сейчас момент покажу на другом примере. Мм, секунду. Да, на другом примере. То есть, если попросить делать попроще и полегче, то странички будут попроще и полегче. Например, можно попросить его просто в чате взять там, например, какие-нибудь русские сказки и тоже попытаться ассимилировать, э, ну и так далее. Собственно, основная идея здесь ровно в том, как я сказал, чтобы знания превращались в структурированную систему, с которой агентом было бы максимально просто работать. А и для этого как раз вот и используется подобная связка. Дальше в будущем у неё появится несколько режимов. То есть вот текущий режим, как я его назвал, режим максимальной ассимиляции. Но по факту конкретный режим должен выбирать сам агент, исходя из того контента, с которым вы работаете. И что ещё хорошо, это видоизменяемая вещь. Общаясь с агентом, мы можем вносить э любые изменения. Аэстное, что мы не можем просто взять и переписать информацию внутри этой Вики, так как нам заблагорассудится, потому что у агента есть ограничение просто так. Он это делать не может. Именно потому, что это должна быть связанная история, у которой есть свои источники, у которой есть чётко прослеживаемый провиненс и который, соответственно, можно пользоваться. [вздыхает][тяжело вздыхает]
А-а вот аа дальше мы будем больше говорить про управление знаниями и про то, как более эффективной делать эту среду и больше углубляться уже в режимы автономии. Как сделать так, чтобы не просто мы сами со всем этим работали, а чтобы с этим работали наши именно проактивные агенты, как условно отдать эту базу знаний на откуп OpenCl, чтобы он все наши данные, например, в момент работы туда загружал. Ну и, в принципе, больше будем погружаться именно в автоматизацию. Вот. А-а, у меня в целом всё. Я с удовольствием готов ответить на дополнительные вопросы, если они есть. А если же вопросов нету, то могу только пригласить попробовать э- подобный инструмент и в следующий раз поделиться обратной связью. Она будет максимально ценной, потому что именно ваша обратная связь позволяет делать такие штуки лучше, эффективнее и тому подобное. [вздыхает][тяжело вздыхает] А вот так что на этом в целом всё. Большое спасибо. Если есть, если вопросов нету, то рад был всех видеть. Вопросы можно оставить в комментариях под видео. Ссылки на загрузку и установку также будут в комментариях. А-ам прощаюсь и до уже достаточно скорой встречи. Мы как раз планируем со следующей недели начать большее погружение в мм историю с тем, как делать аген как превращать реактивных агентов в полноценных когнитивных партнёров. Вот. Так что всем большое спасибо. Надеюсь, это было полезно и до встречи на следующей неделе.