GPT-4.1

Анти-спам для канала, часть 2

Каждый комментарий на моём канале проверяется на спам, об этом у меня недавно выходил пост. Если вкратце — я скармливаю текст комментария в GigaChat вместе с системным промптом, и GigaChat оценивает, является ли комментарий спамом.

У этого решения есть проблема У GigaChat есть тематические ограничения запросов — если затронуть одну из запретных тем, GigaChat не будет обрабатывать такой запрос.

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

Причём тут GitHub Models Во вчерашнем посте про бесплатный доступ к моделям OpenAI я затронул LangChain, который стандартизирует обращения к API разных моделей. У GigaChat тоже есть своя библиотека для интеграции с LangChain, и мой антиспам бот написан на ней.

Это означает, что при желании мне не составит никакого труда переключить анти-спам на любую другую модель. Например, на бесплатную GPT-4.1, которая хостится на Microsoft Azure.

Что это даёт У Microsoft Azure тоже есть правила фильтрации запросов, но их сообщение об ошибке более информативное.

В случае срабатывания фильтров Azure я получую 400-ую ошибку и объект content_filter_results. В нём будет указано, какие именно фильтры сработали. Кстати, там даже есть фильтр на попытки промпт-инъекций.

Дальше всё просто Если GigaChat откажется проверять комментарий на спам из-за того, что в нём затронуты запретные темы, я просто переотправляю этот же комментарий в GPT-4.1 на Azure. В результате я либо получу результат проверки на спам от GPT-4.1, либо получу инфо о том, почему срабатывают фильтры.

Лимитов на бесплатное использование Azure как раз хватит, чтобы обрабатывать такие редкие кейсы.

P.S. В комментариях к предыдущему посту вы предложили много других сервисов для работы с LLM. Спасибо! Планирую воспользоваться всеми, сделаю сравнение по разным параметрам: фильтрам, лимитам, скорости и т.д.

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

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

Что ж, пришлось действовать старым "дедовским" способом. Открыл веб-версию канала и пролистал всю ленту, чтобы загрузились все сообщения (там используется подгрузка при скроле). Далее открыл консоль и буквально "на коленке" написал скрипт, который через DOM выбрает все блоки постов, выбрает нужные данные из них, отчищает текст сообщений от лишней разметки и превращает его в markdown. Наконец-то пригодилось знание DOM для чего-то полезного 😏 Код вышел грязным и в лоб – но свою работу делает.

В итоге вышло ~450Kb текста с атрибутами, без изображений и видео. В Word'е в дефолтных настройках (Calibri 12pt) это 166 страниц (58 тысяч слов). Этот текст превращается в ~118 тысяч токенов (OpenAI Tokenizer), что умещается в текущий стандарт для размера окна контекста в 128k токенов и еше немного остается.

Несмотря на размер контекста модели (для GPT-4o — 128k, GPT-4.1 — 1M, GPT-o4-mini — 200k), в интерфейсе ChatGPT нельзя отправлять сообщения более определенной длины. Точных размеров не выяснял, но это где-то около 100Kb (символов, не токенов). То есть скормить текст такого размера как у меня (450Kb) целиком в чат не выйдет, или по крайней мере не одним сообщением.

Хорошо, у нас еще есть возможность прикреплять файлы. Пробуем, но это работает совсем не так как ожидается. Целиком файл не обрабатывется, AI модель так или иначе делает выборки из файла (фрагмент или фрагменты) и работает с выбранным. Для выборок обычно модель пишет Python код. Что попадет в выборку и по какому принципу, тот еще вопрос. Вернее как модель решит. Например, может взять первые несколько килобайт (для чего напишет скрипт), или решит искать по ключевым словам (то есть напишет код, который это делает), при этом поиск строгий и набор слов (количество и состав) — это как повезет. Надежность такого подхода сомнительная. В целом, работа с прикрепленным файлом носит очень приблизительный характер. Может хорошо работать для файлов с данными, типа CSV, так как это лучше поддается детерминированой программной обработке. Но вот для текста (markdown), где большая вариативность — работает так себе. Вероятность успеха (success rate) не нулевая, но чем больше текст тем больше падают шансы.

В общем, для полноценной работы с текстом (например, чтобы не потерялись какие либо факты или детали) весь он должен быть в контекстном окне. Чтобы использовать контексное окно целиком для больших текстов, остается только использовать либо API (в конечном итоге), либо Playground. Плюсы: больше контроля, можно управлять параметрами, например, температурой (насколько рандомизируется результат). Главный минус — стоит отдельных денег, то есть нужно оплачивать входящие/выходящие токены, но цены вполне умеренные.