Как выбрать AI-бота в Telegram с минимальной цензурой

Пошаговый разбор выбора AI для Telegram без лишних ограничений: что оказалось нерабочим, а что в итоге дало стабильный результат на Grok API.

Идея, которая быстро вышла из-под контроля

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

Сказано — сделано. Точнее, почти. Эксперимент довольно быстро перестал быть «простеньким», разросся по объему и заметно затянулся по срокам.

Концепт: что было критично при выборе модели

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

У меня было три критически важных требования:

Если с первыми двумя пунктами всё более-менее решалось, то третий оказался самым болезненным.

ChatGPT и другие модели: где начались проблемы

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

Скриншот запроса к ChatGPT и ответа с отказом.
Image 1: скриншот отказа ChatGPT на roleplay-запрос.

Gemini, Llama, Qwen и DeepSeek были немного гибче, но до нужного мне уровня свободы всё равно не дотягивали.

Поворот в сторону uncensored-моделей

Дальше я ушёл в сторону так называемых uncensored-моделей: меньше встроенной морали, меньше отказов, больше контроля на стороне разработчика. Искал варианты на Hugging Face и остановился на Dolphin 2.7 Mixtral 8x7B от Эрика Хартфорда.

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

Ollama есть, но железо никто не отменял

В отличие от mainstream-LMM с готовым API, open-source модель нужно либо поднимать локально, либо арендовать сервер. Да, есть удобный раннер Ollama, который быстро даёт API поверх локальной модели. Но локальный хостинг крупных моделей — это дорого и требовательно к железу.

В случае Mixtral 8x7B «8» — это восемь экспертов, а «7B» — около 7 млрд параметров на каждого. На практике это десятки миллиардов параметров, огромный размер модели и высокий порог по VRAM.

Скриншот сервера, который не тянет тяжелую open-source LLM без компромиссов.
Image 2: мой «малыш»-сервер к таким нагрузкам был не готов.

Квантизация: спасение, которое не спасло

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

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

Тупик, думскроллинг и неожиданно очевидное решение

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

Первый релиз Grok, который стал поворотным моментом в проекте.
Image 3: первый релиз Grok — момент, когда пазл сложился.

Почему в итоге я выбрал Grok

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

Финал: бот всё-таки дописан

Если вы всё ещё со мной — да, бот в итоге дописан. На одном только выборе модели у меня ушло больше недели при полной занятости на основной работе, и это до того, как был написан основной код бота.

В качестве пруфа: @ROLEPLAY_AI_BOT. Заходите на свой страх и риск.