Профессии промпт-инженера никогда и не было. Те кто профессионально занимается применением LLM как раз таки работает со всем спектром инструментов — контекстом, параметрами моделей выбором самих моделей и т.п., а не только с промптами.
О, это классика. Менеджеры разного уровня время от времени, насмотревшись презентаций про «успешный успех», приходят с такими идеями.
Могу привести аналогию с фастфудом. No-code/low-code — это фастфуд. Можно ли построить бизнес на фастфуде? Конечно! Особенно если вы франчайзер и продаёте фастфуд-решения, а не сам фастфуд.
Фастфуд не получает звёзд Мишлен.
И, наконец, если у вас есть сеть ресторанов и вы хотите сократить расходы за счёт превращения её в фастфуд, то у вас не будет ни сети ресторанов, ни фастфуда.
Стоит упомянуть также проблему плоского списка тулов. Это может быть не важно, если тулов пару десятков, но их точно будет становиться больше и больше. В MCP не предусмотрена иерархия или фильтрация тулов.
У современных LLM большие контекстные окна, но они как правило реализованы на алгоритмических трюках и не являются честными. Со временем это может привести к проблемам потери внимания и выбору неправильных тулов в MCP.
Так что да. Идея очень правильная, но реализация всё ещё сырая. Ждём следующие версии протокола.
Сходу видится нерешённая проблема выбора тулов. Пока их пара десятков -- это не проблема. Можно получать их все и все сразу отправлять в LLM. Но любые системы имеют тенденцию расти. И в какой то момент тулов может стать пара тысяч. Идея хорошая, но выглядит, что требуется более глубокая проработка.
Тоже зацепился глаз за это предложение. Только функция знает допускает ли её параметр неинициализированную переменную. И это часть сигнатуры функции. Давая возможность помечать переменные [[indeterminate]] мы потенциально делаем код неустойчивым к изменениям. Если мы в какой то момент заменим void fill(int&) на void bar(int&), которая не предполагает использование неинициализированных переменных, то мы не получим диагностических сообщений.
При прочтении возникла мысль, что квантизация могла бы быть дополнена дистилляцией. То есть, сначала мы проводим квантизацию модели. Полученная модель уже близка к исходной, но при этом оптимизирована с точки зрения расхода ресурсов. Затем мы проводим дистилляцию, обучая квантизованную модель на основе исходной. Этот процесс потребует значительно меньше ресурсов, чем обучение исходной модели с нуля, и позволит минимизировать потерю информации, которая могла произойти в результате квантизации.
Ссылки поправил. Спасибо. GitHub не смог отрендерить этот файл потому что там предопределённый unordered_map с 50000 значений. Я вкомпилировал словарь в бинарь библиотеки, что бы не нужно было загружать его отдельно. Это довольно большой файл.
Спасибо, что продолжаете делиться своими наработками. Вы абсолютно правы, смысл опенсорса не в том, что вам будут присылать багрепорты или писать код за вас. Хотя и в этом тоже. Эти поводы легко объяснить далёким от IT менеджерам, но они не главные. Смысл опенсрса -- счастье команды. И это вполне разумный аргумент. Высшее счастье инженера -- видеть как результатами его труда пользуются и они приносит пользу другим людям, а высшее несчастье -- работа в стол. И если у вас команда профессионалов, то выкладка кода в открытый доступ безусловно принесёт удовлетворение, мотивирует работать лучше. Кроме того, чего греха таить, когда мы знаем что наш код попадёт в опенсорс, мы прикладываем больше усилий, что бы код был максимально качественным. А вот утаивание кода приносит меньше профитов, чем принято думать. Ну и конечно, опенсорс повышает престиж компании. Ведь мы судим о компании в том числе по её коду. Рад, что ответственные люди в Яндексе на стороне прогресса. И надеюсь, что эта практика понемногу станет нормой повсеместной.
То что он забывает контекст при запросах через API это абсолютно нормально. У него нет способа помнить контекст если вы ни как его не передали. Странности в ответах могут быть связаны с настройками. Например, там есть такие параметры как temperature и top_p. Нужно правильно выбрать параметр model для максимальной близости с чатом GPT нужно выбирать text-davinci-003. Ну и наконец, вполне возможно что в чате используется модель недоступная в API.
То что я описал не применимо к временным рядам. По крайней мере напрямую. Поэтому сравнивать с авторегрессией неуместно -- это совершенно разные задачи. У меня же шла речь о классических задачах регрессии, когда по заданной обучающей выборке мы пытаемся предсказать некую непрерывную величину. Никакой привязки ко времени тут не предполагается. Согласен, что пример на реальных данных был бы уместен. Я использовал предложенный алгоритм на своих рабочих задачах. И, к сожалению, не могу опубликовать здесь результаты. Возможно позже сделаю пример на каком-нибудь открытом датасете.
Немного дополню. На предыдущей работе делал систему детектирования атак на основании определения аномалий в трафике по логам веб сервера. Основная концепция такая: атакующий будет стараться прикинуться добропорядочным пользователем, но распределения отдельных параметров трафика всегда очень специфичны и ему не известны. Т.е. невозможно подделать распределения. Этот метод хорошо сработал и позволял почти молниеносно реагировать.
А алгоритмически смысл очень простой: Подход в лоб, в виде анализ статистических характеристик (таких как статистические моменты) работает плохо и неустойчиво. Но, информационные характеристики существенно обогащают понимание закономерностей и дают устойчивые результаты. Под информационными характеристиками я имею ввиду такие вещи, как энтропии, взаимную информацию между отдельными рядами, информационные расстояния (дивергенции) и т.п.
Плюс по сравнению с нейросетевыми подходами: во-первых скорость и простота реализации. Во-вторых интерпретируемость и возможность очень чётко понять в какой из систем что пошло не так.
Скрытый текст
Проблема с такими агентами в том, что все умеют писать промпты для LLM, но лишь единицы умеют делать это правильно.
В создании агентов очень много тонкостей даже не связанных с промптами напрямую. И даже в написании промптов очень много нюансов.
По тексту я вижу, что вы взялись за такую систему не обладая опытом и экспертизой. А сначала нужно было этот опыт каким-то способом получить.
И да технология, хотя и потрясающая, всё ещё не совершенна. У неё очень много ограничений.
Профессии промпт-инженера никогда и не было. Те кто профессионально занимается применением LLM как раз таки работает со всем спектром инструментов — контекстом, параметрами моделей выбором самих моделей и т.п., а не только с промптами.
О, это классика. Менеджеры разного уровня время от времени, насмотревшись презентаций про «успешный успех», приходят с такими идеями.
Могу привести аналогию с фастфудом.
No-code/low-code — это фастфуд. Можно ли построить бизнес на фастфуде? Конечно! Особенно если вы франчайзер и продаёте фастфуд-решения, а не сам фастфуд.
Фастфуд не получает звёзд Мишлен.
И, наконец, если у вас есть сеть ресторанов и вы хотите сократить расходы за счёт превращения её в фастфуд, то у вас не будет ни сети ресторанов, ни фастфуда.
Стоит упомянуть также проблему плоского списка тулов. Это может быть не важно, если тулов пару десятков, но их точно будет становиться больше и больше. В MCP не предусмотрена иерархия или фильтрация тулов.
У современных LLM большие контекстные окна, но они как правило реализованы на алгоритмических трюках и не являются честными. Со временем это может привести к проблемам потери внимания и выбору неправильных тулов в MCP.
Так что да. Идея очень правильная, но реализация всё ещё сырая. Ждём следующие версии протокола.
Сходу видится нерешённая проблема выбора тулов. Пока их пара десятков -- это не проблема. Можно получать их все и все сразу отправлять в LLM.
Но любые системы имеют тенденцию расти. И в какой то момент тулов может стать пара тысяч.
Идея хорошая, но выглядит, что требуется более глубокая проработка.
Тоже зацепился глаз за это предложение.
Только функция знает допускает ли её параметр неинициализированную переменную. И это часть сигнатуры функции.
Давая возможность помечать переменные
[[indeterminate]]мы потенциально делаем код неустойчивым к изменениям.Если мы в какой то момент заменим
void fill(int&)наvoid bar(int&), которая не предполагает использование неинициализированных переменных, то мы не получим диагностических сообщений.Спасибо за действительно интересный обзор!
При прочтении возникла мысль, что квантизация могла бы быть дополнена дистилляцией.
То есть, сначала мы проводим квантизацию модели. Полученная модель уже близка к исходной, но при этом оптимизирована с точки зрения расхода ресурсов. Затем мы проводим дистилляцию, обучая квантизованную модель на основе исходной. Этот процесс потребует значительно меньше ресурсов, чем обучение исходной модели с нуля, и позволит минимизировать потерю информации, которая могла произойти в результате квантизации.
Wase тоже местами врёт, но не так ужасно, как Google. Хуже Гугла, наверное ничего нет
Hidden text
Посмотрите лекции Константина Владимирова на Ютубе. Они действительно потрясающие. Не только, кстати, для начинающих.
Ссылки поправил. Спасибо.
GitHub не смог отрендерить этот файл потому что там предопределённый unordered_map с 50000 значений. Я вкомпилировал словарь в бинарь библиотеки, что бы не нужно было загружать его отдельно. Это довольно большой файл.
Всё верно. Но не все используют Python для своих проектов.
Именно для этих случаев и нужны альтернативные решения.
Спасибо, что продолжаете делиться своими наработками.
Вы абсолютно правы, смысл опенсорса не в том, что вам будут присылать багрепорты или писать код за вас. Хотя и в этом тоже. Эти поводы легко объяснить далёким от IT менеджерам, но они не главные.
Смысл опенсрса -- счастье команды.
И это вполне разумный аргумент.
Высшее счастье инженера -- видеть как результатами его труда пользуются и они приносит пользу другим людям, а высшее несчастье -- работа в стол.
И если у вас команда профессионалов, то выкладка кода в открытый доступ безусловно принесёт удовлетворение, мотивирует работать лучше.
Кроме того, чего греха таить, когда мы знаем что наш код попадёт в опенсорс, мы прикладываем больше усилий, что бы код был максимально качественным.
А вот утаивание кода приносит меньше профитов, чем принято думать.
Ну и конечно, опенсорс повышает престиж компании. Ведь мы судим о компании в том числе по её коду.
Рад, что ответственные люди в Яндексе на стороне прогресса. И надеюсь, что эта практика понемногу станет нормой повсеместной.
Самый адекватный комментарий во всём этом паникёрском чате :)
То что он забывает контекст при запросах через API это абсолютно нормально. У него нет способа помнить контекст если вы ни как его не передали. Странности в ответах могут быть связаны с настройками. Например, там есть такие параметры как
temperatureиtop_p. Нужно правильно выбрать параметрmodelдля максимальной близости с чатом GPT нужно выбиратьtext-davinci-003.Ну и наконец, вполне возможно что в чате используется модель недоступная в API.
Степан Олегович Фролов.
То что я описал не применимо к временным рядам. По крайней мере напрямую. Поэтому сравнивать с авторегрессией неуместно -- это совершенно разные задачи. У меня же шла речь о классических задачах регрессии, когда по заданной обучающей выборке мы пытаемся предсказать некую непрерывную величину. Никакой привязки ко времени тут не предполагается.
Согласен, что пример на реальных данных был бы уместен. Я использовал предложенный алгоритм на своих рабочих задачах. И, к сожалению, не могу опубликовать здесь результаты. Возможно позже сделаю пример на каком-нибудь открытом датасете.
Немного дополню. На предыдущей работе делал систему детектирования атак на основании определения аномалий в трафике по логам веб сервера.
Основная концепция такая: атакующий будет стараться прикинуться добропорядочным пользователем, но распределения отдельных параметров трафика всегда очень специфичны и ему не известны. Т.е. невозможно подделать распределения.
Этот метод хорошо сработал и позволял почти молниеносно реагировать.
А алгоритмически смысл очень простой:
Подход в лоб, в виде анализ статистических характеристик (таких как статистические моменты) работает плохо и неустойчиво.
Но, информационные характеристики существенно обогащают понимание закономерностей и дают устойчивые результаты.
Под информационными характеристиками я имею ввиду такие вещи, как энтропии, взаимную информацию между отдельными рядами, информационные расстояния (дивергенции) и т.п.
Плюс по сравнению с нейросетевыми подходами: во-первых скорость и простота реализации. Во-вторых интерпретируемость и возможность очень чётко понять в какой из систем что пошло не так.
Спасибо за перевод. Очень крутая статья.
Не стоит противоставлять Пуанкаре и Эйнштейна. Они оба гениальны.