Как маленькая фирма заплатила $2000 за пароль «12345678»

История о том, почему кибербезопасность — это не только для больших корпораций

Есть такой распространённый миф среди владельцев небольших бизнесов: «Мы маленькие, кому мы вообще нужны? Хакеры идут за Газпромом и Сбербанком, а не за нашей бухгалтерией». Я понимаю эту логику. Она кажется разумной. Она даже звучит убедительно на планёрках. Только вот она в корне неверна — и я расскажу вам конкретную историю, после которой этот миф, надеюсь, умрёт навсегда.

Обычное утро, которое пошло не так

Представьте: маленькая компания, шесть человек, региональный городок. Торговля, склад, бухгалтерия — всё как у людей. Работают себе, никого не трогают. Есть сервер с 1С, есть удалённый программист, который этот сервер обслуживает. Классическая схема для малого бизнеса.

И вот однажды утром сотрудники приходят на работу, запускают 1С — и ничего. Программа не открывается. Заходят на сервер, смотрят на папку с базой данных — а там какая-то хрень непонятная. Файлы есть, но расширения чужие, незнакомые. И рядом лежит текстовый файл.

Открывают его — а там, значит, всё вежливо написано: ваши данные зашифрованы, для восстановления свяжитесь с нами вот по этому Telegram-аккаунту. Приятного аппетита.

Это был классический ransomware — программа-вымогатель. Вся база 1С, со всей историей заказов, клиентами, остатками на складе, взаиморасчётами — всё превратилось в набор нечитаемого мусора.

Бэкапов не было. Вообще. Ни одного.

Три дня переговоров

Директор — человек закалённый, не из робкого десятка — три дня вёл переговоры с мошенниками через Telegram. Торговался. Объяснял, что компания маленькая, что денег нет, что он вообще готов судиться. Те, в свою очередь, демонстрировали профессиональный подход: скидок не давали, на жалость не велись, но и цену особо не задирали. Бизнес, что поделать.

В итоге сошлись на двух тысячах долларов в биткоинах. Деньги перевели, ключ получили, базу расшифровали. Всё заработало.

Казалось бы — хеппи-энд? Ну, такой себе хеппи-энд, если честно.

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

Как это вообще произошло

Меня пригласили разобраться, что случилось. И знаете, это оказалось до обидного просто.

Удалённый программист 1С — нормальный, в общем-то, специалист по своей части — для удобства работы открыл наружу порт RDP. RDP — это Remote Desktop Protocol, то есть удалённый рабочий стол Windows. Штука удобная: подключаешься из дома, работаешь с сервером как будто сидишь рядом.

Только вот он этот порт повесил прямо в интернет. Без VPN, без дополнительной защиты, без ничего. И поставил пароль.

Пароль был что-то типа 12345678.

Вот и весь взлом. Никакой супер-хакерской атаки, никаких zero-day уязвимостей, никакой социальной инженерии. Просто боты в интернете постоянно сканируют все IP-адреса подряд, ищут открытые RDP-порты, и методично перебирают простые пароли. Это называется brute force, и это полностью автоматизировано. Никакой человек даже не смотрел на эту компанию специально — просто алгоритм нашёл открытую дверь с кодовым замком «1234» и зашёл.

Поздравляю, вы взломаны.

Что пришлось делать после

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

Корпоративный VPN. Никакого RDP наружу. Хочешь подключиться к серверу — сначала подключись к VPN, и только потом иди куда надо. Это как охранник на входе: пропускает только своих.
Файрволл с внятными правилами. Закрыть всё, что не нужно. Разрешить только то, что реально используется. Это звучит банально, но у большинства маленьких компаний файрволл либо отсутствует, либо настроен по принципу «разрешить всё входящее».
Резервное копирование. Нормальное, регулярное, с проверкой, что бэкап вообще работает. Бэкап, который никто никогда не проверял — это не бэкап, это иллюзия безопасности. Правило 3-2-1: три копии данных, на двух разных носителях, одна из которых хранится отдельно.
Обучение сотрудников. Люди кликают по фишинговым письмам, используют пароль «qwerty» на всём подряд, подключают чужие флешки. Не потому что они плохие — просто их никто никогда не учил, что это опасно.

Почему малый бизнес особенно уязвим

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

У крупных корпораций есть выделенные специалисты по безопасности, корпоративные политики, сложная инфраструктура с несколькими уровнями защиты. Их сложно взломать. А малый бизнес — это открытый порт RDP с паролем «12345678». Это рай для автоматических атак.

Современный киберкриминал — это давно не романтичные хакеры в худи, которые целенаправленно охотятся за конкретной компанией. Это организованный бизнес с разделением труда: одни пишут зловредов, другие их распространяют, третьи ведут переговоры с жертвами, четвёртые отмывают биткоины. Им абсолютно всё равно, большая вы корпорация или ИП с шестью сотрудниками. Боты работают 24/7, сканируют весь интернет, и если у вас открытая дверь — они войдут.

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

Что сделать прямо сейчас

Если вы читаете это и понимаете, что у вас «тоже примерно так» — вот короткий чеклист на сегодня:

Закройте RDP наружу. Если удалённый доступ нужен — используйте VPN.
Проверьте все пароли на серверах — если там что-то короче 12 символов без спецсимволов, меняйте немедленно.
Настройте резервное копирование с автоматической проверкой.
Убедитесь, что на всех компьютерах установлены актуальные обновления — особенно на серверах.
Поговорите с сотрудниками о фишинговых письмах.

Это не rocket science. Это базовая гигиена, которая закрывает 80% реальных угроз для малого бизнеса.

Вместо заключения

Два часа работы нормального специалиста по безопасности — и этой истории с $2000 в биткоинах, тремя днями нервотрёпки и реальным риском потерять всю историю компании просто не было бы.

Информационная безопасность — это не про паранойю и не про бюджеты уровня «Роснефти». Это про элементарную ответственность перед своим бизнесом. Если вы застраховали машину и офис — застрахуйте и данные. Потому что данные сегодня стоят дороже любого имущества.

Современный киберкриминал не разбирает, большой вы или маленький, столичный или провинциальный. Ему важно одно: есть ли у вас открытая дверь. Не давайте ему этого шанса.

Берегите свои данные. И ставьте нормальные пароли, чёрт возьми.

«Прикрутите ИИ за 3 тысячи» как инфорынок сломал реальность

«Ну вы там просто прикрутите ИИ»

Последнее время я всё чаще замечаю: люди стали заметно переоценивать возможности искусственного интеллекта и в быту, и в бизнесе.

Иногда прилетают заказы из разряда «ну вы там просто прикрутите ИИ» вроде бота, который сканирует и собирает статистику со 100 аккаунтов в 10 соцсетях, или «ИИ-парсера» для WB на миллион товаров с обновлением каждые 10 минут. И всё это за совсем символические деньги, в диапазоне 3 — 5 тысяч рублей.

И самое забавное (и чуть грустное) таких запросов становится больше. Рынок фриланса, честно говоря, и раньше не славился системностью и трезвой оценкой сложности, но сейчас это прямо заметно.

Кажется, многие поверили, что если добавить к проекту приставку «ИИ», то приложение будь то, бот или парсер автоматически превращается в волшебную палочку. Хотя по факту это всё тот же бот и тот же парсер: ему всё равно нужен алгоритм, логика, обработка ошибок, лимиты, прокси, капчи, авторизация, хранение данных и куча рутины.

Всё чаще встречаются запросы из серии: «сделайте нам свой ИИ, чтобы он сам составлял сметы и генерировал документы по нашим данным». Причём обычно это подаётся так, будто речь про “прикрутить кнопку”, а не про полноценную систему с данными, правилами, безопасностью, проверками и ответственностью за ошибки.

Отдельный жанр техническое задание, нагенерированное ChatGPT. Огромная простыня текста на несколько экранов, где половина слов звучит солидно, но заказчик сам не до конца понимает, что они означают и зачем там вообще написаны. В ТЗ встречаются “агенты”, “векторные базы”, “самообучение”, “интеграция со всем”, “автономное принятие решений” а на вопрос “что именно должно получиться в итоге и как вы это будете проверять?” начинается пауза.

Перегретый инфорынок и иллюзия “нажми кнопку”

Виноват во многом перегретый инфорынок. Вокруг ИИ сейчас столько шума, что создаётся ощущение: он уже умеет вообще всё просто “нажми кнопку”. Эту картинку особенно активно продают инфоцыгане: короткие ролики, громкие заголовки и обещания в стиле «запусти ИИ-бота и забудь про работу».

Чего только стоит история с ClawBot на таких кейсах отлично видно, как легко хайп превращает технику и софт в “волшебную инвестицию”, а ожидания улетают в космос.

И на этом “ИИ-пафосе” появилась отдельная прослойка «интересных разработчиков» — новички после экспресс-курсов (я таких реально встречал). Часто это люди с почти нулевыми хардами, но отлично прокачанными софтами: уверенная речь, презентации, “упаковка”, обещания и тон “мы сейчас всё запилим”. И они искренне (или очень убедительно) продают реализацию проектов, которые либо технически не взлетят, либо взлетят, но совсем за другие сроки и бюджеты.

Быстрее — да. Само — нет

Да, с ИИ писать и продумывать стало быстрее и проще. Но «быстрее» не значит «само». Основная работа всё равно остаётся на разработчике.

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

Но вот идея, что ИИ “сам пойдёт” и соберёт всё из десяти площадок — это не магия. Это обычная инженерия: авторизации, лимиты, блокировки, прокси, капчи, хранение, очереди, мониторинг. И всё это делает не «умный бот», а нормальная система, которой руководит специалист.

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

Получается смешная (и опасная) ситуация: люди хотят не реализовать проект, а ощущение, что “если написать умными словами, оно само заведётся”. Хотя на практике всё наоборот: чем больше пафоса в описании, тем важнее приземлить задачу на конкретные данные, чёткие требования, понятные критерии качества и реальные ограничения. И отдельная иллюзия — что если в проекте есть «ИИ», значит он должен стоить копейки. Будто нейросеть — это бесплатная магия, которую “просто прикрутили”, и всё заработало за вечер. Но ИИ не отменяет разработку, он добавляет к ней новые слои: данные, интеграции, инфраструктуру, безопасность, тестирование, мониторинг и ответственность за ошибки.

