Вася Сизов | grok ML

Сколько подов нужно сервису?

(часть 3 серии про оценку ML-задач в банке)

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

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

#процессы

ФТ и НФТ: с чего начинается оценка

(часть 2 серии про оценку ML-задач в банке, часть 1 — выше)

Прежде чем оценивать задачу, нужно понять, что мы вообще строим. И тут всё упирается в два типа требований.

• Функциональные требования (ФТ) — какие возможности система даёт пользователю. Пример для RAG-сервиса: «пользователь задаёт вопрос; если есть релевантный фрагмент — система возвращает ответ со ссылкой на источник, если нет — явный ответ "в базе ничего не найдено"».

• Нефункциональные требования (НФТ) — не что система делает, а как хорошо: производительность, надёжность, безопасность, масштабируемость. Пример: SLA, средний и пиковый RPS, требования к безопасности.

Звучит просто, но многое зависит от формулировок. Хорошее требование — это:

• Однозначное и объективное — описывает одну функциональность, без «и ещё хорошо бы».
• Тестируемое — по нему можно написать тест-кейс с проверяемым результатом. Не «работает быстро», а «отвечает за N мс на пиковом RPS».
• Измеримое (особенно для НФТ) — есть метрика или стандарт, на который опираемся.

Зачем такая строгость? На размытом «сделайте умный поиск» нельзя ни спроектировать решение, ни оценить ресурсы.

На старте детализированных требований почти никогда нет. А про процесс оценки — в следующих постах.

#процессы

Большая статья на Хабре: Graph RAG и «Гарри Поттер»

Помните мой эксперимент с графовым RAG на новогодних праздниках? Я наконец собрал всё в большую статью на Хабре. В январе рассказывал про это на нашей внутренней площадке ComDS — теперь выкладываю публично и с кодом.

Если коротко: я написал собственный фреймворк Temporal Graph RAG и проверял его на «Гарри Поттере». На художественном тексте удобно гонять сложные вопросы — например, «перечисли все испытания на пути к философскому камню». А также удобно проверять.

Что внутри:

• как я нарезал текст с учётом границ глав
• чем мой Temporal Graph RAG отличается от Microsoft GraphRAG: временная позиция событий, составной ключ сущности, двухуровневый реранкинг
• весь стек на одной H100: vLLM, Qwen3-30B, bge-m3 на эмбеддинги и реранкинг
• сравнение классического и графового RAG

Читать здесь.

#техпроект #анонс

Бюджетная кампания, или откуда у меня берутся 30 задач разом

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

Сначала про устройство. В банке с точки зрения бизнеса есть несколько ГБЛ — глобальных бизнес-линий. Для простоты — вертикали, крупные стратегические направления:

• Розничный бизнес (РБ)
• Средний и малый бизнес (СМБ)
• Крупный и инвестиционный бизнес (КИБ)

А я работаю в департаменте анализа данных и моделирования — мы делаем все проекты, связанные с ML. Департамент тоже делится по вертикалям: мои команды закрывают СМБ и КИБ.

Теперь сама кампания. Примерно в середине года с бизнеса собираются все потребности в ML-задачах (сейчас, конечно, половина — с приставкой «ИИ», которую я не очень люблю). Дальше задачи спускаются с уровня департамента на управления.

И в какой-то момент передо мной оказывается постоянно меняющийся список из 20–30+ задач, которые надо оценить. И это даже сама кампания не началась.

А оценка — это по сути упрощённый ML System Design, но с ноткой продакта. Про это и будет серия: как из списка задач от бизнеса получаются оценённые проекты, которые можно приоритизировать.

В следующем посте — про ФТ и НФТ. Без них задачу нормально не оценить.

А у вас как прилетают задачи — через нормальный процесс или «надо было вчера»?

#процессы

Также рекомендую посмотреть выступление от моего коллеги Николая Кравченко. С виду простая задача обработки сообщений службы поддержки порождает ворох неочевидных проблем, которые тоже нужно решать. Подробнее на 3:25:23 по ссылке.

Сегодня выступал на Data Fest в гостях у ВТБ. Рассказывал про наш пилот рага для кредитных специалистов. Детали в карточках, подробнее на 3:08:04 по ссылке.