Ваши AI агенты все еще застревает в циклах? Тогда я иду к вам! 💃
Меня вчера все таки выдернули на короткую консультацию(очень не хотелось работать в выходные.)
по проблеме стараой, доброй и прозаичной – "нам вообще не понятно почему оно периодически проваливается в бесконечный цикл tool-call вызовов."
При этом там одна *большая модель от гугла.*
В проекте использовался LlamaIndex с примерами прямо из документации :)
На удивление функциональности у агента мало, а в бесконечный цикл он провалился из-за противоречивого типа(ну точнее структуры) данных в ответах одной из функций (ну и промпт там был явно со странной структурой.)
Разобрались ровно за один часовой звонок. И вот буквально 10 минут назад мне отписались что "утром переписали, весь день тестируем и ни одного провала в циклы!"
Решили всё с помощьюсеребрянной-пули Schema Guided Reasoning – по каноничному примеру с выбором нужного тула (см тут.)
Никаких promp-издевательств.
Никаких бесконечных циклов.
¯\_(ツ)_/¯
В довесок приятно было услышать что ребята послушали мой "совет на закуску" и попробовали все таки модели подешевле – всё работает хо-ро-шо!
Вот она прелесть SGR - структурируешь и свое рассуждение и рассуждения LLM, решение работает если не одинаково, то как минимум предсказуемо на разных моделях.
Ну и денег можно сильно сэкономить :)
@m0n0x41d
Меня вчера все таки выдернули на короткую консультацию
по проблеме стараой, доброй и прозаичной – "нам вообще не понятно почему оно периодически проваливается в бесконечный цикл tool-call вызовов."
При этом там одна *большая модель от гугла.*
В проекте использовался LlamaIndex с примерами прямо из документации :)
На удивление функциональности у агента мало, а в бесконечный цикл он провалился из-за противоречивого типа
Разобрались ровно за один часовой звонок. И вот буквально 10 минут назад мне отписались что "утром переписали, весь день тестируем и ни одного провала в циклы!"
Решили всё с помощью
Никаких promp-издевательств.
Никаких бесконечных циклов.
¯\_(ツ)_/¯
В довесок приятно было услышать что ребята послушали мой "совет на закуску" и попробовали все таки модели подешевле – всё работает хо-ро-шо!
Вот она прелесть SGR - структурируешь и свое рассуждение и рассуждения LLM, решение работает если не одинаково, то как минимум предсказуемо на разных моделях.
Ну и денег можно сильно сэкономить :)
@m0n0x41d
Please open Telegram to view this post
VIEW IN TELEGRAM
Вы конечно можете закидать меня дизлайками, но правды это не поменяет:
AI не принес никаких кардинально новых проблем/задач в программную инженерию.
По крайней мере со стороны системного и программного дизайна.
***
Ну, посудите сами - разве раньше не было проблем с постоянным тушением пожаров, вечной войной с багами, медленными и разрушительными релизами? а?💣
Корни этих проблем всегда находятся где-то между:
- Проблем с тестированием; Либо тесты вообще не пишутся, либо они тестируют реализацию вместо интерфейсов;
- Высокой связности, при том не важно чего – псевдо-микросервисов в распределенном монолите, или модулей в монолите обыкновенном :)
- Серьезных затруднений в рассуждении о программных системах у наших разработчиков – мало кто реально осознает разницу между прикладным уровнем системы и уровнем ее дизайна;
- Низкой наблюдаемостью – не сразу понятно (или не понятно вообще), где что сломалось и как подступаться к дебагу;
- И так далее...
Какие же тут качественно новые вызовы со внедрением AI на бекенд?
Да существенно никаких.
Если мы не занимаемся машинным обучением, дата сатанизмом и прочим из "ядра" AI, а утилизируем готовые решения, пусть то модели по API или даже хостинг открытых моделей, не важно – все реальные боли упираются и легко вписываются в те самые "старые добрые".
Просто эти "старые" системы легче прощали ошибки, и спать ошибки тоже могли дольше.
Эти системы были много терпимее к плохой архитектуре, долго могли сохранять иллюзию надежности.
Так что для успешной разработки AI систем вам нужно не воображение и вера в чудеса, а инженерия ¯\_(ツ)_/¯
@m0n0x41d
AI не принес никаких кардинально новых проблем/задач в программную инженерию.
По крайней мере со стороны системного и программного дизайна.
***
Ну, посудите сами - разве раньше не было проблем с постоянным тушением пожаров, вечной войной с багами, медленными и разрушительными релизами? а?
Корни этих проблем всегда находятся где-то между:
- Проблем с тестированием; Либо тесты вообще не пишутся, либо они тестируют реализацию вместо интерфейсов;
- Высокой связности, при том не важно чего – псевдо-микросервисов в распределенном монолите, или модулей в монолите обыкновенном :)
- Серьезных затруднений в рассуждении о программных системах у наших разработчиков – мало кто реально осознает разницу между прикладным уровнем системы и уровнем ее дизайна;
- Низкой наблюдаемостью – не сразу понятно (или не понятно вообще), где что сломалось и как подступаться к дебагу;
- И так далее...
Какие же тут качественно новые вызовы со внедрением AI на бекенд?
Да существенно никаких.
Если мы не занимаемся машинным обучением, дата сатанизмом и прочим из "ядра" AI, а утилизируем готовые решения, пусть то модели по API или даже хостинг открытых моделей, не важно – все реальные боли упираются и легко вписываются в те самые "старые добрые".
Просто эти "старые" системы легче прощали ошибки, и спать ошибки тоже могли дольше.
Эти системы были много терпимее к плохой архитектуре, долго могли сохранять иллюзию надежности.
Так что для успешной разработки AI систем вам нужно не воображение и вера в чудеса, а инженерия ¯\_(ツ)_/¯
@m0n0x41d
Please open Telegram to view this post
VIEW IN TELEGRAM
#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
Читаете ли вы email подписки?
Anonymous Poll
19%
Читаю, но только eu (сабстак и тд)
3%
Читаю на русском (есть такие?🪨 )
16%
Читаю и eu и ru
63%
Нет, я читаю сам что хочу без рассылок.
🌭1