Speaker A
Спрашиваешь агента, почему в проекте Кавка? Он отвечает: "Порядок по ключу партиции". И это критично для биллингов.
Обзор проблем и решений в организации памяти для мультиагентных систем и кодинг-агентов с акцентом на синтез и хранение знаний.
Ask about this video. Answers come from its transcript only — with the timestamp, so you can check them.
Generated from the transcript and can be wrong — check the timestamp.
Key Takeaways
- Выбор между синтезом знаний при записи и обработкой на запросе критически влияет на качество памяти.
- Параллельная запись нескольких агентов в одну память приводит к потере данных и конфликтам.
- Дизайн памяти и координация агентов важнее интеллекта модели для стабильной работы системы.
- Память должна сохранять не только факты, но и причины решений и историю изменений.
- Использование вики с запретом ручных правок помогает избежать искажений и потери информации.
What the video covers
- Обсуждение важности правильной организации памяти в мультиагентных системах и кодинг-агентах.
- Различие между синтезом знаний при записи и обработкой их на запросе, с плюсами и минусами каждого подхода.
- Проблемы с параллельной записью в общую память несколькими агентами и потеря данных (Lost Update).
- Рассмотрение архитектурных решений для координации агентов и предотвращения рассинхрона.
- Опыт работы с графовыми базами данных для памяти и переход к командной работе с общей памятью.
- Важность понимания, что память — это не просто хранилище, а инструмент для осмысления и переиспользования знаний.
- Роль памяти в сохранении контекста между сессиями и при работе нескольких участников.
- Обзор исследований и практических кейсов, выявляющих основные причины сбоев мультиагентных систем.
- Подходы к ведению истории изменений и синтезу информации для минимизации искажений.
- Рекомендации по использованию вики и запрету ручных правок для сохранения целостности знаний.
Chapters
- 00:00Введение и проблемы с памятью в мультиагентных системах
- 01:38Вопросы к памяти и симптомы проблем
- 04:00Синтез знаний: при записи или на запросе
- 05:59Работа с памятью на одном ноутбуке и проблемы масштабирования
- 08:20Конфликты при параллельной записи и потеря данных
- 10:27Недоверенный вход и влияние внешних данных
- 12:56Координация агентов и предотвращение рассинхрона
- 15:22История изменений и ведение памяти в команде
- 18:05Роль графовой базы данных и синтез информации
- 19:12Заключение и рекомендации по работе с памятью
Full Transcript — Download SRT & Markdown
Speaker A
Гладко отвечает со ссылками, том человека, который сидел на том обсуждении, когда принимали это решение.
Speaker A
Только в тре, из которого эта страница в памяти родилась, биллинг не упоминается вообще. Половина причин там нет, а самое обидительное придумано агентом. Страница месяцами пересказывала сама себя и с каждым кругом звучала всё увереннее.
Speaker A
Забывчивую память видно сразу. Это коллега, который каждый час всё забывает. Переспросил: "Ты вздохнул?" Объяснил заново. И это же намного хуже.
Speaker A
Она не переспрашивает, она отвечает. И это не баг инструмент, а это дефолт, который выставили за тебя. Память сегодня собирается за один вечер.
Speaker A
Просишь агента и получаешь Вики, под неё какую-то базу данных, возможно, и ещё и векторный поиск добавится. И всё это работает. Только внутри этой сборки уже приняты определённые решения, о которых тебя забыли спросить. На одном ноутбуке это почти не стреляет тебе же в ногу. Но
Speaker A
[музыка] когда в эту память начинает писать второй человек или десяток агентов, ты запускаешь разом, то это может очень незаметно, а потом больно выстрелить тебе в обе стороны. Я с памятью увожусь с тех пор, как чатботы научились дёргать внешние источники и
Speaker A
начинал [музыка] с мемори графовой базы данных. С тех пор прошло очень много времени, и последний год — это уже работа в команде, где много человек, их агенты и одна память на всех.
Speaker A
Комбинаций мы перепробовали столько, что половину уже и не вспомнить. [музыка] И вот из всех этих попыток остался довольно богатый опыт. Те решения, которые мы принимали для того, чтобы всё это работало. И как раз-таки в этом видео мы будем обсуждать те вопросы,
Speaker A
которые надо задавать памяти, и как же на них можно отвечать. Возможно, ты узнаешь свои симптомы. Токены, сгорающие на перепроверянии одного и того же, и записи коллег, исчезнувшие из общей памяти без следа. А к концу станет понятно, почему же, если вы используете
Speaker A
Вики, то в ней запрещено править что-либо руками. Ну что, погнали. У любой системы знаний с ней внутри есть одна развилка. Она не про то, когда знание кладётся. Кладут все одинаково, когда пришло. Развилка про то, когда агент это знание осмысляет, связывает с
Speaker A
уже известными и разруливает все противоречия, которые могли накопиться. И делает он это сразу или кладёт сырым и перепроверяет только на ваш вопрос. То есть осмыслить или на входе, или уже на самом запросе. Кто строил дата пайплайны, помнит пару: схема при записи
Speaker A
против схемы при чтении. За структуру платишь либо когда пишешь, либо когда читаешь. Здесь точно такая же механика, только про знание агента.
Speaker A
И рассмотрим отличие. Синтез сразу. Допустим, к нам прилетел какой-то источник, возможно, разбор инцидента, какая-то переписка, какой-то ADR или какой-то тикет, или, может быть, инсайты после реализации какой-то задачи. И агент сразу с ним работает, вытаскивает оттуда суть, переписывает страницы,
Speaker A
ставит связи, помечает, где новое конфликтует со старым. И эта вся тяжёлая работа, она делается один раз. И когда вы уже спросите второй раз про эту информацию, уже всё готово. Агент просто читает из того, что он до этого сделал.
Speaker A
Другой же вопрос. Если мы с вами всё храним сырым, то мы будем с вами всё обрабатывать на запросе. То есть, когда к нам пришёл источник, мы его кладём сырым. Никакого синтеза. Работать и начинает на запросе, читает нужные записи и собирает ответ заново. Это у
Speaker A
нас как структурная база. Здесь у нас тяжёлая работа на записи, но один раз. Здесь же у нас запись практически даром, но та же работа возвращается на каждый похожий запрос.
Speaker A
Агент гоняет токены заново и упирается в лимиты там, где мог бы один раз переварить и забыть. И казалось бы, зачем вообще этот выбор? Прекрасно, можем синтезировать один раз, второй раз ничего не выбирать, но у [музыка] этого у всего есть одна цена, которую видно
Speaker A
только потом. Готовит она этот синтез один раз, и это сжатие с потерями в одну сторону, что выкинулись из источника при синтезе. И страницы уже не достанешь.
Speaker A
При этом, когда мы храним сырое, это дороже на каждом запросе, [музыка] зато пересобирает ответ из оригинала и не копит искажение этих пересказываний.
Speaker A
Развилку эту сформулировал я. Карпаты в первом же абзаце про LLM Вики противопоставляет рак, который представляет знания на каждый запрос, и вики, которую агент собрал один раз и поддерживает. Google в своём новом документе про Open Knowledge формат стандартизует ровно викисторону. В
Speaker A
работе протим этому дали имя Right before Query Bearer. Решение, что выкинуть прижатие, принимается до того, как ты узнал, на чём завязнит будущий вопрос. Корнями всё уходит в схему на записи против схемы на чтении, который в датаинженерии уже не один десяток лет.
Speaker A
Так вот, давайте разбираться, о чём же молчат многие работы исследования и что нам говорят различные блогеры. И рассмотрим мы это под прицелом, что мы используем это для нашего кодинг-агента.
Speaker A
И для кодинг-агента правая часть есть уже довольно-таки большая. И это наш гид. И память нашему агенту не гайд для того, что лежит в коде. Она нужна для того, чего код у нас с вами не держит. Почему мы так решили? Какие тупики уже прошли,
Speaker A
какие в команде договорённости и что было постмортами после инцидента? Память — то, что переживает сессию и переиспользуется [музыка] потом. Это как разница между In-memory и Persistent. Контекст живёт, пока живёт прог, перезагрузил и всё потерялось.
Speaker A
Если ты работаешь в одиночку и у тебя один проект, и все [музыка] знания — это твои конвенции, твои решения, плюс гит, этот контекст у нас закрывает почти всё, что может потребоваться, и городить какие-то сложности точно не требуется. В
Speaker A
случае же, если у тебя несколько писателей для твоего проекта, то понимание того, как работает память, что нам куда сложить, может быть, что-то хранится сырым, где-то делать синтез, это уже начинает окупаться очень хорошо. Но при этом здесь же это всё и начинает
Speaker A
ломаться. Поэтому, когда мы используем один ноутбук с одним агентом, всё работает без сюрпризов. Я и мой агент и память, и кроме нас в неё никто не пишет. Ломается это, когда в один стек памяти пишет несколько [музыка] человек или когда на
Speaker A
одной машине крутится десяток агентов разом. И память под ними и под всеми общая. Больше одного писателя в одно знание одновременно может привести к проблемам. И это дыра, которую инструменты закрывают только наполовину.
Speaker A
Подключить общий инстант памяти на несколько агентов сегодня — это пара строк кода. Можно найти различные проекты и mzero, и многие другие. И всё это описано в различных кукбуках и других источниках. Но что же будет происходить, когда в этом memory пишут
Speaker A
двое одновременно? Кто кого, возможно, затирает? А как нам разводить противоречия? И это, на самом деле, не вопрос того фреймворка, который ты используешь. И это твой вопрос, на который должен ответить ты перед тем, как создаёшь своё memory для того, чтобы
Speaker A
разобраться, как она работает. И оказывается, это основной режим отказа. И абсолютно нередко его разбирали в Берке. Взяли больше полутора тысяч реальных прогонов мультиагентских систем по семи фреймворкам и разметили, на чём именно те падают. Две самые частые причины оказались не про тупость
Speaker A
отдельной модели. Первая была — это кривой дизайн самой системы. Вторая — рассинхрон между агентами. То есть рвётся передача контекста, теряется состояние находов. Выходы друг другу противоречат около трёх четвертей всех падений. И модель поумнее эту поломку не чинит, лечит дизайн памяти и
Speaker A
координации. Механизм первый. Потеря записи. Два агента пишут в одну запись параллельно. Оба её прочитали, поправили, каждый свою половину записали обратно. Правки не складываются. Последняя запись ложится поверх первой целиком. Первая же исчезает. Запись выглядит целой, но половина знаний в ней уже нет. Болезнь
Speaker A
старая — это Lost Update или Write Mod, которая в базах знают уже полвека. Меняется одно: писатели недетерминированы и пишут естественным языком, поэтому обычные блокировки по версии строки не спасают. Текст
Speaker A
противоречий. У структурной базы корень другой, но ничуть не легче. Многих писателей она держит спокойно, ничего не затирает, зато опт противоречия молча.
Speaker A
Год назад агент записал: "Работаем по Gitфлоow фичи в отдельных ветках через PR. Полгода спустя другой записал: "Перешли наAS, комитим в main, работаем с фичефлагами". Оба факта были верны, но в свой момент времени база честно хранит обе строки, а потом агент идёт заводить
Speaker A
фичу и разводит длинную ветку под процесс, от которого команда уже отказалась. И это известно как концепт дрифт. Мир меняется во времени, и хранимое знание устаревает не потому, что было неверным, а потому, что сменилась реальность. Соблазно, чтобы модель прямо при записи сама всё это
Speaker A
разрулила. Новый факт противоречит старому, пусть перезапишет старое. На паре фактов работает, когда их сотни, и часть этих фактов уже поменялась? Нет.
Speaker A
[музыка] В MМ Zero это проверили, поставили симуляции, где у пользователя по ходу меняются предпочтения и смотрели, разделяет ли модель старая и новая или валит всё в кучу. Так вот, разрулить это надёжно не выходило.
Speaker A
[музыка] Противоречия оставались висеть. Кончилось тем, что они отказались от перетирания старого и перешли на только добавление. Новые записи добавляются, ничего не переписывается и не удаляется, и вся история остаётся на месте.
Speaker A
Механизм третий, про который забывают - это отравление памяти. Пока память только у меня и пишу в неё только я- это вопрос гигиены. Общая память, в которой пишут несколько источников, это у нас становится уже поверхностью атаки. До сих пор мы говорили про то, как мы
Speaker A
складываем знания, но кто-то эти знания читает. И читает его чаще всего агент, а у него есть определённые ручки, которые он может подёргать. Он может проверить почту, может быть какой-то API, а может и отправить письмо или ещё что-либо сделать с вашими данными. И на уровне
Speaker A
этого агента есть известная ловушка. Её сформулировал Саймон Уилсон, [музыка] тот самый, который вёл термин Prompt injection. Он назвал это смертельная троица. Агент по-настоящему опасен, когда сходится три условия раза. Первое - это доступ к приватным данным.
Speaker A
И это может быть твой код, может быть твой календарь, переписка в чатах, да, всё, что ты там хранишь и все тулы, которые ты подключил к своему агенту.
Speaker A
Второе - это недоверенный вход. Что-то пришедшее не от тебя. Возможно, какое-то входящее письмо или содержимое публичного репозитория или какая-то веб-страница, которую твой агент засёрфил и прочитал на ней информацию.
Speaker A
И третье - это канал Наружу, через который все эти данные можно куда-либо передать. По отдельности каждая безобидна и не может причинить вреда. Но когда это всё вместе, достаточно одной отравленной строки, чтобы агент сам утащил все твои приватные данные и передал это всё
Speaker A
куда-то третьим [музыка] лицам. Так вот, наша память, она как раз-таки бьёт во второе условие. Чужая запись в общей памяти - это, возможно, недоверенный вход. Только живёт она не одну сессию, а постоянно и переиспользуется на каждом следующем запросе. И разовая инъекция
Speaker A
становится постоянной и попадает к агенту, у которого есть два других условия, потому что без этих условий кодинг-агент абсолютно бесполезен. И казалось бы, всё это теория, и нас с вами, наверное, не коснётся. Ну кто же будет писать в нашу какую-то командную
Speaker A
Вики плохие данные, которые всё у нас украдут или понаделают ещё чего хуже с нашими серверами, если туда, не дай бог, у вас лежат какие-то ключи доступа к вашему продакшену. Так вот, провели эксперимент и назвали эта атака минья.
Speaker A
Атакующий был обычный пользователь, и доступа к хранилищу памяти у него не было. Он делал только обычные запросы к агенту платформы, но формулировал он их так, что после его сессии в общую память садится вредная [музыка] запись и всплывает потом как готовый пример на
Speaker A
чужом, ни в чём не повинном вопросе, и проверяли это на нескольких агентах, включая медицинский. Так вот, вредную запись удавалось протолкнуть почти всегда. Другая же группа исследователей решила проверить эту атаку ближе [музыка] к реальности, где память уже была забита большим количеством
Speaker A
нормальных записей. И там, конечно, успех у них атаки резко падает, но слово падает, это не значит безопасно. Атака не исчезает, но она становится реже. И если у вас будет большой поток таких данных, то редкая на потоке она всё
Speaker A
равно становится регулярной, и один отравленный ответ на 1.000 при ваших объёмах сработает не раз в год, а каждый день. И как раз-таки вот из этой троицы следует и защита. Имета назвала её правилом двух. Агенту можно держать максимум два условия из трёх, но не все
Speaker A
три разом. Уберите любое, и тогда цепочка порвётся. Либо красть уже нечего, либо слить уже некуда. Для памяти нам проще всего снять третье. То есть все действия наружу будут идти через человека. Можно ещё умнее, если мы будем гейтить по состоянию. То есть не
Speaker A
дёргать человека на каждый чих, после которого он скажет: "Да, всё, давай выполняй, я тебе доверяю, погнали".
Speaker A
Потому что каждый раз вроде всё выглядит хорошо. А завязать это разрешение на историю. То есть, если наш агент потрогал какие-то критичные данные, то канал наружу автоматически закрывается.
Speaker A
То есть прочитал конвенциальные какие-то данные, всё, наружу мы никуда не даём ему доступ. И получается, что разрешение зависит не от текущего вызова, а от того, что агент уже сделал до этого момента. Да, в реализации это, конечно, заметно дороже. Надо тащить состояние и
Speaker A
следить за тем, что было сделано, что было прочитано, но при этом мы не используем с вами человека. на каждый возможный вариант выхода из нашего агента куда-то наружу. Но базово, конечно, проще всего закрыть это всё на Human in the Loop. Отравление мы знаем,
Speaker A
как закрыть: через гейта или через понимание того, что делает наш агент. Осталось ответить теперь, что же делать с возможной потерей знаний или накапливаем противоречия. И их лечит у нас дисциплина записи. И она отвечает сразу на два вопроса из тех, которые мы
Speaker A
хотим себе задать. Кто пишет и чем привязан? Кто пишет? Самый простой ответ: один писатель на файл. Звучит это как капитуляция, но при этом даёт ноль конфликт, потому что конфликтовать будет некому. КД-код для сапагентов выбрал ровно это. У каждого своя память, и с
Speaker A
координатором не шарится. Изоляция тоже решение, и можно использовать его по дефолту, чтобы писать вдвоём втроём, порядок записи не должен иметь значения.
Speaker A
Каждый дописывает свою строку в конец и ничего не трогает из того, что было выше. Это у нас получается append only log. И он в целом сливается чисто в любом порядке. Это очень похоже на eventт Sourcing. Тот же MZO отказался от
Speaker A
перезаписи ради сохранения истории. Иская работа user as a code доводит эту мысль до предела. Влог, который не отбрасывает ни одного факта. А осмысление - это у [музыка] нас периодический чекпоинт поверх этого лога. Записи синтез разведены по времени. Развилка из нашего первого
Speaker A
вопроса и решённое, что мы берём и то, и то. Чем связаны наши знания? Беда первого механизма была не только в [музыка] затирании. Даже слив обе версии аккуратно, агент может не понять, что это про одно и то же, просто разным
Speaker A
текстом. И лечится это довольно просто. Якобы каждое утверждение тащит происхождение. Возможно, это номер адрки какой-то или хэшкомита, или ссылку на какое-то решение, которое мы приняли. И получается, что перед записью агент может грепнуть по этому якою. Если факт с таким источником у нас уже есть, то мы
Speaker A
его дополняем и не пладим второй. То есть у нас происходит дедупликация по происхождению, и это становится половиной защиты от отравления. То есть запись без подтверждённого источника не имеет права добавляться к нам в наши знания. Cloud Fayer в своём Agent Memory
Speaker A
[музыка] довёл это до паплайна. Каждый извлечённый фракт тащит индексы строка исходного транскрипта. И перед записью факт сверяется с этим транскриптом.
Speaker A
Проверка владения. У них это не опция, а этап конвейера. Исследователи к этому же выводу пришли с другой стороны, [музыка] от атак. Свежий обзор безопасности агентской памяти формулирует прямо: защиту не навесить на чтение задним числом. Проверка владения и версионирования должны стоять с момента
Speaker A
записи, а группа, прогнавшая 5.000 атак на память через шесть популярных защит, зарепортила. Пять из шести не работают и решает [музыка] не текст записи, а её происхождение и полномочия. Поэтому якорь - это не просто гигиена, а это у нас с вами
Speaker A
несущая стена, от которой зависит очень многое. Знание не затирается без предупреждения. Факт устарел. Не стираем, помечаем, что это больше не актуально. На смену пришло новое с такого-то числа. При этом вся старая информация у нас с вами остаётся. Так
Speaker A
сделано в графите. Старую запись он не удаляет, а закрывает с нужной даты. Поэтому получается, что у нас с вами история на месте. И можно спросить, какие же были у нас правила в нашей команде в марте прошлого года? Потому
Speaker A
что, возможно, тебе важно не только текущая решения, но и почему отказались от прошлого. Разница в том, кто держит руку на записи. В структурное хранилище агент не пишет напрямую. Между ним и базой стоит наш с вами тул, который менеджит запись. Нет источника и
Speaker A
времени, мы её не пропускаем и не добавляем в нашу базу. Поэтому получается, что инвариант держит наш с вами тул, а не агент. При этом Вики агент правит сам своими руками в маркдаун, и между ним и файлом нет никого. Он сам себе писатель и
Speaker A
проверяющий. И на длинном прогоне проверяющий у нас с вами отваливается первым. Первоисточник уплыл или метку забыл поставить или страницу не пересобрал, потому что решил, что и так будет нормально. Я думаю, все мы с вами видели, как агенты тупят и не следуют
Speaker A
нашими с вами инструкциям, потому что они решили, что, возможно, у нас не продакшн или нам и так сойдёт, или уже слишком большое контекстное окно, и можно половину этого всего не делать, потому что, да, вроде и так нормально.
Speaker A
[музыка] Поэтому гейт нельзя вешать на самооценку агента. Тот же агент, что забыл обновить метку, уверенно запишет противоречие и пойдёт дальше.
Speaker A
Уверенность модели ничего не говорит о её правоте, поэтому часть проверок на входе, она довольно-таки тупая и детерминирована, и это может поймать наш с вами код. Нет источника или нужных параметров. Мы [музыка] запись не принимаем и отдаём агенту обратно, что
Speaker A
надо всё это доработать. При этом могут возникать смысловые противоречия, где текст разный, а суть одна. Перешли на BAS против фичи в отдельных ветках.
Speaker A
Кодом такую проверку, конечно, не поймаешь. Поэтому у нас ловит отдельный арбитр, агент, который прочёсывает память в фоне. То есть наш фоновый агент пересобирает, консолидирует фрагменты, дедуплицирует, архивирует устаревшее, находит какие-то конфликты. Мы такого агента назовём Вики грумер. И у него три
Speaker A
работы. И каждая закрывает одну из дыр. Первое: каждый день он собирает новые факты, что добавились в память, и кидает дайджестом в командный чат. И это позволяет нам не просто шарить знания через вики в команде. Но и в момент,
Speaker A
когда публикуется [музыка] digдст, сразу же знания, которые туда добавлялись, которые мог увидеть только тот, кто их добавил или, возможно, кто ревюер эти знания, у нас все остальные участники команды видят, что же произошло. То есть дать же сделать запись, видимой всем, а
Speaker A
не одному ревюеру. И возможно в этой точке кто-то может увидеть: "О, что-то новое пришло, дай почитаю, дай посмотрю". Или скажет, что вы там сделали? Потому что взгляд человека очень важен, а база наших знаний, она невероятно важна, потому что это чистота
Speaker A
нашего контекста. Чем наш контекст, чем лучше понимание системы у агентов, тем лучше мы будем получать качество на выходе. Следующая роль этого агента, он ищет факты, которые бьются друг с другом. И это у нас концепт дрифт из второго механизма. И при этом также
Speaker A
пишет в наш чат: "Вот расхождение. Решайте, что с этим делать". Поэтому человек не сидит на каждой записи, а подключается только когда есть на что смотреть. Третье. Если факт памяти разошёлся сырым источником, грумер пишет об этом сразу. Зачем это [музыка] нужно,
Speaker A
мы с вами разберём в отдельном большом блоке в этом видео. И все эти три задачи нашего грумера про одно. Общую память бросают не потому, что она ошибается.
Speaker A
Ошибаются все. Её бросают, когда ошибки становятся необъяснимыми. Запись пропала или непонятно, что произошло. Агент ответил чушь. Непонятно, откуда он взял эти данные. Так вот, когда у вас памяти, которую вы шарите внутри команды, будут постоянно происходить странные вещи, то
Speaker A
команда перестанет доверять этой памяти. А память, которой не верит, она мертва. Так вот, якорь, дайджест, [музыка] сверка с нашими сырыми данными - это не порядок ради порядка. Это чтобы у каждой ошибки был адрес.
Speaker A
В какой форме надо держать наши знания? И здесь часто возникает путаница, потому что кажется, что надо выбрать какой-то один инструмент и с ним работать. Не надо. Инструментов под каждую форму очень много, а самих форм всего четыре.
Speaker A
И вопрос не какую взять, а как их между собой можно объединять и дополнять, и когда какая нам с вами пригодится.
Speaker A
Первое. Проза или вики или маркдаун. Модель пишет связанные страницы из источников документация отчёты разборы инцидентов, ответы на вопросы, почему мы так решили, и осмысляет на входе: положить дорого, считать дёшево.
Speaker A
Расплата, потери при синтезе и протухании. По форме это будут просто маркдаун файлы. И Карпатый показал, как их разложить в рабочую видь. Источники отдельно, синтез отдельно, сверху индекс файла, по которому агент находит нужное.
Speaker A
И можно взять какой-либо инструмент, очень популярен обсидиан. Там у нас [музыка] будет красивая грав View и связи. Всё это можно посмотреть и использовать работать. Знание при этом живёт в файлах. Так вот, когда его использовать, когда важно, почему. И
Speaker A
читателей больше, чем писать. Структурные записи. У каждого факта жёсткая структура, и она разбита на поля. Сам факт, источник, время, что он заменяет возможно какие-то дополнительные [музыка] метаданные. По полям можно точно искать. Дай все решения по сервису платежей за квартал.
Speaker A
И писать могут хоть 10 агентов раз, потому что работает это на запросе. Но при этом связь между фактами и сплошной нарратив мимо. Строка знает свои поля, но не знает, как сцеплено соседней. И здесь мы можем с вами выбирать любую
Speaker A
базу данных для хранения таких факторов. Так вот, использовать такую структуру мы можем, когда нужны фильтры по времени или источнику или каким-то другим параметрам, и при этом писателей больше одного. Граф - это сущности и связи.
Speaker A
Берём его, когда ценность не в самих фактах, а в том, как они между собой связаны, что от чего зависит и что чем заменилось. Над кодом это, например, график. Прогнал репу через парсер и виден божественный хелпер внутри payments, на котором висит [музыка]
Speaker A
половина этого модуля. При этом в документации про него нет ни единого слова. Над знанием граф строят из-за разговоров и решений от граффити до когни. Свежий отчёт от mero по состоянии агентской памяти фиксирует тот же самый сдвиг. Графовое ушло из экспериментов
Speaker A
prodдаction, но не как всем нужна графовая база, а как когда чистого вектора недостаточно и связывание сущностей встраивается прямо в пайплайн.
Speaker A
Сила графа там, где ответ собирается из нескольких источников. При этом слабое место у всех графах общее. И оно не в чтении, читают быстро, оно в построении.
Speaker A
Модель должна из каждого куска вытащить сущности и связи. И это довольно дорого. При этом, если извлекать и не сверять с тем, что уже есть в графе, то новое у нас с вами ложится рядом со старым, и противоречие копится ровно как у команды
Speaker A
из нашего прошлого блока. Вектор и имбединг. Здесь, когда нам нужен нечёткий поиск по смыслу, то есть нам надо найти похожее, когда точных слов мы не знаем и наш греб бессилен. Это также работает на запросе. При этом источником правды это держать нельзя. Имбединги не
Speaker A
помнят ни источников, ни времени, потому что он нам отвечает, что одно похоже на другое, а похоже не значит, что верно и не значит, что это свежая информация.
Speaker A
Так вот, эти формы хранения, они не конкурируют, они у нас с вами объединяются, и каждая закрывает то, на чём слепы другие. И поэтому мы не выбираем форму, в которой мы будем хранить наши знания, а мы смотрим, какая у нас структура данных, и мы можем
Speaker A
собрать различные слои для нашего мемоory, которые будут закрывать недочёты друг друга. При этом любую из этих четырёх форм хранения можно забросить, не следить за ней, и это всё приведёт к протуханию нашей мемори.
Speaker A
Поэтому давайте разбираться, как узнать, что память соврала. И раскол идёт по той же линии, что в первом вопросе. Осмыслять на входе или хранить сырым? Те, что хранят сырым и собирают на запросе. Структура, граф, вектор поверх них. Они протухают
Speaker A
пробелами. Факт устарел или его не положили. Но если мы уже что-то туда положили, то оно лежит как есть. Поэтому в целом мы можем найти пробелы и заполнить их информацией. А то же, что осмысляет на входе Вики, оно стареет
Speaker A
немного иначе. не пропусками, а порчей самого пересказа. И эта петля порчи, она не где-то в чужих стартапах. Она, скорее всего, включена у тебя прямо сейчас, если ты используешь Д-код, то он с февраля ведёт Autemory. Агент сам пишет себе заметки о проекте и при старте
Speaker A
сессии грузит первые 200 строк, а фоновая консолидация эти заметки периодически пересобирает. Возможно, конечно, в новых релизах уже что-то по-другому, но так оно было устроено на момент записи. То есть агент пересказывает собственные записи, и поверх стоит грумер, который пересобирает пересказы. И это довольно
Speaker A
удобно, но давайте посмотрим, что же может происходить с фактами в такой петле. И мерили это на цепочках перевода. Брали текст, разгоняли через перевод и обратно, круг за кругом, и считали, сколько фактов дожило. Так вот, доживо мало, и подмены правдоподобны.
Speaker A
Водители грузовика превращаются в водителю автобуса. Штрафы в компенсацию. Перевод - это частный случай. Общее правило, как только модель раз за разом перерабатывает собственный выход, факты осыпаются. Вики, которая пересказывает сама себя, ровно этот самый случай. И да, вы скажете, можно взять контекстное
Speaker A
окно побольше, но это не спасает, но по другой причине, чем принято думать. Тут две разные вещи, и их легко склеить.
Speaker A
Первое - это Lost in the middle. В начале и в конце контекста модель достаёт лучше, чем в середине. И вторая - это контекст road, то есть протухание контекста. Chронова 18 актуальных моделей, включая те, что с миллионными окнами. Сыпятся все и вывод жёстче
Speaker A
позиционный. Точно падает уже от самой длины, когда даже нужный факт лежит удобно и никакой середины нет. Поэтому большое окно проблему не убирает.
Speaker A
Упихать всю Вики в контекст - это прямой [музыка] путь в деградацию, а не обход.
Speaker A
Самый наглядный родственник, то, что в неч назвали Model копapс. берут модели, скармливают ей её же собственный выход.
Speaker A
Да, обучают, повторяют. К девятому кругу текст, начинавшийся про средневековую архитектуру, выродился про перечисление видов за при этом часть из них не существовала. Это про обучение на синтетике. Это не один в один про наш инфиренс, но интуиция та же, и бьёт она
Speaker A
в нашу вид. [музыка] Наша уверенная проза могла давным-давно оторваться от фактов, если мы суперинтенсивно используем её. Есть и прикладная цифра с оговоркой. Зеп на своём битчмарке сравнил, как разные виды памяти [музыка] отвечают на вопросы. Подход, где старая сжимается в пересказ, а потом пересказ в
Speaker A
пересказ. Ответил верно, примерно на треть. Память, где факты лежат с источником и по кругу не пережимаются, около 95. Это их собственный прогон и их продукт в нём, конечно, выигрывает.
Speaker A
Направление при этом совпадает с независимыми работами. Отсюда ответ на следующий вопрос, и он несимметричный.
Speaker A
Заброшенная структура стареет как незнание. Пробелы можно обнаружить и их заполнить, а заброшенная Вики стареет как дезинформация. Страница читается уверенно, гладкой прозой, и не видно, что она врёт, потому что звучит как будто [музыка] бы всё верно, правдиво. И да, действительно, так оно всё и было.
Speaker A
Поэтому агент и человек может прочитать и поверить. Поэтому, выбирая сторону развилки, мы выбираем и способ протухания. Так вот, под это невидимое протухание у нас должен стоять какой-то детектор, и он должен проверять каждое наше утверждение, а значит, источник должен присутствовать под каждым
Speaker A
утверждением. То есть мы можем сверить нашу страницу сырыми данными. Если разошлось, это сигнал, что-то идёт не так. Это и есть работа нашего грумерагента, который постоянно проверяет факты сырыми данными для того, чтобы убрать этот пересказ, пересказ, пересказа, пересказа и сверить с тем,
Speaker A
что же лежит в основе всех этих красивых слов. Так что незаметное вот это старение этой прозы - это не переговор прозе. Это просто вопрос гигиены. И как мы с вами сверяем и проверяем факты, которые мы с вами накопили в этой самой
Speaker A
просьбе. У Карпатова сырьё лежит и мутабельным слоем внизу. Он сам зовёт это источником правды. Но рабочий слой тот, что агент читает и правит. Вики, и живёт она редактированием поверх себя. Страницы обновляются инкрементно, а удачный ответ подшивается обратно новой страницей. Это
Speaker A
прямо прописано, что знание должно компаудиться. Для его случая это работает. Один писатель, один читатель, [музыка] и читатель он сам, и каждый тень. И граница проходит там, где писателей становится больше одного, а порча невидимый для остальных. С этого момента схема переворачивается.
Speaker A
Пересобираемым [музыка] должно знать то, что читает, а канонам то, из чего пересобирают. Каноном становится структура с видимым владением, то есть та сторона, что стареет видимыми пробелами, а проза становится кэшом собирательным представлением, которое не жалко выкинуть. Механика такая: новая
Speaker A
добавляется в базу с источником и временем. И это переживает параллельную запись. Агенткомпилятор по расписанию читает базы и пишет Вики страницы, проставляя ссылки и подмечая, где факты противоречат. И именно поэтому Вики мы руками не исправляем. Вообще это как правка руками кэша, абсолютно
Speaker A
бессмысленное занятие, потому что мы с вами записываем [музыка] мимо наших фактов, мимо сырых данных, из которых потом весь этот кэш создаётся. А также это может привести к тому, что версий правды у нас теперь стало несколько. И какая [музыка] из них настоящая, никто
Speaker A
не знает. Поэтому любая ошибка в нашем КШ или в верхнем представлении, возможно, Вики чинится в одном месте в данных, которым мы доверяем. То есть поправили факт в базе, пересобрали.
Speaker A
Также ещё момент, почему не стоит писать все факты напрямую Вики, если мы держим сырые данные как источник нашей правды.
Speaker A
Потому что если кто-то дописал в собираемую страницу решение или наблюдение не поверх нашего канона, а просто туда, где было под рукой, то следующая наша перезрка, она его не исказит, она его просто сотрёт, потому что в нашем источнике не было этой
Speaker A
информации, и в новой версии нашей страницы также не будет. Поэтому правило, каждое утверждение собираемой страницы обязаны вести туда, где факт лежит долговечно. Утверждение без такой ссылки это уже потерянное знание. И в этом случае страница не отрывается от реальности, потому что каждый раз она
Speaker A
пересобирается заново. И вход будет источник, а не прошлая версия этой страницы. Да, это, конечно, не бесплатно, потому что каждая пересборка гоняет модель по источнику. Это наши токены и время. Но с другой стороны, если мы накапливаем какие-то плохие факты или дезинформацию, это опять же
Speaker A
будут сожжённые токены и время. Поэтому компиляция и груминг по расписанию раз в день или по событию и сводка собираются из сырого лога, не из вчерашней сводки, иначе мы вернёмся в эту плохую петлю обратно. [музыка] И да, получается, что
Speaker A
мы храним и сырьё, и сводку. И это у нас как дубль выглядит, но при этом у них абсолютно разные роли. Цельё - это источник правды. Его мы не трогаем. А сводка - это наш кэш. В любой момент мы
Speaker A
можем его выкинуть и собрать заново. Диагностика по симптомам. Если агент второй раз идёт в тупик, который вы уже проходили в прошлом месяце, значит, нет памяти по решению, которая могла пережить это время. И, возможно, знание живёт в контексте одного какого-то
Speaker A
вашего прогона. Или агент уверенно отвечает процессом, от которого команда отказалась весной. устаревание не помечается и древ никто не ловит. И то, с чего мы начали, тот вопрос про Кавка.
Speaker A
Теперь видно, что с ним случилось. И это была не одна поломка, а все наши пять вопросов, отвеченные дефолтами.
Speaker A
Осмысление на входе без сверки сырыми данными. Пересказ кормил пересказ. Писал кто угодно и как угодно. Под самым убедительным утверждением не было источника правды. И, конечно, детектор вранья не стояло. Поэтому некому было заметить, что страница разошлась с нашей реальностью, а кэш работал каноном
Speaker A
страницы правили и читали как правду. Так вот, давай теперь обозначим эти вопросы, на которые надо ответить.
Speaker A
Первый, когда агент осмысляет знания на входе или на запросе. Второй, кто имеет право писать и что происходит при конфликте. Третий, чем каждый факт привязан к источнику. Четвёртый, как я узнаю, что память соврала. И пятый, что является [музыка] источником правды, что является кэшом. И
Speaker A
ответы на эти вопросы у каждого проекта будут свои. Так вот, ответив на эти вопросы, мы можем подобрать тот инструмент, который подходит именно для нашего проекта, команды, процесса, для того чтобы эта база знаний нам помогала в разработке и ни в коем случае нас не
Speaker A
замедляла. А если же вы просто взяли какой-то инструмент и не ответили на эти вопросы, то, возможно, со временем вы выстрелите себе в ногу тем, что знания устарели, перезаписались или, возможно, очень сильно исказились. И в большом продакшене, где работает большая команда
Speaker A
и множество агентов, чаще всего это не один инструмент, а связка множества, и у каждого может быть своя. Поэтому, выбирая систему хранения для ваших агентов, ваших команд, подумайте и ответьте на эти вопросы. А потом следуйте гигиене для того, чтобы эта
Speaker A
база знаний ни в коем случае не протухла и несла только пользу. Спасибо за внимание. Хорошего вечера.
Topics:память агентовмультиагентные системыкодинг-агентысинтез знанийструктура данныхконфликты записиLLM викиуправление знаниямипотеря данныхкоординация агентов
