Vbolgar_IT
Болгар Виталий Юрьевич
На платформе с 20.04.26
Основатель srezAI.ru
Российский поисковый MCP\API для ИИ-агентов.
"Безопасный и чистый результат, без рекламы, навигации и лишнего шума"
Нужны те, кто:
• пользуются платными AI-сервисами: Tavily, Exa, Brave, Firecrawl, perplexity
• Или знаете эти сервисы, хотели использовать, но не начали
И пользуетесь любым ИИ на платном тарифе.
От вас: 30–40 минут ответов на вопросы.
От нас с командой: 30–40 минут консультации по IT, маркетингу, запускам, продукту, бренду, соцсетям.
Как и говорил, ноль продаж, 100% польза (опыт у нас от 10 до 20 лет в своих нишах).
Вместе с командой ИИ-интузиастов, я принимаю участие в отборе на самую престижную конференцию AAMAS 2027
Это 26-я International Conference on Autonomous Agents and Multiagent Systems. То есть это главная и самая престижная в мире площадка по автономным агентам и мультиагентным системам (уровень A* / CORE A*).
3–7 мая 2027, Ханой, Вьетнам
Конечно, это подразумевает научную статью в формате лютого исследования проблем текущей ИИ-архитектуры и предложения по исправлению недостатков
В основном, всё это касается режимов deep-research и должно быть доказано на практическом опыте (короче замес с кучей непонятных терминов и слов
😐 Я, как менеджер, при первой же встрече с командой, сразу решил что нужно сделать всё как учили!
Собраться, накидать план, устроить брейншторм и тд и тп... Иии...Поехали
НО! Как оказалось... так уже никто не работает.
Как это выглядит теперь
Представьте себе. Четыре человека, сидят в комнате за столом с ноутбуками и тупо молчат. Никто вообще не пытается сказать ничего по делу. Потому что все ничего не понимают. Вообще ничего
(при чем ребята не первый год посвятили свою жизнь этому делу
Потому что всё делают ИИ-агенты.
Выглядит это так
1) организовывается приватный репозиторий на github (или аналоги
2) приглашаются участники и дается доступ агенту к файла
3) никто даже не пытается глазками почитать всё что написано в документации этого репозитория
4) все просто пинают своих агентов - а те лазают в интеренете, собирают инфу и пишут то что думают.
Твоя задача - лишь выбрать какие кнопочки нажимать Да или Нет. Точка
Обсуждать что-то - просто стало бессмысленно!
Ибо даже сам "Оператор ИИ" - не понимает что там написано. И приходится применять волшебную часть промпта "Объясни мне как ребенку что тут написано.."
У каждого члена команды есть свой ИИ-агент, они разные: (Antigravity, Claude, Codex и др.
И если один скажет "брат! Я сделал идеальный план! Эта статья разорвет Ревьюера..." - то другой скажет "Это полное дерьмо, никому это не показывай. Давай лучше сделаем вот так...
Помимо того, что агенты общаются только через репозиторий и у них нет никакого понимания о текущем состоянии проекта (ибо в этот самый момент - могут вноситься важные правки и все вместе просто тупо сжигают токены не по делу) - так еще и галюцинации каждого провайдера (а они наслаиваются друг на друга и погоняют друг другом...) короче беда
Но самое страшное -
из сотни команд на AAMAS - будут использовать в 2026 году ИИ - 💯% команд.
То есть, нейрослоп пойдет в научные массы, статьи и конечно же сами Ревьюеры будут использовать своих ИИ-агентов чтобы проверить то что намолотили другие ИИ-агенты участников... И конечно им тоже будет ничего вообще не понятно.
Так как эти сотни команд будут писать на своем "языке" с горой дерьма и слопа.
То есть чтобы проверить каждый параграф из сотни страниц доклада - нужно чтобы их Агенты объясняли подробно как детям.
Короче замес ребята.
В этом году - это будет впервые за всю историю
Вот и всё изменилось..
А зачем тогда нужен тут человек то вообще? Нажимать кнопочки Да или Нет?
Они же сами могут обо всём договориться
Компании внедряют ИИ, чтобы ускорить поддержку, аналитику, подготовку документов и работу с клиентами.
Ожидание простое: задал вопрос, получил готовый ответ.
На практике всплывают три боли, которые стоят денег и доверия:
Боль 1. Модель уверенно отвечает устаревшими данными
Языковая модель знает мир на дату, когда её обучили. Она не в курсе вчерашнего изменения тарифов, свежего закона, актуального курса или того, что конкурент поднял цену.
При этом отвечает так же уверенно, как на любой другой вопрос. Бизнес получает красивый текст с фактами двухлетней давности и принимает по нему решение.
Ещё хуже, когда модель просто выдумывает: ссылку, цифру, название документа. Проверить это на глаз сложно, потому что звучит правдоподобно.
Ответ: дать агенту доступ к живому вебу и отдельный шаг проверки. срезAI ищет по актуальным источникам, а проверка утверждения возвращает вердикт с дословными цитатами из нескольких независимых страниц. Факт либо подтверждён ссылкой, либо помечен как непроверенный. Решение принимается не на догадке модели.
Боль 2. Агент не видит половину нужных страниц
Большинство современных сайтов собирают контент через JavaScript прямо в браузере. Если агент забирает страницу простым запросом, он получает пустую заготовку без цен, таблиц и карточек товаров. Команда думает, что данные собраны, а половина ответа пустая.
срезAI открывает страницу полноценным браузером: JavaScript выполняется на нашей стороне, и агент получает то же, что видит человек, только в чистом Markdown без меню и рекламы. Отдельный инструмент вытаскивает нужные поля сразу в готовый JSON по вашей схеме: цена, характеристики, контакты, а не весь текст страницы.
Боль 3. Собственный парсинг: отдельный проект, а не строчка кода
«Мы сами всё соберём» звучит дёшево ровно до первого месяца. Дальше это команда, серверы и постоянные починки: сайт поменял вёрстку, и сбор встал. Люди, которые должны развивать продукт, чинят чужую разметку.
срезAI снимает этот слой. Вы обращаетесь к готовой инфраструктуре через MCP или REST, а поиск, рендер и извлечение работают как один сервис. Цена прозрачная: 1 кредит равен 0,10 ₽, и вы платите за вызов, а не за размер выдачи. Один поисковый запрос стоит одинаково, вернул он 5 результатов или 30.
Что это даёт в деньгах
меньше ошибок от устаревших и выдуманных фактов: ответ опирается на свежие источники с проверкой;
полный охват данных, включая динамические страницы, которые обычный запрос не видит;
нет расходов на собственный парсинг-контур и его поддержку.
При этом ответственность за то, что именно уходит в запрос, остаётся на стороне заказчика. Инфраструктура даёт данные, а бизнес решает, какие поля отправлять и зачем. Про работу с персональными данными это отдельная тема, мы разбирали её в прошлом материале.
А где ваш ИИ-ассистент чаще подводит: отвечает устаревшим, не добирается до нужных страниц или слишком дорого стоит в поддержке?
Компании запускают ИИ-ассистентов для поддержки, поиска по документам и разбора заявок.
Обычно это простой пилот: подняли модель, подключили базу знаний, дали попробовать.
Проблемы начинаются позже...
В промпт попадает имя клиента, почта, текст обращения, номер договора. Запрос уходит в лог, ответ в историю чата, копия в векторную базу.
Через пару месяцев никто не может сказать, где лежат эти данные и кто к ним имеет доступ. На этом месте эксперимент превращается в обработку персональных данных.
"Модель стоит внутри, значит рисков нет"
Это не так! Локальное размещение убирает часть рисков передачи данных наружу, но требования 152-ФЗ остаются.
Компания всё равно должна понимать, какие данные обрабатывает, зачем, где хранит, кто получает доступ и когда удаляет.
К тому же локальная модель пишет логи, хранит историю диалогов, шлёт телеметрию, использует внешние эмбеддинги или сторонний поиск.
На схеме "всё внутри", а один компонент отправляет текст наружу.
Внешняя LLM не запрещена, но тогда проверяют условия обработки, место хранения, сроки удаления, использование данных для обучения и субподрядчиков.
Фразы "мы не обучаемся на ваших данных" в рекламе мало, это должно быть в договоре.
Что закон считает персональными данными
Любая информация, по которой прямо или косвенно можно определить человека. В ИИ-проектах это ФИО, телефон, почта, номер договора и заявки, текст переписки с клиентом, резюме, кадровые, медицинские и финансовые сведения, а также комбинации полей и логов, по которым человека можно восстановить.
Разработчик видит "просто JSON". Для закона формат не важен.
Пять вопросов до запуска агента
1) Какие данные попадут в промпт. Что сотрудник вставит в чат в понедельник утром: письмо клиента, карточку из CRM, договор? Часто ФИО и телефон модели не нужны, нужен сам текст проблемы.
2) Кто и на каком основании обрабатывает. Проверьте в договоре с поставщиком: перечень данных, запрет использовать их самостоятельно, срок хранения промптов, удаление, субподрядчиков.
3) Где данные на каждом шаге. Не только модель: интерфейс, API-шлюз, журнал запросов, хранилище документов, векторная база, мониторинг, резервные копии, внешние интеграции. Передача за пределы РФ рассматривается отдельно.
4) Что попадает в логи. Частый провал: сохранение промптов отключили, потом включили подробный лог для отладки, и через неделю там вся переписка с клиентами. Решите заранее, что сохраняется, кто видит, сколько хранится, маскируются ли контакты.
5) Как реализовать права человека. Если нельзя удалить запись разом из базы, кэша, истории диалога, векторного индекса и бэкапа, значит жизненный цикл данных не описан.
Что советую сделать на этой неделе
- Выпишите все ИИ-сценарии и поля данных в запросах.
- Нарисуйте маршрут от интерфейса до модели и логов.
- Уберите из промптов лишнее.
- Отключите сохранение запросов, где оно не нужно.
- Проверьте договоры поставщиков.
- Тестируйте на синтетических данных: если агента нельзя проверить без реальных, сценарий недостаточно обезличен.
Отдельный риск: веб-поиск
Если сотрудник отправляет в поиск фразу из обращения клиента, наружу уходит больше, чем планировалось.
Безопаснее по шагам:
убрать идентификаторы, сформировать нейтральный запрос, получить источники, а потом использовать их в работе.
Поисковый слой должен получать минимум данных.
Мы строим срезAI как инфраструктуру веб-поиска для ИИ-агентов. Но никакой API сам по себе не делает процесс соответствующим 152-ФЗ: ответственность начинается с архитектуры заказчика.
Поэтому в рабочих сценариях мы рекомендуем не передавать в поиск ФИО, контакты и исходные тексты обращений.
Если у вас уже есть ИИ-агент или локальная LLM, начните с трёх вопросов:
1) какие ПДн попадают в промпты сейчас?
2) где хранятся запросы и ответы?
3) кто подтвердит, что поставщик не использует их иначе?
Если нет точного ответа хотя бы на один, это повод для инвентаризации.
А что у вас было самым сложным при запуске ИИ: выбор модели, защита промптов, логи или согласование с юристами?
Наверняка вы слышали про n8n и многие блогеры уже чуть-ли не открестились от него в пользу вайпкодинга. Якобы эволюция никого не щадит и даже n8n уже ушел на покой.
Но на самом деле всё не так.
Я называю ClaudeCode - "идеальным сотрудником", а n8n - "BPMN на стеройдах" и вот почему:
Если вы когда либо планировали бизнес-процессы или блок-схемы (диаграммы) - то заметили, что всё сводится к одному - обеспечить визуально понятное и последовательное выполнение рутинных операций шаг за шагом. Надежно, эффективно и предсказуемо. С жесткими рамками, условиями и правилами. Только так. На кону бизнес-стратегия и соответствующие издержки.
Однако всё изменилось, когда на смену ИИ - пришли ИИ-агенты. Которые можно встроить в процессы и получить еще более умную систему и гибкие настройки ожидаемого результата от процессов.
Это идеально встраивается в контекст бизнеса, когда требуется обработать входящую почту, поискать по запросу в интернете или, например, организовать встречу в календаре. То есть у ИИ появились ручки и ножки чтобы куда-то сбегать или что-то сделать вместо человека.
Важно что все эти процедуры жестко зарегламентированы и агенты выполняют только определенный набор задач, и всё зависит от того какими инструментами ты его обогатил.
С агентами типа ClaudeCode, Codex, Hermes и др. - всё не так. Верней философия та-же, но это скорее замена команды разработчиков или сотрудников, нежели автоматизация бизнеса.
В отличии от n8n - вы видите только чат и код (который для вас, скорее похож на древние иероглифы или заклинания предков, чем на что-то осмысленное)
В то время как в n8n - вы видите все процессы аж в четырех представлениях (schema, table, JSON, binary) + формат диагарам никогда не превратит проект в легаси-код. Вы всегда можете прочитать содержимое воркфлоу и понять что за что отвечает.
Но люди - ленивые существа и с появлением таких технологий - забивают на образование и усердие. Таким образом получается что стараются внедрить агентов туда - куда не стоит и грузят их тем - чем не нужно. А потом жалуются что ИИ - "тупой" и вообще, что всё это "чушь".
Поверьте я встречал таких!
И могу сказать - что лучше поймите основы n8n!
Это реально крутая штука! И на самом деле - всё просто!
А вы используете ИИ-агентов на работе или в бизнесе?
#ai #экономия #точныйрасчет #деньги
Вчера мы реализовали и выкатили новый инструмент verify_claim для нашего сервиса https://srezai.ru/ , который дает возможность моделям с маленьким контекстом 32\64\128k токенов экономить контекстное окно и полагаться на веса более старшей модели.
Как выглядит проблема без verify_claim. Маленькая модель отвечает на вопрос из своих весов. Она не различает "я это знаю" и "мне это кажется" - на выходе в обоих случаях уверенный текст.
Даже если дать ей веб-поиск, она прочитает одну страницу, и та станет для неё истиной: одна страница не даёт возможности заметить, что вторая говорит обратное.
Плюс арифметика контекста: чтобы сверить факт по-настоящему, нужно прочитать 3-5 страниц по 4-6 тысяч символов, это 20-30k символов сырья. У модели с окном 32k после этого не остаётся места на собственную задачу.
Что делает verify_claim. Вся черновая работа идёт на нашей стороне: поиск, выбор источников по одному с домена, параллельное чтение, прогон через модель. Наружу уходит короткий вердикт - то есть сотни токенов вместо десятков тысяч.
Модель, которую просят подтвердить утверждение цитатой, охотно цитату придумывает, и получается худший возможный исход: выдуманный факт с выдуманным пруфом, выглядящий проверенным.
А так же приводит вердикт в соответствие с тем, что реально подтвердилось. Если часть источников за, часть против — вердикт становится mixed, потому что расхождение важнее той стороны, которую выбрала модель.
Ну и наконец - считаются независимые домены, а не цитаты. Три статьи с одного сайта не добавляют независимости, поэтому verify_claim берёт по одной ссылке с домена. "Три источника согласны" стоит чего-то только когда это три разных сайта.
Зачем это вашему агенту? Он получает не "правда/ложь", а картину целиком: сколько доменов за и сколько против, дословные цитаты со ссылками и чего проверка не покрыла.
Модуль намеренно не выносит истину — решение остаётся за агентом и его пользователем.
Практический эффект: маленькая модель перестаёт быть обязана угадывать.
Вместо "отвечу уверенно, потому что другого режима у меня нет" у неё появляется третий вариант - сказать, что проверить не удалось, и показать, что именно говорят источники.
