yoklateknik mülakat
GelişimGeçmiş

AI Engineer Senior Mülakat Soruları

1285 doğrulanmış AI Engineer Senior mülakat sorusu — cevaplarıyla çöz, açıklamalarıyla öğren, gerçek simülasyonda kendini test et.

Gerçek simülasyonu dene →

Örnek sorular

Agents Tool UseZorluk 3
Test sırasında bir agent, birkaç iterasyon boyunca aynı aracı aynı argümanlarla tekrar tekrar çağırıyor ve dönen gözlem de her seferinde değişmiyor, yine de agent nihai bir cevap üretmiyor. Bu en olası nasıl açıklanır ve makul bir çözüm nedir?
  • aBu, tasarımı gereği herhangi bir agent loop için beklenen bir davranıştır ve müdahale gerekmez; değişmeyen bir gözlemle tekrarlanan çağrılar zaman içinde kendiliğinden çözülür.
  • bAracın kendisi non-deterministik olmalı; doğru çalışan bir agent loop, iyi kurulmuş deterministik bir aracı asla birden fazla kez çağırmaz.
  • cAgent muhtemelen bir döngüye takılmıştır; gözlemi yanlış yorumluyor ya da bir durma koşulu eksik. Aynı çağrının tekrarını tespit edip döngüden çıkmak, adım limitinin yanında makul bir çözümdür.✓
  • dBu, modelin context window'unun aşıldığını gösterir ve agent'ın tekrarı bırakmasının tek yolu tamamen farklı bir araca geçmektir.
Açıklama:Değişmeyen bir gözlemle aynı çağrının tekrar tekrar yapılması ve cevaba doğru hiç ilerleme olmaması, agent'ın takıldığının klasik bir işaretidir (ör. gözlemi yanlış okuması ya da bir durma koşulunun eksikliği); sabit bir adım limitinin yanında hedefe yönelik bir tekrar kontrolü faydalı bir çözümdür. Bunu beklenen davranış saymak, aracın non-determinizmine bağlamak ya da context window boyutuna atfetmek tarif edilen belirtiyle örtüşmez.
Agents Tool UseZorluk 3
Bir agent'ın erişebildiği bir delete_customer_account aracı var. Agent loop içinde bu spesifik aracı ele almak için en güvenli tasarım hangisidir?
  • aBunu tıpkı get_customer_info gibi salt-okunur bir araç gibi ele al, çünkü model açısından ikisi de her an isteyebileceği sıradan araç çağrılarıdır.
  • bBu çağrı yıkıcı ve geri döndürülmesi zor olduğundan, okuma araçlarının aksine, çalıştırılmadan önce açık bir insan onayı ya da güçlü bir iş kuralı kontrolü şart koş.✓
  • cModelin yanlışlıkla çağırma olasılığını azaltmak için araca daha uzun ve detaylı bir açıklama ver, çalışma zamanı için herhangi bir güvenlik önlemi ekleme.
  • dAgent'a doğru yapması için sınırsız deneme hakkı vermek üzere, özellikle bu araç için adım limitlerini devre dışı bırak.
