Ç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ı

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 AI kullanım analitiği ve OpenAI-uyumlu bir API aracılığıyla birden çok sağlayıcıya öncülük eden bir ağ geçidinde LLM gözlemlenebilirliği için pratik bir tasarım açıklanmaktadır. Bu model, belirli bir satıcıyı 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, kiracı talebinden model çağrısına, bilgi alma bağlamına ve faturalandırılan maliyeti yeniden denemeye kadar olan yolun tamamını tek başına açıklamaz.

Hedef, toplam jeton içeren başka bir kontrol paneli değil. Amaç şu gibi operasyonel soruları yanıtlamaktır:

• Hangi kiracı veya API anahtarı harcama artışına neden oldu?
• Model takma adı değiştikten sonra gecikme arttı mı?
• Yeniden denemeler veya yedekler çift sayma maliyeti midir?
• Hangi bilgi istemi sürümü en fazla hata bütçesini tüketir?
• Geri alma işlemi çok fazla bağlam belirteci eklediği için RAG iş akışı pahalı hale geldi mi?
• Özel kullanıcı istemlerini okumadan bir olayda hata ayıklamayı destekleyebilir miyim?

Gerçekler, öneriler ve tahminler

Gerçekler: OpenTelemetry, sohbet, generate_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. Ana model sağlayıcılar aynı zamanda 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: Yüksek Lisans 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ıracak.

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ı aralığı: 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üldüğü.
• Son işlem aralığı: JSON doğrulama, şema onarımı, alıntı kontrolleri veya son biçimlendirme.

Üst 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 daha sonra kontrol panellerinde toplanması daha iyidir.

Her LLM çağrısında yakalanan meta verileri normalleştirin

Sağlayıcıdan bağımsız olarak her model isteği tutarlı bir kayıt oluşturmalıdır. Tam şema değişiklik gösterebilir ancak pratik minimum şu şekilde görünür:

{
  "request_id": "req_01J...",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "tenant_id": "tenant_123",
  "team_id": "team_456",
  "app_id": "support_bot",
  "gateway_key_id": "key_789",
  "operation": "chat",
  "provider": "provider_name",
  "model": "provider-model-id",
  "model_alias": "fast-support-chat",
  "prompt_template_id": "refund_policy_v5",
  "prompt_hash": "sha256:...",
  "response_schema": "support_answer_v2",
  "status": "completed",
  "error_class": null,
  "latency_ms": 1842,
  "input_tokens": 2110,
  "output_tokens": 384,
  "cached_input_tokens": 1200,
  "estimated_cost_usd": "0.00492",
  "final_billed_cost_usd": null,
  "finish_reason": "stop",
  "retry_count": 0,
  "fallback_used": false,
  "content_capture_policy": "metadata_only"
}

İki fikri ayrı tutun: telemetry olanları açıklarken, kullanım defteri nelerin ücretlendirilmesi, mutabakatının 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, bir jeton ve maliyet defteri 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 bunu güncelleyin.

Yararlı defter durumları

• kabul edildi: kimlik doğrulama ve politika kontrolleri geçildi.
• iletildi: istek bir sağlayıcıya gönderildi.
• streaming: 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, ağ geçidindeki her iş boyutunu kapsamayacaktır. Şunun için ağ geçidine ait öznitelikler veya defter sütunları 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ü;
• istem ş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.

Önemlilik, önemliliktir. 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 istem 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 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ı onayı, ö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.

Redaksiyonun mükemmel olduğunu düşünmeyin. 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 birlikte 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 belge veya alakasız içerik 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;
• geri 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ı kesiliyor: sağlayıcı, oluşturulan jetonları faturalandırmaya devam ederken ağ geçidi iptal edilen bir istemciyi 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: istek 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ı değişiklikleri: model fiyatlandırması, jetonlaştırma davranışı veya faturalandırma dışa aktarmaları 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 iyi istem sürümleri;
• İş akışına göre RAG bağlam jetonu paylaşımı;
• Korkuluk blokları ve istem enjeksiyonlu 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

/chat/completions proxy'si için akış basit olabilir:

1. İsteği alın ve request_id atayın ve bağlamı izleyin.
2. Ağ geçidi anahtarının kimliğini doğrulayın ve kiracıyı, ekibi, uygulamayı ve politika kapsamını çözümleyin.
3. Üst ağ geçidi aralığını oluşturun.
4. accepted.
durumuna sahip bir genel muhasebe satırı oluşturun
5. Model takma adını sağlayıcı modeline ve yönlendirme politikası sürümüne çözümleyin.
6. Meta verileri kaydedin: işlem, bilgi istemi şablonu kimliği, şema adı, bilgi istemi karması ve içerik yakalama politikası.
7. Genel AI semantik niteliklerini (varsa) kullanarak model çağrı aralığını başlatın.
8. İsteği seçilen sağlayıcıya iletin.
9. 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.
10. Tamamlandığında, sağlayıcı kullanımını, bitiş nedenini, durumu ve hata sınıfını ayrıştırın.
11. Defteri jetonlar, tahmini maliyet, yeniden deneme/yedek ayrıntıları ve son istek durumuyla güncelleyin.
12. Defter ve aralık verilerinden metrikleri yayınlayın.
13. 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

• Kurallı 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 uzlaş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üğü 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 dizi, geliştiricilere, gözlemlenebilirliği yeni bir veri açığa çıkma riskine dönüştürmeden gecikme, kalite ve harcama hatalarını ayıklamak için ihtiyaç duydukları kanıtları sağlar.

İlgili okuma

• LLM'de yeniden deneme ve geri dönüş davranışı API yönlendirme
• istem önbelleğe alma ve toplu maliyet kontrolü modeller
• ekip API temel yönetim ve harcama sınırları