Как выбрать AI-бота в Telegram с минимальной цензурой
Пошаговый разбор выбора AI для Telegram без лишних ограничений: что оказалось нерабочим, а что в итоге дало стабильный результат на Grok API.
Идея, которая быстро вышла из-под контроля
Примерно четыре месяца назад мне пришла в голову простая идея: написать Telegram-бота на базе ИИ, задать ему конкретное поведение (историческая личность, политический персонаж, вымышленный герой) и добавить в наш чат с друзьями, чтобы он общался с людьми и оживлял диалог.
Сказано — сделано. Точнее, почти. Эксперимент довольно быстро перестал быть «простеньким», разросся по объему и заметно затянулся по срокам.
Концепт: что было критично при выборе модели
Первым шагом стал выбор модели — это сердце всего проекта. Я сразу отказался от идеи дообучать существующие модели или тем более собирать свою LLM с нуля: слишком высокий порог по знаниям, времени и ресурсам. Поэтому фокус был на готовых решениях, где поведение задается промптом.
У меня было три критически важных требования:
- модель должна быть достаточно умной для живого диалога и контекста;
- модель должна хорошо работать на русском языке;
- минимум ограничений и цензуры: бот должен свободно отыгрывать роли, включая жесткие форматы общения и политические темы.
Если с первыми двумя пунктами всё более-менее решалось, то третий оказался самым болезненным.
ChatGPT и другие модели: где начались проблемы
Первым, естественно, был ChatGPT. Он отлично справлялся с качеством диалога и русским языком, но по части ограничений оказался самым жестким. Любая попытка отыгрывать «неудобного» персонажа быстро упиралась в отказ.
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.
Квантизация: спасение, которое не спасло
Конечно, я пробовал квантизацию. В теории всё красиво: сжимаем модель,
экономим память, сохраняем максимум качества. На моем железе самым
рабочим вариантом оказался формат Q4_K_M.
Но по факту качество ответов сильно просело и перестало устраивать. Получилась классическая ловушка: mainstream-модели были слишком зацензурированы под мой сценарий, а open-source я не мог стабильно тянуть локально без серьёзных вложений в инфраструктуру.
Тупик, думскроллинг и неожиданно очевидное решение
В какой-то момент я реально был близок к тому, чтобы закрыть идею. Ирония в том, что решение буквально было перед глазами: в одном из «специфических» тредов в X я снова увидел Grok и решил проверить его уже как базу для проекта.
Почему в итоге я выбрал Grok
- удобное и стабильное API;
- сильная модель уровня топовых решений;
- заметно более мягкие ограничения по роли и тону ответов, что было ключевым для концепции roleplay-бота.
В итоге получилось жизненно: я потратил много времени на обходные пути, разобрался в куче технических деталей, а рабочее решение оказалось гораздо ближе, чем казалось в начале.
Финал: бот всё-таки дописан
Если вы всё ещё со мной — да, бот в итоге дописан. На одном только выборе модели у меня ушло больше недели при полной занятости на основной работе, и это до того, как был написан основной код бота.
В качестве пруфа: @ROLEPLAY_AI_BOT. Заходите на свой страх и риск.