Коллеги, сегодня бот прошёл боевое крещение 😅

Случился первый (и очень надеюсь — последний) масштабный сбой: виртуальный сервер (VPS), на котором крутится бот, впал в ступор. Провайдер, увы, оказался ненадёжным. Сервер у них до сих пор полностью не пришёл в себя.

Хорошая новость: работу бота на текущий момент мы восстановили! 🚀

Приносим извинения за доставленные неудобства 🙏
Если у вас из-за недавней нестабильности возникли проблемы — пишите здесь или напрямую боту: он передаст сообщение живым людям в поддержку, разберёмся оперативно. 💬🛠️

Мы уже принимаем меры: уходим от ненадёжного провайдера (SSD Nodes — вдруг кому интересно) и переносим сервис на новую инфраструктуру. Спасибо, что остаётесь с нами! ❤️

И да, если у вас были похожие подставы/траблшоты — делитесь в комментариях. Ваш опыт поможет всем 🙌

Для меня до сих пор удивительно, что мой бот, который ещё не набрал широкой известности, уже оказался под прицелом 🎯
Почему я думаю, что это была именно компания?
А может, это были просто блуждающие боты, которые ищут слабо защищённые ресурсы и пытаются их взломать — так я сначала и подумал. Ну мало ли: вышли в публичное поле, сайт заметили, боты активизировались.
Пока не проанализировал масштаб атаки.
А масштаб впечатляет.
Всё по законам жанра — били сразу по трём направлениям:
огромное количество HTTP-запросов🌐 (до 47 000 в пике),
флуд по логам, из-за которого диск💽 забивался на 100% за несколько минут,
и САМОЕ ГЛАВНОЕ — эти две атаки служили прикрытием попытки взлома: в это же время один IP-адрес активно пытался подобрать логин и пароль для входа по SSH 🕵🏻‍♂️
То есть по тактике, приёмам и масштабу — атака тянет на ЗАКАЗНУЮ!

📊 КТО АТАКОВАЛ:
🇨🇳 Китайский residential botnet (≈80%)
Основные операторы: China Mobile, China Telecom, China Unicom
Географически распределены по всему Китаю (Guangdong, Hebei, Liaoning и др.)
🇻🇳 Координатор из Вьетнама
🇺🇸 VPS для SSH-брутфорса из США (Colorado)

⚙️ ПАРАМЕТРЫ АТАКИ:
Длительность: ~8–12 часов (с пиками)
Инфраструктура: residential botnet + VPS-координаторы
Дополнительно: параллельный SSH-bruteforce

🎭 ПРОФИЛЬ АТАКУЮЩЕГО:
Профессиональная заказная DDoS (DDoS-as-a-Service)
Комбинированная атака: L4 SYN flood + L7 HTTP flood + SSH bruteforce
Использование residential IP (сложнее блокировать)
Полностью автоматизированные инструменты

Всем привет! 👋
Все уже наверное наслышали про новый тренд — создание ИИ-помощников. Топовый представитель этого тренда — Open Claw. 🤖

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

Вот и я дошёл до этой стадии. 🏗️
Создал личного помощника — только не для себя, а для строительного бота. Который сам находит новые стандарты, скачивает, переводит в читаемый формат, анализирует актуальность, индексирует и добавляет в базу знаний! 📚

Результат — база знаний доросла до 1000+ стандартов. 🎉
Из них 500+ скачано помощником с официального сайта стройкомплекс.рф — об этом расскажу подробнее.

Как это работает: ⚙️
Я даю указания прямо в ТГ: скачай, проанализируй, добавь — помощник выполняет. Если что-то не получается — сообщает и объясняет причину. 📲
Но чтобы помощник заработал, сначала нужно вручить ему инструменты. 🛠️

— Для скачивания документов со стройкомплекса разработан отдельный Tool: заходит на сайт, ищет новые доки, скачивает.
— Для перевода сканов в читаемый вид — свой Tool.
— Для каждого шага — свой инструмент.
— И общий Tool, который читает логи и ловит ошибки, чтобы их исправить. 🔍

Пример выполнения задачи

Вот пример дебага, когда помощник словил ошибку и привел причину

Данное сообщение сгенерировано человеком, с незначительным участием трансграничного ИИ.