ИИ может помочь ускорить подготовку документов, подсказать формулировки, разложить данные по полям, но “сделайте нам своего ИИ, чтобы он сам всё делал” — это обычно про дорогую, сложную, долгую разработку. И чем “умнее” обещания, тем дороже в реальности обходится их выполнение: нужно собирать и чистить данные, настраивать доступы, учитывать лимиты и сбои, строить проверяемые сценарии и систему контроля качества. Такой проект нельзя закрыть бюджетом “в пределах пары походов в магазин” только потому, что в описании где-то написано слово «ИИ».

Лобстер, токены и иллюзии: почему ИИ-хайп перегрет

ИИ-рынок перегрет: почему хайп вокруг «умных агентов» опережает реальность

За последние пару лет искусственный интеллект превратился из любопытной технологии в массовый культ. Кажется, что ИИ «уже всё умеет»: пишет тексты лучше людей, программирует, управляет бизнесом, заменяет ассистентов и вот-вот начнёт жить вместо нас. На этом фоне появляются проекты вроде OpenClaw — домашнего ИИ-помощника, который якобы не просто болтает в чате, а «делает дела»: пишет сообщения, лазит по интернету, запускает команды, работает с файлами и сервисами.

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

Почему людям кажется, что ИИ уже стал «личностью»

Большие языковые модели умеют убедительно разговаривать. Они отвечают уверенно, пишут гладко, поддерживают стиль, шутят и даже «сочувствуют». Мозг автоматически приписывает этому разум и самостоятельность. Отсюда рождается опасная иллюзия: если модель умеет красиво объяснять, значит она умеет и думать, и планировать, и отвечать за результат.

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

OpenClaw как иллюстрация: «он действует», но не сам

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

Но если посмотреть внимательно на реальные истории использования, выясняется важная вещь: почти всё работает только при условии, что человек постоянно подсказывает. Когда говорят «агент купил автомобиль», за кадром часто остаётся главное: владелец пошагово указывает, где искать цены, какие сайты использовать, что именно писать дилеру и на что не соглашаться. ИИ в таких сценариях — это не самостоятельный переговорщик, а скорее умный автомат для переписки и поиска, который ускоряет рутину. Это полезно, но это не «замена человека».

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

Экономика хайпа: почему «магия» часто оказывается дорогой

Ещё одна причина перегрева — люди не считают стоимость «волшебства». Сам OpenClaw может быть бесплатным, но работа агента почти всегда требует облачной модели. А каждая операция — это токены. Чем больше контекста, памяти, «дневников», проверок и служебных запросов — тем выше расход. В итоге демонстрация «ИИ-ассистента на каждый день» превращается в подписку, которая может стоить как хороший сервисный пакет: десятки или сотни долларов в месяц.

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

Главный слон в комнате: безопасность и доверие

Когда ИИ получает право запускать команды, читать файлы и писать от вашего имени, цена ошибки становится очень высокой. И тут хайп особенно опасен: люди ставят модный инструмент «как есть», не думая о сетевой безопасности, прокси, токенах доступа, правах и изоляции. В результате возникают типичные истории: открытые панели управления, утечки ключей API, доступ к аккаунтам мессенджеров и сервисов.

Есть и более тонкая угроза: prompt injection — когда злоумышленник пытается «внушить» агенту выполнить действие через текст. И если модель посчитает это логичным в рамках контекста, она может сделать то, чего вы не хотели. Это не фантастика и не «страшилки», а реальный класс проблем, который признают даже разработчики подобных систем.

Плюс фундаментальный вопрос: даже если агент живёт у вас дома, мозг у него чаще всего в облаке. Значит, ваши запросы, контекст и иногда чувствительная информация уходят внешнему провайдеру. Для многих это может быть приемлемо. Но это точно не то, о чём говорят в рекламных роликах, где «домашний ИИ» выглядит как полностью локальное и безопасное решение.

Почему люди разочаровываются после покупки «будущего»

Самый честный сценарий часто звучит так: человек с энтузиазмом ставит агента, даёт разрешения, тратит выходные на настройку — а потом понимает, что автоматизировать особо нечего. Большая часть бытовых задач уже решается привычными сервисами. А те задачи, которые действительно важны, почти всегда требуют контроля, уточнений и ответственности. В итоге получается пара эффектных, но редких сценариев (плейлист, новости, простые напоминания) и чувство, что ожидания были выше пользы.

Это не значит, что ИИ бесполезен. Это значит, что массовая аудитория ждёт «магии без усилий», а получает «инструмент для технарей». И вот тут рынок перегревается: маркетинг продаёт мечту всем, хотя реально она подходит меньшинству.

Так ИИ переоценён или просто неправильно понят?

ИИ мощный. Но его часто воспринимают как универсальный интеллект, хотя это скорее универсальный помощник для конкретных задач. Он ускоряет работу, помогает черновиками, объясняет, предлагает варианты, автоматизирует рутину — и в этом он великолепен. Но он не гарантирует качество, не несёт ответственности, не понимает контекст «по-человечески» и не становится автономным менеджером вашей жизни просто потому, что у него красивый интерфейс.

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

