Антон Непша.js

Моё хобби — менять названия полей в тулах и смотреть, как это влияет на качество заполнения тулов данными, когда модель эти тулы вызывает. Потому что влияние там действительно есть))

Поначалу это влияние может быть незаметным, но на масштабе в сотни тестовых вызовов оно становится ощутимым — можно увидеть, как в 5-10% случаев нейронка пропускает какое-нибудь поле, заполняет его не тем, чем нужно, или не вызывает тул вообще (у DeepSeek такое часто происходит — он больше всех любит переспрашивать перед тем, как тул вызвать).

И если, например, ваша модель периодически пропускает какое-то одно поле, то дело может быть не только в описании поля, но и в его названии. Поэтому я люблю проводить эксперименты с названиями таких полей, стараюсь давать им как можно более конкретные и узкие наименования. Например, username вместо простого name или более конкретное product_page вместо широкого url.

Один из участников JS x AI Conf предложил проверить, что будет, если названия полей и тулов будут не на латинице, а на кириллице — ведь русские названия полей действительно должны быть максимально близки по смыслу к тому, что потенциально будет обсуждать русскоговорящий пользователь в чате с таким ассистентом. Соответственно, и работать это должно лучше. Да и JSON останется валидным, если вместо "username" я напишу "имя_пользователя".

Короче, я не мог не проверить эту гипотезу))

Перевёл все названия полей на русский язык, подключил GigaChat-2-Max, новую GigaChat-3-Ultra и DeepSeek-V4-Pro, и прогнал несколько ранов по одному из своих инструментов (1200 вызовов на каждую модель, 5 вызовов на каждый элемент в датасете). Затем сравнил результаты с одним из своих старых прогонов, где все поля и инструменты были на английском.

Результаты сравнивал по p95 latency и по точности заполнения полей. Получилось следующее:

DeepSeek-V4-Pro: количество ошибок заполнения полей снизилось с 6,9% до 6,7%, но зато p95 latency вырос с 12 до 18 секунд.

GigaChat-3-Ultra: ошибки в моих схемах выросли с 15,5 до 18,4%, зато p95 latency снизился с 6,6с до 3,9с!

Но самый интересный результат показал GigaChat-2-Max: p95 latency снизился с 6,19с до 4.67c, общее количество ошибок снизилось по моему датасету с 39,8% до 23,4%. Хотя по одному из полей ошибки выросли с 0,01% до 55,6% кейсов, содержащих данное поле. Так что, кажется, можно ещё подкрутить описание и выйти вообще в ноль)

Да, понимаю, это не те бенчмарки, по которым обычно сравнивают модели между собой. Не претендую на научную ценность исследования, но некоторая прикладная картина всё же вырисовывается — сразу видны слабые места в описаниях конкретно моих полей и инструментов. Чужие сухие бенчи такого никогда не покажут. Но всё-таки на кириллицу в JSONах я бы переходить не стал. Но если вдруг захочется заминмаксить latency ответа гиги на какой-нибудь простой задаче — кто знает, может быть и воспользуюсь таким лайфхаком)

Расширил свой недавний доклад про работу с GigaChat API и расскажу его 25 июля на Технохаб конф в Санкт-Петербурге.

Трансляции моего трека снова не будет, кстати, но в этот раз мой доклад будет записываться. В нём я поделюсь своим личным опытом перехода из фронтенд-разработки в разработку агентов, и на примере проблем, с которыми я сталкивался в последние два года, затрону архитектуру, observability и evals.

Хочу ещё попробовать включить в доклад одну любопытную идею, которая прозвучала из зала на JS x AI Conf на той неделе.
Но если вдруг не успею — в любом случае напишу об этом пост.

Регистрация на мероприятие обязательна, подробности на сайте Технохаб Конф.

Никогда ещё не уходил с митапа под таким сильным впечатлением, как вчера после JS x AI conf.

Думаю, можно смело удалять JS из названия митапа, потому что теперь есть просто AI, а JS — неважная деталь реализации, и фокусироваться на одном только JS больше не получится.

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

Девять человек! Девять разных спикеров за вечер говорят об одном и том же.

Некоторые — прямым текстом. Например,
Алексей Авдеев @aavdeev_channel и Саня Стародубцев @strdub рассказали, что в их компаниях уже нет никаких «я только фронтендер» или «я только ещё кто-то».