Примерно вот так выглядело бы сообщение в суверенном ИИ-будущем. 😄

Такие мысли приходят после изучения проекта закона о регулировании ИИ 👆
https://regulation.gov.ru/projects/166424/

Что в законе: 📋
— Вводятся понятия национальной и суверенной моделей
— Упоминается реестр доверенных моделей — для допуска в госсектор и на критическую инфраструктуру
— Требование по маркировке материалов, созданных ИИ 🏷️
— Намёки на международное сотрудничество тонкой нитью вплетены в ограничения для трансграничных моделей 🌐

Текущая версия — рамочная. Чётких определений и технических деталей нет, многое отдано на откуп будущим нормативным актам различных ведомств. Многое ещё может измениться в ту или иную сторону. 🔄

Но направление прослеживается между строк — я бы выделил три главных вектора, на которые нацелен закон:
Независимость. Безопасность. Контроль. 🔐

С n8n всё? 🤔

Так получилось, что по бизнес-задачам мне нужно было поработать в n8n. Это популярное no-code приложение для быстрого создания собственных сервисов и ИИ-агентов. Пик популярности — наверное, года два-три назад.

Для меня это артефакт эпохи. 🏺
n8n успел проскочить в тот короткий промежуток, когда агентное программирование ещё не обрело качество, пригодное для полноценной разработки (как сейчас), но интерес к ИИ-агентам уже был подогрет.

n8n предлагает лёгкий путь: хочешь агента, но не хочешь программировать — вот тебе no-code, набросал схемку из узлов и связей, чат-бот работает! ✅
Сейчас же любой может описать задачу в Claude Code или Copilot — и получит рабочий вариант своего приложения. 💻

Где n8n ещё может пригодиться: 📋
Единственная ниша — обучение, и, возможно, прототипирование (но с большой оговоркой).

Когда погружаешься в основы создания ИИ-агентов без бэкграунда программиста — сложно понять весь механизм, опираясь лишь на техническую документацию.
n8n даёт наглядное графическое представление, привычное для человеческого восприятия 👁️ — быстрее начинаешь понимать базу проектирования ИИ-систем.

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

Про прототипирование — и да, и нет ⚖️

Существует мнение: в n8n можно быстро накидать прототип для тестирования гипотезы, а потом на продакт-фазе выйти на полноценную разработку.

Плюс: время в n8n ≈ времени вайб-кодинга. Но создав прототип — вы понимаете, как он работает внутри. При чистом вайб-кодинге вы создаёте чёрный ящик. 📦

Минус: n8n сильно ограничивает архитектурно. Выполнение операций всегда происходит последовательно в потоке (flow) от узла к узлу. 🔗

Пример из практики: 🛠️
Разработали ИИ-агента в n8n — красивая схема, всё работает идеально. Скармливаете схему нейронке, даёте задание перенести в код, получаете рабочий код, запускаете — всё работает!
Только проект будет перенесён "дословно". Механика n8n прослеживается и в коде — но там уже совершенно другая история, другие законы, другие паттерны проектирования. И подход n8n будет только мешать. 🚧

Что в итоге: 💡
Для быстрого запуска MVP и прототипирования гипотез — n8n всё ещё актуален. Визуально, быстро, понятно.
Но не могу не заметить тенденцию как профильные n8n ТГ-каналы плавно сменили фокус с no-code на вайб-код. 📉
Видимо, окно возможностей для n8n закрывается. 🪟

Как создать корпоративную Вики? 📚

Работаю над задачей объединения всех корпоративных политик в единую базу знаний — чтобы ИИ мог ей пользоваться и консультировать сотрудников на её основе.
Тестирую подход llm-wiki. Его суть в том что вместо RAG поиска через математического высчитывания схожести запроса пользователя с кусочками текста из Базы знаний - мы сохраем базу знаний как это делает Википедия, создавая иерархию и сохраняя связь между статьями. И осмысленно вытаскиваем те статьи, которые нам нужны для ответа на вопрос пользователя.

