Yapay Zeka Entegrasyonu ve Platform Mühendisliği · Model çağrısı sözleşmeleri

LLM API Entegrasyonu

Model API'si, sağlayıcı davranışını içeride tutan ve veri sınırlarını, hataları, bütçeleri ve sonuç doğuran yeniden denemeleri birlikte test eden uygulama sözleşmesinin arkasında çalışıyor.

Uygulamanızı model API'lerine, ürünün geri kalanının güvenebileceği bir sözleşmeyle bağlıyoruz. Sağlayıcı ayrıntılarını sınırın içinde tutuyor, şemaları, gizli bilgileri, doğrulamayı, yeniden denemeleri, geri dönüşleri, bütçeleri ve hata sinyallerini ayrı ayrı test ediyoruz.

Test edilmiş bir adaptör, açık sağlayıcı sınırları ve ne zaman yeniden deneneceğini, geri dönüleceğini, eskale edileceğini ya da durulacağını gösteren sinyallerle ayrılıyorsunuz.

API sınırını konuşalımUygulama geliştirmeyi inceleyin
LLM API Entegrasyonu illüstrasyonu: bir yapay zeka yeteneğini mevcut kurumsal sistemlere bağlayan ekip

Birlikte çalıştığımız 500'den fazla markadan birkaçı

Tüm referansları gör
  • Amazon
  • İstikbal
  • Desa
  • Teyit.org
  • S Sport Plus

Adımlar, kapılar ve kararı verenler

Çalışma şeklimiz

Önce model çağrısının sözleşmesini tanımlıyoruz. Ardından sağlayıcı davranışının bu uygulama sınırını bozabileceği bütün yolları test ediyoruz.

  1. Model çağrısı sözleşmesini tanımlıyoruz

    Girdi ve çıktı şemalarını, veri sınıflarını, kimlik doğrulamayı, gizli bilgi yollarını, sağlayıcı sınırlarını, hata vakalarını ve her yanıtın tetikleyebileceği uygulama davranışını tanımlıyoruz.

    Yapay zeka desteği
    Mevcut API çağrılarından ilk şema ve veri sınıfı haritasını model hazırlıyor. Uygulama sorumlusu taslağı inceleyip düzeltiyor.
    İnsan onayı
    İzinli veri yolları ve uygulama sözleşmeleri onaylandı mı? Geliştirme başlamadan önce izinli veri yollarını uygulama sorumlunuz onaylıyor.

  2. Sağlayıcıyı tek bir sınırın arkasında tutuyoruz

    Yapılandırılmış çıktı doğrulamasını, hız sınırlarını, önbelleği, yeniden denemeleri, geri dönüşleri ve bütçeleri taşınabilir bir uygulama arayüzünün arkasında topluyoruz. Sağlayıcıya özgü alanlar ürün sözleşmesine dönüşmüyor.

    Yapay zeka desteği
    Sağlayıcı yanıtından kararlaştırdığımız arayüzün dışına çıkan alanları model işaretliyor. Mühendislik lideri her bulguyu inceliyor.
    İnsan onayı
    Uygulama sınırı, içinde tutmak için tasarlandığı sağlayıcı ayrıntılarını gerçekten gizliyor mu? Yayından önce arayüz sınırını mühendislik lideriniz onaylıyor.

  3. Hata yollarını bilerek çalıştırıyoruz

    Temsili akışlarda geçersiz yanıt, zaman aşımı, sağlayıcı hatası, kalite gerilemesi, yük, yedek sağlayıcıya geçiş ve tekrarlanan aksiyon vakalarını çalıştırıyoruz. Her noktada uygulamanın verdiği tepkiyi inceliyoruz.

    Yapay zeka desteği
    Zaman aşımı, yeniden deneme, geçersiz yanıt ve sağlayıcı hatası vakalarını model hazırlıyor. Mühendisler vakaları test setine girmeden önce doğruluyor.
    İnsan onayı
    Yeniden deneme ve geri dönüş yolları, sonuç doğuran işi tekrarlamadan hata verebiliyor mu? Sonuç doğuran bir aksiyonu tekrarlayabilecek her yolu mühendislik lideriniz inceliyor.

  4. Destek ekibinin kullanabileceği sinyalleri kuruyoruz

    Maliyet, latency, hata, yeniden deneme ve şema geçerliliği sinyallerini belgelenmiş destek adımlarına ve adı belli sorumlulara bağlıyoruz. Sağlayıcı ya da sözleşme değiştiğinde izlenecek yol böylece açık kalıyor.

    Yapay zeka desteği
    Kaydedilen maliyet, latency, geçerlilik, yeniden deneme ve hata sinyallerinden destek rehberini model taslaklıyor. Destek sorumluları rehberi inceleyip düzeltiyor.
    İnsan onayı
    Sorumlu kişi değişen sözleşmeyi veya sağlayıcı davranışını fark edip güvenli biçimde müdahale edebiliyor mu? Rehberi ve eskalasyon koşullarını uygulama sorumlunuz kabul ediyor.