Михаил Харитончик в открывающем докладе рассказал, как он привязал умные очки к Hermes. Но лично для меня этот доклад был не про очки, а про «я могу взять агента и связать что угодно с чем угодно, и для таких повседневных задач не обязательно детально учить апи нужных мне сервисов или быть специалистом по настройке сетей или конкретных девайсов».

Ну а Рома Троицкий @vzhyx_exp рассказал про mcp-apps, которые сами по себе стирают границы между фронтом, бэком и AI.

Доклады с оффлайна тоже были в том же векторе — недостаточно быть узким специалистом, нужно перестраиваться, адаптироваться, бесконечно расширять экспертизу и постоянно следить за индустрией.

Мне сложно давалось принятие этого тренда — физически не хватало сил следить за обилием новостей и скоростью изменений, и я довольно долго оставался на уровне работы с Cursor серединны 2024 года, когда ещё приходилось что-то перепроверять, дописывать, допиливать напильником, разбираться в деталях. В общем, держался за привычную роль разработчика, цепляясь за традиционные подходы.

Но вчерашний митап окончательно дал мне понять, что привычная роль разработчика — всё.

Короче. Доклады здесь. Правда, в записи было только 4 доклада из 9, но лично для меня полезными оказались все.

Агентские фреймворки больше не нужны

Мне стали часто попадаться видео автора Jake Van Clief, который в каждом видео говорит, что LangChain и прочие агентские фреймворки — это пустая трата времени, и что для разработки агента достаточно написать несколько .md-файлов.

И я не смог не попасться на такой кликбейт, особенно если учесть, что я уже два года на LangChain разрабатываю. Вдруг я и правда зря время потратил))
Пришлось погрузиться в статью этого автора на arxiv.org, чтобы в этом разобраться. Оказалось, это был не совсем кликбейт.

Interpretable Context
Methodology
Вообще это скорее маркетинговое название подхода, а не термин. А идея подхода состоит в том, что для построения поэтапного пайплайна работы агента достаточно воспользоваться пронумерованными папками, которые и будут являться шагами этого пайплайна.

В каждой папке лежит свой промпт, которому агент должен следовать на текущем этапе, и описание контракта на вход и на выход. И какие-нибудь скрипты, которые на этом этапе нужно выполнить.

Конечно, лучше всего это работает с Claude или чем-то похожим — для этого подхода нужен агент, способный ходить по папкам и читать .md-файлы с контекстом.

Зато, во-первых, читать эти .md-файлы он будет не все сразу, а поэтапно, и только те из них, которые нужны на текущем шаге.

Во-вторых, при переходе на каждый последующий этап контекст из нужного файла попадёт в конец контекстного окна, что должно исключать Lost in the Middle.

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

Неким подобием observability будут служить те же .md-файлы, которые будут создаваться на выходе на каждом этапе. И их же при необходимости можно поправить руками в VS Code перед тем, как агент приступит к следующему этапу и загрузит их в контекст.

В чём минусы, или почему агентские фреймворки всё-таки нужны
В статье честно говорится, что у подхода есть ряд ограничений: например, ICM последовательный buy design, параллельные вызовы LLM в нем не настроить. В нём нет отказоустойчивости: ни ретраев, ни фоллбэков, только ручной перезапуск. Нет алгоритмических проверок structured_output, нет четкого роутинга, нет многопользовательскости. Энтерпрайз решение на .md-файлах пока что не построишь.

Для чего тогда нужен ICM?
Лично я использую этот подход как один из способов написания скиллов для Claude и гигакода.
Он удобен в случаях, когда от скилла требуется поэтапное выполнение инструкций, когда нужна возможность валидировать и править промежуточные результаты, или если вам важно не подмешивать в LLM лишний контекст раньше времени.

В репозитории ICM есть несколько примеров таких скиллов.

Я для прикола решил по образу и подобию собрать пайплайн поиска инфы в интернете через гигакод. Ходит теперь, чейньжлоги с гитхаба собирает для меня, статьи с хабра и посты с реддита, агрегирует это всё, а потом собирает дайджест.

На LangChain я бы точно поленился это писать))

Тра-та-та, а вот и я)))

OWASP Top 10 для агентских приложений

Стандарты кибербезопасности Open Web Application Security Project есть не только для веба, но и для LLM-приложений и агентов.

В OWASP Top 10 For Agentic Applications 2026 перечислены 10 самых опасных уязвимостей, которым могут быть подвержены разрабатываемые нами AI-агенты, а так же способы их предупреждения и устранения.

