OpenAI Uyumlu API Ağ Geçidinin Arkasında Çok Kiracılı RAG

Müşteriye dönük yapay zeka asistanlarının erişimle artırılmış nesile ihtiyacı vardır, ancak istekler tek bir model sağlayıcının yerel yığını yerine OpenAI uyumlu API ağ geçidi üzerinden aktığında RAG daha da zorlaşır. Ağ geçidi, kiracı verilerini izole etmeli, model sağlayıcılar arasındaki alıntıları korumalı, dizine eklenen içeriği zamanında silmeli ve yerleştirme, alma ve oluşturma maliyetlerini doğru müşteriye atfetmelidir.

Pratik yanıt, alma işlemini birinci sınıf bir ağ geçidi alt sistemi olarak ele almaktır. Bunu tek bir sağlayıcı entegrasyonunun içine saklamayın. Alma işlemini oluşturmadan ayrı tutun, her isteğe kiracı kapsamlı bir alma bağlamı verin, alıntıları geri göndermeden önce normalleştirin ve faturalandırılabilir her adımı bir deftere kaydedin.

Okuyucu Sorunu

Birçok müşteri için yapay zeka asistanı oluşturan bir ekip genellikle basit bir akışla başlar: belgeleri yükleyin, parçaları yerleştirin, en önemli eşleşmeleri alın, bu parçacıkları istemin içine koyun ve bir modelden yanıt vermesini isteyin. Bu, ürün birden fazla model sağlayıcıya, müşteri düzeyinde faturalandırmaya, katılıma ve denetlenebilirliğe ihtiyaç duyana kadar işe yarar.

Risk yalnızca yanlış yanıtlar değildir. Daha büyük operasyonel riskler arasında kiracının ad alanı hataları, doğrulanamayan alıntılar, belge silindikten sonra eski dizinler ve alma maliyetlerinin genel altyapı harcamalarında ortadan kalkması nedeniyle açıklanamayan marjlar yer alır.

Bu makalede gerçekler, öneriler ve tahminler birbirinden ayrılmıştır. Gerçekler, mevcut sağlayıcı ve vektör veritabanı API'leri tarafından belgelenen uygulama yetenekleridir. Öneriler bir ağ geçidi ürünü için mimari seçimlerdir. Tahminler, sağlayıcı alma özellikleri değişmeye devam ettikçe bu mimarinin muhtemelen esnekliğe ihtiyaç duyacağı noktalardır.

Referans Mimarisi

Ağ geçidi düzeyinde bir RAG tasarımının beş bileşeni olmalıdır:

• Kiracı çözümleyici: gelen API anahtarını, çalışma alanını, müşteri hesabını veya İş Ortağı API müşterisini bir canonical tenant_id.
• Alma profili: hangi derlemin aranacağını, hangi yerleştirme modelinin kullanılacağını, sonuç sayısını, filtreleri, yeniden sıralama seçeneklerini, alıntı gereksinimlerini ve geri dönüş davranışını tanımlar.
• Alım bağdaştırıcı katmanı: tek bir dahili aracılığıyla yerel sağlayıcı alımını, harici bir vektör veritabanını veya özel bir arama hizmetini çağırır arayüz.
• İstem derlemesi ve oluşturma bağdaştırıcısı:, arayanlara vektör arka uç ayrıntılarını göstermeden alınan bağlamı seçilen model sağlayıcıya iletir.
• Kullanım ve denetim defteri: kayıt yerleştirme, dizine ekleme, alma, bilgi istemi belirteçleri, tamamlama belirteçleri, kiracı, model, sağlayıcı ve izleme tanımlayıcılar.

Minimum istek sözleşmesi sağlayıcıdan bağımsız kalabilir:

{
  "tenant_id": "tenant_123",
  "model": "gpt-compatible-or-claude-compatible-model",
  "retrieval_profile": "support_docs_v2",
  "citation_required": true,
  "messages": [
    {"role": "user", "content": "What is our refund policy for annual plans?"}
  ]
}

Yanıt aynı zamanda sağlayıcıdan bağımsız olmalıdır:

{
  "answer": "Annual plans can be refunded within the configured policy window...",
  "citations": [
    {
      "source_id": "doc_789",
      "title": "Billing Policy",
      "url_or_internal_ref": "kb://billing-policy",
      "chunk_id": "chunk_044",
      "offsets": {"page": 3},
      "score": 0.82,
      "retrieval_provider": "vector_db",
      "model_provider": "openai_compatible",
      "provider_payload": {}
    }
  ],
  "retrieval_trace_id": "rt_456",
  "billable_tenant": "tenant_123",
  "embedding_usage": null,
  "retrieval_usage": {"queries": 1, "results": 6},
  "model_usage": {"input_tokens": 1920, "output_tokens": 180}
}

