Transcription
Привет. Сегодня у нас интересная тема, и агенты, и конкретно как управлять их контекстом. У нас тут собраны мысли инженеров, основателей компаний, но тех, кто прямо сейчас на передовой и работает. Попробуем разобраться, как извлечь максимум из моделей, особенно для сложных штук. Ну, там код писать или когда диалог долгий. И хочется понять это без погружения в совсем уж хардкорные технические дебри. Это ведь больше, чем просто промты писать.
Да, именно так. Ну, по сути, мы говорим о том, чем мы кормим, и тут всё довольно прямолинейно, я бы сказала. Качество результата, оно напрямую зависит от качества того, что на входе, то есть от контекста. Это основа.
Хорошо, давай тогда копать глубже. Что вот это такое управление контекстом или там инженерия контекста? Что за этим стоит?
Процесс принятия решений. Решение о том, что именно должно попасть в так называемое окно контекста модели прямо сейчас, в этот момент времени. Окно контекста - это, ну, если грубо, сколько информации модель может одновременно видеть и обрабатывать. И туда входят не только инструкции команды, но и важная информация по теме, история переписки, примеры какие-то. Это сложнее, чем просто промт инженеринг. Тот больше про то, как спросить, а инженерия контекста про то, на основе чего модель будет отвечать. Это более стратегическая штука.
Логично. Но ведь сейчас столько разговоров про огромные окна контекста. Миллионы токенов. Токен - это же у нас слово или часть слова?
Да. Единица текста для модели. И звучит так, будто вот оно решение. Загрузил туда всё, что есть, и готово. Модель сама разберётся.
Эх, если бы. Звучит, конечно, заманчиво, но на практике, вот, честно, не так всё радужно. Есть исследования, вот тот же технический отчёт хрома, Джейф его упоминал. Они показывают, реальная производительность моделей, она начинает падать и падать сильно раньше, чем мы добираемся до этих теоретических миллионов токенов. Даже на, казалось бы, простых задачах что-то извлечь из текста. Джефф приводил пример, там точность ответов прямо резко падала, когда контекст был всего-то тысяч 10 токенов.
То есть больше не значит лучше, просто объём сам по себе не гарантирует результат.
Именно вот эти тесты, которыми лаборатории любят хвастаться, иголка в стоги сена, но это когда модели нужно найти один-единственный факт в огромном тексте. Джефф прав, говорит: "Это же очень узкая задача". Она проверяет, ну, найдёт модель кусочек или нет. А реальные задачи сложные, скажем, проанализировать большой кусок кода или написать статью по куче источников. Там же надо не просто найти, а синтезировать, понять связи, удержать внимание, рассуждать на основе большей части контекста. А вот с этим у моделей, когда контекст очень большой, пока проблема.
И это, наверное, выливается в какие-то конкретные проблемы. Вот в разработке софта, например.
Да. Да. Безусловно, Dex из Human Layer, он ссылался на исследование Стэнфорда. Они там анализировали данные 100.000 разработчиков, представляешь? И оно показало, что когда ИИ используют в разработке, часто получается много реворк, ну, переделок. То есть вроде быстро что-то написал, а потом сидишь и долго это допиливаешь, исправляешь, потому что оно не совсем точное или неэффективное или в систему не вписывается. Особенно это касается сложных задач. Или когда работаешь с унаследованным кодом, ну, с таким, знаешь, старым, запутанным проектом, Brownfield Tasks их называют. Вот там по данным исследования ИИ может даже замедлить разработку.
Ясно. Значит, стратегия "вали всё в кучу" не вариант. А что тогда работает? Какие подходы более осмысленные? Декс, кажется, говорил про какую-то эволюцию.
Да, он так разделил по уровням зрелости, скажем так. Самый базовый уровень - это когда ты просто кричишь на агента, ну, повторяешь команды, пытаешься скорректировать, пока лимит контекста не кончится. Или терпение, знакомая многим история, да? Чуть более продвинутый, когда видишь ошибку, останавливаешь всё, перезапускаешь, но уже с уточнениями: "Нет, сделай вот не так, а эдак".
Но был же и какой-то более системный подход про намеренное сжатие, что-то такое.
Точно. Намеренное сжатие. Intentional compaction - это вот прямо центральная идея Декса. И суть не в том, чтобы просто историю почистить, а в том, чтобы активно управлять тем, что в контексте находится. Цель его - оптимизировать по нескольким параметрам сразу: корректность, нет ли там ошибок, устаревшей инфы; полнота, всё ли нужное там есть; размер, не слишком ли он раздут для модели; и ещё траектория, то есть ведёт ли вот этот текущий контекст нас к конечной цели. Самое главное - убрать всю нерелевантную информацию, неполную, избыточную, весь этот шум, который модель только сбивает.
Звучит как такая серьёзная инженерная работа. А как это на практике делают? Он упоминал, что стандартные команды типа "компакт" они не очень.
О, Декс про них довольно резко высказался. "Мусор", говорит. Вместо этого его команда придумала делать специальные файлы прогресса. Это такие структурированные документы. В них чётко описывается, что сейчас с задачей происходит, что сделано, какие выводы, какие решения приняли, что дальше делать. И вот этот файл потом становится главным контекстом для следующего шага или когда ты к задаче возвращаешься. Это позволяет сохранить саму суть, а всю шелуху диалога, все эти попытки и ошибки отбросить.
Интересный подход. А были ещё какие-то взгляды, как вот фильтровать контекст, формировать его?
Да, у Джефа из Хрома была похожая идея, но метафора другая. Собрать и отобрать. Gather and Glean. Первый шаг - собрать (Gather). Тут задача - собрать вообще всю потенциально нужную информацию. Стремимся к полноте, даже если лишнего захватим. Источники разные. Поиск по документам, по векторным базам. Chrome как раз этим и занимается. Вызовы API, файлы локальные, история чата. Иногда сама LLM может помочь нагенерить кучу поисковых запросов, чтобы больше данных собрать. А второй шаг - отобрать (Glean). Вот тут уже идёт тщательная фильтрация. Цель - максимальная точность, релевантность. Убираем шум, оставляем только самое-самое важное. И тут тоже разные техники. От простого отбора топ-результатов поиска до более хитрых штук. Например, реципрокное ранжирование - это способ так скомбинировать результаты из разных списков, чтобы быть увереннее, что они релевантны. Или даже можно подключить другие LLM, попроще и подешевле, чтобы они оценили пользу каждого кусочка информации перед тем, как давать его основной большой модели.
И конечная цель всех этих манипуляций - держать контекст относительно небольшим. Декс вроде цифру называл, да?
Декс говорил, что они стараются, чтобы окно контекста было заполнено меньше, чем на 40%. В наше время, когда все говорят про миллионы токенов, это может показаться странным, да? Но вот их опыт, их тесты показывают, именно так получаются лучшие результаты для сложных задач, особенно в кодинге. Меньше шума - модель работает качественнее.
Декс ещё описывал конкретный рабочий процесс для кодирования, который, как он сказал, их команде сильно помог. Можешь про это подробнее.
Управление контекстом и контроль человека на важных этапах. Сначала агент проводит исследование (research), изучает код, который уже есть, анализирует зависимости, разбирается, как система работает, где именно менять надо. Результат этого этапа - такой структурированный отчёт прямо со ссылками на файлы, на строчки кода. Потом на основе этого отчёта агент составляет детальный план (Plan). Что конкретно меняем, в каких файлах, какие функции затронем, как это на систему повлияет, как будем тестировать. И только потом, когда человек, разработчик, этот план посмотрел, одобрил, вот только тогда агент переходит к реализации (Implement), то есть пишет или меняет код.
А в чём тут главный плюс? По сравнению с тем, чтобы просто сказать "напиши мне вот эту фичу".
Ключевой момент. Декс на этом прямо настаивал. Это что проверяет человек? Вместо того, чтобы копаться в тысячах строк сгенерированного кода и пытаться понять, оно вообще работает? Оно туда идёт? Разработчик смотрит на гораздо более компактные штуки, но концептуально важные. Отчёт об исследовании и план действий. Это позволяет намного эффективнее всех в команде настроить на одну волну. Ну, mental alignment, как он сказал, и ошибки ловить на самом раннем этапе, концептуальные ошибки. У Декса была отличная аналогия про иерархию ошибок. Ошибка в исследовании. Не так поняли систему. Это могут быть тысячи строк бесполезного кода. Или даже вредного. Ошибка в плане - это уже сотни строк не того кода, а ошибка уже при написании кода - это гораздо меньшая проблема. Этот подход как бы фокусирует внимание человека там, где оно ценнее всего. И именно он, по словам Декса, позволил им решать реально сложные задачи, там исправить критическую ошибку в огромной кодовой базе BAML или очень быстро, за 7 часов запилить новую фичу вместе с SEO компанией Boundary.
Понятно. Этот структурированный подход помогает управлять активным контекстом, тем, что нужно прямо сейчас. Но вот информация, которая должна храниться дольше между сессиями, например, или в длинных многошаговых задачах. Сэм из Master, он же как раз про память агентов говорил.
Да, память агента - это ещё один суперважный элемент, особенно для долгих взаимодействий. По сути, память агента - это и есть такое управляемое, сжатое представление всей истории диалога, всех накопленных знаний. Сэм рассказывал про бенчмарк Long Memory Evaluation. Они его создали и использовали, чтобы оценивать и улучшать память в своём фреймворке Master. И в этом бенчмарке есть разные типы задач, которые проверяют разные аспекты помятливости агента.
Какие именно аспекты?
Ну, там несколько главных. Во-первых, просто достать факт, который упоминался когда-то давно в другой сессии. Во-вторых, временное рассуждение, то есть, чтобы модель понимала, что было раньше, что позже, на основе истории. В-третьих, обновление знаний. Когда новая информация приходит, она должна правильно заменить старую или дополнить её. Сэм приводил смешной пример про себя. ChatGPT упорно считала его пятилетней девочкой, которая обожает игрушки Squishmallows, просто потому что он часто обсуждал их со своей дочкой. Модель как-то неправильно обновила знания о нём. И, наконец, способность агента понять, что нужной информации в его памяти, то есть в контексте, просто нет. И не пытаться выдумать ответ, не галлюцинировать.
Интересно, а как они на практике это улучшали? Память эту.
Сэм описал несколько этапов улучшений, как раз по результатам тестов на этом бенчмарке. Например, они поняли, что лучше не перезаписывать всю рабочую память агента каждый раз целиком, а делать более точечные, целевые изменения. Так меньше риск потерять что-то важное или внести ошибку. Ещё оказалось критически важно правильно использовать временные метки (timestamps) для каждого кусочка информации. Плюс помогло структурирование истории, ну, например, группировать сообщения по дням или часам. Это улучшило как раз временное рассуждение. В общем, выяснилось, что даже то, как информация из долговременной памяти извлекается и подаётся модели, вот прямо сейчас в текущем контексте, это сильно влияет на результат.
Так хорошо. Память помогает держать нить разговора, состояния. Но как убедиться, что каждый отдельный шаг, который агент делает, используя эту память, этот контекст, что он корректный, надёжный? Я так понимаю, Джейк из Context, он прямо маньячил по поводу тестирования вот этих EVALs.
Абсолютно верно. Использование EVALs (оценочных тестов) - это просто must have для создания надёжных AI-приложений. Особенно в таких областях, как юриспруденция, где Джейк работал над Counsel, там цена ошибки очень высока. EVALs - это, по сути, набор автоматических тестов для AI. Подход очень методичный. Для каждого шага, который LLM выполняет в рамках какого-то сложного процесса, ну там анализирует юридический документ или ищет похожие судебные дела, для каждого такого шага создаётся пачка тестов. И каждый тест звучит примерно так: "Если дать вот такие инструкции, вот такой контекст, например, текст документа, то правильный ответ должен быть вот таким".
И как это выглядит на практике? Запустил тест и всё?
Нет, это итеративный процесс. Сначала команда пишет, ну, скажем, 10 тестов для шага, запускают. Модель проходит, допустим, шесть из десяти. Джейк говорил, что на этом этапе многие могут сказать: "Ну, норм", но его команда шла дальше. Они итеративно улучшали промпт (инструкции), настройки модели, там температуру, примеры добавляли, пока модель не начинала стабильно проходить все 10 тестов. Потом они добавляли ещё тесты: 50, 100, 1.000. Пытались покрыть все возможные случаи, и типичные, и нетипичные, и всякие странные запросы пользователей. Crazy Shit, как он выразился. Он подчёркивал, что иногда приходилось реально не спать 2 недели, чтобы добиться стопроцентного прохождения тестов для одного важного шага.
Получается, это тест не только самой модели или промта, а всей системы целиком, от начала до конца.
Именно так. И вот что особенно важно, Джейк заметил. Эти тесты часто показывают проблемы не в самой LLM и не в промпте, а где-то раньше в конвейере обработки данных, например, в качестве той информации, которую достали из базы данных или векторного хранилища (retrieval). То есть модель может врать не потому, что она не поняла или промпт кривой, а потому, что система поиска, та же Chroma, дала ей не тот кусок текста или не полный. Или, как у них было с юридическими документами, проблема могла быть вообще в качестве оцифровки старых бумаг. OCR (распознавание текста со сканов). Если из-за плохого OCR модель на вход получает какой-то мусор текстовый, то и на выходе будет мусор. Какой бы умной LLM ни была, принцип "мусор на входе, мусор на выходе" тут работает на 100%.
Уловил. То есть, чтобы ИИ работал надёжно, мало просто хорошо просить и контекст правильно готовить. Нужно ещё очень тщательно проверять и результат, и то, на основе чего он получен на каждом шаге. Итак, давай попробуем подвести итог. Что у нас получается из всего этого погружения? Кажется, что ключ к эффективному использованию ИИ он не столько в размере моделей, не в гонке за токенами, а скорее в том, чтобы выстроить умные, такие дисциплинированные системные подходы к работе с информацией, с той информацией, которую мы этим моделям даём.
Да, можно, наверное, сформулировать несколько таких ключевых выводов, которые следуют из опыта наших источников. Первое: релевантность важнее размера. Гигантский контекст пока не панацея. Производительность страдает. Важнее качество и точность того, что в этом контексте лежит. Второе: структурируй работу и как работу команды. Подходы типа исследования, план, реализация, они помогают справиться со сложностью, улучшают взаимопонимание в команде, позволяют ловить ошибки раньше. Третье: активно управляй контекстом. Вот это намеренное сжатие, intentional compaction или фильтрация "собрать и отобрать", Gather and Glean. Это не просто опция, это необходимость для эффективности и качества. Четвёртое: тестируй неустанно. Строгая итеративная оценка каждого шага. А EVALs - это просто обязательное условие, если хочешь сделать надёжное AI-приложение, которым можно доверять. Ну и пятое: качество на входе решает. Качество данных из поиска, из баз, из истории диалога, даже качество OCR - это всё фундаментально важно. Похоже на то, что сам процесс работы с ИИ, вот эта инженерная дисциплина, выработанные практики, они становятся не менее важны, а может даже и более важны, чем сама базовая технология LLM.
Именно. И это подводит к такой, знаешь, интересной мысли для размышления. Она навеяна идеями Денса. Вот если предположить, что сами базовые ИИ-модели, они со временем станут ещё круче, доступнее, ну, и в каком-то смысле превратятся в такой стандартный товар (commodity), то не сместится ли главное конкурентное преимущество не с самой технологии на то, как компании и команды с ней работают, то есть на их уникальные процессы, на выстроенные практики управления контекстом, на системы оценки, на общую способность команды быстро адаптироваться и эффективно всё это применять? Как это может поменять требования к инженерам, к организации работы целых команд уже в ближайшем будущем?
Вот на этой ноте, пожалуй, и завершим наш сегодняшний разбор подходов к управлению контекстом ИИ. Надеемся, это было полезно, интересно и дало пищу для размышлений. До новых встреч.