Некоторые из уязвимостей прям любопытные:
Есть, например, ASI08: Cascading Failures, когда из-за одного зараженного агента эффектом домино компрометируются остальные агенты, которые начинают получать и исполнять вредоносные инструкции от вышестоящего в иерархии агента.
Или ASI04: Agentic Supply Chain Vulnerabilities — если вы используете MCP-сервер или какое-нибудь удалённое хранилище промптов, а они вдруг окажутся взломанными, то ваш агент начнёт делать не то, что вы от него ожидаете. Так что поаккуратнее с опенсорсными MCP.
Ну и ASI01: Agent Goal Hijack — подмена цели вашего агента через скрытые инструкции (например, скрытый текст, который попадает в ваш промпт при парсинге веб-страниц). Отличие от промпт-инъекции здесь в том, что влияние происходит не на один аутпут модели, а на саму цель, которую будет преследовать ваш агент. То есть потенциально будут затронуты все последующие действия вашего агента.

Как всего этого избежать:
Во-первых, не доверять никакому внешнему контенту без предварительной проверки. Это касается не только MCP, но и пользовательского инпута и запросов от других агентов - не забываем его санитизировать и валидировать.
Во-вторых, агентам следует выдавать только минимальный набор необходимых полномочий и, по возможности, аппрувить вызовы некотрых функций вручную (привет, YOLO-mode из курсора).
В-третьих, и об этом упоминается практически в каждой второй уязвимости, очень важно настроить грамотное логирование и мониторинг событий. Это поможет раньше заметить те случаи, когда ваш агент делает что-то, что не входит в его изначальный набор привилегий. Как раз пригодится мой доклад про дебаг LLM-приложений, где мониторинг и логирование тоже затрагивается.

И, кстати, помимо OWASP Top 10 For Agentic Applications 2026, который специализируется на агентах, есть ещё OWASP Top 10 для LLM-приложений, где собраны основные советы по противодействию обычным промпт-инъекциям, утечкам системных промптов, по устранению уязвиомостей векторов и эмбеддингов, и т.д.

Как я искал утечку памяти в приложении на Python

На этапе нагрузочного тестирования обнаружилась утечка памяти в контейнере приложения, которое я разрабатываю.

До этого мне приходилось сталкиваться с утечками в JS в браузере, я даже доклад про это рассказывал, но в этот раз утечка была в агенте на Python, поэтому браузерные девтулзы там не помогли бы — пришлось разбираться в этом вопросе заново.

Профилировать я начал с pytest-memray.
Это было проще всего — подключаешь плагин pytest-memray к уже написанным тестам на pytest, запускаешь тесты как обычно, и получаешь на выходе топ 5 функций, которые за время работы тестов аллоцировали наибольшее количество памяти.

Memray
Отчёт pytest-memray не самый подробный — это просто текст.
Поэтому я решил перейти на обычный memray, который работает независимо от pytest и способен выдавать самые разные форматы отчетов. Я использовал Flamegraph-диаграмму и линейный график.

Подготовил скрипт для memray, который вызывал бы моего агента со всеми возможными наборами параметров, сделал заглушки на вызовы гигачата и других сервисов, прогнал этот скрипт 10000 раз — и увидел тот самый классических восходящий график использования памяти, а так же статистику по использованию памяти во всех вызванных функциях.

Причина утечки
Работа с результатами отчета привела меня к файлу с таким кодом:

from prometeus_client import Histogram

metrics = Histogram(
name="my_service",
labelsnames=("sender", "status", "time"),
)

def send_metrics(
sender: StrEnum,
status: StrEnum,
time: float
):
metrics.labels(
sender=sender,
status=status,
time=time
).observe(time)

Респект, если вы уже догадались, в чём тут причина)) Я гадать не стал, признаюсь, сразу пошел в гигачат. Это не реклама, кстати, просто из корпоративной сети мне доступен только он. Но я и не жалуюсь, т.к. гигач сразу указал на причину утечки — лейбл time.

Почему именно time, а не, например, status?
У лейбла status набор возможных принимаемых значений ограничен енумом — либо "success", либо "error" (это для примера). Соответственно, сколько бы я ни гонял свой скрипт, хоть 5 раз, хоть 500, в метриках сохранится только два варианта значений этого лейбла — "success" или "error".

У лейбла sender значений чуть больше, но тоже вполне ограниченное количество.