Gerçek: Sağlayıcı Alma Özellikleri Aynı Değil

OpenAI'in Vektör Mağazaları API şunları yapabilen vektör mağazalarını destekler: oluşturulabilir, aranabilir, parçalama stratejileriyle yapılandırılabilir, dosya meta verileriyle ilişkilendirilebilir ve silinebilir. Vektör mağazası araması sorguları, filtreleri, maksimum sonuç sayısını, sıralama seçeneklerini, puan eşiklerini ve sorgu yeniden yazma kontrollerini destekler. Bu kontroller, ağ geçidi yazarlarına gecikme, alaka düzeyi ve maliyet açısından yararlı düğmeler sağlar.

OpenAI Platform veri kontrolleri aynı zamanda yaşam döngüsü tasarımını da önemli kılar: vektör mağazalarındaki müşteri içeriği silinene kadar tutulur.Bir kiracı ayrılırsa veya geçici bir projenin süresi dolarsa ağ geçidi, sağlayıcının dizine eklenen içeriği ürünün iş programında otomatik olarak kaldıracağını varsayamaz.

Anthropic, alıntılar için farklı bir model ortaya çıkarır. Uygulamalar, kaynak ve başlık meta verilerini içeren arama sonucu içerik blokları sağlayabilir ve alıntılar etkinleştirildiğinde model, oluşturulan metne alıntı referansları ekleyebilir. Pratik kısıtlamalar vardır: bir istek içinde arama sonucu alıntı ayarları ya hep ya hiç şeklindedir, arama sonucu blokları metin içeriğini destekler ve alıntı ayrıntı düzeyi içeriğin bloklara nasıl bölündüğüne bağlıdır.

Bunun anlamı doğrudandır: bir ağ geçidi, bir sağlayıcıyı kalıcı erişim otoritesi yapmayı amaçlamadığı sürece, bir sağlayıcının alma şeklini kamu sözleşmesi olarak göstermemelidir.

Öneri: Geri Alma Adaptörlerini Kullanın, Değil Alma Kilitleme

Dahili bir alma bağdaştırıcısı arayüzü oluşturun. Ağ geçidi, arkasındaki birkaç arka ucu destekleyebilir:

• Yerel sağlayıcı erişimi: müşteri, bir sağlayıcının dosya arama veya vektör depolama özelliklerine giden en hızlı yolu istediğinde kullanışlıdır.
• Harici vektör veritabanı: ürünün tutarlı kiracı izolasyonu ve yaşam döngüsü ile birçok model sağlayıcıyı desteklemesi gerektiğinde kullanışlıdır kontroller.
• Önceden getirilen arama sonucu blokları: ağ geçidi, alınan metni birleştirdiğinde ve bunu açık alıntıya duyarlı bağlamı destekleyen bir sağlayıcıya aktardığında kullanışlıdır.

Bağdaştırıcı, arka uçtan bağımsız olarak aynı iç yapıyı döndürmelidir:

interface RetrievalResult {
  retrievalTraceId: string;
  tenantId: string;
  corpusId: string;
  chunks: Array<{
    sourceId: string;
    title: string;
    text: string;
    urlOrInternalRef?: string;
    chunkId: string;
    offsets?: { page?: number; byteStart?: number; byteEnd?: number; tokenStart?: number; tokenEnd?: number };
    score?: number;
    metadata: Record<string, string | number | boolean>;
    providerPayload?: unknown;
  }>;
  retrievalUsage: {
    provider: string;
    queryCount: number;
    resultCount: number;
    billableUnits?: number;
  };
}

Bu, oluşturma katmanının OpenAI vektöründen gelip gelmediğini bilmeden bağlam almasını sağlar depolar, Pinecone, Weaviate, bir veritabanı tam metin arama dizini veya dahili bir karma alıcı.

Kiracı Yalıtımı Vektör Sorgusundan Önce Başlar

Kiracı yalıtımı istem talimatlarına bağlı olmamalıdır. Almadan önce, depolama sınırında ve sorgu sınırında uygulanması gerekir.

