#ai_on_backend
Кто-бы как не любил (или наоборот - бурно обожал Питон), но он пока остается, если не самым, то одним из самых удобных языков для быстрой разработки AI и не AI бэкенд систем.
Ну правда ведь одно удовольствие расписывать SGR на Pydantic моделях и красиво отдавать на запрос. А с Pydantic-AI еще красивее. А FastAPI, FastMCP... Ну сказка 100x разработчика!
Но по разным причинам у нас не всегда есть/оправдан Питон ¯\_(ツ)_/¯
***
Хорошо если AI компонент системы легко выделяется и можно просто "рядом" запустить его как сервис.
Плохо если AI либо уже как-то внедряли (и перевязали с бизнес логикой слишком туго), либо сам дизайн просится "по месту в модуле" в целях сохранения этой самой модульности или ее видимости.
>Например в бэкенд монолите плотно намешана работа, и надо туда нормально внедрить AI. Это просто тупо дешевле чем переписывать несколько кусков и выносить в отдельный сервис. Ну... просто ничем не оправданно.
***
Так что там с _хорошими библиотеками_ в других языках?
tl;dr – на фоне Пайдентиков Питона все не так лучезарно, но все еще неплохо. Если вы четко уверены что будете использовать OpenAI или OpenAI Compatible интерфейс, думать нечего – смотрите сразу на клиенты поддерживаемые OpenAI.
Возможно они не всегда так выразительны как хотелось бы – но Strctured Output вы там в том или ином виде найдете.
Просто потому что мейнтейнеры этих библиотек обязаны обеспечивать все API OpenAI.
Там даже коммиты на пулреквесты выглядят как-то так:
>* Add full support for Responses API
---
Чего не скажешь про чудесные и одичалые библиотеки – либо поддержка там просто отстает (ну некогда!), либо "исповедуются" безнадежно устаревшие странности-парсеры вроде baml.
И все таки... Должны же быть хорошие oss библиотеки не спонсируемые большими компаниями?
Есть! instructor на PHP!
Единственная его проблема – чрезмерная переизбыточность, как минимум в документации/примерах в гитхабе. Я чуть было не отказался от этой библиотеки пока разбирался как же все таки отправлять запросы на Strict SO :)
>instructor-php поддерживает и те самые парсеры, и подкапотные внедрения json'ов в промпты.
Но в итоге вы получаете опыт похожий на привычный brrrrr от Пайдентика в Питоне со вложенными классами/энумами и описателями полей :)
(openai-php/client не умеет в рефлексию схем из php классов, там вам придется рисовать JSON елки руками или сторонними штуками.)
@m0n0x41d
Кто-бы как не любил (или наоборот - бурно обожал Питон), но он пока остается, если не самым, то одним из самых удобных языков для быстрой разработки AI и не AI бэкенд систем.
Ну правда ведь одно удовольствие расписывать SGR на Pydantic моделях и красиво отдавать на запрос. А с Pydantic-AI еще красивее. А FastAPI, FastMCP... Ну сказка 100x разработчика!
Но по разным причинам у нас не всегда есть/оправдан Питон ¯\_(ツ)_/¯
***
Хорошо если AI компонент системы легко выделяется и можно просто "рядом" запустить его как сервис.
Плохо если AI либо уже как-то внедряли (и перевязали с бизнес логикой слишком туго), либо сам дизайн просится "по месту в модуле" в целях сохранения этой самой модульности или ее видимости.
>Например в бэкенд монолите плотно намешана работа, и надо туда нормально внедрить AI. Это просто тупо дешевле чем переписывать несколько кусков и выносить в отдельный сервис. Ну... просто ничем не оправданно.
***
Так что там с _хорошими библиотеками_ в других языках?
tl;dr – на фоне Пайдентиков Питона все не так лучезарно, но все еще неплохо. Если вы четко уверены что будете использовать OpenAI или OpenAI Compatible интерфейс, думать нечего – смотрите сразу на клиенты поддерживаемые OpenAI.
Возможно они не всегда так выразительны как хотелось бы – но Strctured Output вы там в том или ином виде найдете.
Просто потому что мейнтейнеры этих библиотек обязаны обеспечивать все API OpenAI.
Там даже коммиты на пулреквесты выглядят как-то так:
>* Add full support for Responses API
---
Чего не скажешь про чудесные и одичалые библиотеки – либо поддержка там просто отстает (ну некогда!), либо "исповедуются" безнадежно устаревшие странности-парсеры вроде baml.
И все таки... Должны же быть хорошие oss библиотеки не спонсируемые большими компаниями?
Есть! instructor на PHP!
Единственная его проблема – чрезмерная переизбыточность, как минимум в документации/примерах в гитхабе. Я чуть было не отказался от этой библиотеки пока разбирался как же все таки отправлять запросы на Strict SO :)
>instructor-php поддерживает и те самые парсеры, и подкапотные внедрения json'ов в промпты.
Но в итоге вы получаете опыт похожий на привычный brrrrr от Пайдентика в Питоне со вложенными классами/энумами и описателями полей :)
(openai-php/client не умеет в рефлексию схем из php классов, там вам придется рисовать JSON елки руками или сторонними штуками.)
@m0n0x41d
"Мы были очень осторожны и тщательно занимались контекст инженирингом, но агент все еще периодически выбирает не правильные тулы или галлюцинирует в числах или датах, хотя дату мы прямо в промп динамически пишем :("
Смотрим под капот – код вроде бы вполне чистый... но проморгавшись видим в сумме 32 тула от подключенных mcp серверов + разные эвристически добавляемые присадки в промпт, где некоторые размером почти с газетный лист.
– "А как вы подходили к контекст инженерингу? Чем руководствались?",
– "Ну, мы на выступлениях услышали, что надо давать модели как можно больше контекста для выполнения задачи!"
– "А как определяли, что агенту реально нужно?"
...
¯\_(ツ)_/¯
Контекстная инженерия - это не фаршировка утки яблоками.
Без четкого представления о структуре и ответственности агента, и об интересах его пользователей, контекст легко превращается в помойку.
А это прямой путь к галлюцинациям.
Контекстная инженерия - это в первую очередь про ограничение контекста. Определение главной роли/ответственностей агента. И уже только потом про компрессию, перекладывание файликов, выбора тулов или любые прочие прикладные реализации.
Когда проводите такое моделирование, ответы на вопрос "Что нужно в контексте на самом деле?" возникают почти сами собой.
И сделать это проще чем кажется: поставьте себя (или эксперта в домене) "на место агента" и ответьте: какие документы, инструменты, знания и иные ресурсы мне нужны для выполнения задач? Какие действия и в каком порядке я буду выполнять?
Многие AI-системы работали бы стабильнее и успешнее, если бы такой подход применяли с самого начала.
@m0n0x41d
Смотрим под капот – код вроде бы вполне чистый... но проморгавшись видим в сумме 32 тула от подключенных mcp серверов + разные эвристически добавляемые присадки в промпт, где некоторые размером почти с газетный лист.
– "А как вы подходили к контекст инженерингу? Чем руководствались?",
– "Ну, мы на выступлениях услышали, что надо давать модели как можно больше контекста для выполнения задачи!"
– "А как определяли, что агенту реально нужно?"
...
¯\_(ツ)_/¯
Контекстная инженерия - это не фаршировка утки яблоками.
Без четкого представления о структуре и ответственности агента, и об интересах его пользователей, контекст легко превращается в помойку.
А это прямой путь к галлюцинациям.
Контекстная инженерия - это в первую очередь про ограничение контекста. Определение главной роли/ответственностей агента. И уже только потом про компрессию, перекладывание файликов, выбора тулов или любые прочие прикладные реализации.
Когда проводите такое моделирование, ответы на вопрос "Что нужно в контексте на самом деле?" возникают почти сами собой.
И сделать это проще чем кажется: поставьте себя (или эксперта в домене) "на место агента" и ответьте: какие документы, инструменты, знания и иные ресурсы мне нужны для выполнения задач? Какие действия и в каком порядке я буду выполнять?
Многие AI-системы работали бы стабильнее и успешнее, если бы такой подход применяли с самого начала.
@m0n0x41d
🌭1