У меня ровно такие же ощущения были, когда пробовал писать своих агентов. (вот мои скромные эксперименты, для тех кому интересно почитать код https://github.com/600dc0de/ai_agents)
// Запуск одного агента в интерактивном режиме (никогда не завершается)
AgentRunner::interactive($agent, ['начальное сообщение']);
// Запуск нескольких агентов для сравнения
AgentRunner::pool([$agent1, $agent2], "Сравни эти два файла");
// Запуск агента несколько раз с одним и тем же запросом
AgentRunner::shot($agent, "Сгенерируй 5 креативных названий", 5);
// Запуск двух агентов в диалоге друг с другом
AgentRunner::polemic($agreeAgent, $disagreeAgent, "Кофе лучше, чем чай", 1);
Агент это просто "автономный чат, который слишком много себе позволяет". Фактически, все те тулзы, которые сейчас на слуху, представляют собой не особо сложные менеджеры агентов, которые можно и нужно уметь писать самостоятельно, если вы хотите минимально понимать что же там происходит под капотом.
Модульность и слияние нужно реализовать не как фичу самих конфигов, а в том месте где они подключаются, после декодирования - и при этом вообще не зависеть от формата - вот куда усилия приложить надо, а не в изобретение json диалекта
В том то и дело, что если доставка успешна (данные вернулись клиенту) - это 200.
Но HTTP же ещё много нетранспортных вещей кодирует и они в RPC на уровне отдельных запросов в батче. Т.е. внутри 1 HTTP запроса может быть 3 RPC запроса (условно bad request, access denied, server error) - в таком случае общий HTTP статус просто напросто сводится только к факту доставки, т.е. 200.
Вероятно, это можно проверить статистически - взять случайную выборку и сделать факт-чек вручную, получив некоторый "процент доверия".
Замечу, что "процент доверия" llm наверняка выше любой полученной в частной беседе информации (люди тоже "галлюционируют", но мы скромно называем это "заблуждаются"). У СМИ наверняка ниже, у википедии лишь чуть выше за счёт механизма модерации, но и он также подвержен эффекту правдивой лжи. Вообщем, llm в этом плане не сказать что сильно отличается от других источников информации. Было бы конечно интересно увидеть какие-то исследования данной темы.
Вот читаю такие статьи и складывается у меня стойкое ощущение, что AI, с одной стороны, действительно создаёт пропасть между энтузиастами и луддитами (что в целом норм), а с другой - ещё бОльшую пропасть между новичками и опытными разработчиками. Потому что джун пытается через AI бустить количество, а сениор - всё таки качество, и это буквально движение в противоположных направлениях.
Автор, перечитайте плиз свой список из 7 задач (в котором 8 пунктов, но вообще типа около 20 и из них многие дублируются). Это абсолютно бессистемное месиво.
Особого комментария заслуживает пункт с саммари созвонов. Вот бесплатный совет: всячески бойкотируйте бесполезные созвоны. Не допускайте их в свой рабочий процесс. А из действительно полезных вы и без автоматизаций вынесите все что нужно.
Все просто, нашёл запросом "php profiler", когда возникла потребность в профайлере) Сравнивал только с Xprof/Xdebug и Blackfire, это решение показалось существенно проще и наглядней.
Да, без всяких интеграций и только для локального пользования, только это мне и было нужно.
Разве для программиста или пользователя важна эквивалентность в смысле - эти две программы теоретически представимы одним набором инструкций и это можно доказать? Это просто забавный факт как по мне. Парадигмы не по такому принципу надо сравнивать, а с учетом кучи нюансов реального мира. Одна и та же программа в разных парадигмах будет с разной скоростью выполняться (потому что компиляторы не идеальны) и самое главное - по разному читаться и пониматься. Это архиважно, если мы говорим о сравнении парадигм.
Представляете, практический пример это код. Моё предположение в том, что автоматически верифицируемые программы настолько тривиальны, что польза в такой верификации совершенно незначительна. А для всего что "нечистое" всё так же нужно писать тесты. Ваш пример развеет моё невежество.
Тут требуется очень подробное объяснение (или авторитетная ссылка), т.к. меня учили что это принципиально разные парадигмы, хотя в каком-то смысле...
2.Практичный пример того, про что вы написали - простого автоматического верифицирования. Именно практичный, полезный пример использования, хочу видеть насколько это круто.
3. Ну допустим, я написал пару десятков программ на NASM в лохматые годы. Это вообще никак не относится к идее, что ассемблер не единственный язык ТОЛЬКО потому, что код пишут человеки.
Вот это хорошее объяснение, мотивирует в 3 раз попытаться разобраться с Haskell =)
Справедливости ради, типизация везде дает эффект лучшей предсказуемости. Но не настолько крутой, чтобы вообще не писать тесты. Кстати, как выглядят тесты на Haskell, они вообще бывают нужны?
Ассемблер - отличный пример. Есть места где ассемблер будет просто незаменим в практическом смысле. Незаменимого ФП я придумать не могу.
Ну а издержки и компромиссы буквально везде есть. Небольшой доп.объём кода я переживу, а вот ментальную модель без переменных но с необъяснимыми монадами - спасибо, но нет.
ФП противопоставляют ООП не просто так - в ООП меньше концепций. Да, они не так глубоки и универсальны. Постоянно то тут то там всплывают досадные неудобства - то null обработать, то временную переменную завести, то хочется скомбинировать функционал, который почему-то не спроектирован как комбинирующийся. НО. Это буквально вопрос эстетики, мир не рушиться от этих именно что не удобств. Со временем ООП-макака становиться мудрой ООП-макакой и заранее знает как аккуратно нивелировать эти неудобства, оставаясь в приятных рамках всё того же небольшого набора концепций.
От ФП Троггу грустно. ФП Троггу давать молоток для всего с алмазным напылением с большая инструкция на 500 страниц. ООП давать Троггу молоток, отвёртка, микроскоп. Всё подходит забить гвоздь!
А если серьёзно, ну давайте лучше с процедурным программированием сравним и ответим честно на 2 вопроса: что нельзя написать процедурно? В чём отличие, кроме "красоты"? Хотите красоты - делаете DSL, не пытаясь решать сразу все проблемы мира
Календари, имхо, нужны для сугубо 3 целей - не забывать о важных делах, привязанных к строго определённому времени. Причем, для этого основную пользу составляет не календарь, а привязанные к нему оповещения за день/час. - быстро найти подходящее свободное время под новую задачу. Эээ, у меня например всегда без календаря получалось. - психотерапевтический эффект - открыть календарь и сказать самому себе "ооо, какой я занятой, какой я молодец"
Всё. Всякую рутину туда заносить, причём динамически - это мусорные действия, даже с точки зрения той же эффективности
Существуют ли вообще хоть какие-то попытки стандартизировать эти многочисленные ui-библиотеки?
3/4 компонентов кочуют из одной либы в другую, просто кастомизируя апи кто во что горазд. С очень большой вероятностью половина перечисленных либ будет заброшена через несколько лет. Разве это не безумие, использовать ни с чем не совместимую библиотеку, создавая себе долг на ровном месте? Ладно, если это был бы действительно специфичный функционал. Но ui компоненты, Карл!
Для начала стоит команды не напрямую на хосте выполнять, а проксировать в виртуалку / контейнер. Если ai не знает что он в виртуалке, случайно вылезти из неё не особо реальная ситуация.
Второе - в случае GPT, стоит использовать апи функций, что позволит более конкретно ограничивать, какие именно возможности будут у нейронки.
Странно мешать в одну кучу конфиденциальность и AI специфику.
Очевидно, openai пылесосит данные пользователей абсолютно также, как и любая другая "корпорация добра". И использует их ровно также. А вот подмешивать конфиденциальные данные в нейронку крайне тупо, так как, насколько я понимаю, потом невозможно будет гарантировать, что она не начнёт их выплёвывать направо и налево с максимальными репутационными потерями. Более того, непубличные персональные данные это не то чтобы полезный датасет в плане обучения - что, возможно, негативно скажется на качестве.
Странно мешать в одну кучу конфиденциальность и "злую корпорацию".
Что если юзер сам копипастит файлик с паролями в чат (уверен, такие люди есть)? И чем это принципиально отличается от варианта распечатать этот файлик на бумажке и наклеить её на видное место? Это совсем никак с компанией не связано, зато даёт хороший ответ на вопрос "Можно ли доверять GPT-4o конфиденциальные данные?" - НУ КОНЕЧНО НЕТ. Если вы не хотите утечки своих данных - как минимум, они не должны быть в Интернете.
У меня ровно такие же ощущения были, когда пробовал писать своих агентов. (вот мои скромные эксперименты, для тех кому интересно почитать код https://github.com/600dc0de/ai_agents)
Агент это просто "автономный чат, который слишком много себе позволяет". Фактически, все те тулзы, которые сейчас на слуху, представляют собой не особо сложные менеджеры агентов, которые можно и нужно уметь писать самостоятельно, если вы хотите минимально понимать что же там происходит под капотом.
Модульность и слияние нужно реализовать не как фичу самих конфигов, а в том месте где они подключаются, после декодирования - и при этом вообще не зависеть от формата - вот куда усилия приложить надо, а не в изобретение json диалекта
В том то и дело, что если доставка успешна (данные вернулись клиенту) - это 200.
Но HTTP же ещё много нетранспортных вещей кодирует и они в RPC на уровне отдельных запросов в батче. Т.е. внутри 1 HTTP запроса может быть 3 RPC запроса (условно bad request, access denied, server error) - в таком случае общий HTTP статус просто напросто сводится только к факту доставки, т.е. 200.
Это перевод, поэтому наврятли вы получите ответ.
Вероятно, это можно проверить статистически - взять случайную выборку и сделать факт-чек вручную, получив некоторый "процент доверия".
Замечу, что "процент доверия" llm наверняка выше любой полученной в частной беседе информации (люди тоже "галлюционируют", но мы скромно называем это "заблуждаются"). У СМИ наверняка ниже, у википедии лишь чуть выше за счёт механизма модерации, но и он также подвержен эффекту правдивой лжи. Вообщем, llm в этом плане не сказать что сильно отличается от других источников информации. Было бы конечно интересно увидеть какие-то исследования данной темы.
Другой вопрос, как этот "процент доверия" повышать и надо ли. см. https://habr.com/ru/articles/947964/
вы пару раз критически упоминули json-rpc 2.0, но не раскрыли в чём его минусы.
Почему там всегда 200 понятно - изза батчинга. А что ещё?
Вот читаю такие статьи и складывается у меня стойкое ощущение, что AI, с одной стороны, действительно создаёт пропасть между энтузиастами и луддитами (что в целом норм), а с другой - ещё бОльшую пропасть между новичками и опытными разработчиками. Потому что джун пытается через AI бустить количество, а сениор - всё таки качество, и это буквально движение в противоположных направлениях.
Автор, перечитайте плиз свой список из 7 задач (в котором 8 пунктов, но вообще типа около 20 и из них многие дублируются). Это абсолютно бессистемное месиво.
Особого комментария заслуживает пункт с саммари созвонов. Вот бесплатный совет: всячески бойкотируйте бесполезные созвоны. Не допускайте их в свой рабочий процесс. А из действительно полезных вы и без автоматизаций вынесите все что нужно.
кстати, вроде как единственный профайлер, которой сейчас можно просто через PIE установить
Все просто, нашёл запросом "php profiler", когда возникла потребность в профайлере) Сравнивал только с Xprof/Xdebug и Blackfire, это решение показалось существенно проще и наглядней.
Да, без всяких интеграций и только для локального пользования, только это мне и было нужно.
Разве для программиста или пользователя важна эквивалентность в смысле - эти две программы теоретически представимы одним набором инструкций и это можно доказать? Это просто забавный факт как по мне.
Парадигмы не по такому принципу надо сравнивать, а с учетом кучи нюансов реального мира. Одна и та же программа в разных парадигмах будет с разной скоростью выполняться (потому что компиляторы не идеальны) и самое главное - по разному читаться и пониматься. Это архиважно, если мы говорим о сравнении парадигм.
Представляете, практический пример это код. Моё предположение в том, что автоматически верифицируемые программы настолько тривиальны, что польза в такой верификации совершенно незначительна. А для всего что "нечистое" всё так же нужно писать тесты. Ваш пример развеет моё невежество.
Тут требуется очень подробное объяснение (или авторитетная ссылка), т.к. меня учили что это принципиально разные парадигмы, хотя в каком-то смысле...
2.Практичный пример того, про что вы написали - простого автоматического верифицирования. Именно практичный, полезный пример использования, хочу видеть насколько это круто.
3. Ну допустим, я написал пару десятков программ на NASM в лохматые годы. Это вообще никак не относится к идее, что ассемблер не единственный язык ТОЛЬКО потому, что код пишут человеки.
Извиняюсь, что с чем эквивалентно?
Приведите, пожалуйста, практичный пример
Меня полностью устраивает, если останется только ассемблер. С ИИ всё к этому и идёт.
Странно, что до сих пор на хабре не всплывал SPX profiler
https://github.com/NoiseByNorthwest/php-spx
Пользуюсь несколько лет, маскимально удобная штука.
upd.: не, кое что было
https://habr.com/ru/articles/505192/
Вот это хорошее объяснение, мотивирует в 3 раз попытаться разобраться с Haskell =)
Справедливости ради, типизация везде дает эффект лучшей предсказуемости. Но не настолько крутой, чтобы вообще не писать тесты. Кстати, как выглядят тесты на Haskell, они вообще бывают нужны?
Ассемблер - отличный пример. Есть места где ассемблер будет просто незаменим в практическом смысле. Незаменимого ФП я придумать не могу.
Ну а издержки и компромиссы буквально везде есть. Небольшой доп.объём кода я переживу, а вот ментальную модель без переменных но с необъяснимыми монадами - спасибо, но нет.
После таких статей стараюсь о нём не думать =)
ФП противопоставляют ООП не просто так - в ООП меньше концепций. Да, они не так глубоки и универсальны. Постоянно то тут то там всплывают досадные неудобства - то null обработать, то временную переменную завести, то хочется скомбинировать функционал, который почему-то не спроектирован как комбинирующийся. НО. Это буквально вопрос эстетики, мир не рушиться от этих именно что не удобств. Со временем ООП-макака становиться мудрой ООП-макакой и заранее знает как аккуратно нивелировать эти неудобства, оставаясь в приятных рамках всё того же небольшого набора концепций.
От ФП Троггу грустно. ФП Троггу давать молоток для всего с алмазным напылением с большая инструкция на 500 страниц. ООП давать Троггу молоток, отвёртка, микроскоп. Всё подходит забить гвоздь!
А если серьёзно, ну давайте лучше с процедурным программированием сравним и ответим честно на 2 вопроса: что нельзя написать процедурно? В чём отличие, кроме "красоты"?
Хотите красоты - делаете DSL, не пытаясь решать сразу все проблемы мира
Календари, имхо, нужны для сугубо 3 целей
- не забывать о важных делах, привязанных к строго определённому времени. Причем, для этого основную пользу составляет не календарь, а привязанные к нему оповещения за день/час.
- быстро найти подходящее свободное время под новую задачу. Эээ, у меня например всегда без календаря получалось.
- психотерапевтический эффект - открыть календарь и сказать самому себе "ооо, какой я занятой, какой я молодец"
Всё. Всякую рутину туда заносить, причём динамически - это мусорные действия, даже с точки зрения той же эффективности
Вы не правы. IoC может быть вообще без интерфейсов. Он про то, что не программист управляет потоком выполнения, а фреймворк.
Если уж пытаться дружить эти термины, DI это очень частный случай IoC. Поэтому DI-контейнер более точный термин.
Вот у меня вопрос к фронтенд комьюнити.
Существуют ли вообще хоть какие-то попытки стандартизировать эти многочисленные ui-библиотеки?
3/4 компонентов кочуют из одной либы в другую, просто кастомизируя апи кто во что горазд. С очень большой вероятностью половина перечисленных либ будет заброшена через несколько лет. Разве это не безумие, использовать ни с чем не совместимую библиотеку, создавая себе долг на ровном месте? Ладно, если это был бы действительно специфичный функционал. Но ui компоненты, Карл!
Для начала стоит команды не напрямую на хосте выполнять, а проксировать в виртуалку / контейнер. Если ai не знает что он в виртуалке, случайно вылезти из неё не особо реальная ситуация.
Второе - в случае GPT, стоит использовать апи функций, что позволит более конкретно ограничивать, какие именно возможности будут у нейронки.
Странно мешать в одну кучу конфиденциальность и AI специфику.
Очевидно, openai пылесосит данные пользователей абсолютно также, как и любая другая "корпорация добра". И использует их ровно также. А вот подмешивать конфиденциальные данные в нейронку крайне тупо, так как, насколько я понимаю, потом невозможно будет гарантировать, что она не начнёт их выплёвывать направо и налево с максимальными репутационными потерями. Более того, непубличные персональные данные это не то чтобы полезный датасет в плане обучения - что, возможно, негативно скажется на качестве.
Странно мешать в одну кучу конфиденциальность и "злую корпорацию".
Что если юзер сам копипастит файлик с паролями в чат (уверен, такие люди есть)? И чем это принципиально отличается от варианта распечатать этот файлик на бумажке и наклеить её на видное место? Это совсем никак с компанией не связано, зато даёт хороший ответ на вопрос "Можно ли доверять GPT-4o конфиденциальные данные?" - НУ КОНЕЧНО НЕТ. Если вы не хотите утечки своих данных - как минимум, они не должны быть в Интернете.