Satel Generation2026-04-21
Разбор технического собеседования: Satel Generation: RAG, evaluation и production ownership
Технический подробный разбор по RAG-пайплайну: архитектура embeddings/поиск, оценка качества, self-hosted LLM и опыт доведения ML-проектов до production.
Этапы
6
Вопросы
8
Практика
8
Кейс простыми словами
Этот собес выглядит как technical deep dive, но внутри есть полноценный enterprise RAG кейс. Интервьюер проверяет, как кандидат режет юридические документы, как выбирает контекст, как оценивает ответы и как доводит систему до production.
Сильная линия ответа строится вокруг пользовательского запроса. API принимает вопрос, проверяет доступ к документам, ищет чанки, ранжирует их, собирает контекст, вызывает self-hosted LLM и возвращает ответ со ссылками или безопасный отказ.
Вторая часть собеса уходит в moderation service. Здесь важно не только назвать BERT, а разложить действие продукта: какие тексты блокируем автоматически, какие отправляем в ручную очередь, как собираем labels и как после запуска понимаем, что модель помогает модераторам.
Карта разбора
6
этапов с вопросами, просадками и сильной структурой ответа.
Быстро подтянуть
4
повторяющихся слабых мест вынесены наверх перед деталями.
Практика
8
связанных вопросов открываются прямо из этапов разбора.
Главные просадки
- Не хватило полного request flow: от вопроса пользователя и прав доступа до ответа с цитатами.
- Chunking был описан правильно, но можно было явнее сказать, какие metadata хранит каждый chunk: документ, версия, раздел, статья, права доступа и ссылка на источник.
- Не хватило конкретного датасета: какие вопросы попадают в golden set, кто размечает релевантные чанки и как часто этот набор обновляется.
- Production signals можно было связать с действиями пользователей: fallback, жалобы, escalation, latency и стоимость ответа.
Этап 1
Legal RAG: документы, чанки и выбор контекста
Что спрашивали
- Интервьюер начал с архитектуры embeddings/retrieval и быстро перешел к юридическим документам: как их резать на чанки и как выбирать контекст после retrieval.
- Проверялось, видит ли кандидат разницу между fixed-size chunking и нарезкой по структуре документа.
Что было хорошо
- Кандидат не остановился на фразе про embeddings и vector DB. В ответе появились юридическая структура, overlap и отдельный reranker.
- Было правильно разделено качество retriever и качество reranker: первый отвечает за попадание нужного чанка в top-K, второй - за порядок.
Где просело
- Не хватило полного request flow: от вопроса пользователя и прав доступа до ответа с цитатами.
- Chunking был описан правильно, но можно было явнее сказать, какие metadata хранит каждый chunk: документ, версия, раздел, статья, права доступа и ссылка на источник.
Сильная структура ответа
- 1Сильнее было бы начать с ingestion: парсим документы, сохраняем структуру, режем по разделам и пунктам, добавляем parent heading и metadata, затем индексируем lexical и dense представления.
- 2После retrieval top-K нужно проговорить reranker, дедупликацию соседних чанков, сбор компактного контекста и правило: если контекст не поддерживает ответ, система возвращает unknown или просит уточнить вопрос.
Этап 2
Оценка качества: retrieval отдельно, answer отдельно
Что спрашивали
- Интервьюер уточнил, как измерять качество RAG: ведение диалога, поиск документов, генерация ответа и инструменты вроде RAGAS.
- Вопрос короткий, но он проверяет, есть ли у кандидата схема диагностики ошибки.
Что было хорошо
- В ответе прозвучало разделение retrieval и generation, а не одна общая метрика качества текста.
- Были упомянуты automated checks и ручная проверка.
Где просело
- Не хватило конкретного датасета: какие вопросы попадают в golden set, кто размечает релевантные чанки и как часто этот набор обновляется.
- Production signals можно было связать с действиями пользователей: fallback, жалобы, escalation, latency и стоимость ответа.
Сильная структура ответа
- 1Сильнее было бы описать regression set: реальные вопросы, релевантные документы и ожидаемые citations. Retriever оценивается recall@k и nDCG, генератор - groundedness, полнота и отсутствие неподдержанных утверждений.
- 2После запуска команда смотрит latency по stage, долю unknown/fallback, thumbs up/down, escalations и выборочную human review. Если деградация появляется в одном stage, команда чинит именно его.
Практика по просадкам
Этап 3
Production serving: FastAPI, Qdrant, ranker и vLLM
Что спрашивали
- Интервьюер попросил рассказать, на чем развернут RAG: API, vector DB, ranker, MLflow, Docker и self-hosted LLM.
- Это проверка не на список инструментов, а на понимание границ сервисов и наблюдаемости.
Что было хорошо
- Кандидат назвал конкретный стек и не спрятал LLM за внешним черным ящиком.
- Self-hosted inference хорошо ложится на legal/enterprise контекст, где важны privacy и контроль данных.
Где просело
- Стек прозвучал местами как перечисление. Можно было связать компоненты в один путь запроса.
- Не хватило явных логов и rollback-контракта: версии embedding model, reranker, prompt/generation config и trace id для анализа ошибок.
Сильная структура ответа
- 1Сильнее было бы пройти запрос по цепочке: FastAPI проверяет доступ, запускает BM25/dense retrieval, ranker переставляет chunks, context builder собирает prompt, vLLM генерирует ответ, API возвращает citations и fallback reason.
- 2Для эксплуатации нужно логировать stage latency, top chunks, версии моделей, ошибки, fallback и feedback. MLflow хранит артефакты, а rollout новой версии идет через regression set и canary.
Практика по просадкам
Этап 4
Ownership story: что именно кандидат доводил до production
Что спрашивали
- После RAG интервьюер спросил, какой ML-проект кандидат доводил до production.
- Это не отдельная техническая карточка для coverage, но важный момент собеса: интервьюер ждет доказательство реального ownership.
Что было хорошо
- Кандидат смог перейти от модели к запуску и опыту эксплуатации.
Где просело
- Такой ответ легко становится слишком общим, если не назвать роль, границы ответственности и измеримый эффект.
Сильная структура ответа
- 1Сильнее было бы дать короткую историю: какая была задача, кто пользовался системой, что кандидат построил сам, как выкатывал, что мониторил, какой эффект получил и какие ограничения остались.
- 2Для RAG или moderation проекта особенно полезно назвать контрольные точки: offline quality threshold, canary, manual review sample, latency SLO и rollback condition.
Этап 5
Moderation service: модель, thresholds и действия продукта
Что спрашивали
- Интервьюер перешел ко второму production deep dive: как устроить BERT-based сервис модерации.
- Проверялось, понимает ли кандидат разницу между score модели и действием продукта.
Что было хорошо
- В ответе появились policy layer, heuristics, DistilBERT inference, JSON input и routing в ручную модерацию.
- Кандидат не ограничился offline классификацией и говорил про реальный сервис.
Где просело
- Можно было четче описать контракт ответа: scores, action, reason, model version и trace id.
- Thresholds нужно связывать с ценой ошибки: auto-block требует высокой precision, а manual review может принимать более широкий uncertain слой.
Сильная структура ответа
- 1Сильнее было бы разложить каскад: быстрые правила обрабатывают очевидные случаи, модель считает scores по классам, decision layer выбирает pass/block/review, а модераторы получают причину попадания в очередь.
- 2В production команда мониторит latency, долю auto-pass/auto-block/review, fallback при ошибках модели, appeal rate и нагрузку на очередь модерации.
Практика по просадкам
Этап 6
Данные, классы и метрики модерации
Что спрашивали
- Финальный технический блок был про классы, источники labels, class imbalance и offline/online метрики.
- Интервьюер хотел увидеть, что кандидат связывает ML-метрики с реальной очередью модераторов.
Что было хорошо
- Кандидат назвал ручную модерацию, открытые датасеты, augmentation и class imbalance.
- В метриках появились recall/F1 и online impact через снижение нагрузки на ручную модерацию.
Где просело
- Не хватило явной taxonomy классов и правил для спорных примеров. Без этого labels будут шумными.
- Online impact лучше считать не только как снижение нагрузки, но и как качество решений: agreement модераторов, appeals, повторные жалобы и safety incidents.
Сильная структура ответа
- 1Сильнее было бы начать с policy taxonomy: какие классы нужны продукту и какое действие запускает каждый класс. Затем собрать данные из ручной очереди, жалоб, обычного контента и hard cases.
- 2Метрики нужно делить по action: для auto-block важна precision, для опасных пропусков - recall, для manual review - hit rate и нагрузка очереди. После запуска команда регулярно размечает свежую audit sample.
Термины
- Chunk
- Фрагмент документа, который retriever может вернуть в контекст. В legal RAG chunk лучше строить по разделам, статьям и пунктам, а не по случайному числу токенов.
- Groundedness
- Проверка, что ответ модели опирается на найденные источники и не добавляет неподдержанные утверждения.
- Reranker
- Отдельный слой, который получает top-K найденных документов или чанков и переставляет их по точной релевантности к запросу.
- Manual review
- Очередь ручной проверки для спорных или рискованных случаев. В модерации она снижает риск автоматических ошибок.
- vLLM
- Inference runtime для LLM, который помогает self-hosted модели отвечать быстрее и стабильнее при batch/online нагрузке.