Çam Kozalağı tarzı sistemler için, belgelenen çoklu kiralama modeli, sunucusuz dizinlerde kiracı başına bir ad alanıdır. Veri düzlemi işlemleri bir ad alanını hedefler; bu, ad alanının silinmesi kiracının kayıtlarını kaldırdığından kiracı yalıtımını ve ayrılmayı basitleştirir. Pinecone ayrıca ad alanları ile meta veri filtreleme arasındaki dengeleri de belgeliyor: Büyük bir paylaşılan ad alanı içinde filtreleme, ad alanı kapsamlı sorgulara göre daha fazla veri tarayabilir, daha fazla maliyet oluşturabilir ve daha yavaş performans gösterebilir.

Weaviate tarzı sistemler için, çoklu kiracılık her kiracıyı ayrı bir parçada depolar, böylece bir kiracının verileri diğer kiracı tarafından görülemez. Kiracının silinmesi ilişkili parçayı siler.Weaviate ayrıca etkin, etkin olmayan ve yükü boşaltılmış gibi kiracı durumlarını da destekler; bu da nadiren kullanılan kiracılar için bir yaşam döngüsü seçeneği oluşturur.

Uygulama Kontrol Listesi

• tenant_id'i yalnızca kullanıcı tarafından sağlanan gövde alanından değil, kimliği doğrulanmış ağ geçidi kimliğinden çözümleyin.
• tenant_id'i bir vektör ad alanı, parça veya sağlayıcı vektör deposu tanımlayıcısıyla eşleştirin sunucu tarafı kayıt defteri aracılığıyla.
• API anahtar kiracı ile talep edilen topluluk kiracısının eşleşmediği istekleri reddedin.
• Paylaşılan genel tümceleri özel kiracı tümleşiklerinden ayrı tutun.
• Kiracı sınırı zaten seçildikten sonra belge türü, dil, ürün alanı veya tarih aralığı için meta veri filtrelemeyi kullanın.
• Günlük Denetlenebilirlik için ad alanı, parça, corpus_id, retrieval_profile ve retrieval_trace_id.

Ayrı yetkilendirme, ayrı dizinler veya kontrollü toplama yollarıyla açık yönetim iş akışları için kiracılar arası aramayı ayırın. Kiracılar arası aramayı meta veri filtrelerinin tesadüfi bir yan etkisi haline getirmeyin.

Alıntıları Ağ Geçidi Nesneleri Olarak Normalleştirin

Alıntılar yalnızca dekorasyon değil, bir ürün sözleşmesidir. Bir müşteri destek asistanının, yasal taslak hazırlama aracının veya şirket içi bilgi asistanının, bir cevabın neden üretildiğini ve destekleyici metnin nereden geldiğini göstermesi gerekir.

Ağ geçidi, alıntı verilerini kendi şemasına göre normalleştirmelidir:

{
  "source_id": "doc_123",
  "title": "Refund Terms",
  "url_or_internal_ref": "kb://refund-terms",
  "chunk_id": "chunk_006",
  "offsets": {"page": 2, "byte_start": 4410, "byte_end": 5020},
  "score": 0.79,
  "retrieval_provider": "weaviate",
  "model_provider": "anthropic",
  "model_provider_citation_payload": {}
}

Normalleştirilmiş alanları sabit tutmalı ve sağlayıcıya özel uzantılara izin vermelidir. Bazı sağlayıcılar diğerlerinden daha zengin alıntı ayrıntılarını ortaya çıkaracaktır. Bazıları arama sonucu bloklarından alıntı yapacaktır. Bazıları yüklenen dosyalardan alıntı yapacaktır. Bazıları uygulamanızın istediği tam ofset formatını sağlamayacaktır. Ağ geçidi, her sağlayıcının aynı alıntı semantiğine sahip olduğunu iddia etmeden var olanı korumalıdır.

Katı Alıntı Modu

citation_required doğru olduğunda, hata davranışını önceden tanımlayın. Katı bir mod, her gerçek paragrafın en az bir alıntı içermesini veya nihai yanıtın, minimum puan eşiğinin üzerinde alınan parçalardan alıntılar içermesini gerektirebilir. Seçilen model sağlayıcı alıntı sözleşmesini yerine getiremezse, ağ geçidinin hızlı bir şekilde başarısız olması, uyumlu bir sağlayıcı kullanması veya yapılandırılmış bir ret yanıtı vermesi gerekir.

Bu bir öneridir, evrensel bir kural değil. Kesin alıntı modu güveni artırır ancak retleri, yeniden denemeleri ve geri dönüş karmaşıklığını artırabilir. Düşük riskli yaratıcı iş akışları için alıntılar isteğe bağlı olabilir. Müşteriye yönelik destek veya düzenlenmiş dahili iş akışları için citation_required genellikle alma profilinin bir parçası olmalıdır.

Dizin Yaşam Döngüsü Bir Ürün Özelliğidir

