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

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-приложений, где собраны основные советы по противодействию обычным промпт-инъекциям, утечкам системных промптов, по устранению уязвиомостей векторов и эмбеддингов, и т.д.

Инструменты дебага LLM-приложений на JS

Опубликовали запись моего доклада с HolyJS 2025 Autumn, в котором я сравнивал observability- и дебаг-инструменты для LLM-приложений.

Доклад теперь можно посмотреть на YouTube и в VK Видео, а презентацию я уже выгладывал в одном из предыдущих постов.

Как я искал утечку памяти в приложении на 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 и ещё за огромное количество вариаций. Умножьте это количество вариаций на комбинации с остальными лейблами, которых тоже на самом деле было не три, а чуть больше, и вы поймёте, почему я в воскресенье вечером про утечки памяти пишу))

Инструменты дебага LLM-приложений

Вот так в одном слайде могут уместиться результаты полутора лет экспериментов (см. дату моего первого поста про LLM), сравнения разных инструментов и попыток найти наиболее удобный и подходящий под нужды нашего проекта Developer Experience.

Sentry разворачивал через боль просто потому что уж очень хотелось посмотреть, что есть в их новой AI Agents Insights.

LangChain-стек первый год вообще не вызывал ничего, кроме отторжения и непонимания смысла в его лишних абстракциях. Из этого даже отдельный доклад родился. Разобрался, стало легче. Понравилась их студия, которая позволяет, собственно, «дебажить».

Уже позже пришел к Langfuse и Phoenix, и остановился на Langfuse из-за наиболее подходящего под мои нужды набора инструментов и OpenSource лицензии.

В общем, выступил сегодня на HolyJS с обзором возможностей Sentry, LangGraph Studio, Langfuse, Arize Phoenix, Mastra и Lunary в плане дебага, observability и удобства разработки. Самый главный слайд — перед вами)

Вся презентация выложена на сайте конференции. Как только доклад выложат в открытый доступ, тоже сразу поделюсь тут:)

Сегодня этому каналу исполняется два года

Перед тем, как писать этот пост, я решил для сравнения прочитать итоги, которые я подводил год назад. Боже, какой же я тогда был наивный, счастливый и беспечный))

В этот раз хочется обойтись без клише про «стимулы для развития», поэтому попытаюсь рассказать всё как есть)

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

Расскажу на что сейчас уходит мой ресурс и чем приходится заниматься на работе: изучать Python с лангчейном, погружаться в работу k8s и OpenShift (пришлось вспомнить всё, что я знал о линуксах), писать докерфайлы и CI/CD пайплайны, изучать работу новой платформы, в которой каждую неделю появляется что-то новое, разворачивать в банке OpenTelemetry-тулинг для всего этого, и даже писать юнит-тесты на изменение КОСИНУСНОГО РАССТОЯНИЯ.

Параллельно я стараюсь погружать во всё это разработчиков, аналитиков, тестировщиков и архитекторов из соседних трайбов, продумывать удобный DX и разрабатывать целевой релизный процесс. Ну и доделывать оставшиеся задачи по СберБанк Онлайн — они ведь тоже никуда не делись.

Но я не жалуюсь — задачи правда интересные. И ими тоже хочется делиться, хоть они и не совсем подходят под изначальную тематику канала.

Поэтому основной итог года для канала — его превращение из канала про Frontend в канал про Frontend-AI-DevOps))

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 пришлось тоже немного доработать. Плюс, кажется, остались несовместимости в работе эмбеддингов. Но в любом случае пользовательский опыт получился интересный — вводишь пару команд в консоли, и у тебя готовая полноценная команда из чат-ботов.

Ответы на вопросы с MoscowJS, часть 2 Первая часть была опубликована вчера.

Спасибо Ане @it_wildlife за тестирование антиспама в комментариях — благодаря вчерашним тестам мне удалось обойти проблему в Telegram API, из-за которой комменты от ботов тяжело отличить от комментов, оставленных от имени Telegram-канала.

Теперь бот не будет так бурно реагировать на комменты от имени каналов. Ну а я продолжаю отвечать на оставшиеся вопросы:

Использовал ли ты прокси gpt2giga, чтобы уметь перенаправлять запросы из OpenAI без дополнительных костылей и накладок на несовместимые апи? Пока нет, но у меня есть идея, куда его прикрутить: я развернул LangFuse, и в нём помимо трейсинга есть LLM Playground. И, кажется, gpt2giga должен помочь превратить его в GigaChat Playground)) Посмотрим, получится ли)

Векторизацию и векторные базы данных используете если много текста отправляете в ИИ? Расскажите подробнее про это Много текста я не отправляю — контекст у бота ограничен одним постом из телеграма и некоторыми комментариями под ним. Пока этого хватает, но если буду расширять функционал, в LangChain есть поддержка векторных хранилищ.

Есть ли смысл использовать LangChain, если используется только одна апишка? Если вы уже знакомы с LangChain, то думаю, что да, в таком случае смысл есть)) Хотя бы даже ради трейсинга и первичной отладки приложения через LangSmith. Причём для этого достаточно использовать LangChain по минимуму — только для вызова LLM. Всё остальное можно писать на чистом JS/Python.

Получается, если LLM возвращает нормальный JSON, то можно спарсить значение и прогнать логику, к примеру, забанить пользователя за спам? Насколько это рабочая тема на практике? Всё верно. На практике это решение не просто рабочее, а можно даже сказать целевое)) Ну или как минимум одно из целевых, если речь идёт об обработке инпута на естественном языке. Единственное, мне кажется, не стоит использовать его для тех задач, которые можно решить и без LLM.

Если не секрет, какой бюджет уходит на поддержание этого ежемесячно? Бот хостится на бесплатной VM от Cloud.ru. А токенов за месяц у меня расходуется примерно на 300-350 рублей. Но у меня ещё лежит неиспользованный бесплатный миллион токенов GigaChat Lite, и если использовать ещё и их для каких-нибудь простых задач, то выйдет дешевле.

Правильно ли я понимаю, что LangChain - это аналог LangFlow, но без графического интерфейса, и зато с большей гибкостью? Какие плюсы и минусы? Да, LangFlow — no-code/low-code фреймворк, поэтому если сравнивать его с code-first фреймворком вроде LangChain, то плюсы и минусы будут зависеть от того, любите вы писать код или нет)) Если нужно набросать какой-то небольшой прототип или Proof of Concept, то low-code подход, наверное, должен быть более удобным, но лично мне было бы проще навайбкодить код написать)

Пора переучиваться на инженеров нейросетей?) Пока получается переучиваться только в инженеров фреймворков для работы с нейросетями)) Но это тоже неплохой старт, я считаю)

Знаком ли с AI SDK от верцелей? Довольно хорошо подходит для твоей задачи. Тоже абстракция над всеми провайдерами, но вот langchain уровнем выше имеет другие фишки типа для RaG, эмбдингов, сторить всё и т.д. Пока не пробовал, но, судя по документации, инструмент действительно похож на LangChain. И скачиваний в npm у Vercel AI SDK больше. Нужен отдельный доклад с разбором их абстракций))

Материалы с доклада про LangChain

Вчера рассказал этот доклад на @moscowjs. Если вы не были на митапе — есть ссылка на запись. Если были — ссылка на форму обратной связи по организации митапа))

Делюсь презентацией и ответами на первую половину вопросов к докладу (вторая половина будет завтра).

У GigaChat стоимость токенов в 7 раз выше, чем у DeepSeek/Gemini/ChatGPT. Почему GigaChat стоит дороже иностранных ИИ в 7 раз? Сами какую ИИ используете на постоянку? В основном использую как раз GigaChat из-за простоты оплаты в РФ. Там есть Free Tier токены, а платного пакета мне хватает почти на год использования. Последний раз пополнял баланс в декабре прошлого года, израсходовано чуть больше половины.

