Спасибо за статью! Это вообще очень увлекательная и жутко интригующая область исследования лингвистики и истории.
Несколько замечаний.
1. У Вас не раскрыт практически тот факт, что по времени между финикийским и греческим с латынью находился и развивался целый пласт: арамейское и древнееврейское (ивритское) письмо. А они появились раньше греческого и римского (латинского) письма. Увы, для многих современных людей картина древнего мира выглядит слегка упрощённо: были какие-то финикийцы, а затем появились греки с римлянами (это понятно, так учат).
Арамейский же язык в своё время был вообще "Лингва франка" в торговле и его влияние на Древний мир было огромно.
Было бы интересно проследить какое влияние на развитие древней пунктуации оказал именно этот пласт, а именно XI-VIII века до н.э
2. Фраза
"Наиболее мощным выражением этого принципа стало финикийское письмо — предок множества современных систем письма, от латиницы и кириллицы через посредство греческого до иврита, арабской вязи и многочисленных индийских систем письма."
исторически не верна, и выглядит как предложение, сгенерированное ИИ. Эта фраза создаёт ложное впечатление о едином происхождении всех перечисленных письменностей.
Кириллица возникла не из греческого напрямую, а как искусственная система, созданная в IX веке, использующая греческие буквы + дополнительные не греческие знаки (например Ц и Ш).
Финикийское письмо не было предком современного иврита напрямую. Современный иврит использует арамейское квадратное письмо, а не финикийское. Арамейское же письмо - это боковая ветвь, хотя тоже семитская и родственная финикийской. То есть, прямой цепочки "Финикийское письмо -> Иврит" нет, она была бы корректной только для палеоеврейского, но не для современного письма.
И на последок, прямой цепочки “Финикийское -> Арабское” тоже нет. Корректная цепочка выглядит так: Финикийское -> Арамейское -> Набатейское -> Арабское письмо.
Блоки кода в статье добавлены таким образом (копипастом с GPT?), что их почти невозможно прочесть. Я бы наверное попытался в этом разобраться (когда-то сам пытался что-то подобное сделать), но не стал. Пожалуйста приведите статью в удобо-читабелный вид.
Да, конечно можно - и многие так делают, чтобы не зависеть от облака, снизить стоимость или обеспечить приватность данных. Например: Jina Embeddings (локально + Docker) - docker run -p 8000:8000 jinaai/jina-embeddings-v2
Запускаем в отдельном контейнере, делаем доступ через определённый раут и стучимся туда из PHP обычным HTTP-запросом.
Тут я с Вами согласен - движение есть. Возможно в статье я не совсем корректно выразился. Я имел ввиду, что при том, что наши знания и возможности увеличиваются, существует некий предел в достижении абсолютного знания, во всяком случае в том виде и в том мире, в котором мы сейчас существуем. Такова моя научная и религиозная точка зрения - это то, что я хотел выразить.
Вы имеете ввиду конкретную часть текста? Как мне кажется в религии, в философии и в науке под разумом подразумевают несколько разные вещи. То, что учёный 16-го века не понимает квантовой механики - это не потому, что у него разум "слабый", а потому что знаний не хватает.
Пока нет :) Эту задачу решал в отрыве от MediaWiki, скорее как универсальный пример на PHP, а затем мы её имплементировали для нашей базы знаний в Confluence и в GitBook. Но при желании этот же подход несложно упаковать и в экстенш к MediaWiki - там главное правильно вытащить текст страниц и обновлять индексацию, благо сам фреймворк позволяет работать с разными типами документов.
По-поводу восторженной воды и мало конкретики - согласен и полностью принимаю. Просто я действительно был рад обнаружить агентный фреймворк на 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) - просто нужно уметь им пользоваться.
Спасибо за статью! Это вообще очень увлекательная и жутко интригующая область исследования лингвистики и истории.
Несколько замечаний.
1. У Вас не раскрыт практически тот факт, что по времени между финикийским и греческим с латынью находился и развивался целый пласт: арамейское и древнееврейское (ивритское) письмо. А они появились раньше греческого и римского (латинского) письма. Увы, для многих современных людей картина древнего мира выглядит слегка упрощённо: были какие-то финикийцы, а затем появились греки с римлянами (это понятно, так учат).
Арамейский же язык в своё время был вообще "Лингва франка" в торговле и его влияние на Древний мир было огромно.
Было бы интересно проследить какое влияние на развитие древней пунктуации оказал именно этот пласт, а именно XI-VIII века до н.э
2. Фраза
исторически не верна, и выглядит как предложение, сгенерированное ИИ. Эта фраза создаёт ложное впечатление о едином происхождении всех перечисленных письменностей.
Кириллица возникла не из греческого напрямую, а как искусственная система, созданная в IX веке, использующая греческие буквы + дополнительные не греческие знаки (например Ц и Ш).
Финикийское письмо не было предком современного иврита напрямую. Современный иврит использует арамейское квадратное письмо, а не финикийское. Арамейское же письмо - это боковая ветвь, хотя тоже семитская и родственная финикийской. То есть, прямой цепочки "Финикийское письмо -> Иврит" нет, она была бы корректной только для палеоеврейского, но не для современного письма.
И на последок, прямой цепочки “Финикийское -> Арабское” тоже нет. Корректная цепочка выглядит так: Финикийское -> Арамейское -> Набатейское -> Арабское письмо.
Блоки кода в статье добавлены таким образом (копипастом с GPT?), что их почти невозможно прочесть. Я бы наверное попытался в этом разобраться (когда-то сам пытался что-то подобное сделать), но не стал. Пожалуйста приведите статью в удобо-читабелный вид.
Да, конечно можно - и многие так делают, чтобы не зависеть от облака, снизить стоимость или обеспечить приватность данных. Например: Jina Embeddings (локально + Docker) - docker run -p 8000:8000 jinaai/jina-embeddings-v2
Запускаем в отдельном контейнере, делаем доступ через определённый раут и стучимся туда из PHP обычным HTTP-запросом.
В результате будет что-то вроде
Тут я с Вами согласен - движение есть. Возможно в статье я не совсем корректно выразился. Я имел ввиду, что при том, что наши знания и возможности увеличиваются, существует некий предел в достижении абсолютного знания, во всяком случае в том виде и в том мире, в котором мы сейчас существуем. Такова моя научная и религиозная точка зрения - это то, что я хотел выразить.
Вы имеете ввиду конкретную часть текста? Как мне кажется в религии, в философии и в науке под разумом подразумевают несколько разные вещи. То, что учёный 16-го века не понимает квантовой механики - это не потому, что у него разум "слабый", а потому что знаний не хватает.
Пока нет :) Эту задачу решал в отрыве от MediaWiki, скорее как универсальный пример на PHP, а затем мы её имплементировали для нашей базы знаний в Confluence и в GitBook. Но при желании этот же подход несложно упаковать и в экстенш к MediaWiki - там главное правильно вытащить текст страниц и обновлять индексацию, благо сам фреймворк позволяет работать с разными типами документов.
Написал в личку
Я как раз пишу что-то подобное для себя на PHP. Интересно будет сравнить подходы. Спасибо за статью.
Однако должен заметить, что github линк на сайте не откывается, регистрация тоже не работает.
По-поводу восторженной воды и мало конкретики - согласен и полностью принимаю. Просто я действительно был рад обнаружить агентный фреймворк на 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) - просто нужно уметь им пользоваться.