После каждой итерации достаточно говорить "вперёд"
Там агент это уже сам делает :) Ну, если последнее сообщение не от юзера, он добавляет "продолжи цикл", и фраза настраивается :) - он автоматически вызывает модель циклично. Точнее там два режима - автоматический и ручной.
В будущем думаю провести эксперименты конкретно с памятью. Думаю поработать с моделью, и заодно проверить несколько стратегий. Опыт показал, что сильное усложнение стратегии управления памятью может заставлять модель забывать какие-то детали. Хотя идея планировщика для модели это интересно, это мог бы быть плагин...
Если проект наберет много звезд на GitHub, запилю специальный адаптер c цитатами Лемми Килмистра (Motorhead). Представьте агента, который выполняет код в цикле под звуки "Ace of Spades".
При запросе передается контекст диалога, то есть когда идет запрос к модели, передаются предыдущие сообщения, и количество этих сообщений устанавливается в настройках. В этом смысле сессия та же.
У меня нет пользователей, которым нужно что-то программировать. Это проект на github а не сервис.
С практикой, которую вы называете "сложившейся", я не знаком. Возможно, вы её сложили сами. Советы принял — они просят игнор. Недостаток аргументов с вашей стороны не позволяет всерьёз обсуждать стек.
Что касается 1С — отличная идея. Искренне советую заняться. ;)
Да, это возможно, однако как показала жизнь, этого лучше избегать. Если мы имеем дело с системным промптом, то лучше избегать любых лишних условий. Вообще. Если перевести это на программирование, то будет как-то так...
```
<?php
// Плохо - куча лишних проверок, перегруженный промпт
function badExample($request, $budget) {
if ($budget > 0) {
if ($request !== null) {
if (!empty($request)) {
echo "Budget: " . ($budget - 5) . "\n";
if (($budget - 5) > 0) {
echo "Budget: " . ($budget - 10) . "\n";
return "Response";
}
}
}
}
return "Failed";
}
// Неплохо, промпт простой и понятный для нас и для модели
function goodExample($request, $budget) {
if (empty($request) || $budget < 10) return "Failed";
return "Response";
}
?>
Если перевести (очень условно но все-же) это на жизнь, то возможно представить что мы просим ребенка (пусть и умного) что-то сделать. И при этом ставим кучу условий. И он начнет путаться, начнет совершать ошибки. Но в нашей-то задаче мы хотим более надежный результат... И прямо сразу (насколько реальность позволяет)... :)
Да, 10$ так как проект не является коммерческим. Краудфоундера не ищу, но если кто-то захочет поучаствовать в проекте (и не только деньгами), я буду признателен и счастлив. Относительно "выкинуть PHP" - этого не будет. Я могу аргументированно объяснить, почему для этого проекта выбран PHP + Laravel + Vue.js однако как мне кажется, что-то доказывать будет бесполезно :) Если появятся "солидные инвесторы" (ваши слова), я думаю, они оценят качество проекта (техническое, и поверьте, для MVP это много), однако, давайте по-правде: вот я напишу это на условном пайтоне, которого я не знаю. Вы скорее всего первый напишете о недостатках качества проекта. Поэтому, я предлагаю, оставить мне решения по выбору стека технологий для проекта. К тому же, вокруг проекта пока что нет сообщества, поэтому логично будет если решать буду я и только я. Хотя я сейчас готов обсуждать с кем угодно и что угодно :). А 1С для этого мало подходит, вы же и сами знаете...
Я об этом рассуждал, дофамин правильно, но... Кажется одна из моделей на которых тестил его называла "допамин", я подумал "ну ладно, как хочешь" :) Может потому что они обучены лучше всего на английском и эта такого слова по-русски не знала. Но да, наверное стоит грамотно употреблять.
Это точно. Однако, я именно на платных моделях получал лучшее качество (лучшее чем на небольших бесплатных, если точно и честно сказать, исключительно из существующего опыта) :( С одной стороны разные эксперименты/исследования конечно лучше проводить на локальных моделях, но чаще будет разочарование в самой модели :) А так, на платных конечно дорого. Эта штука оказалась очень прожорливая на токены, и любые тесты часто выходят недешево. На моем ноуте Intel® Core™ i5-1335U processor Deca-core 1.30 GHz c Intel Iris Xe уже инферренс на 8b модели - это сверхмазохизм, что уж говорить о чем то большем...
Спасибо, обязательно попробую, как выложу новую версию агента! Промпт на китайском это действительно интересно, главное чтоб потом модель не отвечала на китайском :) Кстати, вчера еще дополнил плагин shell, добавил опцию: когда выполняется команда shell, то когда модели к сообщению прикрепляется результат выполнения, перед ним ставится имитация системного промпта :) Ну, там в ней реальный пользователь, реальная текущая директория, реальный хост, но это просто добавленная строка. Хочу посмотреть что будет, будет ли полезно, сделал опцию отключаемой :)
А вот с векторными базами надо будет отдельно ознакомиться, никогда с ними не сталкивался, и пока что не задумывался о реальном применении в рамках данного проекта. Спасибо огромное!
Память хранится в пресете вместе с системным промптом. То есть переключим пресет, и цикл пойдет уже с другой памятью и системным промптом. При этом с каждым вызовом в системный промпт идет последняя память, то есть, агенту не нужно её смотреть. В данном эксперименте предполагается, что модель только пишет в память, а то что записала она уже "знает". На текущий момент персистентная память ограничена 2000 символов, однако в новой версии, которая вскоре будет залита на github, там уже у плагинов-команд будут кастомные настройки, в том числе и размер памяти. Основной проблемой, кстати, оказалось то что чем больше памяти тем сильнее размазывается контекст, поэтому когда передаем предыдущие сообщения в контекст их не должно быть сильно много. Даже лучше немного...
Спасибо :) У меня это зрело очень долго, года три наверное... А потом когда уволился с работы, появилось время немного и занялся... Кстати, вы даете очень интересные идеи, спасибо :) Я обязательно обдумаю подобные вещи. Однако, я заметил один очень важный момент: хуков не должно быть много, и даже чем их меньше тем лучше. Модели сложно если можно так выразиться "держать это в голове". Возможно с дообучением самой модели, это было бы более реально, но сейчас даже если взять готовую и мощную модель, то все-таки лучше соблюдать несколько моментов:
1. Максимально краткий и эффективный системный промпт. С одной стороны чем короче тем лучше. 2. Система плагинов должна быть максимально примитивной. Знаю, звучит странно, но как оказалось то что нам кажется логичным, крутым и понятным, не всегда так для модели. Я таким образом три раза переделывал систему плагинов, пытаясь найти оптимальный вариант, и не совсем уверен что он и сейчас оптимальный :) 3. Контекст не должен быть слишком большим. Примерно не больше пяти сообщений, а на более мелких моделях и того меньше. 4. Повторюсь, но... Специально дообученная модель :)
Если бы я знал раньше что нечто подобное существует, я бы пожалуй использовал это а не писал свой, но всё равно не жалею...
К вашим словам хотел бы добавить, что наиболее чистый и качественный эксперимент был бы на специально обученной модели. И чем больше что то по проекту делаю и тестирую, тем больше в этом убеждаюсь. Но это затягивает, и сложно остановиться :)
Я как раз вчера думал, что хочу реализовать...
1.Система управления плагинами, а точнее кастомные настройки плагинов. Почти реализовал. 2. Добавление своих плагинов посредствам composer. 3. Плагины для выполнения Python и JS, плагин переключения пресета и останова цикла. 4. Пайплайны. Чтобы в одной итерации возможно было использовать несколько пресетов цепочкой.
Для меня это начиналось как "проект на коленке посмотреть что будет", а потом как то прорвало, и прямо интересно стало. И чем больше втягивался, тем более приятно было над этим работать. Я сам не дата-инженер, и много нового для себя открываю работая с этим, и понятно точно не всё :). Уже вплотную задумался о покупке видеокарты :)
Обязательно будет, и лог и видео и описание эксперимента в следующих статьях. Последний раз когда пытался снять публичное видео, вскрылись некоторые недостатки агента, вроде использования eval() при выполнении кода и подобное. На днях будет большое обновление по проекту, и займусь экспериментом. Если кратко то было вот что при моих предыдущих попытках: 1. Достаточно продвинутая модель вполне выполняет код, действует и пытается выполнять задачи. 2. Ключевое - системный промпт. От его формирования зависит вообще всё. 3. Достаточно сложно бороться с "размазыванием контекста" - чем больше системный промпт, тем модель его усваивает более фрагментарно. На больших моделях проблем меньше, но они присутствуют. Здесь я вижу выход именно в дообучении модели не как ассистента, а как агента. 4. Пересказ прошлых попыток такой: модель создала структуру таблиц в бд, начала использовать команды для мониторинга сервера, пытаться оптимизировать бд и зациклилась на этом, однако, при этом, часть времени уделяла пополнению своей БД пытаясь использовать различные АПИ (но там в системном промпте была установка организовать свою логику хранения памяти). При вмешательстве пользователя откликалась и пыталась выполнять задачи. Контекст я давал небольшой, и большую историю сообщений лучше не отправлять, максимум 4-5 сообщений, и в системном промпте обязательно объяснить как работать с памятью.
Пока что предварительно вывод один: идеальным было бы дообучение модели под такое использование (работа в цикле, команды и т.д.). И модель должна быть не столько всезнающей сколько агентской. То есть это не должна быть сильно тяжелая модель, это должна быть как раз не сильно тяжелая модель, с упором в дообучении именно на агентское поведение, более глобальное мышление (не как модель ассистент которому нужно помочь юзеру здесь, сейчас и по именно вот этому вопросу). В будущей статье я это всё попытаюсь максимально раскрыть и донести, максимально задокументировав.
С одной стороны кажется нерационально, однако, мне видится, придет время, и это станет обыденной повседневностью. Просто сейчас это всё проходит свой путь. И еще на разных задачах такие решения могут показывать разную эффективность, но сейчас сама эта тема на пике популярности, и происходит путь экспериментов, создания собственного опыта, проб и ошибок. В целом, много процессов протекает подобным образом...
Абсолютно согласен, если бы модель работала исключительно в замкнутой системе. Но здесь предполагается доступ к любым внешним источникам, вмешательство пользователя, выполнение реальных действий и подобное. Это только путь, это ведь не что-то финальное, и я ни в коем случае не претендую на то чтоб прямо создать что то production ready. Это просто эксперимент, и он может быть как успешным так и не успешным. С научной точки зрения неуспех эксперимента в каком-то смысле тоже успех :)
В следующей статье обязательно будет, уже не про сам агент а про его испоьзование. Но по факту, мне кажется, это будет зависеть от стартового промпта :)
Там агент это уже сам делает :) Ну, если последнее сообщение не от юзера, он добавляет "продолжи цикл", и фраза настраивается :) - он автоматически вызывает модель циклично. Точнее там два режима - автоматический и ручной.
UPD, понял, предлагаете симуляцию. Ок, завтра протестируем :)
В будущем думаю провести эксперименты конкретно с памятью. Думаю поработать с моделью, и заодно проверить несколько стратегий. Опыт показал, что сильное усложнение стратегии управления памятью может заставлять модель забывать какие-то детали. Хотя идея планировщика для модели это интересно, это мог бы быть плагин...
Если проект наберет много звезд на GitHub, запилю специальный адаптер c цитатами Лемми Килмистра (Motorhead). Представьте агента, который выполняет код в цикле под звуки "Ace of Spades".
В этой реализации новая сессия. Иначе было бы невозможно получить полный контроль над контекстом.
При запросе передается контекст диалога, то есть когда идет запрос к модели, передаются предыдущие сообщения, и количество этих сообщений устанавливается в настройках. В этом смысле сессия та же.
Я не делал веб-сайт.
У меня нет пользователей, которым нужно что-то программировать. Это проект на github а не сервис.
С практикой, которую вы называете "сложившейся", я не знаком. Возможно, вы её сложили сами. Советы принял — они просят игнор. Недостаток аргументов с вашей стороны не позволяет всерьёз обсуждать стек.
Что касается 1С — отличная идея. Искренне советую заняться. ;)
Да, это возможно, однако как показала жизнь, этого лучше избегать. Если мы имеем дело с системным промптом, то лучше избегать любых лишних условий. Вообще. Если перевести это на программирование, то будет как-то так...
```
Если перевести (очень условно но все-же) это на жизнь, то возможно представить что мы просим ребенка (пусть и умного) что-то сделать. И при этом ставим кучу условий. И он начнет путаться, начнет совершать ошибки. Но в нашей-то задаче мы хотим более надежный результат... И прямо сразу (насколько реальность позволяет)... :)
Да, 10$ так как проект не является коммерческим. Краудфоундера не ищу, но если кто-то захочет поучаствовать в проекте (и не только деньгами), я буду признателен и счастлив. Относительно "выкинуть PHP" - этого не будет. Я могу аргументированно объяснить, почему для этого проекта выбран PHP + Laravel + Vue.js однако как мне кажется, что-то доказывать будет бесполезно :) Если появятся "солидные инвесторы" (ваши слова), я думаю, они оценят качество проекта (техническое, и поверьте, для MVP это много), однако, давайте по-правде: вот я напишу это на условном пайтоне, которого я не знаю. Вы скорее всего первый напишете о недостатках качества проекта. Поэтому, я предлагаю, оставить мне решения по выбору стека технологий для проекта. К тому же, вокруг проекта пока что нет сообщества, поэтому логично будет если решать буду я и только я. Хотя я сейчас готов обсуждать с кем угодно и что угодно :). А 1С для этого мало подходит, вы же и сами знаете...
Спасибо большое! Не знал об этом. Обязательно изучу и если это реально, попробую.
Я об этом рассуждал, дофамин правильно, но... Кажется одна из моделей на которых тестил его называла "допамин", я подумал "ну ладно, как хочешь" :) Может потому что они обучены лучше всего на английском и эта такого слова по-русски не знала. Но да, наверное стоит грамотно употреблять.
Это точно. Однако, я именно на платных моделях получал лучшее качество (лучшее чем на небольших бесплатных, если точно и честно сказать, исключительно из существующего опыта) :( С одной стороны разные эксперименты/исследования конечно лучше проводить на локальных моделях, но чаще будет разочарование в самой модели :) А так, на платных конечно дорого. Эта штука оказалась очень прожорливая на токены, и любые тесты часто выходят недешево. На моем ноуте Intel® Core™ i5-1335U processor Deca-core 1.30 GHz c Intel Iris Xe уже инферренс на 8b модели - это сверхмазохизм, что уж говорить о чем то большем...
Спасибо, обязательно попробую, как выложу новую версию агента! Промпт на китайском это действительно интересно, главное чтоб потом модель не отвечала на китайском :) Кстати, вчера еще дополнил плагин shell, добавил опцию: когда выполняется команда shell, то когда модели к сообщению прикрепляется результат выполнения, перед ним ставится имитация системного промпта :) Ну, там в ней реальный пользователь, реальная текущая директория, реальный хост, но это просто добавленная строка. Хочу посмотреть что будет, будет ли полезно, сделал опцию отключаемой :)
А вот с векторными базами надо будет отдельно ознакомиться, никогда с ними не сталкивался, и пока что не задумывался о реальном применении в рамках данного проекта. Спасибо огромное!
Память хранится в пресете вместе с системным промптом. То есть переключим пресет, и цикл пойдет уже с другой памятью и системным промптом. При этом с каждым вызовом в системный промпт идет последняя память, то есть, агенту не нужно её смотреть. В данном эксперименте предполагается, что модель только пишет в память, а то что записала она уже "знает". На текущий момент персистентная память ограничена 2000 символов, однако в новой версии, которая вскоре будет залита на github, там уже у плагинов-команд будут кастомные настройки, в том числе и размер памяти. Основной проблемой, кстати, оказалось то что чем больше памяти тем сильнее размазывается контекст, поэтому когда передаем предыдущие сообщения в контекст их не должно быть сильно много. Даже лучше немного...
Спасибо :) У меня это зрело очень долго, года три наверное... А потом когда уволился с работы, появилось время немного и занялся... Кстати, вы даете очень интересные идеи, спасибо :) Я обязательно обдумаю подобные вещи. Однако, я заметил один очень важный момент: хуков не должно быть много, и даже чем их меньше тем лучше. Модели сложно если можно так выразиться "держать это в голове". Возможно с дообучением самой модели, это было бы более реально, но сейчас даже если взять готовую и мощную модель, то все-таки лучше соблюдать несколько моментов:
1. Максимально краткий и эффективный системный промпт. С одной стороны чем короче тем лучше.
2. Система плагинов должна быть максимально примитивной. Знаю, звучит странно, но как оказалось то что нам кажется логичным, крутым и понятным, не всегда так для модели. Я таким образом три раза переделывал систему плагинов, пытаясь найти оптимальный вариант, и не совсем уверен что он и сейчас оптимальный :)
3. Контекст не должен быть слишком большим. Примерно не больше пяти сообщений, а на более мелких моделях и того меньше.
4. Повторюсь, но... Специально дообученная модель :)
Если бы я знал раньше что нечто подобное существует, я бы пожалуй использовал это а не писал свой, но всё равно не жалею...
К вашим словам хотел бы добавить, что наиболее чистый и качественный эксперимент был бы на специально обученной модели. И чем больше что то по проекту делаю и тестирую, тем больше в этом убеждаюсь.
Но это затягивает, и сложно остановиться :)
Я как раз вчера думал, что хочу реализовать...
1.Система управления плагинами, а точнее кастомные настройки плагинов. Почти реализовал.
2. Добавление своих плагинов посредствам composer.
3. Плагины для выполнения Python и JS, плагин переключения пресета и останова цикла.
4. Пайплайны. Чтобы в одной итерации возможно было использовать несколько пресетов цепочкой.
Для меня это начиналось как "проект на коленке посмотреть что будет", а потом как то прорвало, и прямо интересно стало. И чем больше втягивался, тем более приятно было над этим работать. Я сам не дата-инженер, и много нового для себя открываю работая с этим, и понятно точно не всё :). Уже вплотную задумался о покупке видеокарты :)
Обязательно будет, и лог и видео и описание эксперимента в следующих статьях. Последний раз когда пытался снять публичное видео, вскрылись некоторые недостатки агента, вроде использования eval() при выполнении кода и подобное. На днях будет большое обновление по проекту, и займусь экспериментом. Если кратко то было вот что при моих предыдущих попытках:
1. Достаточно продвинутая модель вполне выполняет код, действует и пытается выполнять задачи.
2. Ключевое - системный промпт. От его формирования зависит вообще всё.
3. Достаточно сложно бороться с "размазыванием контекста" - чем больше системный промпт, тем модель его усваивает более фрагментарно. На больших моделях проблем меньше, но они присутствуют. Здесь я вижу выход именно в дообучении модели не как ассистента, а как агента.
4. Пересказ прошлых попыток такой: модель создала структуру таблиц в бд, начала использовать команды для мониторинга сервера, пытаться оптимизировать бд и зациклилась на этом, однако, при этом, часть времени уделяла пополнению своей БД пытаясь использовать различные АПИ (но там в системном промпте была установка организовать свою логику хранения памяти). При вмешательстве пользователя откликалась и пыталась выполнять задачи. Контекст я давал небольшой, и большую историю сообщений лучше не отправлять, максимум 4-5 сообщений, и в системном промпте обязательно объяснить как работать с памятью.
Пока что предварительно вывод один: идеальным было бы дообучение модели под такое использование (работа в цикле, команды и т.д.). И модель должна быть не столько всезнающей сколько агентской. То есть это не должна быть сильно тяжелая модель, это должна быть как раз не сильно тяжелая модель, с упором в дообучении именно на агентское поведение, более глобальное мышление (не как модель ассистент которому нужно помочь юзеру здесь, сейчас и по именно вот этому вопросу). В будущей статье я это всё попытаюсь максимально раскрыть и донести, максимально задокументировав.
С одной стороны кажется нерационально, однако, мне видится, придет время, и это станет обыденной повседневностью. Просто сейчас это всё проходит свой путь. И еще на разных задачах такие решения могут показывать разную эффективность, но сейчас сама эта тема на пике популярности, и происходит путь экспериментов, создания собственного опыта, проб и ошибок. В целом, много процессов протекает подобным образом...
Абсолютно согласен, если бы модель работала исключительно в замкнутой системе. Но здесь предполагается доступ к любым внешним источникам, вмешательство пользователя, выполнение реальных действий и подобное. Это только путь, это ведь не что-то финальное, и я ни в коем случае не претендую на то чтоб прямо создать что то production ready. Это просто эксперимент, и он может быть как успешным так и не успешным. С научной точки зрения неуспех эксперимента в каком-то смысле тоже успех :)
В следующей статье обязательно будет, уже не про сам агент а про его испоьзование. Но по факту, мне кажется, это будет зависеть от стартового промпта :)