Как я пытался подружить PHP с NER — драма в 5 актах

[granv1]

автор открыл для себя и применил фундаментальный принцип конвейертзации и unix style подхода! Ура!

[FanatPHP]

Мне всё-таки кажется, что это слишком широкое толкование конвейеризации через контейнеризацию. Этак любой прокси-сервер будет unix-style. Из красивых слов тут скорее подошла бы микросервисная архитектура.

[olegl84]

постой запрос к chatgpt дает RubixML для php

[samako]

RubixML это замечательная библиотека, но в ней нет готового решения для NER. Хотя её можно использовать, чтобы создать и обучить свою модель, если есть время и желание, то есть: собрать датасет, разметить токены и построить пайплайн признаков. У меня на это, увы - не было времени.

Впрочем, спасибо за напоминание - добавлю про этот вариант тоже.

[FanatPHP]

Немного обидно за пхп. В Питоне и FastAPI, и красивый логгер, а в пыхе echo 'Curl error: ' кишками наружу. И сам курл без единого враппера, голенький как в первый день творения знакомства с языком.

[samako]

Мда... собиралось быстро и на коленке для POC. Спасибо за замечание - перепишем в лучшем виде.

[olegl84]

логинг - monolog, http - guzzle.

[riv2]

Спасибо (͡°͜ʖ͡°)

[aleksandr-s-zelenin]

Python по какой-то неизвестной мне причине заточили под анализ даных. Может быть просто потому, что там в консоли можно работать более менее удобно. Поэтому там всё и есть и по сей день активно развивается. Этим отчасти и объясняются высокие позиции этого языка в различных рейтингах популярности.

[samako]

Я думаю это произошло не в малой степени из-за того, что им много пользовались не программисты, а учёные и всякого рода исследователи. Простой, близкий к математическому синтаксис был им понятней. Плюс ко всему - Apple поддерживает использование Python на своих устройствах macOS, предлагая инструменты для его установки и запуска, и включила Python в состав своей операционной системы для разработчиков. Всё в совокупности..

[AndrewStephanoff]

https://pecl.php.net/package/phpy

[samako]

Очень интересно, спасибо за наводку - на днях обязательно протестирую! Похоже драма постепенно превращается в "ромком" ))

[samako]

1. Я протестировал PHPY со spaCy - он работает примерно на 10% быстрее, чем вызов spaCy из отдельного Docker-контейнера. Неплохо, но это не самое лучшее решение, если вы обрабатываете миллионы запросов. Чтобы добиться реального улучшения, нужно минимизировать переключения между PHP и Python, то есть использовать пакетные запросы вместо одиночного вызова модели spaCy для каждого запроса. В этом случае мы можем добиться улучшения в 3-4 раза.

2. PHPY - это мост между PHP и Python и это отличная вещь! Он избавляется от HTTP, сериализации JSON и сетевого стека, но всё равно накладные расходы на маршалинг данных PHP <--> Python никуда не девается.. Для простых текстов и токенизации эта экономия практически незначительна, поскольку spaCy выполняется за десятки миллисекунд, а маршалинг занимает микросекунды (это просто для понимания вопроса).

3. И конечно, в обоих случаях узким местом являются процессор и GIL в Python.
   spaCy работает в Python под GIL. Это означает, что даже если PHP выполняет вызовы напрямую, Python всё равно выполняет конвейер "в лоб". PHPY не использует никаких магических эффектов ускорения; он просто удаляет HTTP-вызовы.

Вывод: POC прошёл успешно. Использование PHPY и пакетных запросов (batching) на тестовых данных дало ускорение примерно в 3 раза! С другой стороны, можно использовать пакетные запросы и при запуске spaCy в отдельном докер контейнере.

[AndrewStephanoff]

Если стоит вопрос о миллионах запросах, то наверное нет смысла транслировать вызовы из PHP в Python, а просто использовать python

[samako]

В целом да, но в моём случае ядро программы написано на PHP, поэтому данные приходят в PHP и часть работы по аннотоциям текстов ложится на Python

[AndrewStephanoff]

Он избавляется от HTTP, сериализации JSON и сетевого стека, но всё равно накладные расходы на маршалинг данных PHP <--> Python никуда не девается.. 

Не только. Также нам не нужно держать второй контейнер и поддерживать инфраструктуру для spaCy, а это тоже существенная экономия

[samako]

Согласен, это даёт большую экономию. Но с другой стороны, если использовать spaCy в отдельном контейнере, то можно горизонтально маштабироваться, а если запускать spaCy в том же контейнере, что и PHP, то это проблема, так как всё бежит в рамках одного и того же запроса в php-fpm.

Так что у нас дилема.. но пока что мы начали использовать батчинг. SpaCy очень хорош в обработке батчей, - мы отправляем 1000 текстов для обработки в одном запросе. В результате общее время обработки сократилось почти в 30 раз! И это даже без горизонтального маштабирования.

Хотя сам пакет phpy мне очень понравился. Думаю, что можно написать статью по его использованию.