У OpenAI вышел классный гайд для бизнеса, на тему того как внедрять GenAI в бизнесс процессы:
https://openai.com/business/guides-and-resources/

Внутри 3 части:
– АИ на предприятии: Опыт семи передовых компаний
– Практическое руководство по созданию агентов ИИ: Что агенты АИ могут сделать для ваших сотрудников?
– Определение и масштабирование сценариев применения АИ: На чём концентрируются компании, первыми внедрившие АИ

Я полистал и там внутри много вещей на которых лично я набивал шишки в практике с GenAI, очень рекомендую корпоративным менеджерам

#OCRBench Как строить бенчмарк с LLM-as-a-Judge?

Решил пойти по стопам Рината (@llm_under_hood) и периодически публиковать результаты тех или иных внутренних бенчмарков по разным моделям. Например вот как можно сделать бенчмарк по OCR (Optical Character Recognition), в нашем случае парсинг переписки со скриншота

Для тех, кто не знает, я делаю AI Dating Copilot – приложение, которое по скриншоту переписки или профиля подсказывает, что написать. Короткое демо iOS приложения в действии:

https://t.me/bogdanisssimo/1899

Вообще, разработка эвалов (систем оценки тех или иных задач вашего AI-сервиса) – одно из ключевых занятий при создании AI продуктов. Без них у тебя единственный способ принятия решений – это "по ощущениям". Мы конечно же пропагандируем Data-Driven Dating, поэтому сегодня мы говорим о том, как строить свои бенчмарки

Я понимаю, что этим постом я буквально делаю подарок коллегам по цеху, но если они не догадались в 2025 использовать LLM для OCR, это говорит о том, что они не очень заботятся о качестве продукта для пользователя и совсем не экспериментируют с пайплайном. Тем более, я почти год назад об этом писал сам (см. «Мечтает ли GPT-4o о сегментации картинок»). В конечном итоге оцениваю, что для моей аудитории это даст х100 больше value, чем преимуществ конкурентам

Значит, как я варил свой OCR Benchmark:

1. Берем 100-200 скриншотов переписок от пользователей, особенно нас интересуют сложные кейсы, где классический парсер (TextRecognition + if-else) или LLM часто ошибаются

2. Берем *довольно сложный* промпт для парсинга диалога, со всеми деталями (включая кто на какое сообщение ответил / поставил реакцию / какой длины голосовое и т.д.)

3. Пусть у нас есть какая-то система, которая работает сейчас. Мы через неё прогоняем все кейсы, затем глазками смотрим каждый скриншот, ручками меняем output до идеального. Это наши ground truth. Где-то будут ошибки в отправителях. Где-то будут пропущены какие-то куски сообщений. Где-то будет лишний мусор. Все это мануально вычищается

4. Прогоняем для нужной LLM все скриншоты

5. Теперь самое интересное: как сравнивать предикты и expected output? Год назад (когда ещё не было GPT-4o-mini и Claude 3 Haiku была не такой уж стабильной) я бы это делал по старинке через расстояние Левенштейна. Какие есть проблемы у этого подхода?

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

Поэтому намного стабильнее, практичнее и проще использовать легковесную LLM-судью, которой мы даём кейс, ожидаемый результат и результат модели и просим на основе нашего подробного чеклиста (наши критерии) сравнить, оценить от 0 до 100 + дать фидбек по замеченным ошибкам (которые можно будет использовать для отладки, см. «анализ ошибок в ML системах»).

Внизу прикрепляю результаты замеров OCR Bench по разным LLM из свеже вышедших

—

Разумеется ровно такой же подход распространяется на очень широкий спектр кейсов. По сути это сводит оценку очень сложных выхлопов моделей к подобию тривиальных unit-тестов из разработки. В большинстве (менее технических) задач LLM-оценщик не заведётся с первого раза и понадобится большое количество итераций вместе с экспертом по выравниванию оценок LLM-оценщика и эксперта

Подробнее про LLM-as-a-judge можно почитать здесь:

- https://www.evidentlyai.com/llm-guide/llm-as-a-judge
- https://www.confident-ai.com/blog/why-llm-as-a-judge-is-the-best-llm-evaluation-method
- https://huggingface.co/learn/cookbook/en/llm_judge

Ваш любимый @bogdanisssimo, буду благодарен репостам друзьям и в ваши каналы

P.S. Какие модели надо ещё прогнать? Какие тулзы для эвалов вы юзаете?

#Evals

Теория ограничений (теория узких мест) – это примерно тоже самое, что делать back propagation но в масштабах всего бизнеса. Вместо слоёв у тебя этапы воронки:

https://t.me/bogdanisssimo/1026

Вместо нейронов – компоненты продукта и маркетингового пайплайна (этапы воронки), вместо синапсов - конверсии. На каждом цикле оптимизации ты делаешь оценку в каком направлении что нужно поменять, чтобы больше максимизировать чистую прибыль / LTV:CAC или другую метрику

Как и в deep learning, ты можешь делать как forward pass и backward pass

Например, деньги и юнит-экономика – мы можем "отнормировать" на любом этапе: ты знаешь сколько денег тратишь - можешь оценить CPM (cost per mile, цена за 1000 просмотров) → CPI (cost per install) → CPT (cost per trial) → CAC (customer acquisiton cost, стоимость привлечения 1 платящего пользователя)

Так и, в обратную сторону, backward pass: LTV (Customer LifeTime Value) ← Trial LTV (сколько чистой прибыли принесёт 1 триал) ← Install LTV (сколько денег принесёт 1 инсталл) ← RPM/PPM (revenue per mile / profit per mile, выручка/прибыль на 1000 просмотров)

В случае если канал привлечения один – соотношения (например Install LTV : CPI, LTV : CAC, RPM : CPM) не поменяются. Если несколько каналов (например разбивка по гео) или несколько продуктов (например iOS vs Android) здесь уже начинают размазываться – и можно принимать решение, куда перенаправить усилия, ресурсы

Вопрос от подписчика:

Кстати расскажешь как-нибудь какими тулзами аналитическими пользуешься?

Стек стандартный:

1. Аналитика/тренды в родном кабинете App Store Connect

2. Amplitude для ивентов внутри приложения (in-app воронка, ивенты, сессии пользователей, популярность фичей)

3. Adapty - для revenue management (конверсии, ARPU, ARPPU, выручка, MRR и остальное)

4. База данных в Supabase + своя кастомная аналитика в Datalens поверх. В Cursor настроен Supabase MCP, регулярно пользуюсь

В o3 последние дни активно кидаю. Помню раньше кидал код в ChatGPT, затем появился Cursor. Думаю в этом году решится вопрос с "Cursor для аналитики", где кроме самостоятельного написания SQL будет в целом коннект с широким пулом аналитических инструментов и ты можешь задавать вопросы как к аналитическому отделу, не переходя самостоятельно в отдельный сервис

Видел в YC пару батчей назад стартап на эту тему

Отличное (при этом достаточно короткое) видео про различные виды оптимизаций стандартного MHA (Multi-Head Attention). В видео рассказывается про MLA (Multi-Head Latent Attention), который был представлен в статье про DeepSeek-V3, помимо MLA кратко рассматриваются более ранние оптимизации механизма внимания: MQA (Multi-Query Attention), GQA (Grouped-Query Attention), а также KV-cache.