А вот лейбл time в моём случае означал время обработки запроса. С типом float. То есть, запрос мог обработаться, например, за 0.5 секунд со статусом "success". А мог за 0.2 со статусом "error". Или за 0.10002 секунд, 0.037261846 секунд, 0.137, 0.9989 и ещё за огромное количество вариаций. Умножьте это количество вариаций на комбинации с остальными лейблами, которых тоже на самом деле было не три, а чуть больше, и вы поймёте, почему я в воскресенье вечером про утечки памяти пишу))

UI киты для создания AI-агентов

В последнее время всё чаще приходится создавать прототипы своих AI-ассистентов, чат-ботов, визуализировать агентский воркфлоу и т.д. Лично я за этот год поучаствовал в трёх или четырёх таких проектах, где нужно было прототипизировать фронт для чат-ботов, поэтому решил собрать список UI китов, предназначенных именно для этих целей:

1. AI Elements от Vercel — самое популярное решение для разработки чат-ботов. Содержит кучу компонентов, работает с Next.js, AI SDK и вообще с экосистемой Vercel. Есть даже компонент Web Preview для отрисовки превью разрабатываемых сайтов в iframe. Правда, пока просматривал документацию, поймал себя на мысли, что комплексити этих компонентов иногда даже пугает. Особенно тут, где одна плашка подтверждения разбита на целых 7 компонентов.

2. Assistant UI — ещё один UI kit для чат-ботов. В отличие от предыдущего кита это open source-проект, не Vercel, и с более простым, на мой взгляд, синтаксисом. При этом точно так же, как и AI Elements, компоненты можно устанавливать отдельно через CLI.

3. prompt-kit — набор компонентов поскромнее, чем у предыдущих двух, но вполне может подойти для прототипирования интерфейсов простых чат-ботов. Тем более, даже у этого open source решения тоже есть свой MCP сервер с документацией, который можно подключить к себе в Cursor, например.

4. shadcn-chatbot-kit — практически не отличается от предыдущего UI кита. Чуть меньше компонентов, чуть меньше звёзд на GitHub. Но он очень простой и свою задачу вполне выполняет. Да и выпиливать его будет проще, когда будете переезжать на Assistant UI или на самописный кит)

5. Напоследок решил немного отойти от только чат-ботов и добавить в список несколько библиотек для визуализации графов и диаграмм. Например, ReactFlow сейчас используется практически всеми инструментами с агентскими воркфлоу: на ней работает LangGraph Studio, на ней построен компонент Workflow из Vercel AI Elements и Workflow из Mastra AI Studio. А ещё есть SvelteFlow. И Vue Flow, на котором построен UI в n8n. В общем, если когда-нибудь захотите сделать свой клон n8n или LangGraph Studio, сможете выбрать сразу из нескольких решений.

Заметил, что популярных UI китов под создание агентов как будто бы не так много. Если сесть и целый день целенаправленно их гуглить, найдёшь только пару самых популярных монополистов, а всё остальное будет похоже на их упрощённые форки: везде один и тот же radix-ui + Tailwind под капотом. Разве что, нашёл ещё полузаброшенный CUI Kit, который на написан emotion.

Скорее всего, все либо пилят кастом, либо используют киты с более широкой областью применения, такие как GravityUI. На одном проекте, например, я использовал Plasma UI от SberDevices.

Ну либо radix-ui и Tailwind — это новый стандарт. У той же elizaos фронт тоже на radix-ui написан.

Кто-нибудь разворачивал Sentry локально?

Я вот попробовал. Правда, надо было сначала обратить внимание на минимальные системные требования в 4 ядра CPU и 16 GB RAM + 16 GB swap.

С такими запросами Sentry нагружал до 90% CPU у игрового ноутбука 3-летней давности и забирал почти всю оперативную память. При этом, ставился он часа два (долго скачивались пакеты), а все его 70+ сервисов в Docker Compose поднимались после установки ещё минут 15.

И ты сидишь такой с тормозящим ноутбуком и пытаешься ОШИБКИ ОТЛАВЛИВАТЬ)) Такой себе опыт разработки получился)

Хорошо, что у меня оказался второй ноутбук
Хоть он и старый, но с 32GB RAM, которые как раз можно было бы удачно утилизировать на поднятие Sentry.
Правда, на нём винда, а Sentry на винду ставиться не захотел.
Благо, у Windows есть возможность развернуть виртуальную Ununtu через команду:

wsl.exe --install Ubuntu-24.04

Далее в этой виртуальной Ubuntu я ставлю Sentry, и остаётся только настроить port-forwarding, чтобы перенаправлять запросы из локальной сети до WSL. Делается это через Windows Powershell:

netsh interface portproxy add v4tov4 listenport=9000 listenaddress=0.0.0.0 connectport=9000 connectaddress=$wsl_ip

Ну и там же настраиваем Windows Firewall:

New-NetFirewallRule -DisplayName "Sentry WSL Access" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 9000

Теперь с любого устройства, подключенного к моему Wi-Fi, есть доступ до 9000 порта виртуальной Ubuntu на старом ноуте, где у меня развёрнут и работает Sentry.

Естественно, Sentry полностью забрал на себя почти всю мощность старого ноутбука (vmmem забирает на нём 20+гб RAM), но зато на том устройстве, с которого я привык работать, теперь есть и доступ к Sentry, и все ресурсы свободны.

Вот зачем, оказывается, люди себе домашние серверы ставят. Радуюсь, как ребёнок.

Как из фронтендера стать AI-инженером

Термин "AI-инженер" я подсмотрел в роадмапе AI-инженера, ссылкой на который недавно делился Саня Стародубцев.

Я ведь недавно и сам перешёл из фронтенд-разработки в разработку AI-агентов, поэтому мне стало интересно, стал ли я AI-инженером? Мой собственный опыт "переквалификации" не совсем ложится на эту дорожную карту. Есть ещё один роадмап, вот этот, но там порядок тоже не совсем такой, как у меня. В общем, решил поделиться здесь своей альтернативной версией)

Пререквизиты
Опыт работы с бэкендом всё-таки понадобится. Одной фронтенд-экспертизы явно будет недостаточно. Работать с API нейросетей скорее всего придётся с бэкенда. С фронта тоже можно, конечно, но в этом есть большой риск утечки вашего API-ключа.
Благо у нас, JavaScript-разработчиков, с этим проблем нет))

Впоследствии, конечно, нужно будет углубляться в бэкенд-разработку и заполнять пробелы, если они есть. Но для старта вполне достаточно умения развернуть сервер на Node.js.

Нужен ли ML?
Здесь ситуация чем-то напоминает необходимость изучения алгоритмов для junior-фронтендера в 2019 году. Вызвать API DeepSeek можно и без знания линейной алгебры. Но я бы всё-таки порекомендовал хотя бы в фоне изучить этот бесплатный вводный курс по ML от Google. Очень поможет снять розовые очки и демистифицировать работу самих LLM.

Пишем чат-бота
Прям сразу. На практике разбираться будет проще всего. У меня всё началось с телеграм-бота, и я всем советую начинать с простых текстовых чат-ботов. Для этого придётся изучить работу с текстовыми сообщениями в OpenAI API или DeepSeek API. Лично я рекомендую начать с руководства GigaChat API, т.к. оно на русском языке, а многие концепции у разных моделей очень схожие. Бесплатных токенов за регистрацию в GigaChat API будет более чем достаточно для старта.

Учим чат-бота выполнять функции
Их ещё называют tools. Об этом у меня тоже был пост и примеры кода к нему на JS и на Python. Они нарочно очень простые. У GigaChat тоже есть статья с примерами. А если хочется чего-то совсем запутанного, можно взять шаблон чат-бота из Vercel AI SDK в качестве референса.

Векторные хранилища и RAG
Про векторы есть отличная глава в упомянутом мной выше курсе от Google. В роадмапе AI-инженера, кстати, тоже неплохие ссылки по этой теме в разделах Embeddings и RAG.

Фреймворки
Лично я пока продолжаю погружаться в LangChain. Я уже трижды выступил с докладом про этот фреймворк (в последний раз — на MoscowJS), выпустил два поста с ответами на вопросы (раз, два) и всё ещё не погрузился до конца))
По этому фреймворку есть миллиард примеров от моих коллег из GigaChain: есть примеры на Python, JavaScript и даже на Java. А от создателей LangChain есть кайфовый видеокурс по LangGraph. Он на английском, но его легко смотреть, даже не зная Python и не зная LangChain.