RAG sistemleri veri toplar. Geçici yüklemeler tesadüfen kalıcı hale gelir. Eski müşteriler yerleştirmeleri geride bırakıyor. Ürün ekipleri parçalama stratejilerini değiştirir ve eski dizinleri yeniden oluşturmayı unutur.Bir ağ geçidi, yaşam döngüsü kontrollerini açık hale getirmelidir.

Önerilen yaşam döngüsü kontrolleri şunları içerir:

• Geçici derlem sona erme: Kısa ömürlü bir oturum için yüklenen belgelerin bir sona erme zaman damgası ve bir silme işi olmalıdır.
• Kiracıdan çıkarma: bir kiracının silinmesi sıraya alınmalıdır ad alanlarının, parçaların, sağlayıcı vektör depolarının ve ilgili dosya nesnelerinin silinmesi.
• Soğuk kiracı işleme: desteklendiği yerlerde, etkin olmayan kiracılar kaynak kullanımını azaltmak için etkin değil veya yükü kaldırılmış olarak işaretlenebilir.
• Yeniden dizin oluşturma sürüm kontrolü: mağaza yerleştirme modeli, parçalama politikası, ayrıştırıcı sürümü ve her biri için indexed_at chunk.
• Silme durumu gösterimi: İş ortağı API iş akışları, belge silme, vektör silme ve sağlayıcı tarafı silme işlemlerinin tamamlanıp tamamlanmadığını göstermelidir.

Önemli olan, bazı vektör deposu içeriklerinin silinene kadar saklanmasıdır. Mimari önerisi, silme işlemini müşteriye yönelik bir durumu olmayan eşzamansız bir işe gömmek yerine görünür ve test edilebilir hale getirmektir.

Üç Maliyet Defterini Takip Edin

Tek bir jeton defteri RAG için yeterli değildir. Bir ağ geçidinin en az üç deftere ihtiyacı vardır:

• Yerleştirme ve dizine ekleme maliyeti: belge ayrıştırma, parçalama, yerleştirme çağrıları, dosya depolama, dizin yazma ve yeniden dizin oluşturma.
• Geri alma maliyeti: vektör veritabanı okumaları, yerel vektör deposu araması, yeniden sıralama, sorgu yeniden yazma ve sonuç genişletme.
• Oluşturma maliyeti: Kullanıcı mesajlarından ve alınan bağlamdan alınan giriş jetonları, çıktı jetonları, araç çağrıları, yeniden denemeler ve yedekler.

Bu özellikle AI maliyetlerini yeniden satan veya tahsis eden ajanslar, SaaS satıcıları ve dahili platform ekipleri için önemlidir. Ayrı defterler olmadan RAG marjlarının açıklanması zorlaşır. Küçük nesil kullanıma sahip bir kiracı, sürekli olarak belgeleri yüklerse, büyük derlemleri yeniden dizine eklerse veya geniş erişim sorguları çalıştırırsa yine de pahalı olabilir.

Her defter etkinliği tenant_id, farklıysa customer_id, API anahtar kimliği, retrieval_profile, corpus_id, model, sağlayıcı, trace_id ve faturalandırılabilir birimler içermelidir.Bu, kullanım analitiğinin pratik soruları yanıtlamasına olanak tanır: hangi kiracıların pahalı alma profilleri var, hangi derlemler eski, hangi modeller alıntı hataları üretiyor ve alma işlemi çok fazla bağlam getirdiği için hangi müşteriler büyük boyutlu istemler oluşturuyor.

Test Edilecek Arıza Modları

Bir ağ geçidi RAG alt sistemi, müşterinin görebileceği hasar oluşturan arıza modları için testlere sahip olmalıdır:

• Eksik alıntılar: citation_required doğru, ancak sağlayıcının yanıtı kullanılabilir alıntı referansları içermiyor.
• Eski dizinler: bir belge güncellendi veya silindi, ancak eski parçalar hâlâ alma sonuçlarında görünüyor.
• Kiracı uyumsuzluğu: istek kiracı A'ya çözümlenirken, derlem veya ad alanı kiracı B.
• Aşırı geniş erişim: profil çok fazla parça döndürüyor, bu da maliyeti artırıyor ve yanıt kalitesini düşürüyor.
• Parça boyutu uyuşmazlığı: parçalar o kadar büyük ki alıntılar belirsiz oluyor veya o kadar küçük ki bağlam kayboluyor anlamı.
• Sağlayıcı özelliği uyumsuzluğu: bir model gerekli biçimde alıntılar yayınlayabilirken diğeri bunu yapamaz.
• Yaşam döngüsü hatası: silme isteniyor ancak sağlayıcı tarafındaki depolama etkin veya doğrulanmamış durumda kalıyor.

