Выбор AI-модели для проекта: открытая или закрытая?

Собираешься в поездку, и вот он — момент выбора. На полу два чемодана. Первый — красивый, крепкий, с кодовым замком. Всё аккуратно, ничего не болтается, но код знаешь не ты. И если молния вдруг заест или внутри что-то сломается — ну, извини, только в сервис, только по их графику. Второй — без замка вообще. Зато рядом лежит подробная инструкция, набор отвёрток, запасные винтики и даже наклейка “если что — подкрути вот здесь”. Чуть менее “глянцево”, зато ты хотя бы понимаешь, что у него внутри и что делать, когда что-то пойдёт не так.

Вот примерно так и с моделями. Закрытая модель — это когда она живёт “у них”: на серверах провайдера или в их облаке, а ты к ней подключаешься как к услуге. Что у неё внутри, как она обучалась, почему она отвечает именно так — решают они. Настроить можно только то, что разрешили. Починить — тем более. Open-weights — это когда веса модели (по сути, её “начинка”, память и навыки) можно забрать и держать у себя: запустить на своём железе, ограничить доступ, докрутить под свои задачи, заменить кусок пайплайна, если он бесит или ломается.

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

Я решил сделать простую, почти скучную проверку. Взял один и тот же файл: письмо клиента + кусок внутреннего регламента, и чтобы было по‑честному — добавил туда реальные “грязные” детали: ФИО, телефон, номер договора, сумму, адрес. Задача одинаковая для двух подходов: сжать в 10 пунктов, выделить риски, предложить аккуратный ответ клиенту.

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

Потом я сделал то же самое с open-weights моделью, запущенной локально/в корпоративном контуре. И ощущение другое. Не потому что “она добрее”, а потому что данные никуда не уходят: файл остаётся в моём ноутбуке или внутри сети компании. Это уже разговор на кухне дома: вы сами решаете, кто в комнате, есть ли запись, и вообще — закрыта ли дверь. Да, результат может быть чуть слабее или придётся повозиться с настройкой, но с точки зрения приватности это прям другой класс риска: меньше случайных “утечек по дороге”, меньше вопросов от юристов, спокойнее для комплаенса.

И вот где проходит граница “нормально / стоп-сигнал”. Нормально, когда у вас нет чувствительных данных (маркетинговые тексты, идеи, общие письма без персональных деталей), или когда у провайдера подписан DPA, включены настройки “не сохранять”, и вы точно понимаете, что и куда попадает. Стоп-сигнал, когда в тексте есть персональные данные, коммерческие условия, медицинская/финансовая инфа, внутренние расследования, доступы, всё то, что потом будет больно объяснять. Потому что “модель умная” — это не то же самое, что “модель безопасная именно для моего случая”. В этом тесте выигрывает не тот, кто красивее отвечает, а тот, с кем вы не превращаете рабочие документы в разговор на весь зал.

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

И вот тут разница обычно не “умнее/глупее”, а чисто поведенческая. Одна модель звучит как обаятельный собеседник, который не любит пауз: уверенно, гладко, с юридическими словами — и может выдать пункт, которого в документе нет. Типичная уверенная ошибка выглядит так: «Согласно п. 7.3 договора, штраф составляет 0,1% в день…» — и ты почти веришь, потому что тон спокойный, структура правильная, всё “как в жизни”. Другая модель чаще делает шаг назад: «Я не вижу в тексте прямого пункта о штрафах. Могу поискать разделы “Ответственность”, “Неустойка”, “Санкции”. Пришлите страницу/абзац или разрешите процитировать найденные фрагменты». Она может казаться менее “блестящей”, зато это честное “не знаю” экономит деньги и нервы.

Чтобы ловить такие ошибки, я использую простые правила, почти как чек‑лист:

• Проси цитаты: «Покажи точный фрагмент и номер страницы».

• Проси проверяемую опору: «На какие слова в документе ты опираешься?»

• Разделяй “нашёл” и “предположил”: «Отметь, где факт, а где интерпретация».

• Заставляй уточнять: «Если данных мало — задай 3 вопроса, прежде чем отвечать».

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

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

Условно, чек выглядит так:

• Закрытая модель (API): платите за объём → токены + иногда отдельная строка “за инструмент/поиск/изображение”, плюс лимиты и тарифы.

• Open-weights (у себя): платите за кухню → GPU/серверы, электричество, инференс, хранение, настройка, инженеры, время.

И вот яркая деталь: вы заказали салат, а вам принесли дегустационный сет на 12 подач — вкусно, но счёт удивляет. Так бывает с моделями “рассуждений”: они реально могут быть дорогими в словах. Вместо короткого ответа они раскатывают длинную цепочку рассуждений, уточнений, промежуточных шагов. В токенах это выглядит как: “я просто спросил”, а модель нагенерила в 5–10 раз больше текста, чем было нужно для результата. А токены — это и деньги, и задержка: больше токенов → дольше генерится → выше латентность → больше параллелизма нужно, чтобы держать нагрузку.

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