Итого

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

Если относиться к ИИ как к инструменту, а не как к «разуму», он приносит огромную пользу. Если ждать от него магии и полной замены человека — почти неизбежно придёт разочарование. И именно поэтому сегодня полезно сбавить градус хайпа и трезво оценивать возможности ИИ: он уже помогает, но ещё не спасает.

Как ИИ учится понимать смысл

Эмбеддинги простыми словами: как компьютеры учатся понимать смысл

Представьте огромную библиотеку, где миллионы книг, инструкций, писем и заметок лежат вперемешку. Вы спрашиваете: «Как вернуть товар?», а библиотекарь должен мгновенно найти нужный фрагмент — даже если в документе написано не «вернуть», а «процедура возврата продукции». Человек с этим справится: мы понимаем смысл, синонимы и контекст. Компьютер — нет. Для него текст сам по себе не “смысл”, а набор символов.

Чтобы машина могла работать со смыслом, используют идею: перевести слова, предложения, документы (а иногда и изображения или звук) в числа так, чтобы смысл при этом сохранялся. Такой перевод называется эмбеддинг (embedding).

Что такое эмбеддинг

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

Проще говоря:

было: слово/фраза/документ (понятно человеку);
стало: массив чисел (удобно компьютеру сравнивать).

Важно: эмбеддинг — не просто “кодировка”. Он старается уловить семантику (смысл) и связи между объектами.

Главная метафора: «карта смыслов»

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

Например, «король», «королева», «монарх» окажутся в одном регионе. «Яблоко» и «апельсин» — в другом, тоже рядом. А «король» и «яблоко» будут далеко друг от друга.

Эмбеддинг — это как GPS-координаты каждого “города” на этой карте. Когда у компьютера есть координаты, он может сравнивать смыслы: что ближе, что дальше, что похоже, что относится к одной теме.

Почему вообще нужно переводить смысл в числа

Компьютер в основе работает с числами. Да, текст и так хранится как числа (коды символов), но такие числа не передают смысл. Если просто присвоить словам номера — «кот = 17», «собака = 18», «самолёт = 19» — из этого не видно, что кот ближе к собаке, чем к самолёту.

Эмбеддинги создают числа так, чтобы смысловая близость превращалась в числовую близость.

Чем эмбеддинги отличаются от старых способов “превращать текст в числа”

Существуют классические подходы вроде Bag of Words (“мешок слов”) и TF-IDF. Они считают, какие слова встречаются в тексте и с каким весом. Это полезно, но у метода есть типичные проблемы:

вектор получается очень длинным (по размеру словаря — тысячи или десятки тысяч измерений);
в нём много нулей — такое представление называют разреженным (sparse);
оно слабо понимает смысл и синонимы: «возврат» и «аннулирование покупки» могут выглядеть как разные темы.

Эмбеддинги обычно делают иначе: векторы получаются плотными (dense) — в них большинство чисел не нули, а длина вектора намного меньше (например, 256, 768, 1024, 1536 измерений). При этом такие векторы лучше отражают смысл и связи.

Как эмбеддинги “учатся” смыслу

Эмбеддинги чаще всего не задают вручную. Их обучают на больших данных.

Есть простая идея (её часто формулируют так): слова, которые встречаются в похожих контекстах, имеют похожие значения. Если модель много раз видит, что «кот», «кошка», «пёс», «собака» встречаются рядом со словами «корм», «миска», «дом», «спит», то она начинает располагать их ближе друг к другу на “карте смыслов”.

Если описывать процесс на пальцах:

сначала каждому слову дают случайные координаты (как будто города раскидали на карте случайно);
модель пытается предсказывать окружение слова или слово по окружению;
если ошиблась — слегка “подправляет” координаты;
после миллионов шагов карта становится осмысленной: похожие слова и фразы группируются.

Статические и контекстные эмбеддинги

Есть два больших подхода к эмбеддингам текста.

Статические эмбеддинги (например, Word2Vec и GloVe): каждому слову соответствует один и тот же вектор, который не меняется. Минус: многозначные слова становятся проблемой. Слово «коса» в смысле «причёска» и «инструмент» получает один и тот же вектор.

Контекстные эмбеддинги (например, модели семейства BERT и GPT): вектор слова зависит от контекста. «Коса» в предложении про волосы будет ближе к словам про причёски, а в предложении про инструмент — ближе к словам про сельхозинструменты. Это гораздо ближе к тому, как понимает язык человек.

Что значит “вектор” и почему по нему можно сравнивать смысл

Вектор — это просто список чисел. Если вектор двумерный, он выглядит как [x, y] и это точка на плоскости. Если трёхмерный — [x, y, z]. Эмбеддинги обычно имеют сотни измерений, и представить их глазами трудно, но компьютер отлично умеет работать с такими объектами.

Главное, что с векторами можно делать полезную операцию: измерять близость.

Если два текста похожи по смыслу, их векторы будут близки. Если смысл разный — далеко. Для измерения близости используют разные метрики. На практике часто применяют косинусную близость, которая сравнивает “направление” векторов и хорошо подходит для смыслового сравнения.