Как на спам сообщениях не разориться на токенах? Я сейчас доделываю whitelist, чтобы проверка на спам не выполнялась для комментариев от доверенных авторов (которых у меня в канале почти 100%). Но если будет резкий наплыв с тысячами комментов в час — разорюсь, конечно. Сначала израсходуются токены GigaChat на оставшиеся 800 рублей, потом израсходуются мои $8.5 из OpenRouter, и дальше антиспам будет падать в ошибки, придётся закрывать комментарии и вручную чистить спам. Но скорее всего я закрою комментарии раньше, чем израсходуются все токены — бот мне репортит в личку каждый раз, когда удаляет чьи-то комментарии.

Есть ли в LangChain.js встроенные механизмы для уменьшения затрат на API-запросы (например, кэширование, чанкинг)? Про caching на стороне LangChain есть только вот эта дока, которая наполовину депрекейтед (используется старый класс Openai). Но сам способ в ней описан рабочий — если передать cache: true при объявлении экземпляра класса работы с LLM, то при одинаковых вводных параметрах LLM второй раз не вызовется. Ну и плюс на стороне самих моделей есть механизмы кэширования, правда они везде свои. У GigaChat, например, это вообще заголовок, который через LangChain.js туда не передать. Это как раз один из кейсов, когда приходится вызывать LLM напрямую, минуя LangChain.

В LangChain для каждой нейросети нужно вставлять токен? А если у какой-то нейросети токен закончится — что будет? Будет то же самое, что и без LangChain. LangChain отправит запрос, нейросеть ответит какой-нибудь 403 ошибкой. Но на эти случаи в LangChain можно делать fallback на другие модели.

У вас было много ИИ, все платные, видел DeepSeek, OpenAI, GigaChat, нет ли проблем с оплатой, поддержанием всего этого? А главное зачем? Если они все примерно одинаковые и можно использовать одну ИИ с тем же результатом. А для многих ИИ ещё и прокси нужны, нет ли сложности поддерживать весь этот зоопарк ИИ? С поддержкой проблем нет, LLM для LangChain это всего-лишь строчка с ключом в .env файле и экземпляр класса LLM, который лежит спокойно себе в каком-нибудь файле models.ts в проекте. В этом LangChain как раз и удобен — переключаться между разными LLM с ним очень просто. А вот с оплатой OpenAI и DeepSeek проблемы, конечно, есть. Я писал пост о том, как вызывать OpenAI бесплатно через github models, но там лимит на 50 запросов в сутки, и меня там забанили. Поэтому GigaChat, тем более там 1 млн токенов GigaChat Lite выдаётся бесплатно)

Какой конкретный бизнес профит от этого использования? Если не брать в учет арбузики Как это не брать в учёт арбузики? А вообще, если вопрос о бизнес-профите канала, то его нет, это хобби. А если речь о том, есть ли бизнес-профит в LangChain — тут скажу, что трейсинг запросов через инструменты вроде LangSmith порядочно ускоряет разработку. Порог входа в сам LangChain не самый простой (по крайней мере, лично для меня), но в последствии разрабатывать тоже получается быстрее за счёт того, что часть костылей написано за вас сообществом LangChain.

Какие прокси используете для доступа к ИИ Gemini/OpenAI которые закрыты из РФ с их стороны? Я использую OpenRouter, но его тоже приходится пополнять только с помощью друзей-держателей карт зарубежных банков. В комментариях к этому посту советовали ещё и другие сервисы, но я даже не успел их все попробовать.

Superwhisper beta для Windows

Superwhisper — это speech2text, он преобразовывает вашу речь в текст. Его очень часто можно было увидеть у разных вайбкодинг-блогеров, которые диктуют свои промпты устно в Cursor и радуются этому.

Долгое время superwhisper был доступен только для MacOS, а для Windows можно оставить заявку на Beta-версию. И вот вчера мою заявку на бету аппрувнули, а сегодня я наконец попробовал superwhisper на Windows)

Что понравилось - В отличие от, например, VS Code Speech, superwhisper позволяет диктовать текст не только в открытые в VS Code файлы, но вообще в любой инпут: на любых сайтах, в любых программах, даже в чате в World of Warcraft работает, я проверил.

- Хорошо распознаёт, когда в речи приходится переключаться с русского языка на английский. Очень полезно для работы в Cursor, когда приходится диктовать фразы типа "Посмотри функцию getProductDataParameters и добавь в неё проверку на errorCode в response". Коллеги из 1С, к вам вопросов нет))

