Интересное что-то
517 subscribers
2.72K photos
253 videos
139 files
4.52K links
Материалы и мысли, понадерганные отовсюду
Блог: https://t.me/asisakov_channel
Чат: https://t.me/youknowds_chat
Download Telegram
Aгент-аналитик для всех и каждого. Кейс компании Ramp.

Чтобы принять решение, нам нужна аналитика. Узнать, что покупали, куда кликали, что читали за прошлый день/месяц/год. Вопросы эти срочные. Отлично, если вы сами умеете в SQL. Хорошо, когда у вас свой аналитик. Ожидаемо, когда вы сделали задачу на аналитику, но не дождались ответа и все решили сами. Вот чтобы такого не было, финтех компания Ramp сделала агента дата-аналитика. Разбираем этот кейс.

Архитектура решения


Канал в Слаке, вы тегаете бота, задаете ему вопрос, агент уходит анализировать. Отвечает вам в треде, в этом же треде ему можно задавать доп. вопросы. Деталей, как работает агент, в посте немного, но все такие решения +- одинаково устроены.

1) Пишем техническую документацию. Для любой базы данных должно быть очевидно, что там лежит. Можно прям примеры запросов к этой базе написать.

2) По этой документации запускаем RAG. Находим релевантные базы данных. В контекст агента отправляем полное описание всех полей в базе. Про это читайте мое 5-е правило.

3) Агент пишет SQL-запросы. Запросы выполняются, результаты работы и ошибки отправляются на вход агенту.

4) Агент рефлексирует: все ли, что спрашивал пользователь он нашел? Если нет, можно еще поискать другие БД в пунте 2 или еще пописать SQL в пункте 3.

5) Если все нашли, формируем финальный ответ, показываем пользователю, ждем нагоняй конструктивную обратную связь.

Вот, кстати, неплохой туториал от Google по Text2SQL системам. Очень похожие идеи.

Бизнес эффект

Вы не оптимизируете работу аналитиков. Нет. Вы упрощаете сотрудникам доступ к информации для принятия решения.

В Ramp этому агенту задают 1500 запросов в месяц, а людям-аналитикам задают 66 запросов. Разница больше, чем в 20 раз. Это все те вопросы, которые люди боялись спрашивать или откладывали в длинный бэклог. Не трогай, это вопрос на новый год!

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

Основная проблема этого кейса

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

1) Дежурный аналитик. Заметьте, что вопросы задаются в канале, а не в личных сообщениях. Если бы босс был я, в канале обязательно был бы дежурный аналитик, у которого обязанность проверять, что в ответах не полная ерунда.

2) Явная проверка. Вы делаете через бота предварительную разведку. Если хотите результаты анализа написать на слайде, делаете задачу на отдел аналитики. Они перепроверяют.

3) Copilot для аналитика. Не даем инструмент всем, а только ускоряем работу аналитиков. Они проверяют, что агент отработал адекватно.

Резюме

Из этого кейса нам нужно вынести 2 урока:

- ИИ это не только про автоматизацию. Это про демократизацию и более широкий доступ. Который в долгую может быть намного важнее.

- Помимо самого ИИ, критически важно, как вы этот ИИ интегрируете и проверяете, что ИИ правильно себя ведет. Весь успех легко перечеркнуть.

Что думаете про этот кейс? Жду ваши мысли и вопросы в комментариях. И пишите в личные сообщения, если хотите разобрать другой AI-проект.

#ai_cases
Forwarded from Yandex for Developers
🚀 Road to Highload: видеопроект о проектировании архитектуры высоконагруженных систем

За годы работы инженеры Яндекс 360 накопили значительный опыт в проектировании и разработке систем, которыми ежедневно пользуются миллионы людей и тысячи предприятий. Мы знаем, что такое highload и отказоустойчивость не из книжек и докладов, а из реальной многолетней практики.

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

В выпусках обсуждаем:

