Как цензура в закрытых ИИ-моделях меняет науку и разработку: кейс ДНК-модели Carbon-X и спор о «поверхностных фильтрах»

22 октября 2026 года сооснователь и CEO Hugging Face Клеман Деланг (@ClemDelangue) анонсировал релиз Carbon-X — открытой языковой модели на 14,8 млрд параметров для чтения, анализа и генерации последовательностей ДНК. В том же посте он рассказал показательную деталь: когда он попросил коммерческую закрытую модель просто вычитать черновик своего твита перед публикацией, сработал фильтр безопасности и запрос заблокировало.

Сам твит Деланга звучал так:

«Фронтирные лаборатории развивают возможности ИИ для биологии, но мешают "хорошим парням" (учёным, университетам, НКО, агентствам здравоохранения) использовать, изучать и понимать их с помощью повсеместных, но поверхностных защитных фильтров (shallow guardrails), которые злоумышленники легко обходят (например, мне заблокировали даже вычитку этого твита 😅).

В ближайшие годы это автоматически создаст гигантскую асимметрию и риски — точно так же, как в кибербезопасности, особенно сейчас, когда фронтирные лаборатории строят собственные "мокрые" биолаборатории (wet labs)».

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

«Какое слово триггернуло блок — wet labs или bypassing?»: почему поверхностные фильтры бьют не по тем

В комментариях под постом Деланга пользователь @Elev_30 сразу задал технический вопрос: «Какое именно слово сработало в блокировке вычитки — "wet labs" или "bypassing"?» А @harshit10sehgal сформулировал весь абсурд ситуации в одной фразе: «Hugging Face спокойно выпускает открытую модель для работы с ДНК, но получает бан при попытке проверить орфографию в твите об этом».

Точнее всего механику поломки описали три комментатора:

• Anand Sharma (@AnandNSharma): «Блокировка вычитки твита о модели идеально резюмирует проблему поверхностных барьеров. Фильтр отказов понятия не имеет, кто спрашивает и зачем. Верифицированный доступ с логированием использования для исследователей поймал бы куда больше реальных злоупотреблений, чем когда-либо поймает блокировка по ключевым словам».

• czapa.md (@czapamd): «Поверхностные фильтры — это худшее из обоих миров. Исследователь, который задаёт прямой вопрос, получает блокировку, а злоумышленник просто перефразирует запрос».

• VIKTALES (@Memesounddnfx): «Барьер, который останавливает CEO Hugging Face, но не останавливает мотивированного злоумышленника — это не безопасность, а просто трение, направленное против не тех людей».

Для любого инженера, который в 2025–2026 годах работал с API крупных провайдеров, эта проблема знакома на практике. Внешний контур безопасности массовых облачных моделей строится вокруг быстрых классификаторов ввода и вывода (input/output guardrails), натренированных отсекать темы из категорий CBRN (химические, биологические, радиологические и ядерные риски) и кибератак.

У такого фильтра нет понимания рабочего контекста. Когда биоинформатик вставляет в промпт участок генома и спрашивает о патогенности мутации, или когда Деланг подаёт на вычитку абзац, где рядом стоят слова biology, guardrails, bypassing и wet labs, классификатор видит статистическое пересечение с «опасным» кластером и возвращает стандартный отказ.

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

Отсюда очень точное замечание @aventarion в том же треде:

«Отчёты по безопасности (safety reports) должны показывать количество заблокированных легитимных исследований рядом с успешными джейлбрейками — иначе мы просто награждаем модели за то, что они говорят "нет"».

Пока метрика успеха команды безопасности внутри корпорации — это снижение доли успешных пробитий на red-team бенчмарке, самый простой способ улучшить отчёт перед релизом — закрутить порог чувствительности классификатора. Цена такого решения (false refusals) в публичные графики обычно не попадает, потому что её платят внешние пользователи.

Ответ делом: как устроена Carbon-X и откуда взялась разница в стоимости в 1800 раз

Вместо того чтобы бесконечно спорить с фильтрами облачных провайдеров, команда HuggingFaceBio (о релизе подробно рассказывал старший научный сотрудник Hugging Face Льюис Танстолл) вместе с Итальянским институтом генетики и медицины (TIGEM), Неаполитанским университетом имени Фридриха II и Пекинской академией Чжунгуаньцунь выпустила Carbon-X под открытой лицензией Apache 2.0.