- В платной версии (которая доступна в триале на 15 минут диктования) есть prompt-enhancement, работающий на GPT-4.o и других моделях на выбор. Например, вы надиктовали курсору одно предложение про проверку на errorCode, а GPT-4.o превратит вашу речь в большой и подробный промпт для курсора.

- Может перевести на английский язык то, что вы надиктовали на русском.

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

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

- Если вам кажется, что 20% GPU — это много, то предлагаю вам открыть сайт superwhisper.com и увидеть, как этот сайт моментально забивает все 100% вашего GPU))

Зато можно использовать их сайт как образец того, как не надо верстать — уже можно сразу писать отдельный пост с разбором того, что с этим сайтом не так)

Буду ли я пользоваться superwhisper? Набор текста вручную занимает втрое больше времени, чем произнесение текста вслух, поэтому воспользоваться однозначно стоит. Superwhisper точно ускорит процесс работы в Cursor, и даже видоизменит его. С чатами в онлайн играх, кстати, тоже очень помогает. Да и в тот же самый дискорд своим друзьям можно будет ответить быстрее.

Но вот сам код на нём всё равно не напишешь — тратишь много сил, произносишь "открывающаяся фигурная скобка", а в итоге получаешь саму эту фразу, а не символ "{". А жаль, был бы крутейший инструмент для доступности.

Случайно увидел, что отработал в Сбере уже 10 лет))

Странно, что внутренний портал не предупредил даже)

Как устроен LangChain.js и всегда ли он полезен 🤖

LangChain.js создан, чтобы облегчить работу с языковыми моделями. Но в чём именно его польза? И как не запутаться в слоях его абстракций и обёрток?

Антон Непша, Lead Frontend Developer в Сбере, покажет, как шаг за шагом освоить работу с LLM без преждевременного погружения в сложные термины и документацию.

Разберём, что скрывается под капотом LangChain, на что он действительно способен, а также выясним, когда его использование оправдано, а когда он становится оверхедом.

Приходите 14 июня (сб) послушать доклад Антона 😎

Регистрация открыта! 🚀

И как всегда, задаём вопросы спикеру, читайте наше мини-интервью с Антоном. 🎙

Tbilisi JS Chat | YouTube | LinkedIn | Instagram

Анти-спам для канала, часть 2

Каждый комментарий на моём канале проверяется на спам, об этом у меня недавно выходил пост. Если вкратце — я скармливаю текст комментария в GigaChat вместе с системным промптом, и GigaChat оценивает, является ли комментарий спамом.

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

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

Причём тут GitHub Models Во вчерашнем посте про бесплатный доступ к моделям OpenAI я затронул LangChain, который стандартизирует обращения к API разных моделей. У GigaChat тоже есть своя библиотека для интеграции с LangChain, и мой антиспам бот написан на ней.

Это означает, что при желании мне не составит никакого труда переключить анти-спам на любую другую модель. Например, на бесплатную GPT-4.1, которая хостится на Microsoft Azure.

Что это даёт У Microsoft Azure тоже есть правила фильтрации запросов, но их сообщение об ошибке более информативное.

В случае срабатывания фильтров Azure я получую 400-ую ошибку и объект content_filter_results. В нём будет указано, какие именно фильтры сработали. Кстати, там даже есть фильтр на попытки промпт-инъекций.

Дальше всё просто Если GigaChat откажется проверять комментарий на спам из-за того, что в нём затронуты запретные темы, я просто переотправляю этот же комментарий в GPT-4.1 на Azure. В результате я либо получу результат проверки на спам от GPT-4.1, либо получу инфо о том, почему срабатывают фильтры.

Лимитов на бесплатное использование Azure как раз хватит, чтобы обрабатывать такие редкие кейсы.

P.S. В комментариях к предыдущему посту вы предложили много других сервисов для работы с LLM. Спасибо! Планирую воспользоваться всеми, сделаю сравнение по разным параметрам: фильтрам, лимитам, скорости и т.д.

Используем модели от OpenAI и DeepSeek бесплатно

