Forwarded from Карьера в FAANG
Я рассказал, как писать половину performance review -- self assessment документ. В этом, завершающем цикл, посте поговорим о том, как писать вторую половину -- peer feedback.
Ваши коллеги тоже пишут свой performance review, после чего просят вас написать им фидбэк. Вам нужно будет прокомментировать их работу. Но не просто прокомментировать, а так, чтобы ваши комментарии были полезны оценивающему людей комитету. Эту часть нельзя забывать. Так же, как и в вашем собственном документе, в фидбеке неуместны произвольные возгласы похвалы или критики.
Прежде, чем советовать, что делать, посоветую, чего не делать: не нужно помогать коллеге дописать его self assessment своим фидбэком. Не нужно писать -- ах вот тут еще забыл такую-то деталь! Если приходят такие мысли, передайте их автору приватно. Во-вторых, не стоит комментировать человека. Вы даете фидбэк не человеку, а документу. Человеку можно дать фидбэк лично, или его менеджеру, если есть желание. Ваша работа -- строго прокомментировать существующий контент документа.
В недавнем посте я писал про артефакты, как один из важнейших инструментов написания качественного perf документа. Так вот, вы, автор фидбэка, и есть источник самого главного артефакта. От вас требуется подтвердить заявления автора, которые он не смог подтвердить сам. Допустим, автор снизил p50 latency на 30%. Он может это доказать, приложив ссылку на мониторинг. Но он не может доказать, что это вообще было нужно делать. Поэтому, он просто заявляет, что это улучшило UX. А вы, старший UX дизайнер, подтверждаете это заявление. Если подтверждений нет совсем, надо их подтвердить. Если уже есть артефакты (например, снижение time to first byte), надо их контекстуализировать своим экспертным мнением: я, UX дизайнер шестого уровня, подтверждаю своим авторитетом, что снижение time to first byte доказано положительно влияет на долгосрочные бизнес метрики.
Отсюда следует, что не стоит соглашаться писать фидбэк всем подряд, а кому соглашаетесь, не комментируйте весь документ, а только конкретные места. Спросите себя -- можете ли вы быть артефактом для этого заявления? Есть ли у вас признание вашей экспертности в необходимом автору домене, или будет ли ваш комментарий проигнорирован? Пишите фидбэк только о том, где у вас есть признанный организацией авторитет.
Автор фидбэка, запомни: ты -- артефакт.
Разумеется, к фидбэку так же применимы и правила написания самого документа -- максимально цитировать ладдер и быть структурным.
Ваши коллеги тоже пишут свой performance review, после чего просят вас написать им фидбэк. Вам нужно будет прокомментировать их работу. Но не просто прокомментировать, а так, чтобы ваши комментарии были полезны оценивающему людей комитету. Эту часть нельзя забывать. Так же, как и в вашем собственном документе, в фидбеке неуместны произвольные возгласы похвалы или критики.
Прежде, чем советовать, что делать, посоветую, чего не делать: не нужно помогать коллеге дописать его self assessment своим фидбэком. Не нужно писать -- ах вот тут еще забыл такую-то деталь! Если приходят такие мысли, передайте их автору приватно. Во-вторых, не стоит комментировать человека. Вы даете фидбэк не человеку, а документу. Человеку можно дать фидбэк лично, или его менеджеру, если есть желание. Ваша работа -- строго прокомментировать существующий контент документа.
В недавнем посте я писал про артефакты, как один из важнейших инструментов написания качественного perf документа. Так вот, вы, автор фидбэка, и есть источник самого главного артефакта. От вас требуется подтвердить заявления автора, которые он не смог подтвердить сам. Допустим, автор снизил p50 latency на 30%. Он может это доказать, приложив ссылку на мониторинг. Но он не может доказать, что это вообще было нужно делать. Поэтому, он просто заявляет, что это улучшило UX. А вы, старший UX дизайнер, подтверждаете это заявление. Если подтверждений нет совсем, надо их подтвердить. Если уже есть артефакты (например, снижение time to first byte), надо их контекстуализировать своим экспертным мнением: я, UX дизайнер шестого уровня, подтверждаю своим авторитетом, что снижение time to first byte доказано положительно влияет на долгосрочные бизнес метрики.
Отсюда следует, что не стоит соглашаться писать фидбэк всем подряд, а кому соглашаетесь, не комментируйте весь документ, а только конкретные места. Спросите себя -- можете ли вы быть артефактом для этого заявления? Есть ли у вас признание вашей экспертности в необходимом автору домене, или будет ли ваш комментарий проигнорирован? Пишите фидбэк только о том, где у вас есть признанный организацией авторитет.
Автор фидбэка, запомни: ты -- артефакт.
Разумеется, к фидбэку так же применимы и правила написания самого документа -- максимально цитировать ладдер и быть структурным.
Forwarded from Тоже Паша Техник
RL база.pdf
451.4 KB
живой 🫡
учеба, работа, не совсем успеваю писать
👀 ловите мой "нихуя-как-просто" инсайт с курса по RL у нас в маге.
Без всяких формул и мудрёных греческих букв расскажу, как работает обучение с подкреплением и почему именно оно заставляет большую языковую модель не тупо бубнить текст из интернета, а вести себя так, как нужно нам — слушать промпт, ловко фильтровать бред, фокусироваться на сути и выдавать ответы, за которые реально не стыдно.
Попытался написать максимально просто, но насколько далеко вы прочитаете, зависит от вашего опыта в ML
учеба, работа, не совсем успеваю писать
Без всяких формул и мудрёных греческих букв расскажу, как работает обучение с подкреплением и почему именно оно заставляет большую языковую модель не тупо бубнить текст из интернета, а вести себя так, как нужно нам — слушать промпт, ловко фильтровать бред, фокусироваться на сути и выдавать ответы, за которые реально не стыдно.
Попытался написать максимально просто, но насколько далеко вы прочитаете, зависит от вашего опыта в ML
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Тоже Паша Техник
model are only as good as the context provided to them
- компьютер — это агент
- мышка, клавиатура, микрофон — это инструменты и различные источники контекста для LLM
- usb-c хаб — как раз model context protocol
по сути мы действительно "вставляем" все нужные нам инструменты и источники в парадигму MCP и затем просто используем этот протокол как стандартизированный способ общения с "контекстом".
MCP стандартизирует, как AI приложения взаимодействуют с внешними системами – аналогично тому, как API задают правила общения между веб-приложениями и backend.
Протокол охватывает промпты, тулзы и ресурсы.
У нас есть агент, у которого есть инструменты:
- сходить в задачник (jira) по API и вернуть нужную таску конкретного юзера
- сходить в github и сделать PR в репозитории
Агент с первой картинки:
1. на вход юзер подает тикет
2. агент запрашивает таску
3. решает задачку
4. создает pull request на сделанную задачу
также у нас есть еще пара агентов, которые так или иначе используют API jira и github.
- что если API изменилось? — тогда в каждом агенте придется делать правки
- что если вы захотели изменить пайплайн в каком-то агенте, так как API теперь позволяет еще и прикреплять ревьюера к PR? — придется добавить в агента новый интструмент.
а теперь представим, что у нас есть отдельные сервера для jira и github, в которых прописаны какие инструменты есть и как их использовать. Эти сервера имеют стандартизированные ручки, параметры и ответы.
теперь мы берем агента, говорим зачем он создан и даем ему доступ к этим серверам. При инициализации агент сам спросит у серверов, какие у них есть возможности и будет учитывать их при выполнении запросов. (агент на второй картинке)
этими серверами могут делиться другие разработчики, которые уже написали, например, сервер для взаимодействия с figma.
Архитектура MCP базируется на клиент-серверной модели:
- Host Process – основное AI-приложение (например, Claude Desktop или Cursor)
- MCP Clients – клиенты, которые устанавливают отдельное соединение с каждым сервером
- MCP Servers – специализированные серверы, предоставляющие инструменты и доступ к данным
плюсы: упрощает покдлючение и поддержку новых источников для контекста
минусы: первоначальная настройка и подготовка своей инфры под этот протокол, валидация возможностей чужих серверов + написание своих
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from XOR
Андрей Карпаты выложил свой гайд по моделям ChatGPT
Запоминаем:
Сохраняем и больше не ошибаемся в выборе модели.☕️
@xor_journal
Запоминаем:
🟢 o3 — лучшая для сложных задач. Эта модель рассуждений намного сильнее, чем 4o. Поможет с анализом данных и научными статьями. Карпаты использует эту модель в 40% случаев.🟢 GPT-4o — хорошая, быстрая модель для повседневного использования. Карпаты также использует ее в 40% запросов.🟢 GPT-4.1 — отличный выбор при вайб-кодинге.🟢 GPT-4.5 — если вам нужно покреативить или сгенерировать текст, она сильно меньше других галлюцинирует и ошибается. Но для задач кодинга хуже, чем GPT-4.1 или o3.🟢 режим Deep Research — лучший инструмент для исследований. Нужен, если хочется глубоко разобраться в какой-то теме.
Сохраняем и больше не ошибаемся в выборе модели.
@xor_journal
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Всеволод Викулин | AI разбор
Какую модель применять в NLP.pdf
110.8 KB
Какую модель применять в NLP?
Написал гайд по выбору модели, который сильно упростит вам жизнь. Не только про LLM, но и про другие модели нейронных сетей.
Пользуйтесь, делитесь с друзьями, задавайте вопросы в комментариях.
Все вопросы разберем.
Написал гайд по выбору модели, который сильно упростит вам жизнь. Не только про LLM, но и про другие модели нейронных сетей.
Пользуйтесь, делитесь с друзьями, задавайте вопросы в комментариях.
Все вопросы разберем.
Forwarded from Neural Kovalskii
Когда open-source логирование подставляет, а невнимательность с моделями бьет по метрикам 📊
Все вы помните как я переехал на LiteLLM
Вчера у нас был тот самый день, когда все идет не так, как планировалось
OpenAI API частично лежало, задержки до 16 секунд, пользователи в поддержку валом — классика жанра для любого сервиса с высоким MAU
Проблема №1: Слепая зона в мониторинге
Когда пользователи начали жаловаться на тормоза, мы полезли проверять наш LiteLLM прокси. И тут выяснилось, что без лицензии у нас доступны только базовые метрики в
Мой самописный дашборд показывал, что с прокси все ОК — никаких аномалий
Но задержки-то были! В логах они светились, а в интерфейсе нет
Результат: 2 часа потрачено на копание в прокси, вместо того чтобы сразу проверить статус провайдеров
Ха-ха классический случай "лечим симптомы, а не причину"
Проблема №2: Миграция фильтров без должного тестирования
Наша эволюция фильтров для FLUX генерации:
- Начали с Llama 3.1 + кастомный промпт для нашего FLUX (низкий RPS легко справлялся локальный кластер)
- Переехали на Qwen2.5 (промпт остался тот же)
- Из-за нагрузки мигрировали на gpt-4o-mini
И вот тут началось веселье!
Промпт, который работал с локальными моделями, на gpt-4o-mini показал себя ужасно да как так то? =)
- 37% False Positive срабатываний
- Пользователи, которые писали "девушка" в запросе, не получали генерацию
После анализа данных из единого прокси (спасибо ему за централизованные логи!) команда R&D быстро поняла масштаб проблемы и сделали первое
1) Выгрузил все срабатывания от момента замены модели
2) Глазами просмотрели все FALSE
3) Поняли что нужно менять
Что сделали:
- Переработали промпт под gpt-4o-mini
- Ввели уровни категоризации вместо бинарной фильтрации
- Добавили структурированный вывод (SO)
Результаты после фикса(все просмотрели глазами)
- Снижение общей фильтрации до 17%
- FP уменьшились до 24%
- Пользователи снова получают нормальные генерации
Проблема №3: Мистический расход токенов на $350
Тут была самая загадочная история! Один из API ключей потребил весь свой бюджет на токены за какие-то 5 запросов. Трекнулось аж целых 350 долларов сразу алерты полетели 🚨
Что я сделал? Натравил на логи агента в Cursor, дал ему доступ через SSH к серверу где лежит проект и указал как писать запросы в БД и где лежат логи и сказал: "Найди что тут не так!"
И знаете что? LLM оказался круче любого DevOps инженера! За несколько минут он нашел, что это web search функция, которая за 1000 запросов стоит $35, а не обычная генерация
Дальше мы с LLM стали искать, где же система неправильно трекает этот параметр. 15 взаимодействий с find и grep — и вуаля! Нашли проблемный участок кода.
Баг найден будет отправлен в репозиторий LiteLLM
Честно, почти везде LLM помогли найти проблему быстрее, чем я бы сам
- Анализ латенси — LLM разобрал логи и указал на узкие места
- Поиск багов — структурированный поиск по кодовой базе
- Анализ трафика — выявление аномальных паттернов в запросах
Мой новый подход
1. Логи → LLM для первичного анализа
2. LLM находит зацепки → я иду копать глубже
3. LLM помогает с grep/awk/sed магией
4. Профит!
По мониторингу
- Open-source решения могут подставить в критический момент
- Нужен собственный экспортер метрик для Grafana
- Логи != метрики в дашборде (очевидно, но забываем)
По фильтрации
- Каждая модель требует отдельной настройки промптов
- A/B тестирование фильтров — не роскошь, а необходимость
- Миграция моделей без тестов = выстрел себе в ногу
По дебагу
- LLM + логи = мощный дуэт для поиска проблем
- Структурированный анализ через AI экономит часы времени
- Всегда держите LLM "под рукой" при инцидентах:
Да, скажете "это же база!" — но опыт есть опыт. Иногда нужно наступить на грабли, чтобы понять, где они лежат 😅
И главное LLM действительно может быть вашим DevOps коллегой. Не заменит, но сильно поможет! Главное не дать выполнить критичные команды (читай каждую команду что генерит LLM)
P.S. Единое прокси снова доказало свою ценность — без централизованного логирования мы бы копались в проблеме намного дольше!
Все вы помните как я переехал на LiteLLM
Вчера у нас был тот самый день, когда все идет не так, как планировалось
OpenAI API частично лежало, задержки до 16 секунд, пользователи в поддержку валом — классика жанра для любого сервиса с высоким MAU
Проблема №1: Слепая зона в мониторинге
Когда пользователи начали жаловаться на тормоза, мы полезли проверять наш LiteLLM прокси. И тут выяснилось, что без лицензии у нас доступны только базовые метрики в
/metricsМой самописный дашборд показывал, что с прокси все ОК — никаких аномалий
Но задержки-то были! В логах они светились, а в интерфейсе нет
Результат: 2 часа потрачено на копание в прокси, вместо того чтобы сразу проверить статус провайдеров
Ха-ха классический случай "лечим симптомы, а не причину"
Проблема №2: Миграция фильтров без должного тестирования
Наша эволюция фильтров для FLUX генерации:
- Начали с Llama 3.1 + кастомный промпт для нашего FLUX (низкий RPS легко справлялся локальный кластер)
- Переехали на Qwen2.5 (промпт остался тот же)
- Из-за нагрузки мигрировали на gpt-4o-mini
И вот тут началось веселье!
Промпт, который работал с локальными моделями, на gpt-4o-mini показал себя ужасно да как так то? =)
- 37% False Positive срабатываний
- Пользователи, которые писали "девушка" в запросе, не получали генерацию
После анализа данных из единого прокси (спасибо ему за централизованные логи!) команда R&D быстро поняла масштаб проблемы и сделали первое
1) Выгрузил все срабатывания от момента замены модели
2) Глазами просмотрели все FALSE
3) Поняли что нужно менять
Что сделали:
- Переработали промпт под gpt-4o-mini
- Ввели уровни категоризации вместо бинарной фильтрации
- Добавили структурированный вывод (SO)
Результаты после фикса(все просмотрели глазами)
- Снижение общей фильтрации до 17%
- FP уменьшились до 24%
- Пользователи снова получают нормальные генерации
Проблема №3: Мистический расход токенов на $350
Тут была самая загадочная история! Один из API ключей потребил весь свой бюджет на токены за какие-то 5 запросов. Трекнулось аж целых 350 долларов сразу алерты полетели 🚨
Что я сделал? Натравил на логи агента в Cursor, дал ему доступ через SSH к серверу где лежит проект и указал как писать запросы в БД и где лежат логи и сказал: "Найди что тут не так!"
И знаете что? LLM оказался круче любого DevOps инженера! За несколько минут он нашел, что это web search функция, которая за 1000 запросов стоит $35, а не обычная генерация
Дальше мы с LLM стали искать, где же система неправильно трекает этот параметр. 15 взаимодействий с find и grep — и вуаля! Нашли проблемный участок кода.
Баг найден будет отправлен в репозиторий LiteLLM
Честно, почти везде LLM помогли найти проблему быстрее, чем я бы сам
- Анализ латенси — LLM разобрал логи и указал на узкие места
- Поиск багов — структурированный поиск по кодовой базе
- Анализ трафика — выявление аномальных паттернов в запросах
Мой новый подход
1. Логи → LLM для первичного анализа
2. LLM находит зацепки → я иду копать глубже
3. LLM помогает с grep/awk/sed магией
4. Профит!
По мониторингу
- Open-source решения могут подставить в критический момент
- Нужен собственный экспортер метрик для Grafana
- Логи != метрики в дашборде (очевидно, но забываем)
По фильтрации
- Каждая модель требует отдельной настройки промптов
- A/B тестирование фильтров — не роскошь, а необходимость
- Миграция моделей без тестов = выстрел себе в ногу
По дебагу
- LLM + логи = мощный дуэт для поиска проблем
- Структурированный анализ через AI экономит часы времени
- Всегда держите LLM "под рукой" при инцидентах:
Да, скажете "это же база!" — но опыт есть опыт. Иногда нужно наступить на грабли, чтобы понять, где они лежат 😅
И главное LLM действительно может быть вашим DevOps коллегой. Не заменит, но сильно поможет! Главное не дать выполнить критичные команды (читай каждую команду что генерит LLM)
P.S. Единое прокси снова доказало свою ценность — без централизованного логирования мы бы копались в проблеме намного дольше!
Forwarded from доказательный ⎵ пробел
Профессор ЦЕУ Габор Бекеш продолжает радовать нас открытыми курсами в области анализа данных (об одном из них мы писали ранее). Совсем недавно в свет вышел Курс «Анализ данных с использованием ИИ» (Doing Data Analysis with AI) , который предназначен для студентов с базовыми знаниями в области анализа данных, эконометрики и количественных методов. Курс учит применять ИИ для повышения продуктивности в анализе данных. Основное внимание уделяется использованию крупных языковых моделей (LLMs), таких как ChatGPT, Claude.ai и других. Есть много практических кейсов: например, здесь Бекеш подробно описывает как генерировать графики распределения доходов в привязке к уровню образования и гендеру, приводя примеры промтов и результатов выдачи ChatGPT и Claude.ai. Если еще не используете ИИ в дата-анализе и исследованиях, курс - хорош для погружения 🧠 .
@evidencespace
@evidencespace
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Лига Хруща // League of Hrusch
Revealing a project I was vibe-coding for the past couple of days. For some of my medicine-related projects I need to deploy a web-service based on LLMs that will accept images and text, and create a structured outputs. While I am waiting for the compute (as it needs to run locally), I decided to learn about deploying such web services online - and what could be better toy example than a telegram bot?
Another motivation for this was the influx of casino ads in my comment section. I already had some other automated moderation in place, but it has not been working for the past 6 months at all. So, I decided to both practice in coding and do something useful for myself.
The goal was to create a bot that could:
- Silently monitor all messages, images, and user profiles in a Telegram group.
- Use a powerful AI model to analyze the content and context for signs of spam, scams, or NSFW material.
- Automatically take action by deleting the offending message and banning the user.
- Do all of this on a serverless platform to keep costs near zero for a small community.
Code can be found here
The Tech Stack: Powerful, Modern, and Cost-Effective
Choosing the right tools is half the battle. Here's the stack we settled on after a long and winding road of debugging.
1. Hosting: Google Cloud Run. This was a no-brainer. Cloud Run's serverless nature means you only pay when a request is being processed (scales to 0 when idle). For a moderately active chat, this falls squarely within the generous "Always Free" tier. New users also get a $300 starting credit, making the first several months (or even years) completely free.
2. Language Model: Gemma 3 27B. As detailed in Google's release documents, Gemma 3 is a powerhouse. The 27-billion-parameter instruction-tuned model (gemma-3-27b-it) is multimodal, meaning it can understand both text and images simultaneously—perfect for analyzing user profile pictures alongside their messages. It represents a "pareto sweet spot" of high performance and manageable size.
A major factor in choosing the model was its accessibility. When called via the Gemini API, Gemma 3 models have an incredibly generous free tier: 30 calls per minute. This translates to a staggering 14,400 free analyses per day—more than enough to moderate even a very active community without spending a dime.
3. Web Framework: FastAPI. After initially struggling with Flask, we switched to FastAPI. As a native async framework, it seamlessly integrates with the asynchronous nature of a chatbot, eliminating a whole class of server errors and simplifying the code.
Another motivation for this was the influx of casino ads in my comment section. I already had some other automated moderation in place, but it has not been working for the past 6 months at all. So, I decided to both practice in coding and do something useful for myself.
The goal was to create a bot that could:
- Silently monitor all messages, images, and user profiles in a Telegram group.
- Use a powerful AI model to analyze the content and context for signs of spam, scams, or NSFW material.
- Automatically take action by deleting the offending message and banning the user.
- Do all of this on a serverless platform to keep costs near zero for a small community.
Code can be found here
The Tech Stack: Powerful, Modern, and Cost-Effective
Choosing the right tools is half the battle. Here's the stack we settled on after a long and winding road of debugging.
1. Hosting: Google Cloud Run. This was a no-brainer. Cloud Run's serverless nature means you only pay when a request is being processed (scales to 0 when idle). For a moderately active chat, this falls squarely within the generous "Always Free" tier. New users also get a $300 starting credit, making the first several months (or even years) completely free.
2. Language Model: Gemma 3 27B. As detailed in Google's release documents, Gemma 3 is a powerhouse. The 27-billion-parameter instruction-tuned model (gemma-3-27b-it) is multimodal, meaning it can understand both text and images simultaneously—perfect for analyzing user profile pictures alongside their messages. It represents a "pareto sweet spot" of high performance and manageable size.
A major factor in choosing the model was its accessibility. When called via the Gemini API, Gemma 3 models have an incredibly generous free tier: 30 calls per minute. This translates to a staggering 14,400 free analyses per day—more than enough to moderate even a very active community without spending a dime.
3. Web Framework: FastAPI. After initially struggling with Flask, we switched to FastAPI. As a native async framework, it seamlessly integrates with the asynchronous nature of a chatbot, eliminating a whole class of server errors and simplifying the code.
Forwarded from Лига Хруща // League of Hrusch
The Brain of the Bot: The Moderation Prompt
The core of our AI moderator isn't just the model; it's the instruction we give it. The prompt is carefully engineered to give the AI context and clear criteria for its decisions. It's not just looking at the message text but the whole picture: the user's name, their profile photo, and the message itself.
This prompt empowers the AI to spot nuanced spam tactics that simple keyword filters would miss.
The Crucial Detail: Disabling the Safety Rails
This might sound counterintuitive for a moderation bot, but to make it work, we had to tell the Gemini API to turn off its own safety filters. By default, the API will refuse to process any content it deems harmful. But our bot needs to see the harmful content to classify it.
This is achieved with the generation_config object, where we set the blocking threshold to BLOCK_NONE for all categories.
This tells the API: "Show me everything, unfiltered. Trust me, I'm the moderator here." Our application's logic then takes over to decide what to do with that information.
Conclusion
Building this serverless AI moderator was a deep dive into the modern AI and cloud-native landscape. It showcases how accessible, powerful tools like Google Cloud Run and the Gemma family of models can be combined to solve real-world problems creatively and cost-effectively. The journey was challenging, but the result is a robust, intelligent, and virtually free solution for keeping online communities safe.
The core of our AI moderator isn't just the model; it's the instruction we give it. The prompt is carefully engineered to give the AI context and clear criteria for its decisions. It's not just looking at the message text but the whole picture: the user's name, their profile photo, and the message itself.
You are an AI content moderator for a Telegram chat group. Your task is to classify incoming messages
(text and images), user profiles (name, photo), and user metadata into one of the following categories:
NUDITY, CASINO_ADS, SPAM, VIOLENCE, SAFE.
Some AI bots may appear harmless at first, but they edit their responses to include harmful content later.
That is why you need to analyze their profile names, profile pictures, and any other metadata (provided in context) to determine if they are safe or not.
CRITERIA FOR BOTS/SPAM:
- PROFILE NAME: Names with a strange mix of Cyrillic and Latin/Unicode characters, it is likely a bot. Example: "Мария Знаkмлсьь", "Ульяна Вагuллина".
- PROFILE IMAGE: If the profile image contains NSFW content, it is likely a bot.
- MESSAGE CONTENT: If the message is recruiting workers for a job, it is likely a bot. If the message suggests "having fun", "making money", "easy cash", or similar phrases, it is likely a bot.
- LINK ANALYSIS: If the message is simply mentioning ads in general, but does not contain any links, or telegram usernames (following "@" or t.me/), it is not spam (safe).
These are just some examples; you should use your best judgment to classify the content.
Analyze the content provided and respond with a single, clean JSON object containing two keys:
1. "category": The classification of the content.
2. "reason": A brief, one-sentence explanation for your classification.
This prompt empowers the AI to spot nuanced spam tactics that simple keyword filters would miss.
The Crucial Detail: Disabling the Safety Rails
This might sound counterintuitive for a moderation bot, but to make it work, we had to tell the Gemini API to turn off its own safety filters. By default, the API will refuse to process any content it deems harmful. But our bot needs to see the harmful content to classify it.
This is achieved with the generation_config object, where we set the blocking threshold to BLOCK_NONE for all categories.
generation_config = types.GenerateContentConfig(
safety_settings=[
types.SafetySetting(category=h, threshold=types.HarmBlockThreshold.BLOCK_NONE)
for h in HarmCategory
]
)
This tells the API: "Show me everything, unfiltered. Trust me, I'm the moderator here." Our application's logic then takes over to decide what to do with that information.
Conclusion
Building this serverless AI moderator was a deep dive into the modern AI and cloud-native landscape. It showcases how accessible, powerful tools like Google Cloud Run and the Gemma family of models can be combined to solve real-world problems creatively and cost-effectively. The journey was challenging, but the result is a robust, intelligent, and virtually free solution for keeping online communities safe.
GitHub
GitHub - Max-Trubetskoy/gemma_moderator_bot: Repo, containing code and docker environment of a telegram bot, powered by gemma,…
Repo, containing code and docker environment of a telegram bot, powered by gemma, for Google Cloud Build - GitHub - Max-Trubetskoy/gemma_moderator_bot: Repo, containing code and docker environment...
Forwarded from Machinelearning
Unsolth выложила в открытый доступ в своем репозитории на Github больше сотни готовых ipynb-блокнотов для запуска различных операций в Google Collab практически всех популярных семейств языковых моделей, BERT, TTS-моделей и VLM:
Блокноты включают пошаговые руководства и примеры для вызова инструментов, классификации, синтетических данных, подготовки сетов, инференса и файнтюна моделей и
примеры методов GRPO, DPO, SFT, Continued Pretraining, Reasoning и других.
Unsloth известна тем, что помогает делать большие языковые модели быстрее, компактнее и доступнее при помощи динамического квантования, что позволяет запускать их без сильной потери качества . Их технологии ускоряют обучение и настройку ИИ-моделей в 2 раза и экономят до 70% памяти. Инструменты Unsloth, на сегодняшний день, скачали более 10 млн раз.
Есть подробная документация по использованию, а для тех, кто больше привык к Kaggle - такой же набор блокнотов для запуска на этой платформе.
@ai_machinelearning_big_data
#AI #ML #LLM #Notebooks #Github #Unsloth
Please open Telegram to view this post
VIEW IN TELEGRAM