Вопросы на собеседовании для AI Engineer (2026)
Роль AI engineer новее и менее стандартизирована, чем software или data science, поэтому интервью сильно различаются — но процесс 2026 года обычно исследует основы LLM, retrieval-augmented generation (RAG), prompt и context engineering, оценку, и инженерную работу по надёжной доставке AI-функций. Многие процессы также сохраняют классический раунд по кодингу, так что не игнорируйте структуры данных.
Интервьюеры ищут человека, который понимает и модели, и инжиниринг вокруг них: как трансформеры и attention работают концептуально, как заземлить модель с помощью retrieval, как оценивать недетерминированные системы, и как контролировать задержку и стоимость в продакшене. Расплывчатое 'мы просто вызываем API' — быстрый способ провалиться.
Поскольку область быстро развивается, важнее показать, что вы рассуждаете от первых принципов — и что вы доставляете и измеряете, а не только прототипируете — чем перечислять вчерашние цифры benchmark'ов.
Вопросы на собеседовании для AI Engineer и как на них отвечать
1. Объясните на высоком уровне, как работает attention в трансформере.
Подход: Опишите query/key/value, масштабированное скалярное произведение в attention, и почему self-attention позволяет каждому токену обращать внимание на каждый другой токен — захватывая дальние зависимости, с которыми RNN справляются плохо. Упомяните роль multi-head attention и квадратичную стоимость.
2. Как бы вы спроектировали систему RAG для базы знаний компании?
Подход: Пройдите по пайплайну: стратегия чанкинга, выбор модели эмбеддингов, векторное хранилище, retrieval (top-k, гибрид с keyword), reranking, и сборка промпта. Обсудите перекрытие чанков, обновление устаревших данных, и цитирование источников.
3. Как вы уменьшаете галлюцинации в LLM-приложении?
Подход: Заземлите retrieval'ом, ограничьте структурированными выходами, снизьте temperature для фактических задач, добавьте требования цитирования, и верифицируйте вторым проходом или правилами. Подчеркните оценку: вы не можете уменьшить то, что не измеряете.
4. Как бы вы оценивали недетерминированную функцию LLM?
Подход: Создайте размеченный eval-набор, используйте оценку по рубрике или LLM-as-judge, отслеживайте регрессию при изменениях промпта/модели, и комбинируйте offline-оценки с онлайн-метриками. Упомяните стоимость и смещение LLM-as-judge.
5. Когда вы бы использовали fine-tuning против RAG против prompt engineering?
Подход: Сначала prompt engineering (дешевле, быстрее). RAG для знаний/актуальности. Fine-tuning для поведения, формата, или доменного стиля, которого промптинг не может надёжно достичь. Часто комбинация; обосновывайте стоимостью, задержкой и поддерживаемостью.
6. Как вы контролируете задержку и стоимость в продукте на базе LLM?
Подход: Выбор модели по задаче (маленькие модели для простых ходов), обрезка промпта/контекста, кеширование, стриминг для воспринимаемой задержки, батчинг, и роутинг. Квантифицируйте: меньший контекст и более дешёвая модель могут снизить стоимость на порядок.
7. Какие компромиссы между запуском модели локально и через облачный API?
Подход: Локально: приватность, нет стоимости за токен, offline, но ограничено железом и размером модели. Облако: топовые модели и масштаб, но стоимость, задержка, и данные, уходящие с вашего устройства. Свяжите с use case — именно тот компромисс, вокруг которого построен Natively.
8. Как бы вы выбрали модель эмбеддингов для retrieval?
Подход: Подберите под домен и язык, проверьте бенчмарки типа MTEB, взвесьте размер измерений против хранения/задержки, и валидируйте на СВОИХ данных с помощью eval по retrieval. Не доверяйте leaderboard больше, чем специфичному для домена тесту.
9. Реализуйте простой семантический поиск по набору документов.
Подход: Создайте эмбеддинги документов и запроса, храните векторы, вычислите косинусное сходство (или используйте векторный индекс, например sqlite-vec/FAISS), верните top-k. Обсудите нормализацию и компромисс скорость/точность приближённого поиска ближайших соседей.
10. Расскажите об AI-функции, которую вы выпустили, и как вы измерили её успех.
Подход: STAR. Подчеркните методологию оценки и продакшн-метрику, а не только демо. Ищут AI engineer'ов, которые доставляют и измеряют — а не бесконечно прототипируют.
Получайте помощь в реальном времени на вашем собеседовании AI engineer
Natively сам является local-first AI-приложением — on-device LLM, локальный RAG с sqlite-vec, и архитектура bring-your-own-key. На живом собеседовании по AI engineering он может транскрибировать вопрос и показать точное определение или компромисс в реальном времени на вашем устройстве.