Арифметика смыслов: почему иногда получается «король − мужчина + женщина ≈ королева»

Иногда эмбеддинги показывают красивый эффект: можно “сдвинуться” в пространстве смыслов. Пример: «король» отличается от «королевы» примерно так же, как «мужчина» отличается от «женщины». Если вычесть “мужское” и добавить “женское”, можно оказаться рядом с «королевой».

Это не магия и не обещание, что так будет всегда, но хороший пример того, что эмбеддинги умеют отражать отношения.

Где эмбеддинги применяются в реальной жизни

Семантический поиск (поиск “по смыслу”)

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

Классификация текстов

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

Чат-боты и ответы по базе знаний

Когда компания делает “умного” помощника по своим документам, эмбеддинги становятся основой: вопрос пользователя превращается в вектор, а дальше система ищет самые близкие по смыслу фрагменты из базы знаний.

Эмбеддинги и RAG: как чат-бот отвечает по вашим документам

Один из самых популярных подходов сейчас — RAG (Retrieval-Augmented Generation, “генерация с подкреплением поиском”). Он нужен, чтобы бот отвечал не “из головы”, а опирался на ваши документы.

Схема выглядит так:

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

Именно эмбеддинги в этом процессе играют роль “компаса”, который помогает быстро найти нужные куски информации.

Где хранят эмбеддинги: векторные базы данных

Когда документов много (тысячи, миллионы), для каждого есть вектор. Нужно быстро находить “самые близкие” векторы. Для этого используют векторные базы данных — специальные хранилища, оптимизированные под поиск ближайших соседей.

Если говорить совсем просто: это “база”, которая умеет отвечать на вопрос: «какие 10 фрагментов текста ближе всего по смыслу к моему запросу?»

Эмбеддинги бывают не только для текста

Хотя чаще всего о них говорят в контексте языка, эмбеддинги можно получать из разных типов данных:

изображения — чтобы искать похожие картинки, распознавать объекты, группировать фото;
аудио — чтобы сравнивать записи, искать похожие фрагменты, анализировать голос;
мультимодальные объекты (текст + картинка, картинка + звук) — чтобы учитывать смысл “целиком”.

Почему эмбеддинги важны для “памяти” AI-систем

Когда говорят про “AI-агентов” и “память”, часто речь идёт о том, что система должна уметь:

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

Технически это очень часто делается через эмбеддинги: “вспомнить” означает найти по смыслу похожие записи в памяти, а “похожесть” измеряется близостью векторов.

Ограничения: чего эмбеддинги не обещают

Чтобы ожидания были реалистичными, важно понимать границы технологии.

Эмбеддинги не дают истину. Они дают “похожесть по смыслу”, это вероятностный механизм.
Они могут ошибаться на коротких или двусмысленных запросах.
Качество зависит от данных. Если документы извлечены плохо (например, PDF превратился в “кашу”), то и поиск будет хуже.
Эмбеддинги не заменяют логику. Они помогают найти нужное, но не являются “разумом”.

Поэтому в серьёзных системах эмбеддинги дополняют фильтрами, проверками, “переранжированием” результатов и другими инженерными приёмами.

Как визуально представить эмбеддинги, если у них сотни измерений

Человеческому мозгу сложно представить пространство на 300 или 1000 измерений. Поэтому для демонстраций используют методы “сжатия” размерности (например, PCA или t-SNE). Они переводят многомерные точки на плоскость, стараясь сохранить относительные расстояния.

Если визуализировать эмбеддинги, обычно видно:

кластеры: слова и тексты на близкие темы группируются;
структуру: “страны” отдельно, “животные” отдельно, “еда” отдельно;
направления: отношения вроде “страна → столица” часто похожи для разных пар.

Короткое резюме

Эмбеддинг — это способ представить смысл объекта (слова, текста, документа, товара, картинки) в виде массива чисел так, чтобы похожее по смыслу оказалось близко. Благодаря этому компьютеры могут искать, сравнивать и группировать информацию не только по совпадению слов, но и по смыслу. Именно эмбеддинги лежат в основе семантического поиска, рекомендаций, RAG-чатботов и “памяти” современных AI-систем.

Мини-словарик

Вектор — список чисел (координаты объекта в многомерном пространстве).
Размерность — сколько чисел в векторе.
Семантика — смысл.
Контекст — окружение слова/фразы, влияющее на значение.
Векторная база — хранилище эмбеддингов с быстрым поиском ближайших по смыслу.
RAG — подход “нашёл релевантные фрагменты → добавил в контекст → сгенерировал ответ”.

Балансировка двух провайдеров на MikroTik

Балансировка двух интернет-каналов и failover на MikroTik RB952UA: предсказуемо, без “магии”

У клиента небольшой офис (примерно 10–20 рабочих мест), где интернет нужен постоянно: облачная телефония, CRM, видеосвязь, удалённый доступ, обмен файлами. Раньше всё работало через одного провайдера — и это было «нормально» ровно до первого серьёзного обрыва: при аварии на линии вставало всё, включая телефонию и работу сотрудников.

Клиент решил подключить второго провайдера и поставил задачу:

Сделать балансировку между двумя WAN-каналами, чтобы использовать суммарную пропускную способность.
Сделать автоматическое переключение (failover), чтобы при падении одного провайдера офис не оставался без интернета.
Сохранить предсказуемость: чтобы не ломались сайты/сервисы из-за «скачущего» выхода в интернет и асимметричной маршрутизации.
По возможности — оставить конфигурацию читаемой и поддерживаемой (комментарии, списки интерфейсов, логика без “магии”).

Оборудование и технические данные

В качестве шлюза использовался MikroTik RB952UA (часто встречается как RB952Ui / линейка hAP), потому что он хорошо закрывает офисные потребности “в одном корпусе”:

5 Ethernet-портов (обычно 10/100, в зависимости от ревизии)
Wi-Fi (2.4 ГГц и/или 5 ГГц — зависит от конкретной модели семейства)
RouterOS с достаточным набором функций для NAT, firewall, mangle и policy routing
Компактный формат и низкое энергопотребление
Возможность аккуратно развести WAN/LAN по портам и сразу подключить точки/рабочие места

Для задачи балансировки важны не «гигабитные рекорды», а стабильность маршрутизации и корректная работа firewall/mangle, и MikroTik в этом плане очень удобен.

Схема подключения

Логика была максимально простая:

