Питання на співбесіді AI Engineer: 28 питань з відповідями
На співбесіді AI Engineer перевіряють, чи розумієте ви, як працюють великі мовні моделі та де вони помиляються, чи вмієте отримати від моделі надійну структуровану відповідь, зібрати пошук за документами (RAG) та агента з інструментами, а головне — виміряти якість результату й захистити систему від зловживань. Нижче — 28 питань з короткими відповідями за сімома темами, п'ять практичних задач з кодом на Python, типові помилки кандидатів і план підготовки на два тижні.
AI Engineer у цій статті — інженер, який будує продукти на основі готових моделей: чат-асистентів, пошук за базою знань, агентів, автоматизацію процесів. Це не те саме, що ML Engineer, який навчає та розгортає моделі, хоча на співбесідах теми частково перетинаються. Список питань — авторський добір за темами, які повторюються у вакансіях і на технічних інтерв'ю, а не рейтинг за частотою.
Приклади коду запущено на Python 3.12.2, вони використовують лише стандартну бібліотеку; вивід у коментарях — реальний. Виклики моделей у задачах замінено простими функціями-заглушками, щоб код можна було запустити без ключів API. Назви моделей і ціни провайдерів змінюються кожні кілька місяців, тому в статті їх немає: перевіряйте актуальні дані в документації провайдера.
Як проходить співбесіда AI Engineer?
Зазвичай відбір складається з тих самих етапів, що й у розробника: скринінг з рекрутером, технічне інтерв'ю, практичне завдання та фінальна зустріч з командою. Відмінність у змісті: замість алгоритмічних задач частіше дають завдання, пов'язане з моделлю, — зібрати невеликий RAG, написати виклик з перевіркою відповіді або розібрати, чому агент поводиться неправильно. Склад етапів залежить від компанії, уточнюйте його в рекрутера.
| Етап | Що перевіряють | Як готуватися |
|---|---|---|
| Скринінг з рекрутером | Досвід з LLM, мотивацію, очікування щодо зарплати та формату роботи, англійську | Розповідь про себе та один AI-проєкт за дві хвилини, заздалегідь продумана вилка |
| Технічне інтерв'ю | Розуміння LLM, RAG, агентів, оцінки якості та безпеки; Python і роботу з API | Проговорити вголос відповіді на питання з цієї статті та прив'язати кожну до свого проєкту |
| Практичне завдання | Уміння зібрати робочий пайплайн і перевірити його результат | Розв'язати п'ять задач з цієї статті; для тестового — README з архітектурою, набором тестових запитань і результатами |
| Фінальна зустріч | Як ви ухвалюєте рішення, пояснюєте обмеження моделі бізнесу, працюєте в команді | Приклади: де модель помилялася, як ви це виявили і що змінили |
Про зарплатні очікування краще говорити з цифрами під рукою: медіанні зарплати за рівнями та порівняння з ML Engineer і Data Scientist зібрано на сторінці зарплати AI-інженерів. Що таке агент і як він влаштований, докладно розібрано в статті що таке AI-агент.
Які теми перевіряють на Junior і Middle?
На рівні Junior перевіряють розуміння LLM, промптингу та RAG і вміння написати робочий код навколо моделі; на Middle — рішення в продакшені: оцінку якості, вартість, затримку та безпеку. Межа умовна: у таблиці вказано рівень, починаючи з якого тему зазвичай питають усерйоз.
| Тема | Що перевіряють | Рівень |
|---|---|---|
| Як працюють LLM | Токени, контекстне вікно, параметри генерації, галюцинації | Junior |
| Промптинг | Системні інструкції, приклади в промпті, структурований вивід і його перевірка | Junior |
| RAG | Ембединги, нарізання на чанки, векторний і гібридний пошук | Junior; реранкінг і оцінка пошуку — Middle |
| Агенти | Виклик інструментів, цикл агента, обмеження, MCP | Junior — концепції; Middle — проєктування |
| Якість і продакшен | Набори тестових запитань, логування, вартість, затримка, обробка помилок API | Middle |
| Безпека | Prompt injection, персональні дані, права інструментів | Junior — поняття; Middle — захист |
| Основи ML | Вибірки, перенавчання, fine-tuning | Junior |
Як працюють LLM
З цього блоку починається майже будь-яке інтерв'ю: без розуміння механіки моделі неможливо пояснити, чому вона помиляється.
Як велика мовна модель генерує текст?
Модель отримує на вхід послідовність токенів і передбачає розподіл імовірностей для наступного токена. Обраний токен додається до входу, і крок повторюється, доки модель не згенерує ознаку кінця або не впреться в ліміт довжини. Більшість сучасних LLM побудовано на архітектурі трансформера, описаній у статті «Attention Is All You Need».
Що хочуть почути: модель не «шукає відповідь у базі», а продовжує текст найімовірнішим чином. Звідси і її сильні сторони, і галюцинації.
Що таке токен і чому це важливо?
Токен — одиниця тексту, з якою працює модель: слово, частина слова або знак. Довжину запиту, ліміт контексту та вартість виклику рахують у токенах, а не в символах. Той самий текст різними мовами займає різну кількість токенів, тому вартість і ліміти варто перевіряти на реальних даних проєкту.
Що таке контекстне вікно і що буде, якщо його перевищити?
Контекстне вікно — максимальна кількість токенів, яку модель враховує за один виклик: системна інструкція, історія діалогу, знайдені документи та сама відповідь. Якщо входу більше, API поверне помилку або частину тексту доведеться відкинути. Навіть у межах вікна довгий контекст дорожчий, повільніший і не гарантує, що модель помітить важливу деталь посередині.
Що хочуть почути: рішення для довгих даних — пошук потрібних фрагментів (RAG), сумаризація історії, обрізання зайвого, а не «взяти модель з більшим вікном».
Що роблять параметри temperature і top_p?
Обидва параметри керують випадковістю вибору наступного токена. Низька temperature робить відповіді передбачуванішими й підходить для видобування даних і класифікації; висока — різноманітнішими, що корисно для генерації ідей. top_p обмежує вибір токенами, сумарна ймовірність яких не перевищує заданий поріг. Зазвичай змінюють один із параметрів, а не обидва одразу.
Чому модель галюцинує і як це зменшити?
Модель генерує правдоподібний текст, а не перевірений факт, тому за браку знань вона може впевнено вигадати відповідь. Знизити ризик допомагають: передавання потрібних фактів у контексті (RAG), інструкція відповідати лише за джерелами та визнавати незнання, посилання на джерела у відповіді, перевірка формату й фактів кодом, набір тестових запитань для регулярної перевірки.
Що таке ембединг?
Ембединг — вектор чисел, у який модель перетворює текст так, що близькі за змістом тексти отримують близькі вектори. Ембединги використовують для семантичного пошуку, кластеризації, пошуку дублікатів і рекомендацій. Близькість векторів зазвичай вимірюють косинусною подібністю — приклад є в практичній задачі 2.
Промптинг і структурований вивід
Блок про те, як отримати від моделі передбачуваний результат, який можна обробити кодом.
Чим системна інструкція відрізняється від повідомлення користувача?
Системна інструкція задає роль, правила та формат відповіді для всього діалогу; повідомлення користувача — конкретні запити. Правила, які не повинен змінювати користувач, тримають у системній частині. Але це не межа безпеки: модель може виконати інструкцію з тексту користувача, тому критичні обмеження перевіряють кодом поза моделлю.
Що таке few-shot і коли він потрібен?
Few-shot — кілька прикладів «вхід → очікуваний вихід» просто в промпті. Приклади пояснюють формат і стиль точніше, ніж опис словами, й особливо допомагають у класифікації та видобуванні даних. Мінуси — більше токенів на кожен виклик і ризик, що модель почне копіювати особливості прикладів, тому приклади добирають різноманітними.
Як отримати від моделі відповідь у форматі JSON?
Описати потрібну схему в інструкції та, якщо провайдер це підтримує, увімкнути режим структурованого виводу, за якого API обмежує відповідь заданою JSON-схемою. У будь-якому разі відповідь перевіряють кодом: парсять, звіряють поля й типи, а в разі помилки повторюють запит з текстом помилки або повертають зрозумілу відмову. Приклад перевірки — практична задача 3.
Що хочуть почути: відповіді моделі не можна довіряти без валідації, навіть якщо «зазвичай вона правильна».
Коли досить промпта, коли потрібен RAG, а коли fine-tuning?
Промпт — перший крок: він дешевий і швидко змінюється. RAG потрібен, коли моделі бракує знань — внутрішніх документів, свіжих даних, інформації про конкретного клієнта. Fine-tuning, тобто донавчання моделі на своїх прикладах, застосовують, коли треба закріпити формат, стиль або вузьку навичку, а промпт і приклади не дають стабільного результату. Нові факти надійніше «навчити» через RAG: їх простіше оновлювати й показувати джерело.
RAG, ембединги та векторний пошук
RAG — найчастіша архітектура у вакансіях AI Engineer, тому цей блок питають докладно.
Що таке RAG і з яких кроків він складається?
RAG (Retrieval-Augmented Generation) — генерація відповіді з опорою на знайдені документи. Підготовка: документи ріжуть на фрагменти (чанки), для кожного рахують ембединг і зберігають у векторному сховищі. Під час запиту: рахують ембединг питання, знаходять найближчі чанки, передають їх моделі разом із питанням та інструкцією відповідати за цими джерелами.
Як вибрати розмір чанка і навіщо потрібне перекриття?
Надто малий чанк втрачає контекст, надто великий — розмиває зміст ембединга й витрачає токени. Розмір добирають за типом документів і перевіряють на тестових запитаннях; часто ріжуть за структурою — розділами, абзацами, а не за фіксованою кількістю символів. Перекриття повторює кінець попереднього чанка на початку наступного, щоб думка на межі не загубилася. Код — практична задача 1.
Чим векторний пошук відрізняється від повнотекстового і що таке гібридний пошук?
Повнотекстовий пошук знаходить збіги слів і добре працює з артикулами, іменами та точними термінами. Векторний шукає близькість за змістом і знаходить відповідь, навіть якщо слова в питанні інші. Гібридний пошук об'єднує результати обох підходів, щоб не втрачати ні точні збіги, ні змістові.
Що таке реранкінг?
Реранкінг — другий етап пошуку: з перших кількох десятків кандидатів окрема, точніша, але повільніша модель вибирає та впорядковує найрелевантніші. Так перший етап лишається швидким, а в контекст моделі потрапляють найкращі фрагменти.
Як зрозуміти, що RAG працює погано, і де шукати проблему?
Помилку ділять на дві частини: пошук не знайшов потрібний фрагмент або модель неправильно використала знайдене. Пошук перевіряють окремо: для набору питань заздалегідь позначають правильні документи й рахують, у скількох випадках вони потрапили у видачу. Генерацію перевіряють за знайденими фрагментами: чи спирається відповідь на джерело і чи відповідає на питання.
Що хочуть почути: «покращити промпт» — не перший крок. Спочатку треба виміряти, на якому етапі втрачається якість.
Почати з практики AI-інструментів
На курсі AI Automation у Prog Academy розбирають промпт-інжиніринг і кастомних GPT-асистентів, роботу з NotebookLM, автоматизацію на Make і n8n, Telegram-ботів з AI, Claude Code та OpenAI Codex. Це курс із прикладної роботи з AI-інструментами без програмування, а не з навчання моделей.
Програма курсу AI Automation →AI-агенти та виклик інструментів
Блок про системи, де модель не лише відповідає, а й виконує дії. Докладніше про види агентів — у статті що таке AI-агент, покроковий приклад на Python — у статті як створити AI-агента на Python.
Чим AI-агент відрізняється від workflow з LLM?
У workflow послідовність кроків задає розробник: наприклад, класифікувати лист, потім видобути дані, потім записати в CRM. В агенті модель сама вирішує, який інструмент викликати наступним і коли задачу виконано. Workflow передбачуваніший, дешевший і простіший у тестуванні, тому агента обирають, коли кроки заздалегідь невідомі.
Що хочуть почути: агент — не мета сама по собі. Добра відповідь починається з питання, чи не можна розв'язати задачу простим фіксованим пайплайном.
Як працює виклик інструментів (tool calling)?
Розробник передає моделі опис інструментів: назву, призначення та JSON-схему аргументів. Модель не виконує функцію сама, а повертає запит «виклич такий інструмент з такими аргументами». Код застосунку перевіряє аргументи, виконує функцію та надсилає результат моделі наступним повідомленням. Цикл повторюється, доки модель не дасть фінальну відповідь. Приклад циклу — практична задача 4.
Як обмежити агента, щоб він не наробив зайвого?
Обмежити кількість кроків і час роботи, дати лише ті інструменти й права, які потрібні для задачі, перевіряти аргументи до виконання, вимагати підтвердження людини для незворотних дій — оплати, видалення, надсилання повідомлень. Кожну дію логують, щоб можна було розібрати, чому агент вчинив саме так.
Що таке MCP?
Model Context Protocol — відкритий протокол, через який AI-застосунки підключаються до зовнішніх інструментів і джерел даних за єдиним стандартом. Замість окремої інтеграції під кожен застосунок сервіс реалізує MCP-сервер, а клієнти з підтримкою протоколу отримують доступ до його інструментів. На співбесіді досить пояснити ідею й розуміти, що кожен підключений сервер розширює права системи.
Якість, вартість і надійність
Блок, який відрізняє прототип від продукту: саме його докладно питають на позицію Middle.
Як оцінити якість LLM-застосунку?
Зібрати набір тестових запитань з очікуваними відповідями або критеріями, проганяти його після кожної зміни промпта, моделі чи пошуку й порівнювати результат. Перевірки бувають простими — формат, наявність ключового факту — і складними, коли відповідь оцінює людина або інша модель за заданими критеріями. Приклад найпростішого прогону — практична задача 5.
Що хочуть почути: «подивився кілька відповідей, начебто нормально» — не оцінка. Потрібен повторюваний набір і цифра, яку можна порівняти до і після зміни.
Що логувати в LLM-застосунку?
Вхід і вихід кожного виклику моделі, знайдені документи, виклики інструментів з аргументами й результатами, кількість токенів, затримку, помилки та версію промпта. Це дає змогу відтворити проблемну відповідь, порахувати вартість і знайти повільні кроки. Персональні дані в логах маскують або не зберігають.
Як знизити вартість і затримку?
Скоротити контекст: передавати лише потрібні фрагменти й стискати історію діалогу. Використовувати меншу модель для простих кроків на кшталт класифікації. Кешувати повторювані запити й незмінну частину промпта, якщо провайдер це підтримує. Для користувача затримку зменшує потокова видача відповіді, а для фонових задач — пакетна обробка.
Як обробляти помилки та ліміти API моделі?
Ставити тайм-аути, повторювати тимчасові помилки й відповіді про перевищення ліміту з експоненційною затримкою та обмеженою кількістю спроб, не повторювати помилки в самому запиті. Для критичних функцій — запасний варіант: інша модель або зрозуміла відповідь користувачу, що сервіс тимчасово недоступний.
Безпека та дані
Блок, який дедалі частіше виділяють в окремий розділ інтерв'ю. Основний довідник з теми — OWASP Top 10 for LLM Applications.
Що таке prompt injection і як від неї захищатися?
Prompt injection — текст, який змушує модель виконати чужі інструкції замість інструкцій розробника. Пряма — користувач пише «ігноруй правила». Непряма — інструкцію сховано в документі, листі чи вебсторінці, які модель читає під час роботи. Повністю виключити її не можна, тому захист будують навколо моделі: мінімальні права інструментів, підтвердження людиною небезпечних дій, перевірка вихідних даних кодом, розділення довірених інструкцій і зовнішнього контенту.
Що хочуть почути: системна інструкція «не виконуй чужих команд» сама по собі не захищає. Захищають обмеження, які діють незалежно від того, що відповіла модель.
Як працювати з персональними та конфіденційними даними?
Надсилати моделі лише те, що потрібно для задачі, маскувати персональні дані, перевіряти умови провайдера щодо зберігання й використання даних, розмежовувати доступ до документів у RAG так, щоб користувач не отримав у відповіді фрагмент, який йому не належить бачити.
Основи ML, про які запитають
Навіть якщо ви не навчаєте моделі, базові поняття машинного навчання на співбесіді зазвичай перевіряють.
Чим AI Engineer відрізняється від ML Engineer і Data Scientist?
AI Engineer будує продукти на основі готових моделей: RAG, агентів, інтеграції. ML Engineer навчає, оптимізує та розгортає моделі. Data Scientist досліджує дані, перевіряє гіпотези й будує моделі для конкретних бізнес-задач. Межі в компаніях розмиті, тому обов'язки варто уточнювати за описом вакансії. Як різняться зарплати цих ролей, показано на сторінці зарплати AI-інженерів.
Навіщо ділити дані на навчальну, валідаційну та тестову вибірки?
На навчальній модель вчиться, на валідаційній добирають налаштування, а тестову використовують один раз для чесної підсумкової оцінки. Якщо перевіряти якість на тих самих даних, на яких модель навчалася чи налаштовувалася, результат буде завищено. Той самий принцип працює і для LLM-застосунків: промпт не варто підганяти під той самий набір запитань, за яким ви потім звітуєте про якість.
Що таке перенавчання?
Перенавчання — ситуація, коли модель добре працює на навчальних даних, але погано на нових: вона запам'ятала приклади замість загальної закономірності. Ознака — зростання розриву між якістю на навчальній і валідаційній вибірках. Допомагають більше даних, простіша модель, регуляризація та рання зупинка навчання.
Практичні задачі з розв'язками
Такі задачі дають на live coding або в тестовому завданні: вони короткі, але показують, чи розумієте ви, що відбувається всередині пайплайна. Виклики моделі замінено функціями-заглушками, тому весь код запускається без ключів API.
Задача 1. Як розбити текст на чанки з перекриттям?
Напишіть функцію, яка ріже рядок на фрагменти довжиною size з перекриттям overlap символів.
def chunk(text, size, overlap):
if not 0 <= overlap < size:
raise ValueError("overlap must be in [0, size)")
step = size - overlap
return [text[i:i + size] for i in range(0, max(len(text) - overlap, 1), step)]
print(chunk("abcdefghij", size=4, overlap=1))
# ['abcd', 'defg', 'ghij']
print(chunk("abc", size=4, overlap=1))
# ['abc']
Що хочуть почути: перевірку некоректних параметрів (за overlap >= size цикл ніколи не закінчиться) і розуміння, що в реальному проєкті ріжуть за токенами або за структурою тексту, а не за символами.
Задача 2. Як знайти найближчі документи за ембедингами?
Дано вектор запиту та словник векторів документів. Поверніть k найближчих за косинусною подібністю. У реальному проєкті вектори рахує модель ембедингів, а тут їх задано вручну.
import math
def cosine(a, b):
dot = sum(x * y for x, y in zip(a, b))
norm = math.sqrt(sum(x * x for x in a)) * math.sqrt(sum(y * y for y in b))
return dot / norm if norm else 0.0
def top_k(query, docs, k=2):
scored = [(cosine(query, vec), doc_id) for doc_id, vec in docs.items()]
return sorted(scored, reverse=True)[:k]
docs = {
"refund-policy": [0.9, 0.1, 0.0],
"delivery-times": [0.1, 0.9, 0.1],
"refund-form": [0.8, 0.0, 0.3],
}
for score, doc_id in top_k([1.0, 0.0, 0.1], docs):
print(doc_id, round(score, 3))
# refund-policy 0.989
# refund-form 0.967
Що хочуть почути: на великих обсягах повний перебір замінюють індексом наближеного пошуку у векторній базі даних, а якість видачі перевіряють на тестових запитаннях.
Задача 3. Як перевірити JSON-відповідь моделі?
Модель має повернути об'єкт з полями intent (рядок) і priority (ціле число). Напишіть перевірку, яка повертає дані або зрозумілу помилку.
import json
REQUIRED = {"intent": str, "priority": int}
def parse_reply(raw):
"""Повертає (data, None), якщо відповідь моделі валідна, інакше (None, error)."""
try:
data = json.loads(raw)
except json.JSONDecodeError as e:
return None, f"not JSON: {e.msg}"
if not isinstance(data, dict):
return None, "expected a JSON object"
for field, kind in REQUIRED.items():
if not isinstance(data.get(field), kind):
return None, f"field '{field}' must be {kind.__name__}"
return data, None
print(parse_reply('{"intent": "refund", "priority": 2}'))
# ({'intent': 'refund', 'priority': 2}, None)
print(parse_reply('Звісно! Ось JSON: {"intent": "refund"}'))
# (None, 'not JSON: Expecting value')
print(parse_reply('{"intent": "refund", "priority": "high"}'))
# (None, "field 'priority' must be int")
Що хочуть почути: текст помилки можна повернути моделі для повторної спроби з обмеженою кількістю повторів, а для складних схем використовують бібліотеку валідації, наприклад Pydantic.
Задача 4. Як влаштований цикл агента з інструментами?
Зберіть цикл: модель або просить викликати інструмент, або дає відповідь. Модель тут — заглушка із заздалегідь заданою поведінкою.
def get_order_status(order_id):
return {"order_id": order_id, "status": "shipped"}
TOOLS = {"get_order_status": get_order_status}
def fake_model(messages):
"""Замінює LLM: спершу просить інструмент, потім відповідає."""
if messages[-1]["role"] == "user":
return {"tool": "get_order_status", "args": {"order_id": "A-17"}}
return {"answer": f"Замовлення відправлено: {messages[-1]['content']['status']}"}
def run_agent(question, max_steps=5):
messages = [{"role": "user", "content": question}]
for _ in range(max_steps):
reply = fake_model(messages)
if "answer" in reply:
return reply["answer"]
tool = TOOLS.get(reply["tool"])
if tool is None:
raise ValueError(f"unknown tool: {reply['tool']}")
messages.append({"role": "tool", "content": tool(**reply["args"])})
raise RuntimeError("step limit reached")
print(run_agent("Де моє замовлення A-17?"))
# Замовлення відправлено: shipped
Що хочуть почути: обмеження кількості кроків, обробку невідомого інструмента та перевірку аргументів до виконання функції.
Задача 5. Як зробити простий прогін набору тестових запитань?
Для кожного запитання перевірте, чи містить відповідь очікуваний факт, і порахуйте підсумок.
cases = [
{"question": "Скільки днів на повернення?", "expected": "14"},
{"question": "Чи є доставка до Польщі?", "expected": "так"},
{"question": "Який телефон підтримки?", "expected": "0 800"},
]
def answer(question):
"""Замінює RAG-пайплайн, який тестуємо."""
return {
"Скільки днів на повернення?": "Повернути товар можна протягом 14 днів.",
"Чи є доставка до Польщі?": "Ні, лише по Україні.",
}.get(question, "Не знаю.")
passed = 0
for case in cases:
reply = answer(case["question"])
ok = case["expected"].lower() in reply.lower()
passed += ok
print("PASS" if ok else "FAIL", case["question"], "->", reply)
print(f"{passed}/{len(cases)}")
# PASS Скільки днів на повернення? -> Повернути товар можна протягом 14 днів.
# FAIL Чи є доставка до Польщі? -> Ні, лише по Україні.
# FAIL Який телефон підтримки? -> Не знаю.
# 1/3
Що хочуть почути: перевірка підрядком — найгрубіша. Наприклад, очікуване «так» знайшлося б і всередині слова «також». Тому для вільних відповідей використовують критерії оцінки та перевірку людиною або іншою моделлю, а сам набір запитань зберігають поруч із кодом і проганяють за кожної зміни.
Типові помилки кандидатів
- Немає оцінки якості. Кандидат розповідає про проєкт, але не може сказати, як перевіряв, що відповіді правильні.
- Модель як джерело істини. Відповідь моделі використовують без перевірки формату й фактів.
- Агент там, де вистачить пайплайна. Складна архітектура без пояснення, навіщо вона потрібна.
- Безпека — «у промпті». Захист від prompt injection зводиться до фрази в системній інструкції.
- Немає цифр щодо вартості. Кандидат не знає, скільки токенів і грошей витрачає один запит у його проєкті.
- Проєкт з туторіалу без змін. На питання «чому так» немає відповіді, бо рішення ухвалював автор туторіалу.
Які запитання поставити інтерв'юеру?
- Які AI-функції вже працюють у користувачів, а які поки в розробці?
- Як команда оцінює якість відповідей і як часто проганяє тести?
- З якими моделями та провайдерами ви працюєте і хто ухвалює рішення про зміну моделі?
- Як влаштовано доступ до даних і які обмеження щодо їх передавання зовнішнім провайдерам?
- Які задачі будуть у мене в перші три місяці?
- Які наступні кроки після цієї співбесіди і коли чекати на відповідь?
План підготовки на два тижні
Двох тижнів по одній-дві години на день вистачає, щоб повторити теми й натренувати відповіді вголос, — за умови, що Python і роботу з API ви вже знаєте. Це орієнтир, а не норматив: підлаштовуйте план під свої слабкі місця.
| Дні | Тема | Що зробити |
|---|---|---|
| 1–2 | Як працюють LLM | Своїми словами пояснити токени, контекстне вікно, temperature та причини галюцинацій |
| 3–4 | Промптинг і JSON | Написати виклик моделі з перевіркою структурованої відповіді та повтором у разі помилки |
| 5–7 | RAG | Зібрати RAG за реальною документацією: чанки, ембединги, пошук, відповідь із посиланням на джерело |
| 8–9 | Агенти | Зробити агента з двома інструментами, лімітом кроків і логуванням кожного виклику |
| 10–11 | Оцінка якості | Скласти 20–30 тестових запитань до свого RAG і порахувати, скільки відповідей правильні |
| 12 | Вартість і безпека | Порахувати токени одного запиту; спробувати непряму prompt injection на своєму проєкті та закрити її |
| 13 | Практичні задачі | Розв'язати п'ять задач з цієї статті з пам'яті, з таймером і вголос |
| 14 | Проєкт і пробне інтерв'ю | Розповісти про проєкт за п'ять хвилин: архітектура, оцінка, обмеження; пройти пробну співбесіду |
Якщо ви лише обираєте напрям і хочете зрозуміти, як влаштована прикладна робота з AI без програмування, почніть з гіда по професії AI Automation.
Часті запитання
Чи потрібно AI Engineer знати математику та машинне навчання?
Для більшості вакансій AI Engineer, де будують продукти на основі готових моделей, вистачає розуміння основ: що таке ембединг і косинусна подібність, як модель генерує текст, чим навчальна вибірка відрізняється від тестової. Глибока математика й навчання моделей з нуля — зона ML Engineer і Data Scientist. Вимоги конкретної компанії вказано у вакансії.
Яка мова програмування потрібна AI Engineer?
Найчастіше Python: ним написано основні SDK провайдерів моделей, бібліотеки для роботи з даними та більшість прикладів у документації. У продуктових командах трапляється й TypeScript, особливо якщо AI-функції вбудовано у вебзастосунок. На співбесіді зазвичай перевіряють упевнений Python, роботу з HTTP API та JSON.
Чи буде на співбесіді live coding?
Як правило, так, але задачі відрізняються від класичних алгоритмічних: написати виклик моделі з перевіркою відповіді, розбити текст на чанки, знайти найближчі документи за ембедингами, зібрати простий цикл агента. Формат залежить від компанії, тому уточніть його в рекрутера заздалегідь.
Що показати в портфоліо AI Engineer?
Один-два завершені проєкти кращі за десяток демо: наприклад, RAG-асистент за реальною документацією або агент, який виконує задачу через кілька інструментів. У README варто описати архітектуру, набір тестових запитань, результати оцінки якості та відомі обмеження. На співбесіді запитають, чому рішення влаштоване саме так.
Чи можна користуватися AI-асистентом на співбесіді?
Лише якщо інтерв'юер прямо це дозволив. Для AI Engineer деякі компанії спеціально дають задачу з асистентом і дивляться, як кандидат перевіряє згенерований код. Якщо правила не названо, запитайте на початку. Користуватися підказками таємно не можна.
Чим співбесіда на Middle AI Engineer відрізняється від співбесіди на Junior?
Від Junior очікують розуміння базових понять і вміння написати робочий виклик моделі з перевіркою результату. На Middle питають про рішення в продакшені: як ви оцінювали якість, як знижували вартість і затримку, як захищалися від prompt injection, що робили, коли модель або пошук помилялися в реальних користувачів.
Скільки заробляє AI Engineer в Україні?
Медіанні зарплати AI Engineer за рівнями, за даними зарплатного опитування DOU, зібрано на сторінці «Зарплата AI-інженера в Україні» в розділі зарплат Prog Academy. Там же вказано, скільки відповідей стоїть за кожною цифрою: вибірка за цією посадою поки невелика.
Джерела
- Vaswani et al. Attention Is All You Need (arXiv:1706.03762)
- Lewis et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (arXiv:2005.11401)
- Anthropic: Building effective agents
- Model Context Protocol: documentation
- OWASP Top 10 for LLM Applications
- Python documentation: json — JSON encoder and decoder
- Pydantic documentation
- DOU: Зарплати аналітиків, фахівців з Data Engineering, Data Science, AI, ML — літо 2026
