По-поводу восторженной воды и мало конкретики - согласен и полностью принимаю. Просто я действительно был рад обнаружить агентный фреймворк на PHP, где больше чем 1-2 коммита и который, судя по репозиторию, продолжает активно развиваться. Для меня - это всегда бальзам на мою PHP-шную душу.
По-поводу конечных автоматов и сложных алгоритмов обработки данных. Я не отказываюсь от них - ни в коем случае. Просто иногда запрограммировать сложное поведение, где есть неопределённость может быть проще с AI-агентом. Поясню, для меня AI-агенты - это что-то вроде "Service 2.0", они не просто обрабатывают запрос, а понимают задачу и контекст. Например: есть задача, в которой нужно отправить потенциальному кандидату письмо с вопросом, готов ли он встретиться в офисе такого-то числа и в зависимости от его ответа выслать то или иное сообщение.
Можно использовать классический подход и парсить его ответ на предмет нахождения в нём слов, типа "Да", "Ок", "Согласен" и т.д. А если там будет что-то вроде: "Ну дык, само собой" или "Да, нет"? Как решать эту проблему?
Если же предоставить AI-агенту возможность самостоятельно интерпретировать ответ, он не будет ограничен жёстким списком ключевых слов. Он сможет понять смысл фразы, даже если она выражена неформально, с ошибками (sic!) или с контекстом, который выходит за рамки заранее прописанных правил. Вместо if/else по шаблонам, агент воспринимает задачу как намерение пользователя - он не ищет совпадения строк, а пытается определить смысл и намерение ответа. Это и есть ключевая разница: мы перестаём программировать "поведение", и начинаем ставить цели, а агент уже сам подбирает шаги для их достижения. То есть, в примере с письмом, AI-агент может "понять", что "Ну дык, само собой" = согласие, а "Да, нет" - двусмысленный ответ, который требует уточнения. Дальше агент сам решит, что лучше сделать - поблагодарить за согласие или переспросить.
Ещё раз - всё это не означает, что стандартный подход уже не нужен - совсем наоборот! Мы можем использовать локальную проверку на нужные слова (захардкоженную, чтобы сэкономить ресурсы) + дополнительную проверку с AI-агентом, если есть сомнения. То есть - существуют ситуации, где использование AI-агента в целом не нужно вообще, например: API, транзакции, CRUD и т.д. А есть ситуации, где это необходимо, например: анализ текстов, писем, логов, автоответы, диалоги и т.п.
Теперь по-поводу "AI-агента внутри PHP-приложения". Если коротко: это объект в коде, который может принимать решения на основе контекста и данных, а не просто выполнять жёстко заданные инструкции. Надеюсь, стало немного понятнее.
Контекст агента не реализован OpenAI - он реализуется в самом фреймворке. Когда агенту Neuronа нужно "подумать" или сгенерировать ответ, он вызывает LLM-провайдер и передаёт в модель текущий контекст, сформированный на своей стороне, примерно в таком виде:
{
"messages": [
{"role": "system", "content": "Ты — помощник по анализу статей."},
{"role": "user", "content": "Проанализируй эту статью..."},
{"role": "tool_result", "content": "Текст статьи, полученной при помощи..."}
]
}
Согласен, это даёт большую экономию. Но с другой стороны, если использовать spaCy в отдельном контейнере, то можно горизонтально маштабироваться, а если запускать spaCy в том же контейнере, что и PHP, то это проблема, так как всё бежит в рамках одного и того же запроса в php-fpm.
Так что у нас дилема.. но пока что мы начали использовать батчинг. SpaCy очень хорош в обработке батчей, - мы отправляем 1000 текстов для обработки в одном запросе. В результате общее время обработки сократилось почти в 30 раз! И это даже без горизонтального маштабирования.
Хотя сам пакет phpy мне очень понравился. Думаю, что можно написать статью по его использованию.
Я протестировал PHPY со spaCy - он работает примерно на 10% быстрее, чем вызов spaCy из отдельного Docker-контейнера. Неплохо, но это не самое лучшее решение, если вы обрабатываете миллионы запросов. Чтобы добиться реального улучшения, нужно минимизировать переключения между PHP и Python, то есть использовать пакетные запросы вместо одиночного вызова модели spaCy для каждого запроса. В этом случае мы можем добиться улучшения в 3-4 раза.
PHPY - это мост между PHP и Python и это отличная вещь! Он избавляется от HTTP, сериализации JSON и сетевого стека, но всё равно накладные расходы на маршалинг данных PHP <--> Python никуда не девается.. Для простых текстов и токенизации эта экономия практически незначительна, поскольку spaCy выполняется за десятки миллисекунд, а маршалинг занимает микросекунды (это просто для понимания вопроса).
И конечно, в обоих случаях узким местом являются процессор и GIL в Python. spaCy работает в Python под GIL. Это означает, что даже если PHP выполняет вызовы напрямую, Python всё равно выполняет конвейер "в лоб". PHPY не использует никаких магических эффектов ускорения; он просто удаляет HTTP-вызовы.
Вывод: POC прошёл успешно. Использование PHPY и пакетных запросов (batching) на тестовых данных дало ускорение примерно в 3 раза! С другой стороны, можно использовать пакетные запросы и при запуске spaCy в отдельном докер контейнере.
Я думаю это произошло не в малой степени из-за того, что им много пользовались не программисты, а учёные и всякого рода исследователи. Простой, близкий к математическому синтаксис был им понятней. Плюс ко всему - Apple поддерживает использование Python на своих устройствах macOS, предлагая инструменты для его установки и запуска, и включила Python в состав своей операционной системы для разработчиков. Всё в совокупности..
RubixML это замечательная библиотека, но в ней нет готового решения для NER. Хотя её можно использовать, чтобы создать и обучить свою модель, если есть время и желание, то есть: собрать датасет, разметить токены и построить пайплайн признаков. У меня на это, увы - не было времени.
Впрочем, спасибо за напоминание - добавлю про этот вариант тоже.
Спасибо за cвежий подход к вопросу "PHP устарел". Я лично считаю, что язык совсем не устарел, он продолжает развиваться (хотелось бы быстрее), но тренды задаваемые глобальными корпорациями - это, увы, не так просто преодолеть. По-поводу тех, кто говорит - вот раньше у языка был низкий порог входа и простота - просто не понимает, что и требования к веб-аппликациям были другими 20 лет назад. Сегодня у нас совершенно иное время.
И ещё... я не совсем согласен с подходом к MVP - в том смысле, что его нужно обязательно пилить на NodeJS. Лично я прямо сейчас пишу MVP на основе PHP в связке с Filament (плюс, конечно куча всего другого вокруг этого ядра (куда ж без этого), и... очень доволен результатом, качеством и скоростью разработки) и это после того, как целый месяц мы с моим товарищем потратили на POC на Питоне.
PHP - замечательный инструмент (а я его знаю с версии 3) - просто нужно уметь им пользоваться.
Эта статья - полностью сгенерирована при помощи LLM - начал читать, наткнулся на "стандартные" LLM-приёмы и не смог её дочитать до конца. Хотя идея статьи была изначально довольно заманчива.
Скоро ИИ будут выдавать "нагора" тонны статей, а другие ИИ будут их комментировать и ставить лайки. Это не вайб-кодинг, это вайб-врайтинг (Vibe Writing) - вот наш тупик...
На этом сайте cofounder.ai я нашёл битые линки, что говорит о том, что этот сайт сам был сделан при помощи ИИ, в Линкдине про компанию говорится - там 0-1 человек. Красивая пыль в глаза.
Я тоже скажу как нынешний руководитель и сам в прошлом (да и пока всё ещё) исполнитель - безмолвные исполнители нужны только на самых нижних должностях и то, только там, где нет эмоциональной связи с продуктом, либо в большой корпорации. У нас не так, мы за свой продукт переживаем - слишком много в него вложено душевных сили и энергии.
Спасибо за отзыв. Мы с нашими QA инженерами во всю используем GPT и даже сделали (пока POC) небольшую программу для внутреннего пользования - скидываем в GPT скриншот страницы, а он генерит все степы для для E2E тестов, затем пишет код для тест-кейса и сам запускает его. Пока всё ещё очень сырое, но на обычных CRUD страницах результат очень даже не плохой. Я считаю, что это очень перспективное направление, потому что ручное написание QA автомации очень трудоёмкий процесс, к тому же E2E сами по себе вещь хрупкая.
Согласен, это если каждый месяц клиентов х2, но у нас пока х+2. Когда проблема появится на горизонте, начнём ещё решать, пока ещё этой проблемы у нас нет.
Показал моей жене Ваш коментарий, а также парочку других, где на меня навешали ярлык "сексиста". Она от души посмеялась и сказала - "пиши, пиши еще!" - где я о тебе ещё столько нового узнаю )) Моя жена следует моде и трендам (не всем, конечно) - потому что это её профессия. Она - модный журналист, т.е. журналист "по моде".
По-поводу восторженной воды и мало конкретики - согласен и полностью принимаю. Просто я действительно был рад обнаружить агентный фреймворк на PHP, где больше чем 1-2 коммита и который, судя по репозиторию, продолжает активно развиваться. Для меня - это всегда бальзам на мою PHP-шную душу.
По-поводу конечных автоматов и сложных алгоритмов обработки данных. Я не отказываюсь от них - ни в коем случае. Просто иногда запрограммировать сложное поведение, где есть неопределённость может быть проще с AI-агентом. Поясню, для меня AI-агенты - это что-то вроде "Service 2.0", они не просто обрабатывают запрос, а понимают задачу и контекст.
Например: есть задача, в которой нужно отправить потенциальному кандидату письмо с вопросом, готов ли он встретиться в офисе такого-то числа и в зависимости от его ответа выслать то или иное сообщение.
Можно использовать классический подход и парсить его ответ на предмет нахождения в нём слов, типа "Да", "Ок", "Согласен" и т.д. А если там будет что-то вроде: "Ну дык, само собой" или "Да, нет"? Как решать эту проблему?
Если же предоставить AI-агенту возможность самостоятельно интерпретировать ответ, он не будет ограничен жёстким списком ключевых слов. Он сможет понять смысл фразы, даже если она выражена неформально, с ошибками
(sic!) или с контекстом, который выходит за рамки заранее прописанных правил. Вместо if/else по шаблонам, агент воспринимает задачу как намерение пользователя - он не ищет совпадения строк, а пытается определить смысл и намерение ответа. Это и есть ключевая разница: мы перестаём программировать "поведение", и начинаем ставить цели, а агент уже сам подбирает шаги для их достижения. То есть, в примере с письмом, AI-агент может "понять", что "Ну дык, само собой" = согласие, а "Да, нет" - двусмысленный ответ, который требует уточнения. Дальше агент сам решит, что лучше сделать - поблагодарить за согласие или переспросить.
Ещё раз - всё это не означает, что стандартный подход уже не нужен - совсем наоборот! Мы можем использовать локальную проверку на нужные слова (захардкоженную, чтобы сэкономить ресурсы) + дополнительную проверку с AI-агентом, если есть сомнения. То есть - существуют ситуации, где использование AI-агента в целом не нужно вообще, например: API, транзакции, CRUD и т.д. А есть ситуации, где это необходимо, например: анализ текстов, писем, логов, автоответы, диалоги и т.п.
Теперь по-поводу "AI-агента внутри PHP-приложения". Если коротко: это объект в коде, который может принимать решения на основе контекста и данных, а не просто выполнять жёстко заданные инструкции. Надеюсь, стало немного понятнее.
Контекст агента не реализован OpenAI - он реализуется в самом фреймворке. Когда агенту Neuronа нужно "подумать" или сгенерировать ответ, он вызывает LLM-провайдер и передаёт в модель текущий контекст, сформированный на своей стороне, примерно в таком виде:
То есть, он хранится внутри Neuron - в PHP-слое
.
Согласен, это даёт большую экономию. Но с другой стороны, если использовать spaCy в отдельном контейнере, то можно горизонтально маштабироваться, а если запускать spaCy в том же контейнере, что и PHP, то это проблема, так как всё бежит в рамках одного и того же запроса в php-fpm.
Так что у нас дилема.. но пока что мы начали использовать батчинг. SpaCy очень хорош в обработке батчей, - мы отправляем 1000 текстов для обработки в одном запросе. В результате общее время обработки сократилось почти в 30 раз! И это даже без горизонтального маштабирования.
Хотя сам пакет phpy мне очень понравился. Думаю, что можно написать статью по его использованию.
В целом да, но в моём случае ядро программы написано на PHP, поэтому данные приходят в PHP и часть работы по аннотоциям текстов ложится на Python
Я протестировал PHPY со spaCy - он работает примерно на 10% быстрее, чем вызов spaCy из отдельного Docker-контейнера. Неплохо, но это не самое лучшее решение, если вы обрабатываете миллионы запросов. Чтобы добиться реального улучшения, нужно минимизировать переключения между PHP и Python, то есть использовать пакетные запросы вместо одиночного вызова модели spaCy для каждого запроса. В этом случае мы можем добиться улучшения в 3-4 раза.
PHPY - это мост между PHP и Python и это отличная вещь! Он избавляется от HTTP, сериализации JSON и сетевого стека, но всё равно накладные расходы на маршалинг данных PHP <--> Python никуда не девается.. Для простых текстов и токенизации эта экономия практически незначительна, поскольку spaCy выполняется за десятки миллисекунд, а маршалинг занимает микросекунды (это просто для понимания вопроса).
И конечно, в обоих случаях узким местом являются процессор и GIL в Python.
spaCy работает в Python под GIL. Это означает, что даже если PHP выполняет вызовы напрямую, Python всё равно выполняет конвейер "в лоб". PHPY не использует никаких магических эффектов ускорения; он просто удаляет HTTP-вызовы.
Вывод: POC прошёл успешно. Использование PHPY и пакетных запросов (batching) на тестовых данных дало ускорение примерно в 3 раза! С другой стороны, можно использовать пакетные запросы и при запуске spaCy в отдельном докер контейнере.
Очень интересно, спасибо за наводку - на днях обязательно протестирую! Похоже драма постепенно превращается в "ромком" ))
Я думаю это произошло не в малой степени из-за того, что им много пользовались не программисты, а учёные и всякого рода исследователи. Простой, близкий к математическому синтаксис был им понятней. Плюс ко всему - Apple поддерживает использование Python на своих устройствах macOS, предлагая инструменты для его установки и запуска, и включила Python в состав своей операционной системы для разработчиков. Всё в совокупности..
Мда... собиралось быстро и на коленке для POC. Спасибо за замечание - перепишем в лучшем виде.
RubixML это замечательная библиотека, но в ней нет готового решения для NER. Хотя её можно использовать, чтобы создать и обучить свою модель, если есть время и желание, то есть: собрать датасет, разметить токены и построить пайплайн признаков. У меня на это, увы - не было времени.
Впрочем, спасибо за напоминание - добавлю про этот вариант тоже.
Идея статьи понятна, но если бы автор написал её сам, а так... пятёрку GPT за знания, а автору неуд...
Спасибо за cвежий подход к вопросу "PHP устарел". Я лично считаю, что язык совсем не устарел, он продолжает развиваться (хотелось бы быстрее), но тренды задаваемые глобальными корпорациями - это, увы, не так просто преодолеть. По-поводу тех, кто говорит - вот раньше у языка был низкий порог входа и простота - просто не понимает, что и требования к веб-аппликациям были другими 20 лет назад. Сегодня у нас совершенно иное время.
И ещё... я не совсем согласен с подходом к MVP - в том смысле, что его нужно обязательно пилить на NodeJS. Лично я прямо сейчас пишу MVP на основе PHP в связке с Filament (плюс, конечно куча всего другого вокруг этого ядра (куда ж без этого), и... очень доволен результатом, качеством и скоростью разработки) и это после того, как целый месяц мы с моим товарищем потратили на POC на Питоне.
PHP - замечательный инструмент (а я его знаю с версии 3) - просто нужно уметь им пользоваться.
Эта статья - полностью сгенерирована при помощи LLM - начал читать, наткнулся на "стандартные" LLM-приёмы и не смог её дочитать до конца. Хотя идея статьи была изначально довольно заманчива.
Скоро ИИ будут выдавать "нагора" тонны статей, а другие ИИ будут их комментировать и ставить лайки. Это не вайб-кодинг, это вайб-врайтинг (Vibe Writing) - вот наш тупик...
На этом сайте cofounder.ai я нашёл битые линки, что говорит о том, что этот сайт сам был сделан при помощи ИИ, в Линкдине про компанию говорится - там 0-1 человек. Красивая пыль в глаза.
Я тоже скажу как нынешний руководитель и сам в прошлом (да и пока всё ещё) исполнитель - безмолвные исполнители нужны только на самых нижних должностях и то, только там, где нет эмоциональной связи с продуктом, либо в большой корпорации. У нас не так, мы за свой продукт переживаем - слишком много в него вложено душевных сили и энергии.
Originally introduced in You Are Not Google by Ozan Onay
https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb
Хотелось бы, чтоб в первую очередь были заменены директора и менеджеры - сократить парочку таких с высокими зарплатами - вот и прибыль увеличена.
Спасибо за отзыв. Мы с нашими QA инженерами во всю используем GPT и даже сделали (пока POC) небольшую программу для внутреннего пользования - скидываем в GPT скриншот страницы, а он генерит все степы для для E2E тестов, затем пишет код для тест-кейса и сам запускает его. Пока всё ещё очень сырое, но на обычных CRUD страницах результат очень даже не плохой. Я считаю, что это очень перспективное направление, потому что ручное написание QA автомации очень трудоёмкий процесс, к тому же E2E сами по себе вещь хрупкая.
Согласен, это если каждый месяц клиентов х2, но у нас пока х+2. Когда проблема появится на горизонте, начнём ещё решать, пока ещё этой проблемы у нас нет.
Показал моей жене Ваш коментарий, а также парочку других, где на меня навешали ярлык "сексиста". Она от души посмеялась и сказала - "пиши, пиши еще!" - где я о тебе ещё столько нового узнаю ))
Моя жена следует моде и трендам (не всем, конечно) - потому что это её профессия. Она - модный журналист, т.е. журналист "по моде".