Что получилось:
Руководители отделов просто закидывают документы, описывающие методики работы, в обычный чат-бот — в свободной форме.
Эти документы прогоняются через ИИ, анализируются и парсятся в структурированные Markdown-файлы.
Условно: из пятистраничного PDF получается 5–10 .md файлов, разложенных по соответствующим папкам. Структура папок полностью отражает иерархию статей — от общего к частному.
Дальше эту структуру подхватывает OtterWiki — open-source фреймворк, магия которого в том, что он нативно работает с Markdown: просто считывает документы из папок и выводит все статьи на wiki-сайт компании.

Как это выглядит для пользователей:

Авторы статей (редакторы):
Закидывают свои методики в PDF, DOCX или ссылкой на Google Doc в специальный чат. ИИ уточняет детали, проверяет материал на конфликтность понятий и противоречия — и публикует в Вики.

Сотрудники:
Открывают сайт Вики и просматривают корпоративные политики вручную — или задают вопрос встроенному ИИ-агенту, который отвечает строго по базе знаний.

ИИ-агент:
Работает напрямую со статьями из Вики — без какой-либо дополнительной обработки и без RAG. Не нужно при каждом добавлении новой статьи прогонять её через векторное хранилище и следить за тем, чтобы данные в тексте и в векторе всегда сходились.

Где-то полтора года назад у меня была задача — подсчитать стоимость конфигурации системы для запуска локальных 70B моделей.
30B–70B — это LLM-модели среднего объёма (есть совсем лёгкие 4B - 7B, и есть тяжеловесы 200B и выше).
Задача была подобрать конфигурацию не просто для тестовой среды, а для реального использования внутри компании — чтобы модели не только запускались физически, но и имели комфортное время ответа.
На тот момент было только две опции:
Выстраивать ферму из игровых видеокарт
Использовать профессиональные карты типа A100 и H100
И всё это стоило космических денег.

Сейчас появилась третья опция — и не такая дорогая.

NVIDIA DGX Spark
Nvidia выпустила мини-суперкомпьютер для ИИ-вычислений, и сейчас это оптимальное решение для компаний, которые планируют постоянно работать с локальными моделями.

Spark включает 128 ГБ графической памяти — это как:
4× RTX 5090 или 8× RTX 5080 → $18 000–20 000
A100 с 80 ГБ видеопамяти → $15 000–20 000
Согласитесь, цифры внушительные. 😅

Spark же стоит около $5000, в России выйдет дороже, около 700 000 руб.

Это не реклама 🙂 — я лишь хочу сделать акцент на том, что рынок железа отзывается на реальную потребность: иметь свои локальные корпоративные модели для применения ИИ внутри компании.
И в подтверждение этой версии - AMD анонсировала свою альтернативу Спарку: AMD Ryzen AI Halo, так же со 128 ГБ памяти.

Такие мини супер компьютеры для ИИ способны запускать тяжеловесов до 200 миллиардов параметров локально!

Делитесь в комментариях, на каком железе экспериментируете Вы!

Всем привет!

Наконец-то добрался написать лонгрид по своей любимой теме - RAG.
Тема, с которой я работаю каждый день, и которая, кажется, только с виду простая 🙂

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

Напомню, что суть RAG одним предложением - передать ИИ-модели наиболее подходящий под вопрос материал.

Для наших стандартов это значит: выбрать нужный документ, нужный раздел и нужные страницы, на которых находится описание интересующего нас вопроса.
Но как измерить, насколько вопрос, который мы задаём, близок к тому тексту, который мы выбрали из множества документов?
Что для вопроса про канализационные трубы, СП по ВК должен набрать больше очков схожести, чем СП по стальным конструкциям?
Мы с вами понимаем - но как это выразить что бы поняла машина?

И тут есть два пути:
1. Математический - уже давно проторенный путь через эмбеддинги, векторные хранилища и т.п.
2. Вики-подход, который систематизировал и описал Карпатый (хотя применялся и раньше). Суть в том, что вместо математического вычисления схожести мы отдаём это на откуп ИИ-модели - она сама выбирает нужные куски текста по кратким содержаниям и заголовкам.

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

Расскажу подробнее, с какими нетривиальными кейсами я столкнулся в своей работе 👇

Кейс 1. Поиск по нескольким критериям
Самое простое - взять запрос от пользователя и найти похожий по смыслу текст напрямую. Но что если усложнить задачу? Например, нужно найти текст по двум-трём критериям одновременно: по смыслу и по эмоциональному оттенку.
Найди самый тёплый комментарий про нашу косметику.
Найди самое эмоциональное интервью с клиентом, в котором упоминается связь с домом.