Источники новостей и апдейтов
Очень удобно получать новости с конференций вроде нашего недавнего BigTechNight или с HolyJS, где я тоже скоро буду выступать. Или c разделов на Reddit о тех инструментах, которые вы используете (я, например, читаю в основном про LangChain). Ещё есть Matt Pocock, который параллельно с нами перешёл из TypeScript гуру в гуру нейросетей, выпускает неплохие статьи и видео. Громкие новости об обновлениях у моделей OpenAI / Anthropic / DeepSeek и т.д. всё равно не удастся пропустить. Остальные рандомные новости из соцсетей, кстати, наоборот стараюсь фильтровать: в X что ни пост — так очередная технореволюция)) Хотя, возможно, кто-нибудь в комментариях тоже поделится неплохими источниками информации)

Промпт vs Tools, часть 2

Продолжаю тестировать промпты и тулы по мотивам предыдущего поста, но в этот раз увеличил количество тестов с 25 до 100 и запустил их на зарубежном сервере с доступом к OpenAI API. Ниже делюсь результатами:

Разница в скорости между тулами и промптами у моделей OpenAI не так значительна

gpt-4o-mini обработала 100 запросов с промптами за 35 секунд, с функциями — за 60, т.е. медленнее в 1,7 раза.
GigaChat-2-Max справился с аналогичной задачей за 29 и 107 секунд соответственно, здесь тулы работают медленнее промптов в 3,6 раза.

Местоположение влияет, но не так, как я предполагал

Запущенные мной из дома 100 тест-кейсов с GigaChat-2-Max отработали за 29 секунд. Эти же 100 кейсов, запущенные с зарубежного сервера, выполнились за 158 секунд.

И вроде кажется, всё логично — сервер зарубежный, поэтому такая разница в скорости. Вот только o4-mini справилась с этими же 100 тестами за целых 170 секунд, gpt-5-nano — за 200.

Если бы не gpt-4o-mini, отработавшая за 35 секунд, я бы подумал, что с сервером что-то не то.

Что в итоге
Во-первых, конечно, сравнивать скорость и результат стоило бы у сопоставимых по параметрам и объёму моделей, а не у всех подряд. Но тогда этот пост превратился бы в курсач))

Во-вторых, под каждую задачу, которую вы решаете, нужно подбирать модель отдельно. И это я ещё у самих моделей параметры не менял. По-хорошему, нужно было выставить temperature на минимум и ограничить max_tokens: двух-трёх output-токенов уже будет достаточно для того, чтобы LLM смогла выбрать одно из пяти ключевых слов по моему запросу.

Ну и в-третьих, если вы работаете из России, то вам совершенно нет смысла не использовать GigaChat. Ну или точно нет смысла исключать его из списка моделей, которые вы рассматриваете. С рядом задач он справится значительно быстрее.

Маршрутизация LLM через промпт или через tools

Я никакой не Data Scientist, я просто фронтендер.
Но даже фронтендеру иногда бывает интересно, что лучше отработает — обычный промпт типа такого:

Верни слово "auto", если пользователь говорит про автомобили. Верни слово "movie", если пользователь говорит о фильмах…

или передача в LLM функций (или тулов) с описанием каждой из категорий, между которыми LLM нужно сделать выбор.

И да, эту задачу можно было бы решить и с помощью векторов, но мне захотелось сравнить именно эти два подхода.

Первый способ может показаться ненадёжным и контринтуитивным — мы ведь не используем structured_output, поэтому ответ модели здесь не так строго типизирован, как во втором случае. Но так ли всё просто?

Как я сравнивал промпт и тулы
— Написал первый промпт. Он будет проверять, насколько хорошо LLM маршрутизирует, используя обычное текстовое описание:

Твоя основная задача — правильно определить категорию вопроса пользователя.
Если вопрос касается автомобилей, ответь "auto".
Если вопрос касается кораблей, ответь "ship".
Если вопрос касается фильмов, ответь "movie".
Если вопрос касается мотоциклов, ответь "moto".
Если вопрос не относится ни к чему из вышеперечисленного, ответь "incorrect".
Если из фразы клиента не удалось понять, к какой категории относится вопрос, задай клиенту уточняющий вопрос.

— Второй промпт выглядел так же, как и предыдущий, но без описания категорий — их я вынес отдельно в функции. Этим промптом я буду проверять качество маршрутизации с помощью тулов. Получилось в итоге следующее:

Твоя основная задача - правильно определить категорию вопроса пользователя.
Если из фразы клиента не удалось понять, к какой категории относится вопрос, задай клиенту уточняющий вопрос.