Açıklama:Hesap silme gibi yıkıcı ve geri döndürülmesi zor bir eylem, salt-okunur bir aracın ihtiyaç duymadığı ekstra bir çalışma zamanı güvenlik önlemini (onay ya da iş kuralı kapısı) gerektirir; çünkü yanlış bir çağrının sonucu çok daha ağırdır. Sadece daha iyi bir açıklamaya güvenmek, onu bir okuma aracıyla aynı şekilde ele almak ya da adım limitlerini kaldırmak, bu spesifik aracın ihtiyaç duyduğu korumayı sağlamaz.
Agents Tool UseZorluk 3
Ekipler, bir agent'ın araç setini tasarlarken 'okuma' araçlarını (ör. get_order_status) ile 'yazma' veya yan-etkili araçları (ör. cancel_order) neden yaygın olarak birbirinden ayırır?
  • aYazma araçları yanlış çağrıldığında gerçek, bazen geri döndürülemez değişikliklere yol açabilir; bu yüzden en kötü ihtimalde yalnızca yanlış/eski veri döndüren okuma araçlarından daha sıkı güvenlik önlemleri (onay, doğrulama, idempotency) gerektirirler.✓
  • bOkuma araçları her zaman yazma araçlarından daha hızlı çalışır, çünkü veri okumak her implementasyonda veri yazmaktan doğası gereği daha hafif bir veritabanı işlemidir.
  • cModel, şema formatı içinde okuma işlemlerini yazma işlemlerinden teknik olarak ayırt edemez; bu yüzden bu ayrımı uygulamanın kendi kodunda ayrıca takip etmesi gerekir.
  • dYazma araçları, okuma araçlarıyla aynı şema formatı kullanılarak tanımlanamaz, çünkü yan-etkili işlemler temelde farklı bir parametre yapısı gerektirir.
Açıklama:Risk profili farklıdır: yanlış bir okuma sadece hatalı bilgi döndürür, oysa yanlış bir yazma gerçek, bazen geri döndürülemez bir değişikliğe yol açabilir; bu yüzden yazma araçları genellikle onay ve idempotency gibi ekstra güvenlik önlemleri alır. Bu ayrım execution hızıyla ya da şema-format kısıtlamalarıyla değil, risk ve sonuçla ilgilidir.
Agents Tool UseZorluk 3
Bir turda model iki araç çağrısı istiyor: get_weather(city="Paris") ve get_weather(city="Tokyo"); hiçbirinin argümanları diğerinin sonucuna bağlı değil. Ayrı bir senaryoda ise model get_user_id(email=...) istiyor ve ancak daha sonraki bir turda, birinci çağrının döndürdüğü ID'yi kullanarak get_orders(user_id=...) istiyor. Bu iki durum arasındaki temel fark nedir?
  • aGerçek bir fark yoktur; uygulama araç çağrılarını ne olursa olsun kesinlikle birer birer işlediğinden, her çağrı her zaman bir öncekinin bitmesini beklemelidir.
  • bİki get_weather çağrısı kesinlikle birbiri ardına çalıştırılmalıdır ve asla eş zamanlı çalıştırılamaz, çünkü tek bir konuşma turu yalnızca bir bağımsız eylem içerebilir.
  • cget_user_id ve get_orders çağrıları aynı turda güvenle gönderilebilir, çünkü bağımlı çağrıları birlikte gruplamak, eksik girdiden bağımsız olarak her zaman daha verimlidir.
  • dİki get_weather çağrısı birbirinden bağımsızdır ve paralel çalıştırılabilir; get_orders ise get_user_id'nin sonucuna bağlı olduğundan önce o gözlemi beklemelidir.✓