Я использовал такой подход: сначала вычислял схожесть у N кусков текста и отбирал, например, 20 комментариев про косметику.
Следующим шагом - реранкинг: сортировал выбранные 20 уже по второму критерию - эмоциональности.
Эмоциональность каждого комментария измерялась отдельно, всё тем же ИИ, и хранилась в векторной базе как свойство комментария по 10-балльной шкале.
Таким образом я сначала ловил близкие по смыслу комментарии, а потом сортировал их по нужному критерию.

Кейс 2. Поиск по библиотеке фотографий 📸
Усложним ещё. Представьте: библиотека из ~20 тысяч фото, нужно выбрать несколько по запросу пользователя. Запросы могут быть разных типов:
С фокусом на главном объекте: «найди мужчину средних лет, брюки, добродушная улыбка»
С фокусом на окружении: «найди человека на фоне гор на закате»
Поиск по тегам: «найди мужчину в костюме с бокалом вина в руке» - здесь нужно выполнить несколько измерений по разным смыслам одновременно.

Получается, для каждого изображения нужно хранить несколько описаний: описание сцены/окружения, описание главного объекта, теги, и дополнительные поля - эмоции, оценка качества, освещение, тип кадра (портрет/сцена/динамика) и т.п.
Решение - измерять схожесть по каждому критерию отдельно и сводить всё в формулу с весами, которые меняются в зависимости от типа запроса:
Фокус на главном объекте: Схожесть = 0.5 × Гл. объект + 0.3 × Окружение + 0.2 × Теги
Фокус на окружении: Схожесть = 0.3 × Гл. объект + 0.5 × Окружение + 0.2 × Теги
Тип запроса определяет ИИ - и динамически перераспределяет веса.
Как видите, простая на первый взгляд задача по сравнению двух фраз может превратиться в нетривиальную - с дополнительной сортировкой или нахождением сразу нескольких векторов вместо одного.

Надеюсь, описанные методики помогут вам в понимании механики работы RAG - и, возможно, вы даже что-то примените в своих разработках!

Каково это - стартапить в России 🇷🇺

Не буду касаться экономических моментов - тут, думаю, и так всё понятно. Поделюсь чисто техническими.

Самое сложное на старте - при нынешнем уровне развития ИИ даже не создание продукта, а его продвижение.

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

Потом пошли рандомные блокировки - и сайт попал под раздачу, снова удар по посещаемости.
Потом закон о запрете регистрации через иностранные сервисы - Google-авторизацию пришлось сменить на ВК. Снова потеря прогретой аудитории.

Вот и думаешь: стоит ли вообще вписываться в новый проект, понимая, что решения наверху принимаются без какого либо понимания влияния на бизнес - и что условия для нормальной работы, скорее всего, будут только усложняться 🤷
(вспомните идеи про суверенный ИИ)

Снова про RAG - на этот раз интересный кейс про фактчекинг по религиозной литературе.

Задача: пользователь даёт фразу и просит проверить - есть ли такое утверждение в Библии.
Первый очевидный путь - индексировать священное писание, разбить на чанки, посчитать векторы, и по классике: считаем вектор фразы пользователя, ищем схожее в тексте.
Опробовал - работает, но с нюансом. Вот пример: «перекуют мечи на орала» и «перекуют орала на мечи» почти неразличимы в embedding-пространстве. Чисто математически мы не поймаем ошибку - скор будет высокий, а смысл противоположный. Придется добавлять отдельного агента-чекера на выходе, который уже своим умом сравнивает фразы. Работает, но громоздко.

Второй путь оказался проще.
Все тексты священного писания есть в открытом доступе. Завёл агента с подключённым веб-поиском, указал белый список доверенных сайтов - и всё. Фактчекинг настроен, по тестам ловит ошибки точнее, и в реализации значительно дешевле.
Ещё наблюдение: сравнивал Sonar от Perplexity и GPT (4.1 и 5.4). Хотя Perplexity считается эталоном веб-поиска, в задаче проверки фактов строго на ограниченном наборе сайтов - GPT справляется лучше.

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