🔴 Серия 1. Функциональные и нефункциональные требования. Как сбор требований помогает создавать надёжные и масштабируемые решения

🔴 Серия 2. Надёжный API. Принципы проектирования API, которые помогут сделать его консистентным, предсказуемым и поддерживаемым

🔴 Серия 3. Крупноблочная архитектура: карта вашей системы. Как выглядит такая модель на практике и как использовать её для эффективной коммуникации с различными командами разработки, вовлечёнными в проект

🔴 Серия 4. Практика. Рост баз данных: от единиц запросов к тысячам. Как правильно организовать работу с БД, чтобы система оставалась стабильной и эффективной

🔴 Серия 5. Практика. Взаимодействие со смежными системами. Сложности, с которыми сталкиваются команды при интеграции с внешними сервисами, и как их предотвратить или минимизировать

Наши разработчики создают Диск, Почту, Телемост, Мессенджер, Календарь и другие знакомые вам сервисы. Ими пользуются более 95 миллионов людей ежемесячно, а сервисы держат нагрузки более 1 миллиона RPS, наши базы данных хранят петабайты метаинформации.

📺 Смотрите проект, чтобы узнать, как создаются одни из крупнейших облачных сервисов в России:

Наш сайт
VK Видео
Ютуб

Подписывайтесь:
💬 @Yandex4Developers
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Душный NLP
Запоздавшие статьи с ICLR 2025 — об ускорении инференса

Конференция ICLR 2025 закончилась давным-давно, но она навсегда в наших сердечках — так много интересного там было. Делимся ещё одной — запоздавшей, но от этого не менее любопытной — подборкой статей с мероприятия.

OstQuant: Refining Large Language Model Quantization with Orthogonal and Scaling Transformations for Better Distribution Fitting

Авторы вводят метрику утилизации пространства квантизации. Для наглядности посмотрите на изображение. Есть некоторый объём, который фактически занимает тензор, и тот объём, который может представлять собой квантизованные значения — красный квадрат на картинке. Если эти два объёма смещены относительно друг друга и не полностью совпадают, то имеет место ошибка. В идеале, если сильно упрощать, распределение тензора должно быть чётко вписано в квадрат объёма квантизации.

На практике этого можно добиваться разными способами вроде Rotation или Smooth. Авторы статьи предлагают при нормализации весов добавить к вращению операцию Smooth. На инференсе всё это ужимается в одну матрицу. Таким образом, можно получить прирост по качеству на 1 п.п. при использовании SpinQuant.

Block Verification Accelerates Speculative Decoding

При сэмплинге мы сэмлируем случайную величину от нуля до единицы из равномерного распределения и сравниваем её с вероятностью принятия. В теории любой токен может оказаться принятым. Авторы статьи предлагают в сэмплинге делать не потокенную верификацию, а поблочную — увеличивать вероятность принятия за счёт того, что на верификацию поступает больший объём информации (изображение 2). Этот метод работает, обеспечивая ускорение в 5–10%.

Antidistillation Sampling

Авторы предлагают настройку, призванную защитить модели от несанкционированной дистилляции. Метод представляет собой добавку к распределению в генерации. В основе — расчёт такой оценки градиентов, которая позволит ухудшить качество дистилляции. Получить эту оценку можно в SFT, с помощью реворд-модели или как-то иначе. Метод реализуется через небольшие сдвиги в логитах — они вычисляются с помощью прокси-модели и аппроксимированного градиента. Это ухудшает обучение «студента» при дистилляции, но почти не снижает эффективность «учителя».

TAID

Хак, призванный решить проблемы mode averaging и mode collapse при дистилляции. Авторы предлагают делать прогрессивную дистилляцию — переходить от SFT «студента» к дистилляции в учителя. Это позволяет сделать распределение более разнообразным. Метод даёт не слишком большой прирост по бенчмаркам, но и реализуется совсем не сложно — нужно добавить всего один параметр на смесь логитов «учителя» и «студента».