Bu testler yalnızca bir sağlayıcı bağdaştırıcısında değil, ağ geçidi sözleşme düzeyinde çalıştırılmalıdır. Amaç, alma arka ucu veya oluşturma sağlayıcısı değiştiğinde genel davranışın sabit kaldığını kanıtlamaktır.

Ödüller

Yerel sağlayıcı alımı, uygulama kodunu azaltabilir ve ilk sürümü hızlandırabilir. Bunun karşılığında depolama yaşam döngüsü, alıntı biçimi, sorgu kontrolleri ve özellik kullanılabilirliği tek bir sağlayıcıya bağlı hale gelebilir.

Harici vektör veritabanları operasyonel yüzey alanı ekler. Avantajı, OpenAI-uyumlu modeller, Anthropic modelleri ve gelecekteki sağlayıcılar arasında daha güçlü taşınabilirliktir. Ayrıca, kiracı kapsamlı ad alanlarının veya parçacıkların, ağ geçidinin faturalandırma ve işten çıkarmadan ne zaman sorumlu olduğu konusunda akıl yürütmeyi kolaylaştırır.

İnce parçalı parçalar, alıntıların doğruluğunu ve denetlenebilirliğini artırır. Ayrıca dizin boyutunu, alma hacmini ve hızlı birleştirme karmaşıklığını da artırırlar. Kaba parçalar daha basittir, ancak tam destekleyici pasajdan ziyade geniş bir sayfaya veya bölüme işaret eden alıntılar üretebilirler.

Kesin alıntı gerektiren mod, kullanıcının güvenini artırır. Ayrıca ağ geçidini, gerekli alıntı biçimini üretemeyen modelleri işlemeye zorlar; bu, isteğin reddedilmesi, modellerin değiştirilmesi veya daha düşük bir güven durumuyla yanıt döndürülmesi anlamına gelebilir.

Tahmin: Alma Daha Yerel Hale Gelecek, Ancak Ağ Geçitlerinin Hala Kendi Sözleşmelerine İhtiyacı Var

Sağlayıcının yerel alma özelliklerinin daha yetenekli hale gelmesi muhtemeldir. Daha fazla model, yapılandırılmış kaynak meta verileriyle alınan bağlamı kabul edecektir. Daha fazla API, sıralama kontrollerini, sorgu yeniden yazımını ve alıntı ayarlarını ortaya çıkaracak. Bu, ağ geçidi sözleşmesine olan ihtiyacı ortadan kaldırmaz.

Ağ geçidi hâlâ kiracı kimliğine, anahtar yönetimine, harcama sınırlarına, kullanım analizlerine, İş Ortağı API iş akışlarına ve müşteriye yönelik silme taahhütlerine sahiptir. Sağlayıcı özellikleri bağdaştırıcı katmanının arkasında kullanılabilir, ancak ürün, her kiracıyı, modeli ve faturalandırma iş akışını tek bir sağlayıcının alma soyutlamasına zorlamamalıdır.

Uygulanabilir Sonuç

Çok kiracılı RAG'yi, açık sınırları olan bir ağ geçidi alt sistemi olarak oluşturun.Almadan önce kiracının kimliğini çözümleyin. Kiracı kapsamlı ad alanlarını, parçaları veya vektör depolarını kullanın. Erişimi adaptörlerin arkasında tutun. Alıntıları ağ geçidine ait bir şema halinde normalleştirin. Yaşam döngüsü durumlarını ve silme doğrulamasını ekleyin. Yerleştirme, alma ve oluşturma maliyetlerini ayrı ayrı izleyin.

Bu mimari, ürünü tek bir alma sağlayıcısına kilitlemeden RAG'ı temellendirir. Aynı zamanda ekiplere, bir AI asistanı prototipten müşteriye dönük bir sisteme geçtiğinde ihtiyaç duydukları operasyonel kontrolleri de sağlar: izolasyon, alıntılar, taşınabilirlik, yaşam döngüsü yönetimi ve maliyet ilişkilendirme.

İlgili okuma

• iz alma, jeton kullanımı ve kiracı analitiği tek bir gözlemlenebilirlik modelinde
• arkasındaki sağlayıcıya özgü çıktıları normalleştirir istikrarlı bir ağ geçidi sözleşmesi
• kiracı temel hazırlık ve kullanım ölçümünü İş Ortağı API iş akışlarına bağlayın