Как российский стартап Mostik научил две ИИ-модели обмениваться данными без текста

Коротко: что Mostik обещает и что известно сейчас

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

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

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

Как обычно общаются несколько языковых моделей

Текст как универсальный посредник

Текст стал привычным форматом обмена между разными ИИ-системами по практичной причине: его легко передать через API, сохранить в журнале, проверить человеком и отправить модели другого разработчика. Такой формат поддерживают почти все инструменты для работы с LLM.

Представим обработку договора. Первая модель извлекает из документа даты, суммы и обязательства сторон. Она формирует сообщение вроде: «Срок оплаты составляет 30 дней, штраф за просрочку равен 0,1% в день». Вторая модель получает этот текст и составляет краткое заключение для руководителя. Человек способен прочитать промежуточный результат и понять, почему система пришла к выводу.

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

документ -> первая LLM -> текстовый результат -> API или промежуточный слой -> вторая LLM -> ответ

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

Где возникают лишние расходы и потери смысла

Текстовый обмен добавляет несколько операций. Первая модель тратит вычисления на генерацию последовательности токенов. Затем система передает этот результат по сети или через внутренний сервис. Вторая модель снова разбирает последовательность на токены и помещает их в контекст.

Чем длиннее промежуточное сообщение, тем больше памяти и времени требуется для следующего этапа. В цепочке из трех или четырех LLM такие расходы повторяются. Каждая модель может пересказать предыдущий результат с другой степенью детализации, потерять число, изменить условие или добавить неподтвержденную связь.

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

Что значит обмен через внутренние математические представления

Векторные представления в языковых моделях

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

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

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

Числовое представление не читается как спрятанное предложение. В нем закодированы признаки и связи, которые модель использует для вычислений. Поэтому передача такого массива между двумя LLM требует правил совместимости. Получатель должен понимать, что означают координаты, какие размеры имеют векторы и на каком этапе вычислений их можно использовать.

Почему моделям может понадобиться адаптация

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

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

Возможна и более ограниченная схема: модели заранее адаптируют под общий протокол. Тогда первая LLM передает специальный массив признаков, а вторая знает, как его читать. Конкретный механизм Mostik в доступных материалах не раскрыт. Неизвестно, передаются ли эмбеддинги, скрытые состояния, сжатые признаки или отдельный формат, созданный для конкретной пары моделей.

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

Почему отказ от промежуточного текста может снизить стоимость

Меньше генераций и повторного чтения

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

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

Потенциальная цепочка приобретает другой вид:

документ -> первая LLM -> числовое представление -> преобразователь -> вторая LLM -> ответ

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

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

Почему экономия не гарантирована

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

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

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

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

Mostik, RAG и векторный поиск: это не одно и то же

Как работает RAG

RAG расшифровывается как Retrieval-Augmented Generation, или генерация с поиском по внешним данным. Система сначала принимает документы, страницы базы знаний или записи CRM. Эти материалы разбиваются на фрагменты и преобразуются в векторные представления. Когда пользователь задает вопрос, поиск находит близкие по смыслу фрагменты, после чего LLM получает их в контексте и формирует ответ.

Упрощенная схема выглядит так:

документы -> индекс -> векторный поиск -> найденные фрагменты -> LLM -> ответ

AI Agent Knowledge Base использует похожую логику для долговременной работы с данными. К агенту можно подключать PDF, Notion, CRM и сайт, затем искать в них нужные сведения перед генерацией ответа. Публичные версии LLM сами по себе не видят приватные документы компании. Для такого доступа нужен контроль прав и архитектура вроде RAG или корпоративной версии модели.

Для корпоративных данных RAG иногда оценивают как способ снизить частоту галлюцинаций на 40-60%. Показатель зависит от полноты документов, качества разбиения, поиска и проверки ответа. В отдельном разборе контекстного разрыва и ошибок AI-агентов подробно разобрано, почему даже подключенная база знаний не гарантирует точный результат.

В чем предполагаемое отличие Mostik

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

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

Общее слово «вектор» не делает технологии одинаковыми. В RAG вектор часто служит ключом для поиска похожих фрагментов. Внутреннее состояние LLM может описывать промежуточный результат рассуждения или обработки последовательности. Без опубликованного протокола Mostik нельзя определить, какая именно информация сохраняется при передаче и как она сравнивается с текстовым обменом.

Где такой обмен может пригодиться на практике

Цепочки из специализированных моделей

Гибридная ИИ-система объединяет модели с разными сильными сторонами. Одна модель быстро определяет тему обращения, вторая извлекает факты из документа, третья проверяет соответствие правилам, четвертая формирует ответ для человека.

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

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

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

Тема совместимости особенно важна для компаний, которые соединяют модели разных разработчиков. В обзоре одновременных релизов Qwen3-8-Max, DeepSeek-V4-Pro и Grok 4.6 мы разбирали, почему разнообразие моделей увеличивает выбор инструментов и одновременно усложняет их сравнение. Для прямого обмена внутренними данными требования к такому сравнению будут еще жестче.

Корпоративные и пользовательские помощники

Корпоративный помощник может объединять поиск по внутренним документам, классификацию запросов, аналитику и подготовку ответа. Теоретически одна модель получает документы через RAG, другая оценивает найденные факты, третья превращает результат в понятный текст для сотрудника.

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

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

В бизнесе уже тестируют цепочки с агентами, поиском и специализированными моделями. Например, на конференции Urban ML обсуждались реальные AI-кейсы, включая агентную RAG-систему для нормативных документов и семантический поиск. Эти примеры показывают спрос на составные ИИ-системы, но сами по себе не подтверждают технологию Mostik.

Что нужно проверить до выводов о технологическом прорыве

Какие метрики имеют значение

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

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

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

Четвертый показатель, задержка. Нужны среднее и высокое значения времени ответа, например задержка для 50% и 95% запросов. Одна удачная демонстрация не описывает поведение системы при нагрузке.

Полезно измерять объем передаваемых данных, устойчивость к смене модели и качество после обновления весов. В тестах нужна базовая модель сравнения: та же задача с привычным текстовым обменом, тем же набором данных и тем же оборудованием.

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

Как читать текущие заявления Mostik

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

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

Читателю полезно разделять три утверждения: Mostik заявил о новом принципе, такой принцип технически возможен, преимущество уже доказано. Сейчас подтверждается только первое утверждение в контексте этой публикации. Второе следует проверять по архитектуре, третье требует измерений.

Если появятся исследование, код или новые результаты тестов, оценку можно будет обновить. Есть вопрос или заметили неточность? Сообщите об этом редакции Среды AI, чтобы разбор оставался ясным, проверяемым и полезным.