Çok Modelli API Ağ Geçidinde Yüksek Lisans Gözlemlenebilirliği: İzler, Token Defterleri, Kiracı Analitiği ve Güvenli İstem Günlüğü Kaydı
Çok modelli yapay zeka ağ geçitleri için pratik bir gözlemlenebilirlik mimarisi: her LLM çağrısını bir kez izleyin, telemetriyi belirteç ve maliyet defterleriyle birleştirin, sağlayıcı faturalarını mutabakata varın ve varsayılan olarak ham istemleri saklamadan güvenli bir şekilde hata ayıklayın.
Müşteri bir iş akışının dün neden daha yavaş, daha pahalı veya daha az güvenilir hale geldiğini sorduğunda toplam istek sayıları ve aylık harcama yeterli olmuyor. Çok modelli bir API ağ geçidi, gözlemlenebilirliği kontrol düzleminin bir parçası olarak ele alırsa bu soruyu yanıtlayabilir: her istek bir iz alır, her model çağrısı bir kullanım defterini günceller, her kiracı ve iş akışı ilişkilendirilebilir ve hassas içerik varsayılan olarak korunur.
Bu makalede, OpenAI uyumlu bir API aracılığıyla birden fazla sağlayıcıya öncülük eden bir ağ geçidinde AI kullanım analizi ve LLM gözlemlenebilirliğine yönelik pratik bir tasarım açıklanmaktadır. Bu model, belirli bir satıcı kullanmasanız bile kullanışlıdır: Ağ geçidinde bir kez araç kullanın, model telemetrisini normalleştirin, faturalandırma ilişkilendirmesini koruyun ve yalnızca açık politika kapsamında istem içeriğini yakalayın.
Okuyucu sorunu: "Değişikliğe hangi kiracı, model, bilgi istemi veya alma yolu neden oldu?"
Çoğu ekip sonunda aynı hata ayıklama açığıyla karşı karşıya kalır. Uygulama günlükleri bir özelliğin başarısız olduğunu gösteriyor. Sağlayıcı kontrol panelleri, token kullanımının arttığını gösteriyor. Finans bir yasa tasarısı görüyor. Bu görünümlerin hiçbiri tek başına kiracı talebinden model çağrısına, bilgi alma bağlamına ve faturalandırılan maliyeti yeniden denemeye kadar olan yolun tamamını açıklamaz.
Hedef, toplam jeton içeren başka bir kontrol paneli değil. Amaç aşağıdaki gibi operasyonel soruları yanıtlamaktır:
- Harcamada artışa hangi kiracı veya API anahtarı neden oldu?
- Model takma adı değiştikten sonra gecikme arttı mı?
- Yeniden denemeler veya geri dönüşler çift sayım maliyeti midir?
- Hangi bilgi istemi sürümü en fazla hata bütçesini tüketir?
- RAG iş akışı, alma sırasında çok fazla bağlam belirteci eklendiği için mi pahalı hale geldi?
- Özel kullanıcı istemlerini okumadan bir olayda hata ayıklamayı destekleyebilir misiniz?
Gerçekler, öneriler ve tahminler
Gerçekler: OpenTelemetry, chat, created_content ve text_completion gibi işlem adları da dahil olmak üzere model işlemlerine yönelik Üretken Yapay Zeka semantik kurallarını ve niteliklerini belgelemektedir. Aynı belgeler, GenAI giriş ve çıkış mesajı niteliklerinin hassas bilgiler veya PII içerebileceği ve filtreleme veya kesme gerektirebileceği konusunda uyarıyor. Büyük model sağlayıcıları ayrıca sağlayıcı tarafı mutabakatını destekleyebilecek kullanım kontrol panellerini, API'leri veya dışa aktarmaları da kullanıma sunar, ancak ayrıntılar sağlayıcıya göre farklılık gösterir.
Öneriler: Sağlayıcıdan bağımsız izlemeler için OpenTelemetry'yi kullanın, ancak ağ geçidine ait işletme boyutlarını kendi özelliklerinizde ve defterlerinizde tutun. Ham istemleri veya çıktıları varsayılan olarak saklamayın. Önce meta verileri, karmaları, belirteç sayılarını, bilgi istemi şablonu kimliklerini, şema adlarını, hata sınıflarını ve güvenlik etiketlerini depolayın. İçerik yakalamayı yalnızca isteğe bağlı, erişim kontrollü, kısa süreli hata ayıklama özelliği olarak ekleyin.
Tahmin: LLM gözlemlenebilirliği, yalıtılmış sağlayıcı kontrol panellerinden ziyade, sağlayıcılar arası kontrol düzlemlerine odaklanacak. Ekipler, modeller genelinde gecikmeyi, maliyeti, kaliteyi, politika olaylarını, kiracı davranışını ve faturalandırma değişikliklerini tek bir yerden araştırmayı bekleyecek.
Referans mimarisi: istek yolunun tamamını gözlemleyin
Bir ağ geçidi, her uygulama ekibinin özel telemetri oluşturmasına gerek kalmadan istek yaşam döngüsünün tamamını görebilir. Yararlı bir izleme modeli, gelen müşteri isteği için bir üst aralıkla ve maliyeti, gecikmeyi ve kaliteyi etkileyen adımlar için alt aralıklarla başlar.
Önerilen aralık yapısı
- Ağ geçidi istek aralığı: istek kabul edildi, kimliği doğrulandı, yetkilendirildi, hız sınırlı ve yönlendirildi.
- Model çağrısı aralığı: sağlayıcı, model, işlem, jeton kullanımı, yanıt durumu ve gecikme.
- Alma aralığı: sorgulanan dizin, belge kimlikleri veya karma kimlikler, parça sayısı, alma gecikmesi ve bağlam belirteci paylaşımı.
- Araç çağrı süresi: araç adı, durum, gecikme, hata sınıfı ve yan etki sınıflandırması.
- Yeniden deneme aralığı: yeniden deneme nedeni, deneme numarası, sağlayıcı durumu ve artan maliyet.
- Yedek kapsam: orijinal model, yedek model, tetikleyici, uyumluluk politikası ve nihai sonuç.
- Korkuluk veya denetleme aralığı: çağrılan politika, karar, etiketler ve çıktının engellenip engellenmediği veya dönüştürülüp dönüştürülmediği.
- Son işlem aralığı: JSON doğrulaması, şema onarımı, alıntı kontrolleri veya son biçimlendirme.
Ana aralık kararlı korelasyon tanımlayıcıları taşımalıdır. Çocuk aralıkları normalleştirilmiş teknik nitelikler taşımalıdır. Kullanım defteri, dayanıklı faturalama ve analiz kayıtlarını taşımalıdır. Tüm bilgileri metrik etiketlerine zorlamaktan kaçının; Kiracı kimlikleri, bilgi istemi karmaları ve belge kimlikleri gibi yüksek kardinaliteli değerlerin izlerde, günlüklerde veya genel muhasebe tablolarında saklanması ve ardından kontrol panellerinde toplanması daha iyidir.
Her LLM çağrısında yakalanan meta verileri normalleştirin
Her model isteği, sağlayıcıdan bağımsız olarak tutarlı bir kayıt oluşturmalıdır. Tam şema değişiklik gösterebilir ancak pratik minimum şu şekilde görünür:
<ön>İki fikri ayrı tutun: telemetri ne olduğunu açıklarken, kullanım defteri nelerin ücretlendirilmesi, mutabakatı yapılması ve raporlanması gerektiğini kaydeder. İstek kimlikleri ve izleme kimlikleriyle birbirlerine referans verirler ancak aynı depolama sisteminde yaşamaları gerekmez.
Yalnızca sayaçlar değil, jeton ve maliyet defteri de oluşturun
Jeton sayaçları grafikler için kullanışlıdır ancak faturalandırma veya olay araştırması için yeterli değildir. Bir defter durum geçişlerini temsil etmelidir. Ağ geçidi bir isteği kabul ettiğinde bir satır oluşturun ve istek ilerledikçe bu satırı güncelleyin.
Yararlı defter durumları
- kabul edildi: kimlik doğrulama ve politika kontrolleri başarılı oldu.
- İletildi: istek bir sağlayıcıya gönderildi.
- akış: sağlayıcı jetonları iade etmeye başladı.
- tamamlandı: yanıt başarıyla tamamlandı.
- user_aborted: tamamlanmadan önce istemcinin bağlantısı kesildi.
- yeniden denendi: ek bir sağlayıcı denemesi yapıldı.
- fallback_used: başarısızlık veya politika eşleşmesinden sonra farklı bir model veya sağlayıcı seçildi.
- başarısız oldu: istek, kullanılabilir bir yanıt olmadan sona erdi.
- mutabakat sağlandı: sağlayıcı tarafı kullanımı veya maliyet verileri karşılaştırıldı ve uygulandı.
Bu durum modeli, yaygın faturalandırma ve analiz hatalarının yakalanmasına yardımcı olur: istemcinin bağlantısının kesildiği akışlı yanıtlar, sağlayıcı tarafından ücretlendirilen ancak kullanıcıdan gizlenen yeniden deneme girişimleri, yanlış modeli sayan geri dönüş yolları ve sağlayıcılar arasındaki önbellek hesaplama farklılıkları.
OpenTelemetry GenAI kurallarını kullanın ve ardından dikkatlice genişletin
OpenTelemetry GenAI anlam kuralları, model işlemleri için taşınabilir bir kelime dağarcığı sağlar. İşlem adı, sağlayıcı, model, istek parametreleri, yanıt bitiş nedenleri, belirteç kullanımı ve geçerli oldukları yerlerde hata durumu gibi ortak özellikler için bu kuralları kullanın.
Ancak, sağlayıcıdan bağımsız kurallar bir ağ geçidindeki tüm iş boyutlarını kapsamayacaktır. Aşağıdakiler için ağ geçidine ait özellikleri veya genel muhasebe sütunlarını ekleyin:
- kiracı kimliği, ekip kimliği, bayi müşteri kimliği ve uygulama kimliği;
- ağ geçidi API anahtarı kimliği ve anahtar kapsamı;
- faturalandırma planı, harcama sınırı ve bütçe politikası;
- model takma adı ve yönlendirme politikası sürümü;
- bilgi istemi şablonu kimliği ve bilgi istemi sürümü;
- iş akışı adı ve iş akışı adımı;
- tahmini maliyet, faturalandırılan nihai maliyet ve mutabakat durumu.
Ödünç kardinalitedir. Bu alanlar araştırma açısından değerlidir ancak her yerde metrik etiketi olarak kullanılırsa metrikleri pahalı ve gürültülü hale getirebilirler. Pratik bir kural şudur: düşük kardinaliteli toplamlar metriklere gider; yüksek kardinaliteli tanımlayıcılar izlere, günlüklere ve defterlere gider.
Güvenli bilgi istemi ve çıktı günlüğü tasarlama
Tam istemli günlük kaydı, hata ayıklamayı kolaylaştırır ancak gizliliği, uyumluluğu, depolamayı ve şirket içi risklere maruz kalmayı artırır. Daha güvenli varsayılan, meta veri öncelikli gözlemlenebilirliktir.
Varsayılan: yalnızca meta veriler
Üretim trafiğinin çoğu için şunları depolayın:
- istem şablonu kimliği ve sürümü;
- normalleştirilmiş istemlerin ve çıktıların karmaları;
- giriş, çıkış, önbelleğe alınmış ve bağlam belirteci sayıları;
- yanıt şeması adı ve doğrulama sonucu;
- güvenlik etiketleri ve politika kararları;
- hata özetleri ve sağlayıcı hata sınıfları;
- ham belgeleri değil, meta verileri alın.
Etkinleştirme: kontrollü içerik yakalama
Detaylı hata ayıklama için ham veya düzenlenmiş içeriğe ihtiyacınız varsa açık bir politika isteyin. İyi kontroller arasında ortam izin verilenler listeleri, kiracı izni, örnekleme, maksimum yük uzunluğu, otomatik düzenleme, kısa saklama aralıkları, şifreleme, rol tabanlı erişim, denetim günlükleri ve hassas olaylar için çığır açan bir onay yolu yer alır.
Redaksiyonu mükemmel olarak görmeyin. Riski azaltır; onu ortadan kaldırmaz. Düzenlemeye tabi veya yüksek hassasiyetli iş yükleri için yalnızca karmaları depolamayı ve sorunları onaylanmış test verileriyle sentetik bir donanımda tekrar oynatmayı düşünün.
RAG gözlemlenebilirliğini ayrı bir katman olarak ekleyin
Geri almayla artırılmış üretim hem kaliteyi hem de maliyeti değiştirebilir. Yalnızca son model çağrısının günlüğe kaydedilmesi, alıcı çok fazla parça, eski belgeler veya alakasız bağlam döndürdüğünde temel nedeni gizler.
Her alma adımı için şunu yakalayın:
- dizin veya koleksiyon adı;
- geri alma stratejisi ve yerleştirme modeli;
- belge kimlikleri veya karma kimlikleri;
- parça sayısı ve toplam bağlam belirteçleri;
- alma gecikmesi;
- varsa en yüksek puan dağılımı;
- alıntı kapsamı;
- son yanıtta alınan bağlamın kullanılıp kullanılmadığı.
Bu, "modelin daha da kötüleştiğini" "alıcının düşük kaliteli veya aşırı içerik göndermeye başladığı" ifadesinden ayırt edebilmenizi sağlar. Ayrıca bağlam belirteçlerinin toplam maliyete hakim olduğu iş akışlarının belirlenmesine de yardımcı olur.
Ağ geçidi kullanımını sağlayıcı faturalandırmasıyla bağdaştırın
Ağ geçidi tahminleri hemen kullanılabilir. Sağlayıcı tarafındaki faturalandırma verileri genellikle daha yavaştır ancak daha güvenilirdir. Her ikisini de kullanın.
Günlük mutabakat işi, ağ geçidi defter satırlarını sağlayıcı kullanım API'leri, maliyet API'leri, kontrol paneli dışa aktarmaları veya fatura dışa aktarmalarıyla karşılaştırmalıdır. Deltaları sağlayıcıya, modele, projeye ve zaman penceresine göre gruplandırın. Giriş jetonları, çıkış jetonları, önbelleğe alınmış jetonlar, istek sayıları ve maliyete ilişkin farkları ayrı ayrı izleyin.
Ortak mutabakat farklılıkları
- Akış bağlantısının kesilmesi: Sağlayıcı oluşturulan jetonları faturalandırmaya devam ederken ağ geçidi iptal edilmiş bir istemci görebilir.
- Yeniden denemeler: yalnızca bir son yanıt döndürülse bile birden fazla deneme faturalandırılabilir.
- İstemi önbelleğe alma: sağlayıcılar, önbelleğe alınmış jeton hesaplamasını farklı şekilde ortaya çıkarabilir.
- Yuvarlama: İstek başına küçük farklılıklar geniş ölçekte görünür hale gelebilir.
- Toplu veya kademeli indirimler: Sağlayıcı faturaları, gerçek zamanlı tahminin henüz bilmediği fiyatlandırmaları uygulayabilir.
- Sağlayıcı tarafındaki değişiklikler: model fiyatlandırması, jetonlaştırma davranışı veya faturalandırma dışa aktarımları zaman içinde değişebilir.
Mutabakat bir delta bulduğunda, defterinizin üzerine sessizce yazmaktan kaçının. Orijinal tahmini, sağlayıcıyla mutabakata varılan değeri, mutabakat kaynağını ve biliniyorsa neden kodunu saklayın.
Operasyonel soruları yanıtlayan kontrol panelleri
Kontrol panellerini özel metriklerden değil, okuyucu sorunlarından başlatın. Yararlı görünümler şunları içerir:
- kiracı, ekip, uygulama ve iş akışı başına maliyet;
- yalnızca istek başına maliyet değil, başarılı görev başına maliyet;
- Sağlayıcıya, modele ve model takma adına göre p50, p95 ve p99 gecikmesi;
- rotaya göre geri dönüş oranı ve yeniden deneme oranı;
- zaman aşımı oranı ve sağlayıcı hata sınıfı eğilimleri;
- Önbellek isabet oranı ve önbelleğe alınmış jeton tasarrufu tahmini;
- yapılandırılmış çıktı doğrulama başarısızlık oranı;
- hata bütçesi tüketimine göre en çok bilgi istemi sürümleri;
- İş akışına göre RAG bağlam belirteci paylaşımı;
- Korkuluk blokları ve hızlı enjeksiyon sınıflandırıcı isabetleri.
Uyarı için teknik ve iş sinyallerini birleştirin. Kiracı harcamalarında ani bir artış, küçük bir küresel gecikme artışından daha acil olabilir. Model takma adı değişikliğinden sonra geri dönüş oranındaki sıçrama, bir uyumluluk sorununa işaret edebilir. Tekrarlanan 401, 429 veya 5xx yanıtları önemli sorunlara, kota tükenmesine veya sağlayıcı istikrarsızlığına işaret edebilir.
OpenAI uyumlu bir proxy için minimum uygulama akışı
/chat/completions proxy'si için akış basit olabilir:
- İsteği alın ve
request_id'yi ve izleme içeriğini atayın. - Ağ geçidi anahtarının kimliğini doğrulayın ve kiracıyı, ekibi, uygulamayı ve politika kapsamını çözümleyin.
- Üst ağ geçidi aralığını oluşturun.
kabul edildidurumuna sahip bir genel muhasebe satırı oluşturun.- Model takma adını sağlayıcı modeline ve yönlendirme politikası sürümüne çözümleyin.
- Meta verileri kaydedin: işlem, bilgi istemi şablonu kimliği, şema adı, bilgi istemi karması ve içerik yakalama politikası.
- Genel AI semantik niteliklerini (varsa) kullanarak model çağrı aralığını başlatın.
- İsteği seçilen sağlayıcıya iletin.
- Akış için, ilk parça geldiğinde durumu güncelleyin ve kullanımı sağlayıcı yanıtının izin verdiği ölçüde doğru bir şekilde sayın.
- Tamamlandığında, sağlayıcı kullanımını, bitiş nedenini, durumu ve hata sınıfını ayrıştırın.
- Defteri jetonlar, tahmini maliyet, yeniden deneme/geri dönüş ayrıntıları ve son istek durumuyla güncelleyin.
- Defter ve aralık verilerinden metrikleri yayınlayın.
- Günlük mutabakatı ve mağaza sağlayıcısı tarafından onaylanan maliyeti orijinal tahminden ayrı olarak çalıştırın.
Kullanıma sunma kontrol listesi
- Kanonik istek kimliklerini ve izleme kimliklerini tanımlayın.
- Ortak model telemetrisi için OpenTelemetry GenAI özelliklerini benimseyin.
- İstek durumu geçişlerini içeren bir ağ geçidi kullanım defteri oluşturun.
- Sağlayıcı, model, model takma adı, kiracı, uygulama ve iş akışı boyutlarını normalleştirin.
- Yüksek kardinaliteli araştırma verilerini metrik etiketlerinin dışında tutun.
- Ham istemi ve çıktı yakalamayı varsayılan olarak devre dışı bırakın.
- Örnekleme, düzenleme, saklama ve erişim kontrolü için açık politikalar ekleyin.
- RAG iş akışları için alma meta verilerini yakalayın.
- Maliyet, gecikme, güvenilirlik, doğrulama ve kiracı davranışı için kontrol panelleri oluşturun.
- Ağ geçidi tahminlerini sağlayıcı kullanımı ve maliyet aktarımlarıyla bağdaştırın.
- Harcama ani artışları, gecikme gerilemeleri, geri dönüş atlamaları, doğrulama hataları ve güvenlikle ilgili olaylar hakkında uyarı.
Sonuç
Çok modelli bir ağ geçidi, LLM gözlemlenebilirliğini uygulamak için doğru yerdir çünkü istekleri herhangi bir sağlayıcıya ulaşmadan önce görür ve sağlayıcıların bilmediği iş bağlamını ekleyebilir. En güçlü tasarım "her şeyi günlüğe kaydetmek" değildir. Katmanlı bir modeldir: yürütme için sağlayıcıdan bağımsız izlemeler, faturalandırma için dayanıklı bir belirteç ve maliyet defteri, yönetişim için kiracı analitiği, alma kalitesi için RAG meta verileri ve güvenli hata ayıklama için gizlilik öncelikli istem günlük kaydı.
Meta veriler, durum geçişleri ve mutabakatla başlayın. İçerik yakalamayı yalnızca politika, saklama ve erişim kontrolleri hazır olduğunda ekleyin. Bu sekans, geliştiricilere, gözlemlenebilirliği yeni bir veri maruz kalma riskine dönüştürmeden gecikme, kalite ve harcama hatalarını ayıklamak için ihtiyaç duydukları kanıtları sağlar.