Дизайн ML-систем
Сквозной дизайн систем рекомендаций, антифрода, ранжирования поиска, CTR, модерации, дедупликации, churn, чат-бота, матчинга и ETA — от метрики до стоимости обслуживания.
14 вопросов
SeniorДизайнОчень частоВы проектируете предсказание click-through rate для рекламной биржи. Скоринг идёт на примерно 100k запросов в секунду с бюджетом p99 менее 20 мс, поверх миллиардов показов в сутки. Ставка в аукционе считается как математическое ожидание — предсказанная вероятность клика, умноженная на ценность для рекламодателя, — то есть число от модели тратится напрямую. В признаках доминируют разреженные категориальные признаки высокой кардинальности, такие как id объявления, площадка и устройство. Разберите работу с такими признаками, выбор модели для serving и его причины, смысл calibration здесь и частоту переобучения.
Вы проектируете предсказание click-through rate для рекламной биржи. Скоринг идёт на примерно 100k запросов в секунду с бюджетом p99 менее 20 мс, поверх миллиардов показов в сутки. Ставка в аукционе считается как математическое ожидание — предсказанная вероятность клика, умноженная на ценность для рекламодателя, — то есть число от модели тратится напрямую. В признаках доминируют разреженные категориальные признаки высокой кардинальности, такие как id объявления, площадка и устройство. Разберите работу с такими признаками, выбор модели для serving и его причины, смысл calibration здесь и частоту переобучения.
Категории высокой кардинальности сжимают через hashing или embedding. Бюджет 20 мс при 100k QPS склоняет к неглубокой модели вместо ансамбля. Раз ставка умножает вероятность, выход обязан быть calibrated, а не просто ранжированным, и переобучаться ежедневно.
Типичные ошибки
- ✗Считать, что хорошее ранжирование даёт хорошие вероятности, когда оценка умножается в ставку
- ✗Кодировать one-hot категории высокой кардинальности вместо hashing или embedding
- ✗Переобучать редко, пока распределение рекламы сдвигается за считаные дни
Уточняющие вопросы
- →Какой метод calibration — например isotonic regression, монотонную подгонку — вы бы взяли здесь?
- →Как обнаружить дрейф calibration в production раньше, чем сдвинутся цифры выручки?
SeniorДизайнОчень частоВы проектируете антифрод реального времени для карточных платежей. Поток — около 2000 транзакций в секунду, решение должно возвращаться менее чем за 100 мс. Подтверждённый фрод составляет примерно 0,1% объёма, а метки chargeback приходят через 30-60 дней после транзакции и сами по себе шумные. Мошенники адаптируются к тому, что вы выкатили. Есть очередь ручной проверки, но аналитики успевают разобрать ограниченное число кейсов в сутки. Разберите метрику оценки, которую вы будете защищать, обучение и валидацию на отложенных шумных метках, выбор порога решения и то, что вы мониторите после запуска.
Вы проектируете антифрод реального времени для карточных платежей. Поток — около 2000 транзакций в секунду, решение должно возвращаться менее чем за 100 мс. Подтверждённый фрод составляет примерно 0,1% объёма, а метки chargeback приходят через 30-60 дней после транзакции и сами по себе шумные. Мошенники адаптируются к тому, что вы выкатили. Есть очередь ручной проверки, но аналитики успевают разобрать ограниченное число кейсов в сутки. Разберите метрику оценки, которую вы будете защищать, обучение и валидацию на отложенных шумных метках, выбор порога решения и то, что вы мониторите после запуска.
При доле фрода 0,1% accuracy и ROC-AUC льстят модели, не ловящей ничего, поэтому судят по precision и recall в рабочей точке через PR-AUC. Учатся на вызревших метках 30-60 дней, порог задают от ёмкости проверки и цены отказа, а дрейф мониторят постоянно.
Типичные ошибки
- ✗Читать высокие accuracy или ROC-AUC как успех при доле позитивов 0,1%
- ✗Считать поздние метки chargeback доступными в момент скоринга
- ✗Выбирать порог по одной модели, игнорируя ёмкость проверки и цену отказа
Уточняющие вопросы
- →Как заметить адаптацию мошенника раньше, чем это подтвердят метки chargeback?
- →Как оценить цену ложного отказа против пропущенного фрода при выборе рабочей точки?
JuniorТеорияЧастоКаковы стандартные этапы сквозного проектирования ML-системы?
Каковы стандартные этапы сквозного проектирования ML-системы?
Сначала формулируют бизнес-задачу и решение, которое принимает модель, затем фиксируют offline- и online-метрики. Дальше идут данные и разметка, признаки, простой baseline до сложной модели, serving в рамках бюджета задержки и мониторинг с переобучением.
Типичные ошибки
- ✗Переходить к выбору модели до того, как зафиксированы решение и метрика
- ✗Считать задержку serving и мониторинг инфраструктурной работой после запуска
- ✗Пропускать простой baseline, который сложная модель обязана обойти
Уточняющие вопросы
- →Зачем фиксировать online-метрику раньше offline и как их связать между собой?
- →Что даёт baseline кроме числа, которое модель обязана превзойти?
MiddleДизайнЧастоУ подписочного продукта около 3M активных подписчиков с помесячной оплатой. Команда удержания может лично связаться примерно с 5000 пользователей в неделю, а скор модели запускает предложение скидки. Разберите дизайн и большую его часть посвятите метке — как вы определяете горизонт оттока при помесячной оплате, что делаете с пользователями, у которых горизонт ещё не истёк, где ставите отсечку по признакам, чтобы события после неё не утекли в обучение, и как команде удержания на самом деле пользоваться скором, если она охватывает заметно меньше процента базы в неделю.
У подписочного продукта около 3M активных подписчиков с помесячной оплатой. Команда удержания может лично связаться примерно с 5000 пользователей в неделю, а скор модели запускает предложение скидки. Разберите дизайн и большую его часть посвятите метке — как вы определяете горизонт оттока при помесячной оплате, что делаете с пользователями, у которых горизонт ещё не истёк, где ставите отсечку по признакам, чтобы события после неё не утекли в обучение, и как команде удержания на самом деле пользоваться скором, если она охватывает заметно меньше процента базы в неделю.
Отток — нет продления в течение горизонта после списания, а неистёкшие горизонты цензурируем, а не считаем удержанием. Признаки обрываем на дате наблюдения, чтобы поздние события не утекли. Обзвон ранжируем по ожидаемой ценности.
Типичные ошибки
- ✗Помечать удержанными пользователей, у которых горизонт оттока ещё не истёк
- ✗Строить признаки из событий, случившихся после отсечки наблюдения
- ✗Таргетировать обзвон по сырой вероятности оттока вместо ожидаемой ценности
Уточняющие вопросы
- →Какие атрибуты подписчика вероятнее всего утекут меткой оттока при помесячной оплате?
- →Как само предложение скидки портит метки тех пользователей, которых вы обзвонили?
MiddleДизайнЧастоМаркетплейс публикует около 10M пользовательских объявлений в сутки — тексты и изображения. Команда модерации небольшая — несколько десятков аналитиков, каждый разбирает порядка нескольких сотен объектов в день. По худшим категориям законный SLA измеряется минутами. Доля нарушений заметно меньше 1% потока, а новый тип абьюза может появиться за ночь и разойтись за часы. Разберите дизайн — как вы упорядочиваете дешёвые и дорогие проверки, как выбираете пороги авто-блокировки и авто-пропуска и что происходит с серой зоной между ними, как решения аналитиков становятся разметкой и что вы выкатываете в первый день против типа абьюза, которого модель не видела.
Маркетплейс публикует около 10M пользовательских объявлений в сутки — тексты и изображения. Команда модерации небольшая — несколько десятков аналитиков, каждый разбирает порядка нескольких сотен объектов в день. По худшим категориям законный SLA измеряется минутами. Доля нарушений заметно меньше 1% потока, а новый тип абьюза может появиться за ночь и разойтись за часы. Разберите дизайн — как вы упорядочиваете дешёвые и дорогие проверки, как выбираете пороги авто-блокировки и авто-пропуска и что происходит с серой зоной между ними, как решения аналитиков становятся разметкой и что вы выкатываете в первый день против типа абьюза, которого модель не видела.
Каскад — сначала дешёвые правила, затем лёгкая модель, тяжёлая мультимодальная только на выживших. Пороги авто-блока и авто-пропуска ограничивают серую зону для аналитиков, чьи вердикты становятся разметкой. Новый абьюз закрывают правилами.
Типичные ошибки
- ✗Резать одним порогом вместо раздельных границ авто-блока и авто-пропуска
- ✗Гонять дорогую модель по всему потоку, а не по выжившим в каскаде
- ✗Ждать переобучения на новый тип абьюза вместо того, чтобы выкатить правила
Уточняющие вопросы
- →Как ставить порог авто-блока, если ошибочная блокировка несёт юридический риск?
- →Аналитики размечают только серую зону — как это смещает переобученную модель?
MiddleДизайнЧастоЗаказчик приходит ровно с одной фразой — персонализировать главную страницу. У вас квартал инженерного времени и текущая главная, которая показывает всем посетителям одни и те же статичные блоки. Нет ни брифа, ни целевого числа, ни владельца данных. Прежде чем нарисовать хоть один блок ML-дизайна, пройдите по вопросам, которые обязаны задать — кто пользователи и какое решение принимает система, единая метрика успеха (OEC, overall evaluation criterion) и защищающие её guardrail-метрики, какие данные и разметка уже есть, ограничения по latency, стоимости, приватности и команде, и baseline, который модель обязана превзойти.
Заказчик приходит ровно с одной фразой — персонализировать главную страницу. У вас квартал инженерного времени и текущая главная, которая показывает всем посетителям одни и те же статичные блоки. Нет ни брифа, ни целевого числа, ни владельца данных. Прежде чем нарисовать хоть один блок ML-дизайна, пройдите по вопросам, которые обязаны задать — кто пользователи и какое решение принимает система, единая метрика успеха (OEC, overall evaluation criterion) и защищающие её guardrail-метрики, какие данные и разметка уже есть, ограничения по latency, стоимости, приватности и команде, и baseline, который модель обязана превзойти.
Спрашивают, кто пользователи и какое решение принимает система, затем фиксируют одну метрику успеха и guardrail-метрики. Проверяют, какие данные и разметка уже есть, ограничения по latency, стоимости, приватности и команде, и baseline для сравнения.
Типичные ошибки
- ✗Собирать много метрик вместо одной с guardrail-метриками вокруг неё
- ✗Начинать с модели и пайплайна данных до того, как названо решение для пользователя
- ✗Считать, что текущая главная без персонализации — это вообще не baseline
Уточняющие вопросы
- →Как выбрать guardrail-метрики, ловящие вред, который скрывает метрика успеха?
- →Что спросить, если разметки под целевое решение пока вообще не существует?
SeniorДизайнЧастоВас просят построить динамическое ценообразование для маркетплейса примерно с 1M SKU, где цены можно менять раз в сутки. В истории есть только те цены, которые вы реально выставляли, поэтому вы никогда не видите, сколько принесла бы другая цена. Покупатели замечают движение цен, и заметная волатильность стоит реального доверия — в поддержку уже приходят жалобы. Пройдите по тому, что именно вы оптимизируете и чем опасен одноцелевой максимизатор выручки, как вообще получить контрфактические данные, как проводить A/B-тест цен без ущерба доверию, и что произойдёт, когда ваши же цены станут обучающими данными.
Вас просят построить динамическое ценообразование для маркетплейса примерно с 1M SKU, где цены можно менять раз в сутки. В истории есть только те цены, которые вы реально выставляли, поэтому вы никогда не видите, сколько принесла бы другая цена. Покупатели замечают движение цен, и заметная волатильность стоит реального доверия — в поддержку уже приходят жалобы. Пройдите по тому, что именно вы оптимизируете и чем опасен одноцелевой максимизатор выручки, как вообще получить контрфактические данные, как проводить A/B-тест цен без ущерба доверию, и что произойдёт, когда ваши же цены станут обучающими данными.
Оптимизируют выручку с guardrail-метриками удержания — чистый максимизатор выручки эксплуатирует покупателя. В логах нет контрфактов, поэтому цены рандомизируют на малой доле трафика. Тест — со стабильной единицей рандомизации и ограничением шага цены.
Типичные ошибки
- ✗Считать максимум выручки полной целью и игнорировать удержание
- ✗Верить, что одни логи цен показывают доход от невыставленной цены
- ✗Рандомизировать на показ, а не на пользователя, из-за чего цены прыгают у одного покупателя
Уточняющие вопросы
- →Какую долю трафика вы отдадите на рандомизированное исследование цен и почему?
- →Какая guardrail-метрика досрочно остановит A/B-тест ценообразования?
SeniorДизайнИногдаСлужба доставки выполняет около 500k заказов в сутки и показывает клиенту ETA ещё до оформления. Опоздание обходится в разы дороже в возвратах и оттоке, чем такое же по величине опережение. Предсказание обязано укладываться в 50 мс на p99, и есть сигналы длины маршрута, живого трафика, предложения курьеров, истории готовки ресторана и времени суток. Разберите дизайн — какие признаки строите и как отдаёте их в бюджете задержки, почему функция потерь не может быть симметричной, как оцениваете модель, когда RMSE говорит одно, а бизнес другое, и что происходит с обучающими данными, когда курьеры и клиенты начинают реагировать на показанный ETA.
Служба доставки выполняет около 500k заказов в сутки и показывает клиенту ETA ещё до оформления. Опоздание обходится в разы дороже в возвратах и оттоке, чем такое же по величине опережение. Предсказание обязано укладываться в 50 мс на p99, и есть сигналы длины маршрута, живого трафика, предложения курьеров, истории готовки ресторана и времени суток. Разберите дизайн — какие признаки строите и как отдаёте их в бюджете задержки, почему функция потерь не может быть симметричной, как оцениваете модель, когда RMSE говорит одно, а бизнес другое, и что происходит с обучающими данными, когда курьеры и клиенты начинают реагировать на показанный ETA.
Отдаём предпосчитанные признаки маршрута, трафика, предложения и готовки, чтобы держать p99. Учим quantile loss на верхний квантиль — опоздание дороже опережения — и оцениваем по асимметричной стоимости, а не по RMSE. Показанный ETA загрязняет данные.
Типичные ошибки
- ✗Брать симметричную функцию потерь, когда опоздание и опережение стоят разного
- ✗Судить модель по RMSE вместо асимметричной бизнес-стоимости
- ✗Считать залогированные времена доставки независимыми от показанного ETA
Уточняющие вопросы
- →Как выбирать верхний квантиль, на который нацелена pinball loss — асимметричная квантильная функция потерь?
- →Как сохранить несмещённый срез данных вопреки петле обратной связи от показанного ETA?
SeniorДизайнИногдаВы проектируете рекомендательную ленту на главной странице маркетплейса. В каталоге около 50 млн товаров, ленту открывают примерно 20 млн пользователей в сутки, бюджет p99 на серверную сборку одной ленты — около 150 мс. Примерно 30% показов приходится на пользователей менее чем с пятью прошлыми взаимодействиями, и около 10% каталога обновляется каждую неделю. Доступны логи кликов, добавлений в корзину и покупок, а также названия, описания и изображения товаров. Разберите метрику, которую вы оптимизируете online и offline, разделение на candidate generation и ranking, обработку cold start для новых пользователей и новых товаров, и как дизайн укладывается в бюджет стоимости serving.
Вы проектируете рекомендательную ленту на главной странице маркетплейса. В каталоге около 50 млн товаров, ленту открывают примерно 20 млн пользователей в сутки, бюджет p99 на серверную сборку одной ленты — около 150 мс. Примерно 30% показов приходится на пользователей менее чем с пятью прошлыми взаимодействиями, и около 10% каталога обновляется каждую неделю. Доступны логи кликов, добавлений в корзину и покупок, а также названия, описания и изображения товаров. Разберите метрику, которую вы оптимизируете online и offline, разделение на candidate generation и ranking, обработку cold start для новых пользователей и новых товаров, и как дизайн укладывается в бюджет стоимости serving.
Оптимизируют online-метрику, например покупки за сессию, а offline-метрика ранжирования служит прокси. Serving делят на два этапа — дешёвый candidate generation, затем более тяжёлый ranker — чтобы уложиться в 150 мс. Cold start закрывают контентом, а не историей.
Типичные ошибки
- ✗Ранжировать весь каталог на каждый запрос вместо отбора кандидатов
- ✗Считать offline-метрику ранжирования целью, а не прокси для online-метрики
- ✗Полагать, что cold-start пользователей и товары можно обслужить одной историей
Уточняющие вопросы
- →Как разорвать петлю обратной связи, когда лента показывает лишь то, что уже ранжирует высоко?
- →Какой offline-метрике ранжирования — например NDCG, градуированной метрике — вы бы доверяли?
SeniorДизайнИногдаПлощадка объявлений держит около 100M активных листингов с текстом и фото, и примерно 1M новых объявлений в сутки должны проверяться на почти-дубликаты в течение минут после публикации. Сравнивать все пары невозможно — для 100M объектов это порядка 10^16 пар. Размеченного набора дубликатов нет, и вручную его никто не соберёт. Разберите дизайн — как вы представляете текст и изображения, как урезаете пространство кандидатов, чтобы никогда не считать все пары, чем retrieval и как выбираете порог совпадения, и как измеряете качество при полном отсутствии ground truth.
Площадка объявлений держит около 100M активных листингов с текстом и фото, и примерно 1M новых объявлений в сутки должны проверяться на почти-дубликаты в течение минут после публикации. Сравнивать все пары невозможно — для 100M объектов это порядка 10^16 пар. Размеченного набора дубликатов нет, и вручную его никто не соберёт. Разберите дизайн — как вы представляете текст и изображения, как урезаете пространство кандидатов, чтобы никогда не считать все пары, чем retrieval и как выбираете порог совпадения, и как измеряете качество при полном отсутствии ground truth.
Строим embedding по каждой модальности, режем пространство пар блокировкой и ANN-индексом, пересчитывая только кандидатов. Порог берём по выборочной precision. Разметки нет — берём слабые позитивы из перезаливов и бизнес-прокси.
Типичные ошибки
- ✗Считать сравнение всех пар вычислительной задачей вместо того, чтобы его избежать
- ✗Полагать, что размеченный набор дубликатов есть, вместо оценки через выборку
- ✗Брать порог из распределения скоров, а не из измеренной precision на этом срезе
Уточняющие вопросы
- →Как recall ANN-индекса — приближённого поиска ближайших соседей — ограничивает общий recall?
- →Как two-tower энкодер для retrieval изменит генерацию кандидатов против ручных ключей блокировки?
SeniorДизайнИногдаВам нужно спроектировать ML-платформу для команды из 30 дата-сайентистов, у которой около 40 моделей в production. Сейчас несколько команд пересчитывают одни и те же клиентские признаки чуть разной логикой, общей истории экспериментов нет, а каждый деплой делают руками — тот, кто обучил модель. В платформенной команде три инженера, поэтому построить всё невозможно. Пройдите по платформе, которую вы построите — как training и serving придут к одному определению признаков, как эксперименты станут воспроизводимыми, что model registry с CI для моделей обязан проверять до промоушена, как устроен serving и где вы купите, а не построите.
Вам нужно спроектировать ML-платформу для команды из 30 дата-сайентистов, у которой около 40 моделей в production. Сейчас несколько команд пересчитывают одни и те же клиентские признаки чуть разной логикой, общей истории экспериментов нет, а каждый деплой делают руками — тот, кто обучил модель. В платформенной команде три инженера, поэтому построить всё невозможно. Пройдите по платформе, которую вы построите — как training и serving придут к одному определению признаков, как эксперименты станут воспроизводимыми, что model registry с CI для моделей обязан проверять до промоушена, как устроен serving и где вы купите, а не построите.
Feature store делают единым определением для training и serving — именно это убивает training-serving skew. Дальше experiment tracking ради воспроизводимости, model registry с CI, проверяющим данные и модели, и автоматический serving. Commodity покупают.
Типичные ошибки
- ✗Считать training-serving skew багом serving, а не проблемой определения признаков
- ✗Пропускать модель по unit-тестам кода, не проверяя ни данные, ни саму модель
- ✗Строить все компоненты платформы самим силами трёх инженеров
Уточняющие вопросы
- →Какие проверки model CI вы запустите по данным, а не по коду, и почему?
- →Как перевести 40 живых моделей на общий feature store без заморозки разработки?
SeniorДизайнИногдаВы отвечаете за матчинг резюме и вакансий на джоб-борде. Около 5M резюме и около 300k открытых вакансий, обновляемых ежедневно, а рекрутер смотрит только топ-50 кандидатов по вакансии. Единственная разметка — приглашения рекрутеров и факты найма, разреженная и смещённая тем, кого рекрутеры смотрели раньше. Совсем новые вакансии приходят с нулевой историей взаимодействий, а продукт юридически уязвим по вопросам справедливости. Пройдите по архитектуре поиска и ранжирования, по источнику разметки и её смещению, по cold start для новых вакансий и резюме, и по тому, как вы ограничите и проверите справедливость.
Вы отвечаете за матчинг резюме и вакансий на джоб-борде. Около 5M резюме и около 300k открытых вакансий, обновляемых ежедневно, а рекрутер смотрит только топ-50 кандидатов по вакансии. Единственная разметка — приглашения рекрутеров и факты найма, разреженная и смещённая тем, кого рекрутеры смотрели раньше. Совсем новые вакансии приходят с нулевой историей взаимодействий, а продукт юридически уязвим по вопросам справедливости. Пройдите по архитектуре поиска и ранжирования, по источнику разметки и её смещению, по cold start для новых вакансий и резюме, и по тому, как вы ограничите и проверите справедливость.
Сначала retrieval через two-tower encoder, затем переранжирование шортлиста cross-encoder. Разметка из приглашений и наймов разрежена и смещена к прошлому выбору рекрутеров. Cold start закрывают контентными признаками, справедливость — паритетом исходов.
Типичные ошибки
- ✗Гонять одну тяжёлую модель ранжирования по всему корпусу вместо retrieval
- ✗Читать приглашения рекрутеров как объективную релевантность, а не как логи поведения
- ✗Считать, что удаление защищённых атрибутов убирает и само неравенство исходов
Уточняющие вопросы
- →Как строить негативы, если единственный сигнал — приглашение рекрутера?
- →Какую метрику справедливости мониторить для топ-50 рекрутера и почему?
SeniorДизайнИногдаВы проектируете ранжирование поиска для сайта объявлений. Активны около 100 млн объявлений, поиск работает на примерно 500 запросах в секунду, бюджет p95 — около 200 мс. Редакторской разметки релевантности нет и бюджета на массовую разметку тоже — есть только логи кликов и обращений к продавцу, а результаты показываются пользователю одним ранжированным списком. Разберите, откуда берутся метки релевантности, как вы учите ranker подходом learning-to-rank и что выбираете из pointwise, pairwise и listwise, на какой offline-метрике ранжирования вы гейтите модель и на какой online-метрике выкатываете.
Вы проектируете ранжирование поиска для сайта объявлений. Активны около 100 млн объявлений, поиск работает на примерно 500 запросах в секунду, бюджет p95 — около 200 мс. Редакторской разметки релевантности нет и бюджета на массовую разметку тоже — есть только логи кликов и обращений к продавцу, а результаты показываются пользователю одним ранжированным списком. Разберите, откуда берутся метки релевантности, как вы учите ranker подходом learning-to-rank и что выбираете из pointwise, pairwise и listwise, на какой offline-метрике ранжирования вы гейтите модель и на какой online-метрике выкатываете.
Метки берут из неявной обратной связи — клики и обращения к продавцу — с поправкой на position bias плюс небольшой набор асессоров. Учат pairwise или listwise ranker, ведь продукт — упорядоченный список. Гейтят offline по NDCG, выкатывают по доле обращений в A/B-тесте.
Типичные ошибки
- ✗Принимать сырые клики за несмещённую релевантность и пропускать поправку на position bias
- ✗Оптимизировать pointwise-objective, когда продукт — ранжированный список
- ✗Выкатывать по offline-метрике ранжирования, не подтвердив online-метрику
Уточняющие вопросы
- →Как оценить кривую position bias, не ухудшая выдачу, которую видят пользователи?
- →Когда listwise-objective выигрывает у pairwise в семействе подходов learning-to-rank?
SeniorДизайнИногдаКомпания хочет LLM-ассистента поддержки поверх внутренней базы знаний примерно из 50k документов, из которых несколько процентов меняются каждую неделю. Он будет обслуживать около 20k диалогов в сутки при жёстком потолке в несколько центов на диалог. Каждый ответ обязан ссылаться на документ-источник, а пользователь всегда должен иметь возможность позвать живого оператора. Разберите дизайн — делать fine-tuning по базе знаний или retrieval из неё и почему, что мешает ассистенту выдумать ответ, когда диалог эскалируется на человека, как вы оцениваете систему и куда на самом деле уходит стоимость диалога.
Компания хочет LLM-ассистента поддержки поверх внутренней базы знаний примерно из 50k документов, из которых несколько процентов меняются каждую неделю. Он будет обслуживать около 20k диалогов в сутки при жёстком потолке в несколько центов на диалог. Каждый ответ обязан ссылаться на документ-источник, а пользователь всегда должен иметь возможность позвать живого оператора. Разберите дизайн — делать fine-tuning по базе знаний или retrieval из неё и почему, что мешает ассистенту выдумать ответ, когда диалог эскалируется на человека, как вы оцениваете систему и куда на самом деле уходит стоимость диалога.
Делаем retrieval, а не fine-tuning — меняющимся фактам нужен переиндекс, а не переобучение. Ответ заземлён на найденные фрагменты и ссылается на них, слабый retrieval даёт отказ или передачу оператору. Retrieval и groundedness оцениваем раздельно.
Типичные ошибки
- ✗Делать fine-tuning ради фактов, меняющихся еженедельно, вместо retrieval
- ✗Считать уверенно сформулированный ответ заземлённым, не проверив найденные фрагменты
- ✗Мерить только финальные ответы, из-за чего сбои retrieval остаются невидимыми
Уточняющие вопросы
- →Как подбирать число фрагментов, которые подход RAG — retrieval-augmented generation — кладёт в контекст?
- →Ради чего всё ещё делать fine-tuning, если retrieval уже закрывает меняющиеся факты?
