Согласен, это даёт большую экономию. Но с другой стороны, если использовать 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. Когда проблема появится на горизонте, начнём ещё решать, пока ещё этой проблемы у нас нет.
Показал моей жене Ваш коментарий, а также парочку других, где на меня навешали ярлык "сексиста". Она от души посмеялась и сказала - "пиши, пиши еще!" - где я о тебе ещё столько нового узнаю )) Моя жена следует моде и трендам (не всем, конечно) - потому что это её профессия. Она - модный журналист, т.е. журналист "по моде".
1. Я действительно имею 25 лет опыта работы в веб-программировании. Мой первый проект был сделан в далёком 1999 г. 2. Почему-то последние 15 лет все заморочились этими софт-скилами. В моё время человек просто приходил в команду работать и от него (как от инженера) требовалось не заниматься "выстраиванием" отношений, а в первую очередь честно и грамотно выполнять свою работу. Да и про такое явление как "выгорание" никто слыхом не слыхивал. Но сегодня почему-то считается, что "софт-скилы" - это MUST и даже важнее "хард-скилов" и их нужно "прокачивать" в первую очередь. Нужно учиться выстраивать отношения в команде, между командами, с начальством и т.д. У меня достаточно "мягкий" характер, чтобы в моей команде все чувствовали "кайф" от нашей совместной работы и каждый имеет свою долю уважения и респекта, более того, я открыт и для критики и для новых (полезных) идей. Но с начальством у меня всё наоборот - там я совсем не "мягкий" и более того - не собираюсь этого делать ни сейчас, ни в будущем. На мой взгляд, начальство должно получать правдивую обратную связь, а если им это режет глаза, то что ж... 3. Я правда не провожу никакого исследования и ничего там себе не чешу. Просто наболело. Но Ваша мысль мне понятна - я, наверное, постараюсь избегать в дальнейшем написания подобных статей.
Спасибо за совет и за пинок. На Хабре я это вывалил, чтобы снять груз с души, хотя выглядит так, что я устроил себе бесплатную психотерапию за счёт других.
У Вас разумные аргументы, но я не против AI - команда во всю использует его в своей повседневной работе: помощь в написании документации, поиск багов, генерация черновых Unit и API тестов, POC на скорую руку и т.д. В этом году мы уже зарелизили парочку AI фичей, которые были очень нужны нашим клиентам. Но... для руководства "уже" - это всегда поздно, ведь всё нужно было ещё вчера/позавчера/год назад. Когда у руководства не получается что-то улучшить в отделе продаж - оно часто пытается "навести порядок" в отделе разработки.
Согласен, это даёт большую экономию. Но с другой стороны, если использовать 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. Когда проблема появится на горизонте, начнём ещё решать, пока ещё этой проблемы у нас нет.
Показал моей жене Ваш коментарий, а также парочку других, где на меня навешали ярлык "сексиста". Она от души посмеялась и сказала - "пиши, пиши еще!" - где я о тебе ещё столько нового узнаю ))
Моя жена следует моде и трендам (не всем, конечно) - потому что это её профессия. Она - модный журналист, т.е. журналист "по моде".
1. Я действительно имею 25 лет опыта работы в веб-программировании. Мой первый проект был сделан в далёком 1999 г.
2. Почему-то последние 15 лет все заморочились этими софт-скилами. В моё время человек просто приходил в команду работать и от него (как от инженера) требовалось не заниматься "выстраиванием" отношений, а в первую очередь честно и грамотно выполнять свою работу. Да и про такое явление как "выгорание" никто слыхом не слыхивал. Но сегодня почему-то считается, что "софт-скилы" - это MUST и даже важнее "хард-скилов" и их нужно "прокачивать" в первую очередь. Нужно учиться выстраивать отношения в команде, между командами, с начальством и т.д. У меня достаточно "мягкий" характер, чтобы в моей команде все чувствовали "кайф" от нашей совместной работы и каждый имеет свою долю уважения и респекта, более того, я открыт и для критики и для новых (полезных) идей. Но с начальством у меня всё наоборот - там я совсем не "мягкий" и более того - не собираюсь этого делать ни сейчас, ни в будущем. На мой взгляд, начальство должно получать правдивую обратную связь, а если им это режет глаза, то что ж...
3. Я правда не провожу никакого исследования и ничего там себе не чешу. Просто наболело. Но Ваша мысль мне понятна - я, наверное, постараюсь избегать в дальнейшем написания подобных статей.
Спасибо за совет и за пинок. На Хабре я это вывалил, чтобы снять груз с души, хотя выглядит так, что я устроил себе бесплатную психотерапию за счёт других.
У Вас разумные аргументы, но я не против AI - команда во всю использует его в своей повседневной работе: помощь в написании документации, поиск багов, генерация черновых Unit и API тестов, POC на скорую руку и т.д. В этом году мы уже зарелизили парочку AI фичей, которые были очень нужны нашим клиентам. Но... для руководства "уже" - это всегда поздно, ведь всё нужно было ещё вчера/позавчера/год назад. Когда у руководства не получается что-то улучшить в отделе продаж - оно часто пытается "навести порядок" в отделе разработки.