Adı konmuş, sizde kalan çıktılar

Elinize geçenler

Teslim seti, ürün sözleşmesini sağlayıcı davranışından ayırıyor ve taşınabilirliğin bittiği noktaları açıkça kaydediyor.

  • Mimari dokümanı

    Uygulama sözleşmesi ve model API şema haritası

    Her model çağrısı için uygulama sözleşmesi, sağlayıcı arayüzü, şemalar, kimlik doğrulama yolu ve hata modeli.

  • Matris

    Onaylı veri akışı ve gizli bilgi sınırı haritası

    Veri, kimlik, gizli bilgiler, loglar, önbellekler ve sağlayıcı çağrıları için ortamlar arasındaki onaylı yollar.

  • Test kanıtı

    Şema, sağlayıcı hatası ve geri dönüş bulguları raporu

    Şema hatası, sağlayıcı sorunu, zaman aşımı, yeniden deneme, yedek sağlayıcıya geçiş, kalite gerilemesi, yük ve tekrarlanan aksiyon vakaları.

  • Playbook

    Maliyet, latency ve sağlayıcı değişikliği destek notları

    İstek bütçelerini, sinyalleri, uyarıları, geri dönüş koşullarını, sağlayıcı değişikliği kontrollerini, destek adımlarını ve sorumluları bir araya getiriyor.

Kapsam ve dürüst sınırlar

Bu çalışmanın size uyduğu durumlar

Prototipte çalışan model çağrısını, çevresindeki uygulama için kararlı ve desteklenebilir bir sınıra dönüştürmeniz gerekiyorsa burada başlıyoruz.

Şu durumlarda iyi bir seçim

  • Prototipteki model çağrısı çalışıyor, ama uygulamanın geri kalanı çıktı, hata ve geri dönüş davranışı için kararlı şemalara güvenemiyor.
  • Hassas veri ve gizli bilgiler birkaç ortamdan geçiyor, ama uygulama sorumlusu her isteğin hangi sağlayıcı sınırında kaldığını gösteremiyor.
  • Latency ve hız sınırı kullanıcı akışını değiştiriyor, ama yeniden deneme ile sağlayıcı değişikliği sonuç doğuran tekrarlı aksiyonları görünür kılmıyor.
  • Prototipte girdi ve çıktı şemaları bulunuyor, ama kimlik doğrulama ve gizli bilgi yolları uygulamanın yönettiği sağlayıcı sınırına bağlanmıyor.
  • Yapılandırılmış çıktı başarılı çağrıda doğrulanıyor, ama yeniden deneme, önbellek, geri dönüş ve bütçeler sağlayıcı hatasında farklı davranıyor.
  • Sözleşme testleri normal yanıtı kapsıyor, ama bozuk çıktı, yedek sağlayıcıya geçiş, yük ve tekrarlı aksiyonlar yeniden üretilemiyor.
  • Maliyet ve latency sinyalleri toplanıyor, ama destek sorumluları bunları rehberdeki geri dönüş, eskalasyon veya durdurma koşuluna bağlayamıyor.

Şu durumlarda başka bir çalışma daha doğru

  • Hassas verinin onaysız bir sağlayıcı sınırından geçmesini istiyorsunuz. Bu veri yolunu sorumlu uygulama ekibiniz onaylamadan geliştirme başlamıyor ve sağlayıcı çağrısı açılmıyor.
  • Tekrarlı aksiyonları test etmeden yeniden deneme ve geri dönüşü güvenli saymak istiyorsunuz. Sonuç doğuran yollar kendi hata kanıtını gerektiriyor.
  • Sürekli production işletimi veya sağlayıcı satın alımı istiyorsunuz. Bu işler ayrıca kapsamlanıyor ve farklı sorumlular gerektiriyor.

