OpenAI Uyumlu API Ağ Geçidinin Arkasında Çok Kiracılı RAG
Çok modelli bir API ağ geçidinin arkasında erişimle artırılmış nesil oluşturmak için pratik bir referans mimarisi: kiracı kapsamlı dizinler, sağlayıcıdan bağımsız alma bağdaştırıcıları, normalleştirilmiş alıntılar, yaşam döngüsü kontrolleri ve maliyet ilişkilendirme.
Müşteriye yönelik 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 bir 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. Geri almayı üretimden ayrı tutun, her isteğe kiracı kapsamlı bir erişim 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 iyi 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, ayrılmaya 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 geri 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 esnekliğe ihtiyaç duyabileceği 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 standart bir tenant_id ile eşler.
- Geri alma profili: hangi derlemin alınacağını tanımlar kullanılacak modeli, sonuç sayısını, filtreleri, yeniden sıralama seçeneklerini, alıntı gerekliliklerini ve geri dönüş davranışını içeren arama.
- Geri alma bağdaştırıcısı katmanı: tek bir dahili arayüz aracılığıyla yerel sağlayıcı erişimini, harici bir vektör veritabanını veya özel bir arama hizmetini çağırır.
- Hızlı derleme ve oluşturma bağdaştırıcısı:, vektör arka uç ayrıntılarını arayanlara göstermeden, alınan bağlamı seçilen model sağlayıcıya iletir.
- Kullanım ve denetim defteri: yerleştirme, dizine ekleme, alma, bilgi istemi belirteçleri, tamamlama belirteçleri, kiracı, model, sağlayıcı ve izleme tanımlayıcılarını kaydeder.
Minimum düzeyde istek sözleşmesi sağlayıcı açısından tarafsız kalabilir:
{
"kiracı_id": "kiracı_123",
"model": "gpt-uyumlu-veya-Claude-uyumlu-model",
"retrieval_profile": "support_docs_v2",
"citation_required": doğru,
"mesajlar": [
{"role": "user", "content": "Yıllık planlar için geri ödeme politikamız nedir?"}
]
Yanıt aynı zamanda sağlayıcıdan bağımsız olmalıdır:
{
"answer": "Yıllık planlar, yapılandırılan politika penceresi içerisinde iade edilebilir...",
"alıntılar": [
{
"kaynak_kimliği": "belge_789",
"title": "Faturalandırma Politikası",
"url_or_internal_ref": "kb://fatura politikası",
"yığın_id": "yığın_044",
"ofsetler": {"sayfa": 3},
"puan": 0,82,
"retrieval_provider": "vector_db",
"model_provider": "openai_uyumlu",
"sağlayıcı_payload": {}
}
],
"retrieval_trace_id": "rt_456",
"fatura_kiracı": "kiracı_123",
"yerleştirme_kullanımı": null,
"retrieval_usage": {"sorgular": 1, "sonuçlar": 6},
"model_usage": {"input_tokens": 1920, "output_tokens": 180}Gerçek: Sağlayıcı Alma Özellikleri Aynı Değil
OpenAI'nin Vektör Mağazaları API'si oluşturulabilen, aranabilen, parçalama stratejileriyle yapılandırılabilen, dosya meta verileriyle ilişkilendirilebilen ve silinebilen vektör depolarını destekler. Vektör mağazası araması sorguları, filtreleri, maksimum sonuç sayıları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 platformu 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 saklanır. 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ş planına göre otomatik olarak kaldıracağını varsayamaz.
Anthropic alıntılar için farklı bir model ortaya koyuyor. 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.
Bu çıkarım 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 açığa çıkarmamalıdır.
Öneri: Alma Değil, Geri Alma Bağdaştırıcıları Kullanın. Kilitlenme
Dahili bir geri alma bağdaştırıcısı arayüzü oluşturun. Ağ geçidi, arkasındaki birçok arka ucu destekleyebilir:
- Yerel sağlayıcı alımı: 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ü kontrolleri ile birçok model sağlayıcıyı desteklemesi gerektiğinde kullanışlıdır.
- Önceden getirilen arama sonucu blokları: ağ geçidi, alınan metni bir araya getirdiğinde ve bunu alıcıya ilettiğinde kullanışlıdır. açık alıntıya duyarlı bağlamı destekleyen bir sağlayıcı.
Bağdaştırıcı, arka uçtan bağımsız olarak aynı iç yapıyı döndürmelidir:
interface RetrievalResult {
almaTraceId: dize;
kiracıKimliği: dize;
CorpusId: dize;
parçalar: Dizi<{
kaynakKimliği: dize;
başlık: dize;
metin: dize;
urlOrInternalRef?: string;
parça kimliği: dize;
ofsetler?: { sayfa?: sayı; baytBaşlat?: sayı; baytSonu?: sayı; belirteçBaşlangıç?: sayı; tokenEnd?: sayı };
puan?: sayı;
meta veriler: Record;
sağlayıcıPayload?: bilinmiyor;
}>;
almaKullanım: {
sağlayıcı: string;
queryCount: sayı;
sonuçSayısı: sayı;
faturalandırılabilirBirimler?: sayı;
}; Bu, oluşturma katmanının OpenAI vektör depolarından, Pinecone'dan, Weaviate'den, bir veritabanı tam metin arama dizininden mi yoksa dahili bir hibrit alıcıdan mı geldiğini bilmeden bağlam almasına olanak tanır.
Kiracı Yalıtımı Vektör Sorgusundan Önce Başlar
Kiracı yalıtımı anlık talimatlara 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ı izolasyonunu 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ı kapsamındaki 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 aynı zamanda etkin, etkin olmayan ve yüksüz 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'yi 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'yi sunucu tarafı aracılığıyla bir vektör ad alanı, parça veya sağlayıcı vektör mağazası tanımlayıcısıyla eşleyin. kayıt defteri.
- API anahtarı kiracısı ve talep edilen derlem kiracısının eşleşmediği istekleri reddedin.
- Paylaşılan genel derlemleri özel kiracı bütünlüklerinden 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.
- Ad alanını, parçayı, derlem_id'sini, retrieval_profile'i ve retrieval_trace_id'yi günlüğe kaydedin. denetlenebilirlik için.
Ayrı yetkilendirme, ayrı dizinler veya kontrollü toplama yollarıyla açık yönetim iş akışları için kiracılar arası arama 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:
{
"kaynak_kimliği": "belge_123",
"title": "Geri Ödeme Koşulları",
"url_or_internal_ref": "kb://refund-terms",
"yığın_id": "yığın_006",
"ofsetler": {"sayfa": 2, "byte_start": 4410, "byte_end": 5020},
"puan": 0,79,
"retrieval_provider": "örtün",
"model_provider": "antropik",
"model_provider_citation_payload": {}
Normalleştirilmiş alanları sabit tutun ve sağlayıcıya özel uzantılara izin verin. 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çidi hızlı bir şekilde arızalanmalı, uyumlu bir sağlayıcı kullanmalı veya yapılandırılmış bir ret yanıtı vermelidir.
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ça belirtmelidir.
Ö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 belgelerde bir süre sonu zaman damgası ve bir silme işi bulunmalıdır.
- Kiracıdan çıkarma: bir kiracının silinmesi, ad alanlarının, parçaların, sağlayıcı vektör depolarının ve ilgili dosyanın silinmesini gerektirmelidir. nesneler.
- Soğuk kiracı işleme: desteklendiğinde, etkin olmayan kiracılar, kaynak kullanımını azaltmak için etkin değil veya yükü boşaltı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 bir parça için indexed_at.
- Silme durumuna maruz kalma: İş ortağı API iş akışları, belge silme, vektör silme ve sağlayıcı tarafı olup olmadığını göstermelidir. silme işlemi tamamlandı.
Önemli olan nokta, 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
RAG için tek bir jeton defteri yeterli değildir. Bir ağ geçidinin en az üç deftere ihtiyacı vardır:
- Yerleştirme ve dizine ekleme maliyeti: belge ayrıştırma, parçalara ayırma, çağrıları yerleştirme, dosya depolama, dizin yazma ve yeniden dizin oluşturma.
- Geri alma maliyeti: vektör veritabanı okumaları, yerel vektör deposu arama, yeniden sıralama, sorgu yeniden yazma ve sonuç genişletme.
- Oluşturma maliyeti: kullanıcı mesajlarından gelen giriş jetonları ve alınan bağlam, çıktı belirteçleri, araç çağrıları, yeniden denemeler ve geri dönüşler.
Bu özellikle yapay zeka 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 indekslerse veya geniş erişim sorguları çalıştırırsa yine de pahalı olabilir.
Her defter olayı kiracı_id, farklıysa müşteri_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 analizlerinin pratik soruları yanıtlamasına olanak tanır: hangi kiracıların pahalı alma profilleri var, hangi derlemler eskimiş, hangi modeller alıntı hatalarına neden oluyor ve alma işlemi çok fazla bağlam getirdiği için hangi müşteriler büyük boyutlu istemler oluşturuyor.
Test Edilecek Hata Modları
Bir ağ geçidi RAG alt sisteminin, müşterinin görebileceği hasar oluşturan hata modları için testleri olmalıdır:
- Eksik alıntılar: citation_required doğrudur, ancak sağlayıcının yanıtı kullanılabilir alıntı referansları içermez.
- Eski dizinler: bir belge güncellendi veya silindi, ancak eski parçalar alma sonuçlarında hâlâ görünüyor.
- Kiracı uyumsuzluğu: istek kiracı A'ya çözümlenirken, derlem veya ad alanı kiracı B'ye aittir.
- Aşırı geniş erişim: profil çok fazla parça döndürür, bu da maliyeti artırır ve yanıt kalitesini azaltır.
- Öbek boyutu uyumsuzluğu: parçalar o kadar büyük ki alıntılar kesin değil veya o kadar küçük ki bağlam anlamını yitiriyor.
- Sağlayıcı özelliği uyumsuzluğu: bir model alıntıları gerekli biçimde yayınlayabilirken diğeri bunu yapamaz.
- Yaşam döngüsü hatası: silme isteniyor ancak sağlayıcı tarafı depolama etkin kalıyor veya doğrulanmadı.
Bu testler yalnızca tek bir sağlayıcı bağdaştırıcısında değil, ağ geçidi sözleşme düzeyinde de ç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.
Değiştirmeler
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ı formatı, 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, Antropik modeller 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 taneli parçalar, alıntı hassasiyetini 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 pasaj yerine 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 bir yanıtın 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ı-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 dahil etmeye zorlamamalıdır.
Uygulamaya Uygulanabilir Sonuç
Çok kiracılı RAG'yi açık sınırlara sahip 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. Ayrıca ekiplere, bir AI asistanı prototipten müşteriye yönelik 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.