Кастомизация без магии — это когда ассистент не просто “умный”, а реально говорит вашим голосом и живёт по вашим правилам. Представьте: команда хочет, чтобы ответы звучали как бренд (не “Уважаемый клиент…”, а, скажем, коротко, по‑деловому и чуть дружелюбно), и чтобы в спорных местах он опирался на внутренние регламенты, FAQ и базу знаний. Тут разница между open‑weights и закрытыми моделями ощущается не в лицензии, а в том, как именно вы добиваетесь нужного поведения.

С open‑weights это ближе к “сшить костюм на заказ”. Можно переодеть и перевоспитать модель глубже: подкрутить манеру речи, закрепить локальные правила (“всегда пишем «счёт» через ё”, “не обещаем сроки без проверки”), подключить внутренние документы так, чтобы модель реально на них опиралась, а не просто “угадывала”. Плюс у вас больше доступа к деталям: что подмешивать, где проверять факты, как жёстко фильтровать ответы. Дольше возиться, да, но свободы — вагон.

Закрытые модели — это “взять отличный костюм в прокате и подогнать по фигуре”. Часто там уже есть удобные инструменты: загрузили документы, настроили стиль, поставили ограничения — и через пару дней можно запускать пилот. Но и рамки платформы чувствуются: где-то нельзя поменять поведение глубоко, где-то правила работают “примерно”, а не железно. Зато быстро и без большой инженерии.

И вот яркая бытовая боль: у вас в компании принято говорить “коллеги”, а модель упорно пишет “друзья” — и это бесит, потому что ломает тон бренда. В закрытом подходе вы обычно лечите это “подгонкой”: добавляете правило в настройки, вставляете пару примеров, усиливаете подсказку — и надеетесь, что в 9 из 10 случаев попадёт. В open‑weights можно сделать “перешив”: добавить немного ваших правильных примеров и закрепить правило так, чтобы оно держалось стабильно, даже когда диалог уходит в сторону. В итоге выбор простой: если важнее свобода и контроль — берёте “ателье”; если нужен быстрый запуск без возни — “прокат с подгонкой”.

Давай без “open vs closed — это идеология”. Представь, что ты выбираешь между такси и собственной машиной. Такси — сел и поехал, но платишь за каждую поездку и зависишь от сервиса. Своя машина — больше возни, зато контроль, предсказуемость и можно “допилить под себя”. С моделями примерно так же.

Вот вопросы, на которые реально ответить за 5 минут — и уже станет понятно, куда склоняться:

• Где должны жить данные? Можно ли отправлять тексты/логи/документы во внешнее API или это “только внутри периметра”?

• Сколько стоит ошибка? Ну типа: “не тот тон в письме клиенту” или “ошиблись в медданных/договоре и прилетело”.

• Важнее скорость запуска или контроль? Нужно “вчера в прод” или вы готовы месяц на настройку и отладку?

• Есть ли у вас человек, который будет крутить ручки? Кто-то, кто реально поставит модель, обновит, замерит качество, прикрутит RAG, разберётся с памятью/латентностью.

• Какая нагрузка и экономика? 200 запросов в неделю — одно, 20 млн токенов в день — совсем другое.

• Нужны ли гарантии/поддержка? SLA, договор, ответственность, понятные обновления — или “как-нибудь сами”.

И теперь — три типовых жизненных сценария, без героизма.

1) Фрилансер / малый бизнес: “мне бы просто работало”

Обычно разумнее закрытая модель по API. Это как такси: запустился за вечер, оплатил по факту, не думаешь про сервера, драйвера и почему вдруг всё упало в пятницу. Ошибка тут чаще “дорого, но терпимо”, а скорость внедрения важнее контроля. Open-weights имеет смысл, только если у вас реально болит приватность (например, юридические документы) и есть кто-то, кто готов повозиться.

2) Продуктовая команда (стартап/средний бизнес): “нужно быстро, но с головой”

Чаще выигрывает гибрид. На старте — закрытая модель как такси, чтобы быстро проверить гипотезу и UX. А когда понятно, что фича приносит деньги и нагрузка растёт, появляется смысл “покупать машину”: переносить часть задач на open-weights (например, классификации, черновики, внутренний поиск), чтобы снизить стоимость и получить контроль. Здесь главный критерий — сможете ли вы обеспечить качество и поддержку сами, без вечного “оно само”.

3) Крупная организация с комплаенсом: “сначала безопасность, потом магия”

Тут чаще оказывается разумным open-weights внутри периметра или закрытая модель, но в enterprise‑контуре (частный инстанс, договор, аудит). Потому что вопрос “где живут данные?” решает почти всё. Это как служебная машина: дороже в обслуживании, зато спокойнее — понятные правила, журналы, доступы, контроль. Да, старт медленнее, зато меньше сюрпризов, когда приходит служба безопасности или регулятор.

Если свести к одному правилу: такси (закрытая) — когда важна скорость и простота, машина (open-weights/свой контур) — когда важны контроль, предсказуемость и долгосрочная экономика. И вот уже не “всё сложно”, а вполне конкретный выбор под вашу реальность.