MiniPLM

Распределения «учителя» и «студента» можно классифицировать по трём типам:

— «шумные» — высокая уверенность логитов «студента» и низкая у «учителя»;
— «простые» — логиты «студента» сильно приближаются к логитам «учителя»;
— «сложные» — высокая уверенность «учителя», низкая у «студента».

Авторы статьи предлагают выбрасывать «шумные» примеры, ап-семплить «сложные» и даун-семплить «простые». То есть это просто работа с датасетом, которая, однако, уже показывает хороший прирост качества после дистилляции (изображение 3).

Разбор подготовил Роман Горб

Душный NLP
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Душный NLP
QwenLong-L1 и проблемы рассуждающих моделей на длинных контекстах

Сегодня — статья от инженеров из Alibaba Group, которые сделали свою версию Qwen для ризонинга на длинных контекстах. Как сообщают авторы, их разработка сопоставима по качеству с o3, хотя имеет всего 32 миллиарда параметров.

Авторы отмечают, что при обучении модели рассуждения на длинных контекстах могут наблюдаться спады качества на ревордах. Кроме того, при RL возникает недостаточная вариативность примеров для генерации, а KL-лосс получается очень шумным.

Для обучения QwenLong делают интервенции на SFT и RL-стадии. В первом случае заявляется обучение на домене единых контекстов — том же самом, что и RL. На самой RL-стадии применяются RPO и DAPO. Инженеры используют progressive scaling, то есть увеличивают длину контекста по мере обучения. Применяют комбинированный реворд: LLM-as-a-Judge и Rule-Based.

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

При замерах выделили три типа поведения ризонинг-моделей в работе с длинными контекстами:

Grounding. Модель обращается к релевантной информации в длинном контексте, чтобы поддержать рассуждение: «Позвольте сперва ознакомиться с представленным текстом…»
Subgoal Setting. Модель разбивает комплексный вопрос на несколько более мелких, чтобы решать задачу шаг за шагом: «Чтобы разобраться, нам сперва надо…»
Backtracking. Модель обнаруживает ошибки в генерациях и возвращается к ним, чтобы решать их итеративно: «Такой подход не сработает, потому что…»
Verification. Модель систематически валидирует предсказанные ответы, чтобы убедиться в их корректности: «Давайте подтвердим результат, путём…»

Интересно, что на SFT модель чаще демонстрирует разные типы поведения. Однако это не приводит к росту качества ответов. Это значит, что модели недостаточно просто иметь предпосылки к тому или иному образу действия — нужно ещё и тренировать его на RL.

Разбор подготовил Александр Кайгородов

Душный NLP
Please open Telegram to view this post
VIEW IN TELEGRAM
#rl