Способ подсказал мой коллега Андрей Власов, который лидирует и развивает технохаб Сбера в Казани.

На github есть раздел GitHub Models с каталогом разных LLM, включая OpenAI GPT-4.1, DeepSeek-V3-0324 и т.д., всего около 60 разных моделей. Каждую из них можно протестировать в плейграунде, или настроить их для работы в каком-нибудь вашем приложении.

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

И всё. Абсолютно бесплатный девелоперский доступ к моделям. Там есть лимиты, но для небольших приложений и прототипов их должно хватить.

Использование с LangChain LangChain представляет собой абстракцию над разными API разных LLM. Он удобен, если вам нужно быстро переключаться между разными моделями, не переписывая при этом половину приложения.

Правда, из коробки LangChain вызывает отдельные эндпоинты и Auth-токены для каждой модели, а у нас моделей много, а эндпоинт и токен — общие.

К счастью, в LangChain можно перебить дефолтный baseURL при объявлении экземпляра модели. Что касается auth-токена, то у OpenAI он передаётся напрямую в конфиг, а DeepSeek можно хакнуть, переопределив переменную DEEPSEEK_API_KEY:

import { ChatOpenAI } from "@langchain/openai" import { ChatDeepSeek } from "@langchain/deepseek";

const openAiModel = new ChatOpenAI({ model: "openai/gpt-4.1", configuration: { baseURL: "https://models.github.ai/inference", apiKey: process.env.GITHUB_TOKEN } })

process.env.DEEPSEEK_API_KEY = process.env.GITHUB_TOKEN

const deepSeekModel = new ChatDeepSeek({ model: "deepseek/DeepSeek-V3-0324", configuration: { baseURL: "https://models.github.ai/inference" } })

Завтра поделюсь ещё мыслями по поводу использования этого способа. А если у вас есть свои идеи или лайфхаки по использованию LLM — делитесь в комментах или в личку)

Анти-спам для канала

Устал удалять спам-комментарии вручную, пора задуматься над тем, как это автоматизировать.

Решение в лоб Задача кажется простой, ведь в API телеграма есть флаг is_bot, про который написано: True, if user is a bot. Можно было бы просто удалять сообщения на основе этого флага, или даже банить.

Изначально я так и сделал, и чуть не забанил сам себя — оказалось, что если написать комментарий от имени канала, то ты тоже становишься is_bot: true))

Другим решением могло бы быть создание какого-нибудь словаря из стоп-фраз и проверка вхождения подстроки, но я решил сразу перейти к ИИ.

Решение с ИИ Буду использовать GigaChat-2-Pro (потому что от него у меня ещё остались токены).

В GigaChat я отправляю текст поста, текст комментария и инфо об авторе, а он возвращает мне оценку вероятности спама. В процентах.

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

Тестируем Бот будет оценивать каждый комментарий на предмет спама и будет ставить реакции на комментарии в зависимости от его оценки.

Градация следующая: 0% — ❤️‍🔥; 1 - 25% — ❤️; 26 - 50% — 👍; 51 - 75% — 🤔; 75 - 99% — 😡; 100% — 🤬;

В случае ошибок бот будет ставить "🤷🏼‍♂️"

Отредактировано: тестирование закончено, всем большое спасибо))

Кастомный курсор

В последнее время мы всё чаще слышим про Cursor. Это здорово, но мне кажется, нам нельзя забывать об истинном значении слова курсор))

Поэтому вот, делюсь статьёй от Declan Chidlow о том, как сделать на сайте свой кастомный курсор))

Берём div, и обновляем его положение при каждом срабатывании события mousemove, всегда помещая его прямо под положение самого курсора. А настоящий курсор, который системный, скрываем с помощью CSS:

* { cursor: none; }

Дальше можно стилизовать этот div, как хочется, делая из него курсор вашей мечты))

В статье ещё есть примеры разных кастомных курсорв, но самый наглядный среди них — сайт-портфолио Marlène Bruhat, где вместо курсора по сайту двигается большая градиентная область. Даже на тачскрине работает))

А ещё на доке есть крутая статья с демонстрацией разных значений свойства cursor)