Pytania na rozmowę kwalifikacyjną dla AI Engineer (2026)
Rola AI engineera jest nowsza i mniej ustandaryzowana niż software czy data science, więc rozmowy kwalifikacyjne bardzo się różnią — ale proces z 2026 roku zwykle bada podstawy LLM, retrieval-augmented generation (RAG), prompt i context engineering, ewaluację, oraz pracę inżynierską potrzebną, by wiarygodnie dostarczać funkcje AI. Wiele procesów zachowuje też klasyczną rundę kodowania, więc nie zaniedbuj struktur danych.
Rekruterzy szukają kogoś, kto rozumie i modele, i inżynierię wokół nich: jak transformery i attention działają na poziomie koncepcyjnym, jak zakotwiczyć model retrievalem, jak oceniać systemy niedeterministyczne, i jak kontrolować opóźnienie i koszt w produkcji. Mgliste 'po prostu wywołujemy API' to szybki sposób na porażkę.
Ponieważ dziedzina szybko się zmienia, ważniejsze jest pokazanie, że rozumujesz z podstawowych zasad — i że dostarczasz i mierzysz, a nie tylko prototypujesz — niż recytowanie wczorajszych wyników benchmarków.
Pytania na rozmowę kwalifikacyjną dla AI Engineer i jak na nie odpowiadać
1. Wyjaśnij, jak działa attention w transformerze, na wysokim poziomie.
Podejście: Opisz query/key/value, scaled dot-product attention, i czemu self-attention pozwala każdemu tokenowi 'zwracać uwagę' na każdy inny token — wychwytując zależności dalekiego zasięgu, z którymi RNN-y mają problem. Wspomnij o roli multi-head attention i kwadratowym koszcie.
2. Jak zaprojektowałbyś system RAG dla bazy wiedzy firmy?
Podejście: Przejdź przez pipeline: strategię chunkingu, wybór modelu embeddingów, vector store, retrieval (top-k, hybrydowy z słowem kluczowym), reranking, i składanie promptu. Omów nakładanie się chunków, odświeżanie nieaktualnych danych, i cytowanie źródeł.
3. Jak redukujesz halucynacje w aplikacji LLM?
Podejście: Zakotwicz retrievalem, ogranicz ustrukturyzowanymi wyjściami, zmniejsz temperature dla zadań faktograficznych, dodaj wymagania cytowania, i weryfikuj drugim przejściem lub regułami. Podkreśl ewaluację: nie można zredukować tego, czego się nie mierzy.
4. Jak oceniłbyś niedeterministyczną funkcję LLM?
Podejście: Zbuduj oznakowany zbiór ewaluacyjny, użyj scoringu opartego na rubryce lub LLM-as-judge, śledź regresję przy zmianach promptu/modelu, i połącz ewaluacje offline z metrykami online. Wspomnij o koszcie i biasie LLM-as-judge.
5. Kiedy zastosowałbyś fine-tuning, a kiedy RAG, a kiedy prompt engineering?
Podejście: Najpierw prompt engineering (najtańszy, najszybszy). RAG dla wiedzy/aktualności. Fine-tuning dla zachowania, formatu, lub stylu domenowego, którego prompting nie osiągnie wiarygodnie. Często kombinacja; uzasadnij kosztem, opóźnieniem i łatwością utrzymania.
6. Jak kontrolujesz opóźnienie i koszt w produkcie LLM?
Podejście: Wybór modelu według zadania (małe modele dla łatwych odpowiedzi), przycinanie promptu/kontekstu, cachowanie, streaming dla odczuwanego opóźnienia, batching, i routing. Skwantyfikuj: mniejszy kontekst i tańszy model mogą zmniejszyć koszt o rząd wielkości.
7. Jakie są trade-offy uruchamiania modelu lokalnie vs przez API w chmurze?
Podejście: Lokalnie: prywatność, brak kosztu za token, offline, ale ograniczone sprzętem i rozmiarem modelu. Chmura: modele najwyższej klasy i skala, ale koszt, opóźnienie, i dane opuszczające twoje urządzenie. Połącz z przypadkiem użycia — to właśnie trade-off, na którym zbudowane jest Natively.
8. Jak wybrałbyś model embeddingów do retrievalu?
Podejście: Dopasuj do domeny i języka, sprawdź benchmarki w stylu MTEB, zważ rozmiar wymiarów względem przechowywania/opóźnienia, i zwaliduj na WŁASNYCH danych ewaluacją retrievalu. Nie wierz leaderboardowi bardziej niż testowi specyficznemu dla domeny.
9. Zaimplementuj proste wyszukiwanie semantyczne na zbiorze dokumentów.
Podejście: Zrób embedding dokumentów i zapytania, przechowuj wektory, oblicz podobieństwo kosinusowe (lub użyj indeksu wektorowego jak sqlite-vec/FAISS), zwróć top-k. Omów normalizację i trade-off szybkość/dokładność przybliżonego najbliższego sąsiada.
10. Powiedz mi o funkcji AI, którą wdrożyłeś, i jak zmierzyłeś jej sukces.
Podejście: STAR. Podkreśl metodologię ewaluacji i metrykę produkcyjną, nie tylko demo. Szuka się AI engineerów, którzy dostarczają i mierzą — a nie prototypują bez końca.
Zyskaj pomoc w czasie rzeczywistym na swojej rozmowie kwalifikacyjnej na AI engineer
Natively samo jest aplikacją AI local-first — LLM-y on-device, lokalny RAG z sqlite-vec, i architektura bring-your-own-key. Podczas rozmowy na stanowisko AI engineer na żywo może transkrybować pytanie i wyświetlić precyzyjną definicję lub trade-off w czasie rzeczywistym, na twoim urządzeniu.