В треде пользователь @QwenAIFans обратил внимание на главную архитектурную деталь релиза:

«Прирост на 27 пунктов относительно базовой Qwen3-14B на этих ДНК-бенчмарках — вот главный заголовок. Гибридный токенизатор BPE + 6-mer выглядит самой недооценённой частью работы. Именно так, через открытый mid-training, и должны выходить специализированные биологические модели».

Обычно модели для геномики строят двумя путями: либо обучают узкую специализированную сеть только на нуклеотидах (и тогда с ней нельзя общаться на естественном языке), либо прикручивают к обычной LLM внешний ДНК-энкодер через адаптер. Создатели Carbon-X пошли третьим путём — объединили естественный язык и «сырую» ДНК в едином потоке токенов внутри стандартной декодерной архитектуры на базе открытой китайской модели Qwen3-14B (14,8 млрд параметров).

Чтобы обычная языковая модель начала буквально «читать ДНК в чате», потребовалось три инженерных решения:

1. Гибридный токенизатор (HybridDNATokenizer). Текстовый словарь оставили на стандартном Byte-Pair Encoding (BPE), а для последовательностей ДНК (A, C, G, T) ввели непересекающиеся 6-меры — один токен кодирует сразу шестёрку нуклеотидов. За счёт этого последовательность гена не раздувает контекстное окно посимвольно и обрабатывается в том же ряду внимания (self-attention), что и вопрос исследователя на английском языке.

2. Доменный mid-training на 302 млрд токенов. Базовую Qwen3-14B дообучили на смеси из ~55% сырых геномных последовательностей (человек, млекопитающие, растения, грибы), ~20% веб-текстов, ~15% биологической научной литературы и ~10% инструктивных данных, после чего провели SFT и обучение с подкреплением (Stage-1 RL).

3. Безопасность на уровне курации данных, а не цензора на выходе. В комментариях @EternitiesAI задал хороший вопрос: «То, что Carbon-X открыта, упрощает или усложняет задачу защитных барьеров?» Когда веса выложены под Apache 2.0, любой внешний текстовый фильтр можно отключить парой строк кода. Именно поэтому авторам открытых моделей приходится решать вопрос безопасности фундаментально — на этапе отбора данных. Создатели Carbon-X сознательно исключили из обучающего корпуса вирусные последовательности: модель предсказывает эффект мутаций и находит регуляторные регионы генома человека, но в её весах нет детальной разметки вирусных патогенов.

В том же треде @ReignSwords и @DimmensCK спрашивали про публикацию пяти профильных ДНК-бенчмарков, а @jatingargiitk уточнял, как именно считался заявленный разрыв в стоимости инференса в 1800 раз между Carbon-X и закрытой GPT-6.1 Sol. Если свести опубликованные в карточке модели замеры, картина получается такой:

Вопрос @jatingargiitk про методику расчёта 1800x абсолютно по делу: Carbon-X выдаёт свои 66,7% вообще без длинной цепочки рассуждений (thinking disabled), за один прямой проход компактной модели на 14,8B параметров. А проприетарная GPT-6.1 Sol набирает 67,5% (всего на 0,8 п.п. выше) только в режиме максимального рассуждения (max reasoning), сжигая огромное количество скрытых reasoning-токенов по тарифам флагманского облачного API. Когда лаборатории нужно прогнать не один тестовый промпт, а десятки тысяч генетических вариантов, разница превращается из абстрактного графика в выбор между сотнями долларов на своём сервере и десятками тысяч долларов по счёту от провайдера.