— Описал 25 тестовых фраз и их ожидаемый результат по каждой из них.

— Запустил все 25 тестов с первым промптом, затем 25 этих же тестов со вторым промптом и тулами.

— Повторил проверки на шести разных моделях GigaChat и на DeepSeek.

Результаты
Что касается DeepSeek, то почему-то даже на один мой запрос их API отвечал целых 5 секунд, поэтому он выбыл из гонки, так особо в ней и не поучаствовав.

А вот GigaChat показал интересную статистику:

Во-первых, промпт с тулами отрабатывал в среднем в 2-3 раза медленнее обычного текстового промпта — 25 вызовов GigaChat с текстовым промптом отрабатывали за 6-8 секунд, в зависимости от модели. А 25 запросов с тулами занимали в сумме от 18 до 23 секунд.

Во-вторых, промпт с тулами расходовал в 2-3 раза больше токенов — от 800 до 2300 за обычный текстовый промпт, и от 2400 до 4600 токенов за промпт со structured_output.

В-третьих, structured output не всегда давал 100% точность. Было интересно увидеть, как GigaChat-Max и GigaChat-2-Max с обычными текстовыми промптами показали максимальную точность (25 из 25) среди всех моделей.

Что ещё более странно — наименьшую точность среди всех моделей показали эти же GigaChat-Max и GigaChat-2-Max со structured_output (21 из 25).

Я понимаю, что объём тестовых данных у меня совсем небольшой.
Уверен, что если бы тестов у меня было не 25, а 25000, то результаты, скорее всего, были бы совсем иными.

Но в любом случае результаты меня очень удивили. Проверяйте свои инструменты внимательно под каждую задачу))

Чем приходится заниматься вместо фронтенда

Несколько месяцев назад я перестал быть фронтендером и перешёл в разработку AI-агентов в Сбере. Направление невероятно популярное и очень увлекательное)
Настолько популярное и увлекательное, что фронтенд словно уходит на второй план. Напишешь про какие-нибудь новые проперти для View Transition API в Chrome 140, а у чувака из соседнего канала нейросеть сама пишет целый сайт за один промпт. Да и с переходом на новую роль мне становится всё сложнее выделять время на то, чтобы погружаться в дебри фронтенд-инструментов.

Где найти выход?) Лично я стараюсь совмещать эти два направления. Если и есть что-то общее у фронтенда и у AI-агентов, так это JavaScript) JavaScript-экосистема настолько очистилась обширная, что решений для AI-агентов на нашем любимом языке написано очень много))

Вчера, например, тестил elizaos
Очень любопытный фреймворк для создания мультиагентных систем на JavaScript. Давно на него смотрел, т.к. звёзд на github у него даже больше, чем у LangChain.js. И в два раза больше форков.
Недавно у elizaos добавился cli и обновилась документация, поэтому решил наконец-то попробовать поставить её себе.

Чем привлекает elizaos
- Из коробки доступна среда для создания чат-ботов или агентов и для общения с ними. Можно создавать общие чаты с несколькими ботами сразу, общаться голосом, загружать в них документы и т.д.;
- Интеграция с Telegram и Discord тоже из коробки;
- Ботам можно задавать роли и прописывать для них персонажей. Это, конечно, сводится к большому системному промпту и локальной БД для запоминания ключевых фактов из биографии и диалогов, но лично меня так и тянет сгрузить туда пару постов из своего канала и несколько своих переписок, чтобы заставить моего бота общаться так же, как общаюсь я. Понимаю, что это и так не сложно сделать, но в elizaos вся эта логика уже написана за меня, а мне остаётся только подготовить данные;
- Работает с API OpenAI, Anthropic, Grok или локальными моделями.

Из минусов могу отметить прежде всего тот факт, что это очередной фреймворк, в детали которого придётся погружаться. Причём, скорее всего, не для production-целей.

P.S.
Вчера с удивлением обнаружил, что OpenRouter больше не пропускает запросы из РФ, и просто так OpenAI API мне уже не вызвать. Пришлось импровизировать с gpt2giga — прокси, который принимает запросы в формате OpenAI, и направляет их в GigaChat))
Всё завелось, хоть и не с первого раза — саму gpt2giga пришлось тоже немного доработать. Плюс, кажется, остались несовместимости в работе эмбеддингов. Но в любом случае пользовательский опыт получился интересный — вводишь пару команд в консоли, и у тебя готовая полноценная команда из чат-ботов.