Açıklama:Bağımsız çağrıların (iki hava durumu sorgusu) aralarında veri bağımlılığı yoktur ve potansiyel olarak eş zamanlı çalıştırılabilirler; bağımlı bir çağrı ise (get_orders, kullanıcı ID'sine ihtiyaç duyar) önceki gözlem elde edilene kadar doğru şekilde gönderilemez. Her iki durumu aynı kabul etmek ya da bağımlı bir çağrıyı girdisi henüz yokken gruplamak, bu veri akışı farkını göz ardı eder.
Agents Tool UseZorluk 3
create_shipping_label aracı, dahili olarak üçüncü taraf bir kargo API'sini çağırıyor; bu API, aynı mantıksal isteğe (ör. kargo tarafındaki dahili bir retry nedeniyle) aynı idempotency key ile çağrıldığında bile bazen farklı bir takip numarası döndürüyor. Bu, agent'ın retry mantığı için neden bir sorun?
  • aSorun değildir, çünkü bir idempotency key göndermek, altta yatan kargo servisinin kendi içinde nasıl implemente edildiğinden bağımsız olarak her zaman aynı çıktıyı garanti eder.
  • bSadece agent'ın adım limiti çok düşük ayarlanmışsa önemlidir; bu limiti artırmak, dönen takip numaralarındaki tutarsızlığı tamamen çözer.
  • cAgent loop ile ilgisi yoktur, çünkü aracın determinizmi yalnızca modelin tükettiği muhakeme token sayısını etkiler, gerçekte oluşan hiçbir yan etkiyi değil.
  • dAraç aynı key'e rağmen retry'da hâlâ farklı bir gerçek sonuç üretebiliyorsa, agent'ın güvenlik varsayımı yanlıştır ve retry yapmak fazladan bir sevkiyat gibi mükerrer yan etkilere yol açabilir.✓
Açıklama:Bir idempotency key, ancak altta yatan servis onu tutarlı biçimde gerçekten uyguluyorsa işe yarar; kargo servisi aynı key'e rağmen retry'da farklı bir gerçek-dünya sonucu üretebiliyorsa, agent'ın güvenlik varsayımı yanlıştır ve mükerrer sevkiyatlar oluşabilir. Adım limitini artırmak ya da determinizmin sadece muhakeme token'larını etkilediğini iddia etmek, bu gerçek servis-seviyesi açığı çözmez.
Embeddings Vector SearchZorluk 3
Junior bir mühendis şu benzerlik fonksiyonunu yazıyor:
score = dot(query_vec, doc_vec)

Bu hesaplamadan önce vektörler normalize edilmiyor. Bu ne tür bir soruna yol açabilir?
  • aİki vektörün boyutu farklı olduğunda dot product bir runtime hatası fırlatır.
  • bBüyüklüğü daha fazla olan vektörler, anlamca daha ilgili olmasalar bile daha yüksek skor alarak sıralamayı bozabilir.✓
  • cSonuç, vektör uzunluğundan bağımsız olarak her zaman cosine similarity değerine eşit olur.
  • dİki metin anlamca ilgisiz olduğunda skor her zaman negatif çıkar.
Açıklama:Ham dot product vektör uzunluğuna duyarlıdır; bu yüzden embedding'i büyük büyüklükte çıkan dokümanlar, daha küçük büyüklükteki gerçekten ilgili dokümanları skorla geçebilir. (c) şıkkı bunun tersini anlatır: normalize edilmemiş dot product yalnızca her iki vektör de zaten birim uzunluktaysa cosine similarity'ye eşit olur.

Konular

Agents Tool Use 75Aimlops Deployment Strategies Ml 75Aimlops Experiment Tracking Reproducibility 75Aimlops Feature Store Data Versioning 75Aimlops Ml Cicd Pipelines 75Aimlops Model Monitoring Drift Detection 75Aimlops Model Versioning Registry 75Aipy Async Concurrency Ml Serving 75Aipy Data Pipeline Dataloader 75Aipy Gpu Memory Management 75Aipy Numpy Vectorization Broadcasting 75Aipy Python Ml Packaging Environments 75Aipy Tensor Ops Autograd 75Embeddings Vector Search 75Evaluation Testing 75Fine Tuning Adaptation 75Inference Serving 75Llm Fundamentals 75Prompt Engineering 75Rag Chunking Indexing 75Rag Embeddings Similarity 75Rag Evaluation 75Rag Generation Context 75Rag Reranking Fusion 75Rag Retrieval 75Rag Retrieval Search 75Safety Guardrails 75

Uzmanlığa göre

LLM/RAG 450MLOps 450Python 450

Kıdeme göre

AI Engineer JuniorAI Engineer MidAI Engineer Senior

Diğer alanlar

BackendFrontendFullstackDevOps / CloudVeritabanıMobilGüvenlikQA / Test OtomasyonuData EngineerOyun GeliştirmeML Engineer

2025 soruluk AI Engineer bankasında kendini sına.

Mülakata başla