Bunlardan biri sizin durumunuza daha yakınsa, buradan başlayın: Uygulama geliştirmeyi inceleyin

AI'ı production'a taşıyan mühendisler

Zeo'nun kod yazıp teslim eden tarafı burası. Kıdemli mühendislerimiz agent, chatbot ve RAG sistemleri geliştiriyor, çevrelerindeki otomasyon ve veri işlerini üstleniyor, sistemler canlıya çıktıktan sonra da işletmeyi sürdürüyor. 2011'den beri 500'den fazla markayla çalıştık.

Bu konuda ürettiğimiz içerikler

YazıCan MutioğluOpenAI Modelleri ve OpenAI API KullanımıYazıSamet ÖzsüleymanR Studio'da ChatGPT Kullanımı ve Bilinmesi GerekenlerYazıYiğit KonurMCP Server Architecture: State Management, Security & Tool OrchestrationVideoYiğit KonurHow to Use ChatGPT and GPT-3 APIs for SEO | Yiğit Konur, Wope

Kullandığımız araçlar

Bu işin arkasındaki araçlar

  • Pydantic AI

    Model çıktısının uygulamanın vaat ettiği şemaya uyduğunu doğruluyoruz

  • Outlines

    En katı vakalarda üretimi decode aşamasında şemayla sınırlıyoruz

  • LiteLLM

    Provider farklarını uygulamadan ayıran ortak contract sınırını kuruyoruz

  • OpenRouter

    Ana model çalışmadığında alternatif provider yolunu test ediyoruz

  • Helicone

    Her çağrının gerçek maliyet, latency ve hata sinyallerini izliyoruz

  • Guardrails AI

    Model çıktısını veri yolu ve secret kurallarına karşı kontrol ediyoruz

Sonraki adım

Önce model çağrısının sözleşmesini tanımlayın

Uygulama sözleşmesini, sağlayıcı kısıtlarını ve yayınla destekten sorumlu kişiyi çalışmaya dahil edin.
Entegrasyonu planlayalım

Karar vermeden önce

Sık duyduğumuz sorular

Entegrasyon başlamadan önce neler hazır olmalı?

Uygulama kullanım senaryosu, girdi ve çıktı sözleşmeleri, veri sınıfları, sağlayıcı kısıtları, kimlik ve gizli bilgi modeli, yük profili, bilinen hata vakaları ve kalite sınırları gerekiyor. İlgili test ortamına ve observability sinyallerine de erişebilmeliyiz.

Sağlayıcı bağımlılığı ne kadar azaltılabilir?

Kullanım senaryosu izin verdiğinde uygulama sözleşmesini sağlayıcıya özgü istek biçiminden ve hata davranışından ayırıyoruz. Model yetenekleri, araç arayüzleri, fiyatlandırma, hız sınırları ve çıktı davranışı yine farklı kalıyor. Soyutlama katmanının tam değiştirilebilirlik sanılmaması için her istisnayı ve taşınabilirlik sınırını kaydediyoruz.

Hangi sinyaller yayına hazır olduğumuzu gösteriyor?

Şemaya uygun yanıt oranını, sağlayıcı hatalarını ve yeniden denemeleri, p95 entegrasyon latency değerini ve başarılı istek başına maliyeti belirlediğimiz sınırlarla karşılaştırıyoruz. Veri sınırı ihlalleri, bozuk sözleşmeler ve tekrarlanan sonuç doğuran aksiyonlar ayrıca inceleniyor. Ortalama değerler kritik bir hata yolunu kapatmıyor.

Sağlayıcı değiştiğinde nasıl ilerliyoruz?

Yeni bir model, API sürümü, hız sınırı veya yanıt biçimi devreye girdiğinde hangi kontrollerin çalışacağını sözleşme testleri ve destek rehberi gösteriyor. Bazı değişiklikler entegrasyon güncellemesi gerektiriyor. Uygulama sınırı farkı bulmayı kolaylaştırıyor, ama sağlayıcılar arasındaki anlamlı farkları ortadan kaldırmıyor.