Вот скажите мне - эволюционные методы это же не рл уже?
Неужели мы наблюдаем возрождение эволюционных стратегий как альтернативы RL? Я помню ту работу 2017 года от OpenAI и Суцкевера в частности "Evolution Strategies as a Scalable Alternative to Reinforcement Learning" (https://arxiv.org/abs/1703.03864), где впервые ES показали себя достойной альтернативой RL. Я сам писал про это в начале 2017 года (https://moocaholic.medium.com/2017-the-year-of-neuroevolution-30e59ae8fe18). Но в мир LLM эти подходы так и не пришли, возможно потому что на миллиардах параметров оно сходу не работало. Свежая работа "Evolution Strategies at Scale: LLM Fine-Tuning Beyond Reinforcement Learning" (https://arxiv.org/abs/2509.24372) устраняет этот пробел. Реализация настолько простая, что непонятно, почему это сделали только в 2025-м...

https://t.me/gonzo_ML_podcasts/936
Forwarded from Quant Valerian
Прочитал книгу Эффективный конфликт

По рекомендации моего товарища Андрея прочёл книгу. Многого не ждал — у меня и эмоциональный интеллект достаточно высокий, и с конфликтами я справляюсь как-то естественно хорошо, и кое-чему успел поучиться в жизни.

Но книга оказалась просто пушкой! Какие-то приёмы я знал, но всё равно извлёк тонну пользы из книги, и вообще я в восторге!

Во-первых, хорошая, стройная теория, прям настоящий фреймворк для разрешения конфликтов. Во-вторых, там есть упражнения! А на сайте их есть ещё, и это супер полезно! В-третьих, многие тезисы сопровождаются ссылками на исследования или на consensus.ai, которым я тоже регулярно грешу пользоваться.

О чем книга?

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

Здесь нет ничего про медиацию конфликтов или про то, что делать, когда к вам пришли подчиненные в ссоре. Не рассматриваются конструктивные конфликты, столь полезные в работе группы.

Что за фреймворк?

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

- Эмоциональная стадия это когда вам нагрубили на эмоциях.
- Показ границ используется, когда ваши личные границы нарушили ненарочно, по незнанию или по глупости.
- Защита границ применяется, когда человек точно понимает, что нарушает ваши границы, но отказывается их уважать. Чаще всего это манипуляция или прямая агрессия.
- Сепарация это последний шанс сохранить отношения. На этой стадии вы находитесь, когда понимаете, что уже готовы пойти на разрыв отношений.

Для кого может быть полезно?

Для всех! Книга рассматривает ситуации от банального хамства в общественном транспорте до манипуляций со стороны руководителя или проблемной подруги. Есть даже кейсы, когда родители передавливают с «когда уже дети?». Моя однозначная рекомендация и оценка 10/10.
Forwarded from Yandex for ML
This media is not supported in your browser
VIEW IN TELEGRAM
🔗 Пошаговый ML от практиков: смотрите мастер-классы с Practical ML Conf 2025

Пока мы готовим видео с докладами, делимся записями мастер-классов. Изначально не планировали их записывать, но на конференции они вызвали ажиотаж. Мы всё поняли и сделали выводы: практический ML должен попробовать каждый.

⚪️ Разбор ошибок при проектировании рекомендательной системы. Сергей Кузнецов, технический руководитель RecSys&Search Platform, МТС Web Services. Смотрите на ютубе и в VK Видео.

⚪️ Оптимизация обучения и инференса моделей для генерации видео на множестве GPU. Мария Ковалёва, ведущий специалист по исследованию данных, Sber AI. Смотрите на ютубе и в VK Видео.

⚪️ Как заменить сложные разметки на LLM. Илья Кацев, руководитель отдела аналитики и метрик, Яндекс Поиск. Смотрите на ютубе и в VK Видео.

⚪️ Генерация сюжетных видео, от анализа инструментов до практического опыта. Екатерина Андрейчук, ML-инженер, X5 Digital. Смотрите на ютубе и в VK Видео.

🔳 Пробуйте, делитесь впечатлениями и оставляйте комментарии. Нам интересно узнать, какой мастер-класс зашёл больше всего.

Подписывайтесь:
💬 @Yandex4ML
📹 @YandexML
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from URBAN MASH (Мария Эрцеговац)
АЛГОРИТМЫ МАРШРУТИЗАЦИИ ДЛЯ НАВИГАЦИОННЫХ СИСТЕМ

Я собрала подборку наиболее часто использованных алгоритмов построения маршрутов. Хочу обратить внимание на 2 наиболее популярных.

1️⃣Contraction Hierarchies (CH) - используется в промышленных навигационных системах (Google Maps, OSRM). После предобработки поиск пути занимает миллисекунды даже на графах с миллионами узлов.

2️⃣Классический A-star - это эвристический алгоритм, который сочетает стоимость пройденного пути и эвристическую оценку до цели. Быстрее Dijkstra, но требует хорошей эвристической функции. Идеален для игр и учебных проектов.

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

Полезные Python-библиотеки
# 1. OSMnx - самый популярный для работы с OSM
import osmnx as ox
G = ox.graph_from_place('Belgrade')
route = ox.shortest_path(G, start, end)

# 2. NetworkX - базовые алгоритмы
import networkx as nx
path = nx.astar_path(G, start, end)

# 3. PySAL - географический анализ
from libpysal import weights

# 4. Scikit-learn - для BallTree
from sklearn.neighbors import BallTree


3️⃣BallTree - фича из МЛ, которая используется для более быстрого поиска нахождения ближайшего узла. Когда мы выгружает сеть дорог, преобразовываем его в граф (ребра + узлы), часто получается так, что наши точки не находятся внутри графа (как в моем примере Скупштина и Калемегдан в Белграде). Основная идея заключается в том, что Ball Tree - это древовидная структура данных, которая рекурсивно разделяет пространство на вложенные сферы ("шары") для эффективного поиска ближайших соседей. Сложность такого поиска O(log N) вместо O(N).

from sklearn.neighbors import BallTree
import numpy as np

# Для поиска ближайших узлов графа к координатам
nodes = np.array([[G.nodes[n]['y'], G.nodes[n]['x']] for n in G.nodes()])
tree = BallTree(nodes, metric='haversine')

def nearest_node(point):
point_rad = np.radians([[point[1], point[0]]])
dist, idx = tree.query(point_rad, k=1)
return list(G.nodes())[idx[0][0]]


Современные API провайдеры маршрутизации

❤️Бесплатные:
🔥OSRM
🔥OpenRouteService
🔥GraphHopper

❤️Платные (с free trial доступом):
🔥Google Maps Directions API
🔥HERE Maps Routing API
🔥MapBox Directions API
🔥TomTom Routing API
🔥Apple MapKit JS

@urban_mash
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥 Карьерный роадмап для продактов или "Как мне стать продактом, будучи оборванцем"

Я провел мини-ресерч в области продакт менеджмента, опросил ряд junior/middle/senior продактов из Авито и других компаний.
В исследовании фокус на пути входа aka "вката" в профессию, а не о самой профессии.

▶️Если кратко, вот основные поинты:
1️⃣Найти работу продактам сложнее, чем техам (CS). Метч по вайбу с руководителем решает
2️⃣Грейд-ап для продактов не настолько прозрачный, как у техов. Зачастую нет матрицы компетенций, или она нечеткая
3️⃣Это изматывающая, эмоционально-ёмкая работа
4️⃣Буткемпы, буткемпы и еще раз буткемпы! Теперь нереально попасть продактом без ДПО в бигтех
5️⃣У продактов отличные компенсации, как ds и выше

Спасибо всем, кто принял участие в ресерче! ❤️

▶️Ссылка на схему

PDF-версия в комментариях к посту
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from VF | Science
👀 Про аудио кодеки в Deep Learning School

Сегодня выложили 2 части лекции и она немножко затянулась, примерно на 100 минут :)

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

Лекцию сделал без глубокого погружения в конкретные работы, зато мы обсудили гораздо больше других мыслей и сохранили интуицию по самым важным идеям и проблемам VQ-VAE моделей. Хотелось сделать лецию с упором на актуальные идеи и дать ровно столько, чтобы вы могли решить, куда стоит углубиться самостоятельно, имея фундамент заложенный после просмотра. Пишите возникающие вопросы в чат курса DLS или мне @varfolomeefff

Предлагаю посмотреть и поделиться мнением под постом. Давно я длинные лекции не читал.

На днях выделю особенно интересные тезисы из лекции в канал и обсужу их. Интуиция на леции правда животрепещущая и есть, о чем поспорить/подумать.

Часть 1: https://youtu.be/4mVfb-mhv9k?si=k9Q2wgtsA1h2DcP0

Часть 2: https://youtu.be/kOS6qHc6K2g?si=Po-jHSLwpeO5LmkZ

#audio #perfomances
Please open Telegram to view this post
VIEW IN TELEGRAM