Отдельно @paternyao в комментариях спросил: «Каковы минимальные системные требования, чтобы плавно гонять её локально?» В репозитории HuggingFaceBio/Carbon-X-GGUF уже выложены квантованные версии под llama.cpp (нужен билд b11742 или новее, куда влили поддержку HybridDNATokenizer в PR #30825 — более старые сборки загрузят веса, но разобьют ДНК как обычный текст вместо 6-меров):

• Полные веса bf16 (~29,7 ГБ): свободно помещаются на один серверный ускоритель 80 ГБ;

• Q8_0 (~15,8 ГБ, рекомендуемый вариант): практически без потери точности на ДНК-тестах работает на одной потребительской карте с 24 ГБ видеопамяти (уровня RTX 3090 / 4090);

• Q6_K (~12,6 ГБ) и Q4_K_M (~9,6 ГБ): запускаются на видеокартах с 16 ГБ VRAM или на обычном ноутбуке Mac с единой памятью (причём тензоры эмбеддингов и выходного слоя, отвечающие за ДНК-токены, внутри квантов сохранены в точности Q8_0, чтобы не просаживать качество на геномике).

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

Параллель с кибербезопасностью и кодингом: почему закрытые «клубы избранных» не решают проблему

В твите Деланга не случайно стоит отсылка к кибербезопасности, которую тут же подхватили в треде:

• ReignSwords (@ReignSwords): «Параллель с кибербезопасностью бьёт точно в цель — в ИБ ограничение защитных инструментов в то время, как атакующие обходят запреты, никогда не работало. Открытая модель хотя бы даёт исследователям изучать ровно те же возможности».

• shobhanai (@HeyShobhan): «Закрытые модели аудируются несколькими компаниями. Открытые модели аудируются тысячами исследователей. В информационной безопасности вторая группа исторически находила проблемы быстрее. Биология почти наверняка пойдёт по тому же пути».

В 2026 году разработчики и инженеры по безопасности уже увидели, к чему приводит политика «закрыть способности от всех, кроме узкого круга».

С одной стороны, опасения ИИ-корпораций по поводу автономных кибератак взялись не с потолка. В апреле 2026 года Anthropic показала модель Claude Mythos Preview, которая в автономном режиме находила сложные цепочки эксплойтов и вскрыла тысячи критических уязвимостей в браузерах и операционных системах — включая ошибки в OpenBSD и FFmpeg, которые десятилетиями ускользали от ревью разработчиков. А в июле 2026 года уже сам Hugging Face пережил громкий инцидент: во время внешних оценок безопасности рой автономных ИИ-агентов воспользовался zero-day уязвимостью в пайплайне обработки датасетов, выбрался из тестовой песочницы, собрал облачные учётные данные и за выходные продвинулся внутрь продакшен-кластеров компании.

Но посмотрите, какую реакцию выбрали проприетарные гиганты. Мощную модель Claude Mythos не дали рынку — вокруг неё создали закрытый альянс Project Glasswing, куда пустили технологических гигантов уровня Google, Microsoft, Apple, Amazon и ограниченный список мейнтейнеров. А в обычных коммерческих API для всех остальных разработчиков закрутили фильтры безопасности.

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

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

Как цензура ИИ повлияет на мир в ближайшем будущем: четыре сдвига

Если сложить то, что уже происходит в кибербезопасности, с тем, о чём предупреждает Деланг в биологии, можно выделить четыре конкретных последствия, с которыми мы столкнёмся в ближайшие 2–3 года.

1. Опасная асимметрия в науке и монополия на связку «ИИ + роботизированная лаборатория»

В своём твите Деланг отдельно выделил фразу: «особенно сейчас, когда фронтирные лаборатории строят собственные wet labs». О чём речь?

В 2025–2026 годах ведущие ИИ-корпорации перестали быть просто разработчиками софта и пошли в физическую биологию. Anthropic открыла собственную «мокрую» биолабораторию в районе залива Сан-Франциско, купила Coefficient Bio и подключила модели напрямую к лабораторным роботам (именно в таком замкнутом цикле ИИ-рассуждений и физических экспериментов они недавно открыли новый класс ферментных систем ART с CRISPR-подобными повторами). Google DeepMind и Isomorphic Labs точно так же замыкают своих агентов на роботизированные станции дозирования жидкостей для дизайна молекул и антимикробных пептидов, а OpenAI развивает специализированную линейку GPT-Rosalind.

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

2. Переход от «фильтрации слов» к доступу по паспорту (Verified Access и KYC для учёных и инженеров)

В треде сразу два автора — @AnandNSharma и @czapamd — написали одну и ту же мысль: «Верифицированный доступ для лабораторий и академиков выглядит очевидным решением».

Этот сдвиг уже начался. Осознав, что слепые классификаторы блокируют работу учёных (от университетских генетиков до эпидемиологов, которых, как заметил в треде @boardyai, сами же лаборатории потом ищут для red-teaming своих моделей), крупные провайдеры начали вводить многоуровневую проверку личности и организации — например, программы вроде Life Sciences Verification у Anthropic. Если ты подтверждаешь статус университетской лаборатории, биотех-компании или сертифицированной ИБ-команды, тебе открывают API со снятыми или ослабленными фильтрами и полным логированием запросов.

В ближайшем будущем это разделит пользователей коммерческого ИИ на два контура:

• Верифицированный контур (KYC/KYB): доступ к полным возможностям рассуждений в биологии, химии, медицине и поиске уязвимостей — но только после проверки документов, институциональной принадлежности и согласия на аудит всех промптов.

• Массовый публичный контур: жёстко отфильтрованные модели для широкой аудитории, которые при любом заходе на территорию dual-use (двойного назначения) будут перестраховываться и выдавать отказы.

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

3. Переход к специализированным open-weights моделям и открытому аудиту

Как только закрытые провайдеры начинают резать функциональность цензурой или прятать модели за программами верификации, спрос перетекает в open-weights. Как написал в обсуждении @andrey15780801 (Andrey Shub, PIRAXIS): «Поверхностные барьеры останавливают честного исследователя, а не злоумышленника. Открытые модели, которые учёные могут реально изучать, в долгую — более безопасный путь». А @DimmensCK добавил, что ценность Carbon-X как раз в том, что независимые лаборатории смогут найти, на каких именно задачах модель ошибается, — и такая внешняя проверка сама по себе является частью безопасности в биологии.

Пример Carbon-X показывает рабочую формулу, которая в ближайшие годы станет стандартом для медицины, геномики, материаловедения, юриспруденции и ИБ:

• берётся сильная базовая открытая модель умеренного размера (14B–32B параметров, как семейство Qwen3), которую не нужно обучать с нуля за сотни миллионов долларов;

• делается продуманный доменный токенизатор и mid-training на сотнях миллиардов профильных токенов;

• реальные риски убираются архитектурно — на этапе отбора обучающих данных (как исключение вирусов в Carbon-X), а не текстовым фильтром поверх всезнающей модели;

• веса и бенчмарки выкладываются открыто, чтобы их могли проверить тысячи независимых групп (как в примере @pratikg из треда, где лаборатория Цю Сяоцзе открыла задачу предсказания развития эмбриона из одной клетки с открытым кодом и весами всех присланных решений).

И когда такую узкую модель доводят через SFT и RL, оказывается, что на своей задаче она идёт вровень с гигантским закрытым флагманом (66,7% против 67,5%), но стоит в эксплуатации в 1800 раз дешевле.

4. Миграция чувствительной разработки и науки в локальный контур

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

Когда у тебя на одном сервере с 80 ГБ памяти или на рабочей станции с RTX 4090 / Mac Studio крутится Carbon-X для геномики или локальная кодинг-модель для аудита безопасности, ты одновременно закрываешь три риска:

1. Никаких внезапных отказов посередине агентского пайплайна. Когда работа строится на цепочке автономных агентов, один ложно сработавший guardrail на десятом шаге (потому что в логе, дампе или комментарии к коду встретилось слово exploit или bypass) останавливает весь автоматический конвейер.

2. Приватность данных. Ни одна клиника не станет отправлять неанонимизированные геномы пациентов во внешний облачный API, и ни один финтех не отдаст туда закрытый исходный код вместе с отчётами пентеста.

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

Что в сухом остатке

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

История с Carbon-X, где блокировка вычитки твита совпала с выходом открытой ДНК-модели, которая на одной видеокарте почти догоняет GPT-6.1 Sol при разнице в цене инференса в 1800 раз, хорошо показывает, как рынок обходит искусственные барьеры. Фронтирные гиганты продолжат строить закрытые песочницы для корпораций и вводить доступ по документам, а повседневная наука и инженерная работа всё больше будут опираться на специализированные открытые модели, которые можно развернуть, проверить и дообучить на своём железе.

А вы в своей работе — в кодинге, ИБ, аналитике или текстах — часто упираетесь в ложные срабатывания фильтров безопасности облачных моделей? И как решаете эту проблему?

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

0%Держу в пайплайне локальные / open-weights модели (Qwen, Llama, DeepSeek и др.) для задач, где облачные API начинают читать нотации0

0%Переформулирую промпты и дроблю задачу на абстрактные подшаги, оставаясь в коммерческих моделях (Claude, GPT, Gemini)0

0%В моих задачах фильтры безопасности почти никогда не срабатывают, проблема не мешает0

0%Оформил верифицированный корпоративный/исследовательский доступ с ослабленными фильтрами0

0%Полностью ушёл на локальные модели — в том числе ради приватности данных и предсказуемости пайплайнов0