WAN1 (Провайдер #1) → ether1
WAN2 (Провайдер #2) → ether2
LAN (офис) → bridge из ether3–ether5 + Wi-Fi (если используется)

Примерная схема:

        [ ISP1 ] ---- ether1 (WAN1)
       /

[MikroTik RB952UA]
\
[ ISP2 ] ---- ether2 (WAN2)

LAN: ether3-ether5 + Wi-Fi -> bridge -> офисная сеть

Как мы добьёмся “и балансировки, и предсказуемости”

Если просто сделать два default-route с одинаковой дистанцией, то MikroTik действительно начнёт распределять трафик. Но для офиса это часто заканчивается “странными” проблемами: часть сервисов видит прыгающий внешний IP, где-то рушатся сессии, а ещё появляется асимметричная маршрутизация (пакет ушёл через WAN1, а ответ попытался вернуться через WAN2).

Поэтому используем связку:

PCC (Per Connection Classifier) — распределяем соединения, а не пакеты. Один TCP/UDP-сеанс закрепляется за конкретным WAN и дальше не “прыгает”.
Маркировка соединений и маршрутов — чтобы ответы на входящие/исходящие сессии уходили тем же WAN.
Рекурсивные маршруты + проверка доступности — чтобы failover срабатывал не только при “линк up/down”, но и при реальной недоступности интернета за провайдером.
Читаемость — interface lists, комментарии, минимальная “магия”.

Важно: PCC даёт “суммарную полосу” на множестве соединений. Одна большая загрузка (один поток) не станет в 2 раза быстрее — она всё равно будет сидеть на одном WAN.

Подготовка: интерфейсы, bridge, адреса

Ниже — пример конфигурации через терминал RouterOS. Команды подходят для RouterOS v6 и v7 в части mangle/NAT. Для v7 с “routing tables” можно сделать ещё аккуратнее, но логика остаётся той же (в конце дам примечания).

Предположения (подставьте свои значения):

LAN: 192.168.88.0/24, gateway 192.168.88.1
WAN1: ether1, получает адрес по DHCP или статикой
WAN2: ether2, получает адрес по DHCP или статикой

# 1) Bridge для LAN (ether3-ether5 + Wi-Fi по желанию)
# (Если bridge уже есть — пропустите и только проверьте порты)

# /interface bridge add name=br-lan comment="LAN bridge"
# /interface bridge port add bridge=br-lan interface=ether3
# /interface bridge port add bridge=br-lan interface=ether4
# /interface bridge port add bridge=br-lan interface=ether5
# Wi-Fi интерфейсы добавьте сюда же при необходимости

# 2) IP на LAN
/ip address add address=192.168.88.1/24 interface=br-lan comment="LAN gateway"

# 3) Списки интерфейсов — для читаемости правил
/interface list add name=WAN comment="All uplinks"
/interface list add name=LAN comment="Office LAN"

/interface list member add list=WAN interface=ether1 comment="WAN1 ISP1"
/interface list member add list=WAN interface=ether2 comment="WAN2 ISP2"
/interface list member add list=LAN interface=br-lan comment="LAN bridge"

Если провайдеры выдают адреса по DHCP — включите DHCP-клиенты на ether1/ether2. Если адреса статические — задайте /ip address и /ip route к шлюзам провайдеров вручную (ниже это пригодится для рекурсивных маршрутов).

NAT: отдельная “маскара” на оба WAN

Самый простой и читаемый вариант — masquerade по списку интерфейсов WAN:

/ip firewall nat
add chain=srcnat out-interface-list=WAN action=masquerade comment="NAT to both WAN"

Failover “как надо”: рекурсивные маршруты (чтобы ловить падение интернета, а не только линка)

Если использовать только check-gateway на default route через шлюз провайдера, можно не поймать ситуацию, когда “шлюз пингуется, а интернет умер дальше”. Для офиса это как раз самый неприятный сценарий.

Поэтому делаем так:

Добавляем маршрут до “тестового IP” через реальный gateway каждого провайдера с check-gateway=ping.
Делаем default route рекурсивно через этот “тестовый IP”.

В качестве тестовых IP обычно берут 1.1.1.1 (Cloudflare) и 8.8.8.8 (Google) или любые стабильные адреса. Важно: это должны быть публичные адреса, которые пингуются и доступны “почти всегда”.

# Подставьте GW1/GW2 — шлюзы провайдеров (next-hop), например 10.10.10.1 и 10.20.20.1
# Если WAN получают адрес по DHCP и шлюзы динамические — шлюз можно посмотреть в /ip route или DHCP client.
# В простом офисе часто удобнее закрепить статику на WAN и явно задать GW.

# Тестовые хосты:
# WAN1-test = 1.1.1.1
# WAN2-test = 8.8.8.8

/ip route
add dst-address=1.1.1.1 gateway=GW1 check-gateway=ping scope=10 comment="WAN1 monitor (recursive)"
add dst-address=8.8.8.8 gateway=GW2 check-gateway=ping scope=10 comment="WAN2 monitor (recursive)"

# Основные дефолтные маршруты (общий интернет):
# distance задаёт приоритет: WAN1 основной, WAN2 резервный (или одинаковые — если хотите ECMP без PCC)
add dst-address=0.0.0.0/0 gateway=1.1.1.1 distance=1 target-scope=10 comment="Default via WAN1 (recursive)"
add dst-address=0.0.0.0/0 gateway=8.8.8.8 distance=2 target-scope=10 comment="Default via WAN2 (recursive)"

На этом этапе у вас уже будет “автоматическое переключение” (если WAN1 реально теряет интернет — маршрут через 1.1.1.1 станет невалидным, и трафик уйдёт через WAN2).

Балансировка PCC + симметрия: mangle и policy routing

Теперь делаем распределение новых соединений между WAN1 и WAN2, закрепляя каждое соединение за конкретным каналом, а затем отправляя его через соответствующий маршрут.

Ключевые принципы:

Маркируем connection для исходящих соединений из LAN.
Далее по connection-mark ставим routing-mark.
Добавляем маршруты с routing-mark (policy routes) — “куда идти трафику с этой меткой”.
Отдельно помечаем входящие соединения с каждого WAN — чтобы ответы уходили тем же каналом.

Важно про FastTrack: FastTrack может обходить часть цепочек, из-за чего PCC/маркировки начинают вести себя непредсказуемо. Для стабильности в офисной схеме лучше не использовать FastTrack (или настроить очень аккуратно). Ниже я исхожу из того, что FastTrack отключён.

# Если у вас есть правило fasttrack, временно отключите его:
# /ip firewall filter disable [find where action=fasttrack-connection]

# 1) Входящие соединения: помечаем connection по WAN-интерфейсу
/ip firewall mangle
add chain=prerouting in-interface=ether1 connection-mark=no-mark action=mark-connection new-connection-mark=conn_wan1 passthrough=yes comment="IN: mark connections from WAN1"
add chain=prerouting in-interface=ether2 connection-mark=no-mark action=mark-connection new-connection-mark=conn_wan2 passthrough=yes comment="IN: mark connections from WAN2"

# 2) Исходящие новые соединения из LAN: PCC 50/50
# per-connection-classifier=both-addresses-and-ports — хороший компромисс для офиса:
# - распределяет ровнее
# - одно соединение не прыгает между WAN
add chain=prerouting in-interface=br-lan connection-mark=no-mark dst-address-type=!local \
    per-connection-classifier=both-addresses-and-ports:2/0 action=mark-connection new-connection-mark=conn_wan1 passthrough=yes comment="PCC: new conns to WAN1"
add chain=prerouting in-interface=br-lan connection-mark=no-mark dst-address-type=!local \
    per-connection-classifier=both-addresses-and-ports:2/1 action=mark-connection new-connection-mark=conn_wan2 passthrough=yes comment="PCC: new conns to WAN2"

# 3) По connection-mark задаём routing-mark (policy routing)
/ip firewall mangle
add chain=prerouting in-interface=br-lan connection-mark=conn_wan1 action=mark-routing new-routing-mark=to_wan1 passthrough=no comment="Route-mark LAN via WAN1"
add chain=prerouting in-interface=br-lan connection-mark=conn_wan2 action=mark-routing new-routing-mark=to_wan2 passthrough=no comment="Route-mark LAN via WAN2"

# 4) Ответы на входящие соединения (чтобы не было асимметрии):
# Маркируем роутинг для трафика, который router сам отправляет в ответ (chain=output)
add chain=output connection-mark=conn_wan1 action=mark-routing new-routing-mark=to_wan1 passthrough=no comment="Router replies via WAN1"
add chain=output connection-mark=conn_wan2 action=mark-routing new-routing-mark=to_wan2 passthrough=no comment="Router replies via WAN2"

Теперь добавляем policy-маршруты для меток to_wan1 и to_wan2. Здесь мы используем те же “рекурсивные” шлюзы, чтобы failover работал и внутри policy routing (а не только для “обычного” трафика).

/ip route
add dst-address=0.0.0.0/0 gateway=1.1.1.1 routing-mark=to_wan1 distance=1 target-scope=10 comment="Policy default: to_wan1 (recursive)"
add dst-address=0.0.0.0/0 gateway=8.8.8.8 routing-mark=to_wan2 distance=1 target-scope=10 comment="Policy default: to_wan2 (recursive)"

Что мы получили:

Каждое новое соединение из LAN распределяется между WAN1/WAN2 и закрепляется (PCC).
Ответы на входящие соединения выходят через тот же WAN, откуда пришли (симметрия).
Если у провайдера “умирает интернет”, рекурсивная проверка выключит соответствующий путь, и трафик уйдёт через живой WAN (failover).

Чтобы “не ломались сервисы”: исключения и “липкие” направления

Даже при корректном PCC иногда полезно закрепить некоторые вещи за одним WAN:

банки/гос-сервисы и любые ресурсы, которые строго реагируют на смену IP;
удалённые VPN-туннели (если есть);
IP-телефония/провайдер SIP (часто любит стабильность исходящего адреса).

Делается это через address-list и правило mangle выше PCC: если dst в списке — всегда WAN1 (или WAN2).

# Пример: всё к определённым адресам/подсетям — всегда через WAN1
/ip firewall address-list
add list=sticky_wan1 address=203.0.113.0/24 comment="Example: critical subnet"
add list=sticky_wan1 address=198.51.100.10 comment="Example: critical host"

# Правило ДО PCC (важно!)
/ip firewall mangle
add chain=prerouting in-interface=br-lan dst-address-list=sticky_wan1 connection-mark=no-mark \
    action=mark-connection new-connection-mark=conn_wan1 passthrough=yes comment="Sticky: force WAN1 for critical destinations"

Для доменных имён (например, “crm.example.com”) можно использовать:

ручное обновление IP в address-list (если IP статичен),
или скрипт/резолв (если хочется автоматизации),
или проще: закрепить критичные сервисы за одним провайдером, если это приемлемо организационно.

Минимальный firewall (чтобы не стало хуже)

Если firewall уже настроен — не ломайте “боевую” политику. Ниже — базовый каркас (упрощённый), который обычно есть в офисе:

/ip firewall filter
add chain=input action=accept connection-state=established,related comment="Allow established/related to router"
add chain=input action=drop connection-state=invalid comment="Drop invalid"
add chain=input action=accept in-interface-list=LAN comment="Allow management from LAN"
add chain=input action=drop in-interface-list=WAN comment="Drop input from WAN (router protection)"

Повторюсь: FastTrack лучше отключить, если цель — предсказуемая политика маршрутизации с PCC.

Проверка: как убедиться, что всё работает

Проверка распределения: откройте несколько разных сайтов/видео/загрузок с разных ПК — суммарно WAN должны нагружаться.
Проверка “липкости”: в /ip firewall connection смотрите, что соединения получают conn_wan1 / conn_wan2 и не меняются в процессе.
Failover: отключите кабель WAN1 или “уроните” провайдера (если есть возможность) — интернет должен остаться через WAN2. Потом верните WAN1 — трафик начнёт снова распределяться.

Полезные команды/наблюдение:

# Смотреть маршруты и их статус
/ip route print

# Смотреть маркировку соединений
/ip firewall connection print where connection-mark~"conn_wan"

# Счётчики правил mangle (видно, что правила реально работают)
/ip firewall mangle print stats

Примечания по RouterOS v7

В RouterOS v7 появилась отдельная подсистема маршрутизации (routing tables, routing rules). Логику выше можно реализовать “красивее” через таблицы вместо routing-mark. Но даже если вы оставите вариант с mark-routing, в большинстве офисных сценариев он работает стабильно — главное, чтобы схема была последовательной и проверка доступности провайдера была корректной.

Частые вопросы

Почему одна загрузка не ускоряется в 2 раза?

PCC распределяет соединения. Один поток (например, один HTTP-download) закрепится за одним WAN. Суммарный выигрыш появляется, когда одновременно много разных соединений (пользователи, вкладки, звонки, обновления, облака).

Почему важна симметрия маршрутизации?

Если пакет вышел через WAN1, а ответ ушёл через WAN2 (или наоборот), часть сервисов посчитает это подозрительным: сессии рвутся, SSL/банки/авторизации “капризничают”, VPN может падать. Маркировка входящих соединений и корректные policy-маршруты это предотвращают.

Нужно ли что-то делать с входящими сервисами (порт-форвардинг)?

Если в офисе есть входящие сервисы (например, удалённый доступ на сервер), то для каждого WAN обычно делают отдельные правила dst-nat и понимают, по какому провайдеру люди заходят. При failover “входящий” доступ без внешней динамики (BGP/мульти-WAN с одним IP) автоматически не переедет — это отдельная тема.

Вывод

На RB952UA (и вообще на MikroTik) можно сделать двухпровайдерную схему, которая одновременно даёт и балансировку, и автоматическое переключение, и предсказуемое поведение сервисов. Ключ — распределять соединения (PCC), фиксировать маршрутизацию метками и проверять доступность интернета рекурсивно, а не только “линк поднят/упал”.