Vektör arama, anlamsal olarak bir soruya benzeyen pasajları bulmanın etkili bir yoludur. Her türlü bilgiye yönelik evrensel bir arayüz değildir. Birden fazla belgeye dağıtılan kesin tanımlayıcılar, deterministik hesaplamalar ve ilişkiler, farklı retrieval temel öğelerini gerektirir.
Bir üretim bilgi sistemi, mevcut olan veritabanıyla değil, bilgi ihtiyacıyla başlamalıdır. Açık uçlu sorular bir vektör indeksine ait olabilir. Ürün kodları tam eşleşme alanına ihtiyaç duyarken, bunları çevreleyen teknik açıklamalar da sözcüksel aramadan faydalanabilir. Kesin toplamlar yapılandırılmış tablolardan gelmelidir. Çok atlamalı ilişki soruları grafik geçişleri olarak daha iyi temsil edilebilir.
Bu nedenle retrieval mimarisinin amacı her soruyu tek bir arama yöntemiyle zorlamak değildir. Her soruyu, ona en güvenilir şekilde cevap verebilecek temsile yönlendirmek ve talep çeşitli bilgi türlerini kapsadığında yöntemleri birleştirmektir.
Anlamsal Benzerliğin Yapısal Sınırı
Tedarik anlaşmalarını, ürün kataloglarını ve faturaları içeren bir belge koleksiyonunu düşünün.
Bir anlaşma, A Şirketinin Endüstriyel sensörleri Tedarikçi Beta'dan ve kontrol modüllerini Tedarikçi Gamma'dan satın aldığını belirtiyor. Ayrı faturalarda Beta ve Gamma tarafından tedarik edilen ürünlerin adetleri ve birim fiyatları yer almaktadır. Bir kullanıcı soruyor:
A Şirketinin son çeyrekte onaylı satıcıları tarafından tedarik edilen ürünleri denetlemek için yaptığı toplam harcama ne kadardı?
Hiçbir pasaj mutlaka bu soruya benzemiyor. Cevap birkaç işlem gerektirir:
- A Şirketinin onaylı satıcılarını tanımlayın.
- Hangi ürünlerin izleme kategorisine ait olduğunu belirleyin.
- Bu satıcıları ve ürünleri istenen döneme bağlayan fatura satır öğelerini bulun.
- Miktar, birim fiyat, indirimler ve vergi kurallarından toplamı hesaplayın.
Bir vektör sorgusu, A Şirketi ve tedarikçilerden bahsettiği için satın alma sözleşmesini getirebilir. Ürünlerin izlenmesine ilişkin genel bir pasajı alabilir. A Şirketinin her tedarikçiyle olan ilişkisini takip etme, bu tedarikçileri fatura satırlarına ekleme, tarih filtresi uygulama ve kesin toplam hesaplama konusunda garantili bir mekanizmaya sahip değildir.
Bu her zaman daha büyük bir embedding modeliyle çözülebilecek bir zayıflık değildir. Sorun tamamen anlamsal olmaktan ziyade ilişkisel ve hesaplamalıdır.
Retrieval Yaklaşımları Arasında Seçim
Pratik bir mimari, tek bir politika ve planlama katmanının arkasında birkaç tamamlayıcı retrieval yöntemini ortaya çıkarabilir:
Source documents and operational records
↓
Versioned ingestion pipeline
↓
┌───────────────┼───────────────┬───────────────┐
↓ ↓ ↓ ↓
Exact fields Text indexes Relational data Knowledge graph
↓ ┌────┴────┐ ↓ ↓
Term lookup BM25 Vectors SQL Traversal
└───────────────┬───────────────┴───────────────┘
↓
Router, planner, and policy layer
↓
Validated answer with provenance
| Yöntem | En uygun | Ana güç | Ana sınırlama |
|---|---|---|---|
| Tam eşleşme | Ürün kodları, fatura numaraları, sözleşme kimlikleri, standart varlık kimlikleri | Deterministik kimlik araması | Açıklamaları veya açıklayıcı amacı ele almaz |
| BM25 sözcüksel arama | Nadir terimler, teknik ifadeler, adlar, tam metin anahtar kelime alaka düzeyi | embeddings olmadan güçlü jeton tabanlı sıralama | Anlamsal varyasyona karşı daha az dayanıklı |
| Vektör arama | Kavramlar, açıklamalar, açıklamalar, özetler | Anlamsal olarak ilgili pasajları alır | Kesin tanımlayıcılar ve hesaplamalar için zayıf garantiler; sert filtreler ANN recall'i azaltabilir |
| SQL | Filtreler, birleştirmeler, toplamlar, gruplandırılmış metrikler, mevcut durum | Yazılı ve deterministik hesaplama | Doğrulanmış yapılandırılmış veriler ve açık şema gerektirir |
| Bilgi grafiği | Tekrarlanan çok atlamalı ilişki sorguları | Yeniden kullanılabilir ilişkilerle doğal yol geçişi | Varlık çözünürlüğü, senkronizasyon ve işletim maliyeti ekler |
Anlam için Vektör Arama
Vektör araması, cevabı kavramlara, açıklamalara veya açıklamalara bağlı olan sorular için uygundur:
- Tedarikçi sözleşmesinde hangi riskler anlatılıyor?
- Ürün dokümantasyonu kalibrasyonu nasıl açıklıyor?
- Hasarlı malların iade koşullarını özetleyin.
- Teslimat programı neden değiştirildi?
Bu sorular anlamsal eşleştirmeden yararlanır çünkü kullanıcının ifadeleri belgeden farklı olabilir.
Sözcüksel/yoğun ayrım, retrieval tasarım alanının tamamını kapsamaz. SPLADE gibi öğrenilmiş seyrek retrieval, başka bir retrieval seçeneği [TODO-REF] olarak ortaya çıkarılabilir. ColBERT gibi geç etkileşimli veya çoklu vektör modelleri, başka bir maliyet ve kalite dengesi sunar [TODO-REF]. Half-precision vektörleri ve ikili nicemleme, maliyet ve kalite dengesini değiştirirken indeks boyutunu azaltabilir [1]. Aynı yönlendirme ve füzyon politikası, seçimin evrensel bir öneri olarak ele alınması yerine sorgu sınıfı tarafından değerlendirildiği bu yöntemleri isteğe bağlı dallar olarak ortaya çıkarabilir.
Kimlikler için Sözcüksel ve Tam Eşleşmeli Retrieval
Tam tanımlayıcılar ve sözcüksel uygunluk birbiriyle ilişkilidir ancak farklı retrieval sorunlarıdır. Ürün kodları, fatura numaraları, sözleşme kimlikleri ve standart tedarikçi kimlikleri normalde analiz edilmemiş keyword alanlarında veya eşdeğer tam değer sütunlarında saklanmalıdır. Bir term sorgusu veya veritabanı eşitliği koşulu, kısmen eşleşen belirteçleri sıralamak yerine tam normalleştirilmiş tanımlayıcıyı gerektirebilir. Örneğin Elasticsearch, tam anahtar kelime aramasını analiz edilen tam metin sorgularından ve bir term sorgusunun girişini analiz etmediği belgeleri birbirinden ayırır [2].
Tam eşleşme retrieval aşağıdakiler için uygundur:
- Ürün kodu
PRD-482 - Fatura numarası
INV-2026-0148 - Tedarikçi referans kodu
- Sözleşme tanımlayıcı
BM25 tam metin sözcük dalına aittir. Analiz edilen metni terim istatistiklerini kullanarak sıralar ve özellikle nadir terminoloji, teknik ifadeler, kısaltmalar, ürün adları ve gerçek ifadelerin önemli olduğu pasajlar için kullanışlıdır. Özel bir tanımlayıcı alan olmadığında bile "diferansiyel basınç kalibrasyonu" içeren bir maddeyi alabilir. BM25, tam eşitliğin yerini almayan, sözcüksel alaka düzeyine yönelik bir puanlama modelidir [3].
Embedding alanları anlamsal benzerliği temsil eder. Opak bir tanımlayıcının hiçbir yararlı anlamsal komşuluğu olmayabilir. "PRD-482 için kalibrasyon gereksinimlerini açıklayın" gibi karma bir talep bu nedenle ürün kodu için tam bir filtre, gerçek teknik dil için BM25 ve açıklayıcı pasajlar için retrieval vektörünü kullanabilir. Bu dalları ayrı tutmak, analizcinin PRD-482'i yanıltıcı kısmi eşleşmelere bölmesini ve BM25 puan farklılıklarının deterministik bir aramayı değiştirmesini önler.
Deterministik Değerler için SQL
Yapılandırılmış veritabanları kesin filtreler, toplamalar ve hesaplamalar gerektiren soruları yanıtlamalıdır:
- Mart ayında
PRD-482birim fiyatı ne kadardı? - Tedarikçi Beta'dan kaç birim satın alındı?
- Bir dizi faturadaki toplam vergi tutarı nedir?
- Hangi faturaların genel toplamı bir eşiğin üzerindedir?
Bu cevaplar, ilgili bir chunk metninin ilk beş arama sonucunda görünüp görünmemesine bağlı olmamalıdır. ingestion sırasında kritik alanlar çıkarılıp doğrulandıktan sonra, SQL açık filtreler, tekrarlanabilir hesaplamalar ve öngörülebilir türler sağlar.
İlişkiler için Bilgi Grafikleri
Bilgi grafiği, gerçekleri varlıklar arasındaki ilişkiler olarak temsil eder. Yalnızca metin pasajlarını depolamak yerine aşağıdaki gibi üçlüleri saklayabilir:
(Company A) -[APPROVED_VENDOR]-> (Supplier Beta)
(Supplier Beta) -[SUPPLIES]-> (PRD-482)
(PRD-482) -[BELONGS_TO]-> (Monitoring Products)
Grafikler, soruların yolları içerdiği durumlarda faydalıdır: bir şirketin tedarikçileri, bu tedarikçiler tarafından sağlanan ürünler, ilgili sözleşmeler veya çeşitli kuruluşlar arasındaki bağımlılıklar. Kaynak belgelerin yerini almazlar. Her ilişki, chunk'e veya çıkarıldığı yapılandırılmış kayda bir bağlantıyı muhafaza etmelidir.
Bir Bilgi Grafiği Maliyete Değer Olduğunda
Her retrieval sistemi için bilgi grafiği zorunlu değildir. İlişki basit, istikrarlıysa ve zaten yabancı anahtarlarla temsil ediliyorsa, dizinlenmiş bir SQL birleşiminin çalıştırılması genellikle daha kolaydır ve soruyu daha az senkronize kopyayla yanıtlayabilir. Şirket-tedarikçi ilişkisi ve tedarikçi-ürün tablosu, bir grafik veritabanını otomatik olarak haklı çıkarmaz.
Çok atlamalı geçiş sık olduğunda, aynı ilişkiler birçok sorgu türünü desteklediğinde, yol yapısı yanıtın bir parçası olduğunda ve varlık çözümlemesi yinelenen veya yanlış birleştirilmiş düğümleri önleyecek kadar güvenilir olduğunda bir grafik daha ilgi çekici hale gelir. Ayrıca alanın yeniden kullanılabilir ilişki kaynağına veya heterojen kaynaklar arasında temporal kenarlarına ihtiyacı olduğunda da kullanışlıdır.
Takas faaliyete geçti. Grafik başka bir şemayı, sorgu dilini, depolama motorunu, yetkilendirme yüzeyini, dağıtımı, yedekleme yolunu ve senkronizasyon sürecini tanıtır. Kenar çıkarma ve varlık çözümlemesi izlenmeli, güncellemeler ve silmeler yayılmalı ve grafik sonuçları SQL ve belge dizinleriyle tutarlı kalmalıdır. Bu maliyetler ilişkisel birleştirmelere göre ölçülen faydayı aşarsa, SQL ilişki deposu olarak kalmalıdır.
Ingestion Sırasında Çoklu Temsil Oluşturma
Hibrit retrieval, ingestion'te başlar. Aynı kaynak belge birden fazla senkronize gösterim üretebilir:
- Denetim ve görüntüleme için orijinal belge
- Anlamsal ve BM25 sözcüksel arama için ayrıştırılmış chunks
- Tam eşleşme retrieval için normalleştirilmiş tanımlayıcı alanlar
- Vektör indeksi için Embeddings
- İlişkisel tablolar için doğrulanmış alanlar
- Grafik için normalleştirilmiş varlıklar ve ilişkiler
Bu temsillerin kararlı tanımlayıcıları paylaşması gerekir. Tedarik anlaşmasından çıkarılan bir ilişki, kaynak belge kimliğini, sayfa numarasını, chunk kimliğini, çıkarma sürümünü ve zaman damgasını içermelidir. Yapılandırılmış bir fatura satırı aynı kaynağı korumalıdır.
Örneğin:
{
"source_entity": "Company A",
"relationship": "APPROVED_VENDOR",
"target_entity": "Supplier Beta",
"source": {
"document_id": "agreement-2026-04",
"page": 12,
"chunk_id": "agreement-2026-04-p12-c03"
}
}
Kaynak iki amaca hizmet eder. Oluşturulan yanıtların kanıt göstermesine olanak tanır ve hatalı grafik kenarlarının, bunları oluşturan çıkarımlara kadar izlenmesine olanak tanır.
Chunk Sınırları
Chunk sınırları düzen yapısını veya sabit boyut kurallarını takip edebilir. Düzene duyarlı bölme, başlıkları, cümleleri, listeleri ve sayfa bölgelerini koruyabilir; sabit boyutlu bölme ise öngörülebilir birimler sağlar ancak yapıyı kesebilir. Ortaya çıkan chunks başlıkları, birimleri veya tam tanımlayıcıları kaybedebileceğinden tablolar ve tanımlayıcı bloklar bir kaydın ortasında bölünmemelidir.
Örtüşme, bir sınırın yakınında bağlamı koruyabilir, ancak aynı zamanda ## Combining Hybrid Retrieval Results'teki veri tekilleştirme adımıyla ele alınması gereken yinelenen kanıt maliyeti de yaratır. Güncelleme yayılımı ve üst belge birleştirme için kararlı chunk kimlikleri ve alt öğeden üst öğeye eşlemeler gereklidir. Sınır politikası bir sabitten ziyade değerlendirilen bir parametredir. [YAZAR: bu derleme için ölçülen chunk boyutu/örtüşme sonuçlarını ekleyin]
Grafikte Şema Disiplini
Grafik çıkarma, sınırlandırılmamış bir dil modeli görevi olamaz. Aynı ilişki SUPPLIER, SUPPLIES_TO, VENDOR_OF ve PROVIDES_FOR olarak depolanırsa grafik sorguları tutarsız hale gelir.
Kontrollü bir şema şunları tanımlamalıdır:
- Desteklenen varlık türleri
- Kanonik ilişki adları
- Gerekli özellikler
- Her ilişkinin yönü
- Geçerli kaynak ve hedef türleri
- Temporal özellikleri
- Varlık adları için normalleştirme kuralları
Çıkarma modeli bu şemaya uygun yapılandırılmış çıktı döndürmelidir. Geçersiz ilişki türleri reddedilmeli veya incelemeye yönlendirilmelidir. Varlık çözümlemesi, yinelenen düğümler oluşturmak yerine yazım değişikliklerini ve takma adları sabit kimliklerle eşlemelidir.
Temporal bilgileri de önemlidir. Tedarikçi ilişkisi yalnızca sözleşme süresi boyunca geçerli olabilir. Bir ürün kategorisi değişebilir. Bu nedenle grafik kenarları, etki alanı geçmiş yanıtlara ihtiyaç duyduğunda geçerlilik tarihlerini veya belge sürümü referanslarını desteklemelidir.
Ingestion Yaşam Döngüsü ve Mağazalar Arası Tutarlılık
Tek bir kaynaktan birden fazla temsil oluşturmak tutarlılık sorunu yaratır. Bu nedenle üretim ingestion, idempotent olmalıdır: aynı belge sürümünün aynı çıkarma yapılandırmasıyla yeniden oynatılması, yinelenen chunks, fatura satırları, varlıklar veya kenarlar oluşturmamalıdır. İçerik karması, kararlı kaynak kimliği, belge sürümü ve deterministik alt kimlikler, pipeline'in tekrarlanan çalışmaları tanımasına ve kesintileri güvenli hale getirmesine olanak tanır.
Güncellemeler ve silmeler her gösterime yayılmalıdır. Bir sözleşmenin değiştirilmesi, eski chunks'i, tam eşleşme alanlarını, embeddings'i, çıkarılan varlıkları ve grafik kenarlarını yeni sürümün yayınlanmasından önce veya atomik olarak geçersiz kılmalıdır. Bir faturanın silinmesi, SQL satırlarının kaldırılması veya işaretlenmesi ve chunks'in aranabilir kalmasının engellenmesi gerekir. Eski bir grafik kenarı hâlâ bir ilişki sorgusunu etkileyebiliyorsa kaynak silme işlemi tamamlanmamıştır.
Türetilmiş her kayıt aşağıdaki gibi sürüm meta verilerini taşımalıdır:
{
"document_id": "agreement-2026-04",
"document_version": "7",
"content_hash": "sha256:...",
"parser_version": "parser-3.2",
"extraction_model": "relation-extractor-5",
"extraction_prompt_version": "12",
"chunker_version": "layout-4",
"embedding_model": "retrieval-model-a",
"embedding_revision": "2026-05-18",
"graph_schema_version": "3",
"relational_schema_version": "9"
}
Yeni bir embedding konfigürasyonu, uyumsuz vektörlerin karıştırılması yerine geçiş yapılmasını gerektirir. Yeni temsil, paralel bir dizine doldurulabilir, yeni yazmalarla güncellenebilir, değerlendirilebilir ve atomik bir takma ad veya yönlendirme değişikliği aracılığıyla etkinleştirilebilir. Şema geçişleri aynı disipline ihtiyaç duyar: Saklanan kayıtları ve sorgu şablonlarını birlikte taşıyın, eski ve yeni okumaları doğrulayın ve eşlik denetimleri geçinceye kadar geri almayı koruyun.
Başarısızlıklar tekrarlanabilir olmalıdır. Geçici ayrıştırma, embedding, grafik veya veritabanı hataları sınırlı yeniden denemeleri kullanabilir; sürekli olarak başarısız olan olaylar, kaynak kimliği, aşama, sürüm ve hata ayrıntılarıyla birlikte bir dead-letter queue'e aittir. Yedekleme ve yeniden oynatma işleri, canlı ingestion ile aynı idempotent işleyicilerini kullanmalıdır, böylece operasyonel kurtarma ikinci bir davranış yolu oluşturmaz.
Vektör, grafik ve SQL depoları arasında mükemmel dağıtılmış atomiklik genellikle pratik değildir. Sürümlendirilmiş bir yayın protokolü uygulanabilir bir alternatiftir: türetilmiş yapıtları hizmet vermeyen bir sürüme yazın, beklenen sayıları ve sağlama toplamlarını doğrulayın ve ardından belge sürümünü etkin olarak işaretleyin. Okuyucular yalnızca etkin sürümleri kullanır. Mutabakat işleri, kaynak bildirimlerini her depoyla karşılaştırır, eksik veya eski temsilleri tespit eder ve bunları onarır. Tutarlılık bir varsayımdan ziyade gözlemlenebilir bir değişmez haline gelir.
Grafik Geçişini Yapılandırılmış Hesaplamayla Birleştirme
Önceki toplam harcama sorusu koordineli bir iş akışı olarak yürütülebilir.
İlk olarak grafik, onayı talep edilen dönemle örtüşen satıcıları ve bunlara bağlı ürünleri tanımlar. Örnek, hem onay aralığını hem de talep edilen dönemi yarı açık aralıklar olarak ele alır: [valid_from, valid_to) ve [start_date, end_date). Eksik bir valid_to, onayın açık uçlu kaldığı anlamına gelir.
MATCH (:Company {id: $company_id})-[approval:APPROVED_VENDOR]->(s:Supplier)
WHERE approval.valid_from < $end_date
AND (approval.valid_to IS NULL OR approval.valid_to > $start_date)
MATCH (s)-[:SUPPLIES]->(p:Product)-[:BELONGS_TO]->(g:ProductGroup)
MATCH (g)-[:PART_OF*0..3]->(root:ProductGroup {name: $group_name})
RETURN s.id AS supplier_id, p.code AS product_code
0..3 derinlik sınırı kasıtlıdır ve makalenin grafik araçlarının sınırlı yol uzunlukları kullanması kuralına uyar.
Örtüşme koşulu, bugün onaylanan bir satıcının geçmiş bir çeyreğe dahil edilmesini engeller. Uygulama, $start_date ve $end_date'i, depolanan özelliklerle uyumlu temporal değerleri olarak bağlamalıdır; Cypher, aynı türdeki temporal değerlerinin kronolojik olarak karşılaştırılmasını destekler [4].
Sonuç, bir dizi normalleştirilmiş tedarikçi kimliği ve ürün kodudur. Bu tanımlayıcılar yapılandırılmış bir sorgu için parametreler haline gelir. Bu örnekte validated_invoice_lines, yinelenen kaynak kayıtlarını zaten çözümlemiş ve onaylanmış raporlama döviz kurunu eklenmiş olan yönetilen bir görünüm veya tablodur:
SELECT
COALESCE(
SUM(
CASE WHEN document_type = 'credit_note' THEN -1 ELSE 1 END
* (line_net_amount + line_tax_amount)
* fx_rate_to_reporting_currency
),
0
) AS total_spend_reporting_currency,
COUNT(*) AS matched_line_count
FROM validated_invoice_lines
WHERE company_id = :company_id
AND supplier_id = ANY(:supplier_ids)
AND product_code = ANY(:product_codes)
AND invoice_status IN ('posted', 'paid')
AND is_cancelled = FALSE
AND is_duplicate = FALSE
AND invoice_date >= :start_date
AND invoice_date < :end_date;
Sıfır harcama ve eşleşen verinin olmaması farklı yanıtlardır. matched_line_count, boş bir sonucu, doğrulanmış tutarları sıfıra eşit olan eşleşen satırlardan ayırarak kısmi-tam-karşı politikasının bu farkı korumasına olanak tanır.
Tanıdık quantity * unit_price - discount_amount + tax_amount ifadesi yalnızca bu alanların tam olarak bu muhasebe anlamına sahip olması durumunda geçerlidir. Bir indirim zaten birim fiyata veya net tutara yansıtılmış olabilir, vergi satır veya fatura düzeyinde saklanabilir ve iadeler negatif miktarlar veya ayrı alacak dekontları olarak görünebilir. Formülün körü körüne uygulanması, indirimin iki katına çıkarılmasına veya verginin iki katına çıkarılmasına neden olabilir.
Doğrulanmış line_net_amount ve line_tax_amount alanları hesaplama sözleşmesini daha net hale getirir ancak çevreleyen muhasebe politikası hâlâ önemlidir. İş akışı, iadelerin ve alacak dekontlarının nasıl işaret değiştirdiğini tanımlamalı, iptal edilen veya taslak faturaları hariç tutmalı, çoğaltılan kayıtları tekilleştirmeli, uygun döviz kurunu ve dönüşüm tarihini seçmeli ve hangi fatura durumlarının tanınan harcama olarak sayılacağına karar vermelidir. Sonucun yeniden oluşturulabilmesi için para birimi ve hesaplama politikasının toplamla birlikte döndürülmesi gerekir.
Kaydedilen fx_rate_to_reporting_currency, kayıt sırasında sabit bir oran tipinin ve dönüştürme tarihinin seçildiğini ve doğrulanan her satıra eklendiğini varsayar. Rapor zamanında yeniden fiyatlandırma yapması gereken bir sistemin bunun yerine yönetilen oran tablosuna katılması gerekir.
Grafik, zaman açısından geçerli ilişkileri çözer; SQL deterministik hesaplamayı gerçekleştirir. Dil modeli, fatura değerlerini zihinsel olarak eklememeli veya eksik birleştirmeleri icat etmemelidir. Görevi, isteği anlamak, iş akışını seçmek ve doğrulanan sonucu referanslarla açıklamaktır.
Yönlendirme, Planlama ve Uygulama
Yönlendirici bir isteği analiz eder ve bir veya daha fazla retrieval amacını seçer. Deterministik kuralları, hafif bir sınıflandırıcıyı ve bir dil modelini yapılandırılmış çıktıyla birleştirebilir. Yönlendirmeyi planlama takip eder: Yönlendirici hangi yeteneklerin gerekli olduğuna karar verirken planlayıcı bu gereksinimleri sıralı ve yetkili bir yürütme grafiğine dönüştürür.
User query + authenticated context
↓
Intent and constraint routing
↓
Dependency-aware planning
↓
Exact / BM25 / Vector / SQL / Graph execution
↓
Completeness, policy, and calculation validation
↓
Sourced response or clarification
Talep aynı anda ilişkisel, toplu, anlamsal ve potansiyel olarak kimliğe duyarlı olduğundan tek bir intent alanı tedarik sorusu için yetersizdir. Daha zengin bir sözleşme şöyle görünebilir:
{
"intents": [
{"type": "exact_lookup", "confidence": 0.86},
{"type": "relationship", "confidence": 0.98},
{"type": "aggregate", "confidence": 0.99},
{"type": "semantic", "confidence": 0.74}
],
"confidence": 0.93,
"requires_clarification": false,
"entities": {
"company_name": "Company A",
"product_group": "Monitoring Products"
},
"constraints": {
"time_range": {"start": "2026-01-01", "end": "2026-04-01"},
"invoice_status": ["posted", "paid"],
"reporting_currency": "EUR"
},
"authorization_context": {
"tenant_id": "tenant-42",
"principal_id": "user-817",
"scopes": ["procurement:read", "invoice:aggregate"]
},
"execution_plan": [
{
"step_id": "resolve-company",
"tool": "entity.resolve_company",
"depends_on": []
},
{
"step_id": "find-approved-vendors",
"tool": "graph.find_approved_vendors",
"depends_on": ["resolve-company"]
},
{
"step_id": "find-monitoring-products",
"tool": "catalog.find_products",
"depends_on": ["find-approved-vendors"]
},
{
"step_id": "calculate-spend",
"tool": "finance.aggregate_spend",
"depends_on": ["find-approved-vendors", "find-monitoring-products"]
},
{
"step_id": "retrieve-supporting-clauses",
"tool": "documents.search",
"depends_on": ["find-approved-vendors"]
},
{
"step_id": "validate-result",
"tool": "validation.check_completeness",
"depends_on": ["calculate-spend", "retrieve-supporting-clauses"]
}
]
}
Yetkilendirme bağlamı model tarafından çıkarılmaz ve güvenilmeyen sorgu metninden kabul edilmemelidir. Uygulama bunu kimliği doğrulanmış oturumdan enjekte eder ve planlanan her adım, yürütülmeden önce buna göre kontrol edilir.
Yönlendirme politikası çeşitli ilkeleri takip edebilir:
- Tedarikçi, müşteri, bağımlılık veya sahiplik gibi ilişki dili, grafik geçişini veya ilişkisel birleştirmeyi seçebilir.
- Ürün, fatura, sözleşme veya standart varlık tanımlayıcıları, anahtar kelime alanları, terim sorguları veya eşitlik yüklemleri aracılığıyla tam aramayı seçer.
- Nadir terimler ve teknik ifadeler BM25 sözcüksel retrieval'i seçin.
- Sayısal arama veya toplama, yönetilen bir SQL özelliğini seçer.
- Açıklayıcı, karşılaştırmalı veya özet istekler, vektör veya hibrit metin retrieval'i seçer.
- Kategorileri birleştiren istekler, gerekli tüm amaçları korur ve bağımlılığa duyarlı bir plan üretir.
Güven, bir garanti olarak yorumlanmak yerine amaca göre kalibre edilmelidir. Dönem, para birimi, şirket kimliği veya muhasebe esası belirsizse requires_clarification yürütmeyi durdurmalı ve odaklanmış bir soru üretmelidir. Doğrudan tanımlayıcı araması bir adım gerektirebilir; İlişkileri keşfeden, toplamı hesaplayan ve açıklayıcı kanıtlara ulaşan bir talebin birkaç taneye ihtiyacı vardır. Bu ayrım hem maliyeti hem de güvenilirliği kontrol eder.
Agent Ne Zaman Kullanılmalı
Bir temsilci, bir sonraki eylemin bir ara sonuca bağlı olması durumunda haklı çıkar. Örneğin:
- Grafik geçişi, onaylı tedarikçilerin bir listesini döndürür.
- SQL bu tedarikçiler için fatura toplamlarını döndürür.
- Vektör araması, istisnaları açıklayan sözleşme maddelerini getirir.
- Deterministik bir hesap makinesi son karşılaştırmayı üretir.
- Dil modeli, kaynağıyla birlikte bir yanıt oluşturur.
İş akışı yine de sınırlı olmalıdır. Maksimum sayıda adıma, izin verilen bir araç listesine, yazılı ara duruma, zaman aşımlarına ve açık hata davranışına ihtiyaç duyar. Açık uçlu muhakeme, iş akışı tasarımının yerini almaz.
Hibrit istekler ayrıca genel bir aracı yerine önceden tanımlanmış iş akışlarını da kullanabilir. Yüksek hacimli bir soru türü her zaman grafik → SQL → vektörü takip ediyorsa bu diziyi doğrudan kodlamak daha ucuz ve test edilmesi daha kolaydır.
Model Katmanlaması
Yönlendirme sadece araçları değil aynı zamanda modelleri de seçebilir. Basit sınıflandırma, yeniden yazma ve doğrudan arama yanıtları daha küçük bir modelde çalıştırılabilir. Grafik, SQL ve metin kanıtlarından oluşan karmaşık sentez, daha güçlü bir model gerektirebilir.
Model katmanlaması, daha küçük bir modelin daha büyük bir modelin her çıktısını yeniden üretip üretmediğine değil, rotaya özgü kabul eşiklerine dayanmalıdır. Bir yönlendirme görevi için, gerekli recall amacını, güvenliği, güven kalibrasyonunu, gecikmeyi ve maliyet eşiklerini karşıladığında daha küçük model yeterli olabilir. Sentez için ilgili eşikler bunun yerine faithfulness, alıntı doğruluğu, sayısal tutarlılık ve politika uyumluluğunu içerebilir.
Eşikler riski yansıtmalıdır. Tam bir ürün araması, kimlik ve yetkilendirme doğru kaldığı sürece farklı bir yanıt stilini tolere edebilir. Finansal toplama rotasının daha sıkı bir bütünlüğe ve sayısal doğrulamaya ihtiyacı vardır. Düşük güven, dağıtım dışı girdiler, güvenliğe duyarlı istekler veya başarısız doğrulama daha güçlü bir modele dönüşebilir. Bu basamak, tüm katmanlar aynı düzyazıyı ürettiğinde değil, her katman hizmet sözleşmesini yerine getirdiğinde başarılı olur.
Hibrit Retrieval Sonuçlarını Birleştirme
Kesin, BM25 ve retrieval vektörünün paralel olarak çalıştırılması tek başına tutarlı bir sıralama oluşturmaz. Sistemin açık bir birleştirme ve toplama politikasına ihtiyacı var.
- Meta veri ve yetkilendirme filtreleri uygulayın. Kiracı, erişim kapsamı, belge durumu, dil, ürün ve temporal kısıtlamaları adayları kısıtlamalıdır. pgvector ile ön filtreleme, planlayıcının HNSW dizinini atlamasına neden olabilir, bu da doğruluğu korur ancak yaklaşık arama avantajını kaybeder. Son filtreleme, YSA taramasından sonra çok az sayıda satırın hayatta kalmasına neden olabilir. Katı bir kiracı veya yetkilendirme koşulu bu nedenle recall'i sessizce azaltarak güvenlik kontrolünü retrieval kalite kontrolüyle birleştirebilir. Kullanılabilir araçlar arasında filtre sütununun indekslenmesi,
ef_search'in yükseltilmesi, pgvector 0.8.0'dahnsw.iterative_scankullanılması veya filtrelenen küme küçük olduğunda tam aramaya geri dönülmesi yer alır. Recall yalnızca filtrelenmemiş sorgularda değil, filtrelenmiş sorgularda tam aramaya göre ölçülmelidir [1]. Füzyondan sonra da son bir politika kontrolü yapılması gerekiyor. - Aday birliği oluşturun. Her uygun retriever'ten yeterince geniş bir sonuç kümesi toplayın. Kesin eşleşmeler deterministik bir kimlik bayrağıyla girilebilirken, BM25 ve vektör dalları sıralanan adaylara ve puanlara katkıda bulunur.
- Yinelenen chunks'i kaldırın. Kararlı chunk kimlikleri, içerik karmaları, örtüşen ilişkiler ve kaynak aralıkları, birden fazla dizinde veya örtüşen pencerede göründüğü için aynı kanıtın yapay destek almasını engeller.
- Sigorta sıralamaları. Reciprocal Rank Fusion, BM25 ve vektör puanlarının bir ölçeği paylaştığını varsaymadan sıralama konumlarını birleştirir [5]. Ağırlıklı RRF, doğrulanmış bir sorgu sınıfı için bir dalı vurgulayabilir. Ağırlıklı puanların birleştirilmesi başka bir seçenektir ancak ham puanların önce normalleştirilmesi veya kalibre edilmesi gerekir; aksi takdirde sayısal olarak daha büyük ancak karşılaştırılamaz bir puan aralığı sonuca hakim olur.
- İndirgenmiş kümeyi yeniden sıralayın. Çapraz kodlayıcı, sorguyu ve her adayı birlikte puanlayabilir ve böylece daha yüksek istek süresi maliyetiyle ayrıntılı alaka düzeyini iyileştirebilir. Kesin kimlik ve güvenilir meta veri güçlendirmeleri tamamen reranker'e bırakılmak yerine belirleyici özellikler olarak kalabilir.
- Ana belgeye göre toplayın. Bir anlaşmadaki birkaç güçlü alt chunks, diğer tüm kaynakları dışarıda bırakmamalıdır. Ana belge birleştirme, alt kanıtları birleştirebilir, belge başına katkıyı sınırlayabilir ve yanıt modeli daha geniş bir bağlama ihtiyaç duyduğunda seçilen alt öğeyi üst bölümüne genişletebilir.
Temsilci bir pipeline, 40 vektör adayını, 40 BM25 adayını ve herhangi bir tam eşleşmeyi birleştirebilir; tekilleştirme ve bunları birleştirme; en iyi 20'yi yeniden sıralayın; daha sonra küçük ve çeşitli bir kanıt seti seçin. Bu sayılar varsayılan değildir. Aday derinliği, füzyon ağırlıkları, belge başına sınırlar ve reranker derinliği, tam tanımlayıcılar, teknik dil, anlamsal sorular ve izne duyarlı durumları içeren bir sorgu kümesinde seçilmelidir. [YAZAR: altın sette tam+BM25+vektör füzyonu ve yalnızca vektör füzyonu ve bu derinlikleri üreten ayarlama için recall@k'yi ekleyin]
Kaynak ve Çalışma Zamanı Doğrulaması
Çok kaynaklı bir cevap, her bir sonucun nasıl üretildiğini ortaya koymalıdır. Yararlı bir dahili sonuç nesnesi, kanıtları hesaplamalardan ayırabilir:
{
"result": {
"total_spend": "184250.75",
"currency": "EUR"
},
"inputs": {
"supplier_ids": ["SUP-18", "SUP-27"],
"product_codes": ["PRD-482", "PRD-619"],
"period": "2026-Q1"
},
"sources": [
"agreement-2026-04-p12-c03",
"invoice-2026-0148-line-04",
"invoice-2026-0211-line-07"
]
}
Parasal değerler uçtan uca tam ondalık türleri kullanır ve dizeler halinde serileştirilir çünkü ikili kayan nokta, mimarinin garanti ettiği determinizmi sessizce bozar.
Nihai cevap verilmeden önce, deterministik kontroller, görüntülenen miktarın araç sonucuyla eşleştiğini, belirtilen her kaynağın mevcut olduğunu, gerekli birimlerin mevcut olduğunu ve hesaplamaya hiçbir desteklenmeyen varlığın girmediğini doğrulamalıdır.
Bir araç hiçbir sonuç döndürmezse sistem bu belirsizliği korumalıdır. Eksik bir fiyatı veya ilişkiyi, model belleğinden oluşturulan makul bir değerle değiştirmemelidir.
Retrieval ve Araç Sınırlarında Güvenlik
Hibrit retrieval, tek bir isteğin belge, vektör, grafik, SQL, önbellek ve araç sınırlarını aşabilmesi nedeniyle güvenlik yüzeyini genişletir. Bu nedenle yetkilendirme, prompt talimatı olarak değerlendirilmek yerine her veri hizmeti tarafından uygulanmalıdır.
Kiracı yalıtımı, güçlü fiziksel veya operasyonel ayırma gerektiğinde ayrı veritabanları, şemalar, dizinler veya ad alanları kullanabilir. Paylaşılan mağazaların, model tarafından oluşturulan bağımsız değişkenler tarafından göz ardı edilemeyecek zorunlu kiracı yüklemlerine ve ilkelerine ihtiyacı vardır. SQL rotaları satır düzeyinde yetkilendirmeyi zorunlu kılmalıdır; PostgreSQL satır güvenliği politikaları, kullanıcının hangi satırları okuyabileceğini sınırlamak için veritabanı düzeyinde bir mekanizmadır [6]. Grafik rotaları eşdeğer düğüm ve uç düzeyinde kontrollere ihtiyaç duyar; böylece bir sözleşmeye erişim, bağlı her tedarikçiyi veya faturayı otomatik olarak açığa çıkarmaz.
Alınan içerik güvenilmez kanıttır. Bir sözleşme, web sayfası veya yüklenen belge, modele politikayı göz ardı etmesini veya bir araç çağırmasını söyleyen prompt enjeksiyon metni içerebilir. Araç çıktısı aynı saldırıyı bir sonraki akıl yürütme adımına taşıyabilir. Alınan belgeler ve araç sonuçları, güvenilir talimatlardan açıkça ayrılmalı, riske göre filtrelenmeli ve izin verilmesi veya yürütme planının yeniden tanımlanması engellenmelidir. OWASP, alınan içeriği ve araç çıktısını açıkça dolaylı prompt enjeksiyon yüzeyleri olarak ele alır [7].
SQL erişimi, retrieval ve analitik yollar için, model tarafından oluşturulmuş SQL dizeleri yerine parametreli sorgularla salt okunur olmalıdır [8]. Daha yüksek riskli sistemler, izin verilenler listesindeki sorgu şablonlarını, saklı prosedürleri veya genel bir SQL yürütücüsü yerine finance.aggregate_spend gibi yönetilen bir anlamsal katmanı açığa çıkarabilir. Grafik araçları benzer şekilde ilişki türlerini, geçiş derinliğini ve döndürülen özellikleri kısıtlayabilir.
En az ayrıcalıklı araç izinleri, her yeteneği, ihtiyaç duyduğu veri ve işlemle sınırlar. Belge arama aracının fatura yazma erişimine ihtiyacı yoktur; toplama aracının rastgele ağ erişimine ihtiyacı yoktur. Hız sınırları, zaman aşımları, satır ve sonuç boyutu sınırları ve kiracı başına kotalar hem kötüye kullanımı hem de kazara yayılmayı azaltır. Bilgi istemlerine ve günlüklere girmeden önce PII düzenlenmeli veya en aza indirilmelidir. Denetim kayıtları, kimliği doğrulanmış anaparayı, rotayı, araç argümanlarını, politika kararını, kaynak kimliklerini ve döndürülen sonucu, gereksiz hassas içeriği kopyalamadan birbirine bağlamalıdır.
Güvenlik doğrulaması yürütme sonrasında devam eder. Kiracı, satır, kenar ve belge yetkilendirmesi için son bağlam ve alıntı kümesi yeniden kontrol edilmelidir. Hiçbir füzyon puanının veya grafik yolunun politikayı geçersiz kılmasına izin verilmez.
Yönlendiriciyi ve Araçları Değerlendirme
Her yönlendirme kategorisinin, çeşitli geçerli amaçlara sahip istekler de dahil olmak üzere altın bir sorgu kümesine ihtiyacı vardır. Değerlendirme şunları ölçmelidir:
- Amaç başına precision, recall ve F1
- Çok amaçlı istekler için tam amaç kümesi doğruluğu
- Güven kalibrasyonu ve yükseltme kalitesi
- Açıklama precision ve recall
- Varlık çıkarma doğruluğu
- Kısıtlama ve yetkilendirme bağlamı yönetimi
- Uygulama planı geçerliliği ve bağımlılık doğruluğu
- Araç çağrısı geçerliliği
- Retrieval recall her aracın içinde
- Hesaplama tutarlılığı
- Kaynak bütünlüğü
- Uçtan uca cevap faithfulness
- Yetkisiz retrieval ve enjeksiyon direnci testleri
- Rotaya göre gecikme ve maliyet
[YAZAR: altın küme boyutunu, oluşturma yöntemini ve amaç başına temel puanları ekleyin]
Karışık sorgular özel ilgiyi hak eder çünkü görünüşte makul bir cevap gerekli bir dalın atlanmasına neden olabilir. Bir sözleşmeyi doğru şekilde özetleyen ancak SQL toplamasını unutan bir yanıt, her cümle doğru olsa bile eksiktir.
Araç izlemeleri, seçilen her amacı, güveni, açıklama kararını, çıkarılan varlık ve kısıtlamayı, plan bağımlılığını, bağımsız değişkenleri, döndürülen satırları veya chunks'i, hesaplama çıktılarını, politika kontrollerini ve son alıntıları kaydetmelidir. Bu izler, yanlış yanıtlarla ilgili belirsiz şikayetleri yönlendirme, planlama, retrieval, yetkilendirme, hesaplama veya generation'teki belirli hatalara dönüştürür.
Model katmanları ayrı rota puan kartlarına göre değerlendirilmelidir. Küçük bir yönlendirici, çok amaçlı recall, kalibrasyonu, güvenliği, p95 gecikmesi ve maliyeti, zararsız uç durumlarda etiketleri daha büyük bir modelden farklı olsa bile hedef eşikler dahilinde kaldığında başarılı olabilir. Bir sentez modeli, faithfulness, alıntı kalitesi ve sayısal tutarlılık için farklı eşiklere ihtiyaç duyabilir. Dağıtım kararları, her modeli rotasına ilişkin hizmet sözleşmesiyle karşılaştırmalı, en büyük modelle metinsel eşdeğerlik gerektirmemelidir.
Çok Amaçlı İş Akışlarında Arıza Sınırları
Birkaç retrieval temel öğesinin birleştirilmesi yeni hata modları oluşturur. Bir grafik doğru tedarikçileri döndürebilirken SQL eşleşen fatura satırlarını bulamıyor. Tam arama bir ürün kodunu bulabilirken retrieval vektörü açıklayıcı bir pasaj döndürmez. Sağlam bir iş akışı, kısmi kanıtları tam bir yanıttan ayırmalıdır.
Her aracın yazılı bir istek ve yanıt sözleşmesi olması gerekir. Grafik aracı, kurallı varlık kimliklerini ve kaynak referanslarını döndürebilir. SQL aracı, yazılan değerleri, birimleri, toplama mantığını ve satır kaynağını döndürebilir. Vektör aracı chunks'i, puanları ve belge meta verilerini döndürebilir. Dil modeli, başka bir aracın düzyazısından eksik alanları çıkarmamalıdır.
Aracın yürütülmesi çeşitli sınırları uygulamalıdır:
- Her istek, aracın yazılan giriş şemasına göre doğrulanır.
- Grafik geçişleri, onaylanmış ilişki türlerini ve sınırlı yol uzunluklarını kullanır.
- Hesaplamalarda açık birimler ve para birimleriyle deterministik işlevler kullanılır.
- Her araç çağrısının bir zaman aşımı ve maksimum sonuç boyutu vardır.
- Döndürülen varlık kimlikleri başka bir sisteme aktarılmadan önce doğrulanır.
- Ara sonuçlar kaynak, şema ve çıkarma sürümlerini korur.
Kısmi başarısızlık açık bir politikaya ihtiyaç duyar. Grafik üç tedarikçi buluyorsa ancak SQL yalnızca iki tedarikçinin fatura verilerini doğruladıysa sistem kısmi toplamı tam toplam olarak sunmamalıdır. Yapılandırılmış, tamamlanmamış bir sonuç döndürebilir:
{
"status": "partial",
"calculated_suppliers": ["SUP-18", "SUP-27"],
"missing_suppliers": ["SUP-31"],
"total_spend": "184250.75",
"currency": "EUR"
}
Nihai yanıt, sınırlamayı açıklayabilir veya inceleme talebinde bulunabilir. Tamlık doğruluğun bir parçasıdır.
Yeniden denemeler araca özel olmalıdır. Geçici bir SQL zaman aşımı, grafik çıkarma işlemini tekrarlamadan yeniden denenebilir. Şema doğrulaması tarafından reddedilen bir grafik sonucu değiştirilmeden yeniden denenmemelidir; düzeltilmesi veya insan tarafından incelenmesi gerekiyor. Doğrulanmış ara sonuçların kalıcı olması maliyeti azaltır ve başarılı adımların gereksiz yere tekrarlanmasını önler.
Daha önce tanımlanan güvenlik kontrolleri her adımda aktif kalır. Kısmi yürütme hiçbir zaman kiracıyı, satırı, kenarı veya belge yetkilendirmesini genişletmez.
Bu sınırlar, hibrit bir mimarinin şeffaf olmayan bir etmen döngüsüne dönüşmesini engeller. Dil modeli yetenekleri koordine ederken, yazılı sözleşmeler, politikalar ve deterministik doğrulayıcılar sistem bütünlüğünü korur.
Uygulama Notu: MCP, Embeddings ve HNSW Farklı Katmanlardır
Araç protokolleri, embedding modelleri, uygulama hizmetleri ve vektör indeksleri farklı sorunları çözer. Sınırlarını açık tutmak, retrieval yolunun güvenliğini sağlamayı ve değiştirmeyi kolaylaştırır.
LLM / Application
↓
MCP Host
↓
MCP Client
↓
MCP Server Tool
↓
Application Service
↓
Database and indexes
MCP ana bilgisayarı, istemci bağlantılarını ve izinlerini yöneten yapay zeka uygulama bileşenidir. Bir MCP istemcisi, bir MCP sunucusuna olan protokol bağlantısını sürdürür. Sunucu araçları yayınlar; seçilen bir araç bağımsız değişkenlerini doğrular ve uygulamaya ait bir hizmeti çağırır. Bu hizmet, tam arama, BM25 araması, embedding çıkarımı, vektör araması, grafik geçişi veya SQL işlemlerini gerçekleştirir. Resmi MCP mimarisi bu ana bilgisayar-istemci-sunucu ayrımını açıklamaktadır [9].
MCP, embeddings'i oluşturmaz, HNSW dizinlerini oluşturmaz veya vektör benzerliğini tek başına yürütmez. Araç keşfini ve çağrılmasını standartlaştırır. MCP araçları bir inputSchema bildirir ve bir outputSchema bildirebilir; böylece yalnızca serbest metin sorgusu yerine yazılı, yapılandırılmış argümanlara ve sonuçlara izin verilir [10]. Bir tedarik arama aracı şunları kabul edebilir:
{
"query_text": "calibration requirements",
"identifiers": {
"product_codes": ["PRD-482"],
"contract_ids": []
},
"retrieval_modes": ["exact", "bm25", "vector"],
"filters": {
"document_types": ["agreement", "product_manual"],
"valid_at": "2026-03-31"
},
"limit": 20
}
Güvenilen kiracı ve ana bağlam, model tarafından sağlanan bağımsız değişkenlerden değil, uygulama veya ana bilgisayar tarafından yönetilen kimliği doğrulanmış bir oturumdan gelmelidir. Güvenilir yetkilendirme içeriği hiçbir zaman MCP protokol düzeyindeki bir oturuma bağlanmamalıdır. 2026-07-28 sürüm adayı, protokol oturumunu ve Mcp-Session-Id'i kaldırır, _meta isteğinde protokol ve istemci bilgilerini taşır ve uygulama durumunu sıradan araç argümanları olarak iletilen açık tanıtıcılara bırakır [11]. Yukarıda açıklanan ana bilgisayar-istemci-sunucu ayrımı bu revizyonlarda da geçerlidir; yalnızca oturum mekaniği değişti.
Veri katmanında bir pgvector tablosu şöyle görünebilir:
CREATE TABLE document_chunks (
id BIGSERIAL PRIMARY KEY,
tenant_id TEXT NOT NULL,
document_id TEXT NOT NULL,
document_version TEXT NOT NULL,
chunk_text TEXT NOT NULL,
embedding VECTOR(1024),
metadata JSONB NOT NULL
);
CREATE INDEX document_chunks_tenant_document
ON document_chunks (tenant_id, document_id);
CREATE INDEX document_chunks_embedding_hnsw
ON document_chunks
USING hnsw (embedding vector_cosine_ops);
ALTER TABLE document_chunks ENABLE ROW LEVEL SECURITY;
ALTER TABLE document_chunks FORCE ROW LEVEL SECURITY;
CREATE POLICY document_chunks_tenant_isolation ON document_chunks
USING (tenant_id = current_setting('app.tenant_id', true));
Kiracı sütunu, bileşik dizin ve satır düzeyinde güvenlik politikası, daha sonraki bir eklentiden ziyade retrieval şemasının bir parçasıdır [6]. Bu politika aynı zamanda füzyon bölümünde açıklanan sabit filtre ve yaklaşık dizin etkileşimini de oluşturur, dolayısıyla recall'in kiracı tarafından filtrelenen sorgularda değerlendirilmesi gerekir.
Uygulama hizmeti uyumlu bir sorgu gösterimi oluşturur ve bunu PostgreSQL'e gönderir; PostgreSQL, yaklaşık komşuları almak için HNSW dizinini kullanır. pgvector, varsayılan olarak tam aramayı ve hız için recall'in bir kısmını takas eden isteğe bağlı yaklaşık bir dizin olarak HNSW'i belgeler [1]. Bu veritabanı mekaniği, hizmetin MCP, HTTP, bir kuyruk veya dahili bir işlev aracılığıyla çağrılmasına bakılmaksızın aynı kalır.
Sorgulama ve belgeleme embeddings'in her zaman aynı kodlayıcıdan gelmesi gerekmez. Bunların aynı kodlayıcıdan veya aynı gizli alanı üretmek üzere eğitilmiş uyumlu sorgu ve belge kodlayıcılardan gelmesi gerekir. Asimetrik retrieval modelleri kasıtlı olarak farklı sorgu/belge istemleri veya kuleleri kullanabilir; Örneğin Cümle Dönüştürücüleri, asimetrik anlamsal arama için ayrı sorgu ve belge kodlama yollarını ortaya çıkarır [12].
Ortak tek kodlayıcı tasarımında uyumluluk, model adının, model revizyonunun, vektör boyutunun, normalleştirme politikasının, sorgu/belge prompt veya talimat yapılandırmasının ve indeksleme ve sorgu zamanında kullanılan benzerlik fonksiyonunun sürümlendirilmesi ve eşleştirilmesiyle sağlanmalıdır. Bir uyumsuzluk, API türleri hala geçerli görünse bile, depolanan vektörleri sessizce karşılaştırılamaz hale getirebilir.
Uzun Bağlam ve Agentic Arama İtirazı
En güçlü alternatif, bu retrieval altyapısının çoğundan kaçınmaktır. Dosyaları doğrudan arayan bir aracıyla eşleştirilmiş uzun bağlamlı bir model, önceden hesaplanmış bir ingestion pipeline, senkronize vektör ve grafik gösterimleri veya bir çapraz depo şeması olmadan, talep üzerine kaynak materyali okuyabilir. Temsilci, dosyaları seçebilir, içeriklerini inceleyebilir ve tek bir esnek iş akışı içinde bir yanıt oluşturabilir.
Bu yaklaşım, küçük veya yavaş hareket eden derlemler, keşif soruları, düşük sorgu hacmi ve prototipler için daha iyi bir tasarım olabilir. Ayrıca, sorgu başına maliyet ve gecikmenin kontrol kısıtlamaları olmadığı ve soruların dayanıklı yapılandırılmış gösterimler gerektirmediği durumlarda da makul olur. Bu durumlarda operasyonel basitlik, çok depolu retrieval mimarisinin avantajlarından daha ağır basabilir.
Tedarik örneğinin merkezindeki gereksinimleri ortadan kaldırmaz. Belirleyici bir toplam hâlâ bir retrieval sonucu değildir; yetkilendirmenin yine de bir aracının okumayı seçtiği dosyalar yerine veri hizmeti tarafından uygulanması gerekir ve rapor edilen bir sayının yine de tekrarlanabilir kaynağına ihtiyacı vardır. Hacim açısından, sorgu başına işlem maliyeti mimari bir sorun olmayı sürdürüyor ve çok kiracılı yalıtım, modelin doğru dosyaları seçmesine bağlı olamaz. [YAZAR: sorgu başına maliyet karşılaştırmasını ekleyin]
Doğru Gösterimi Seçmek
Vektör arama, bilgi sistemlerinin temel bir bileşeni olmayı sürdürüyor ancak çözdüğü sorun için kullanılmalıdır: yapılandırılmamış içerik üzerinde anlamsal retrieval. Tam kimlik, sözcüksel uygunluk, ilişkiler ve hesaplamalar, onlar için tasarlanmış temsilleri hak eder.
Güvenilir bir mimari, tam eşleşmeli retrieval, BM25, vektör aramayı, yönetilen SQL'i ve ilişki karmaşıklığı bunu haklı çıkardığında açık bir yönlendirme ve planlama politikasının arkasındaki bilgi grafiğini birleştirir. Aracıları yalnızca ara sonuçların sonraki eylemleri belirlediği durumlarda kullanır. Hesaplamaları deterministik tutar, temsiller arasındaki kaynağı korur ve her aracı ölçülebilir bir bileşen olarak ortaya koyar.
Sonuç yalnızca daha büyük bir retrieval yığını değildir. Sorunun yapısının cevap yolunun yapısını belirlediği bir sistemdir.
Referanslar
1.pgvector. “Postgres için açık kaynaklı vektör benzerlik araması.” Resmi belgeler. 2. Elastik. “Terim sorgusu.” Elasticsearch Referansı. 3. Elastik. “Benzerlik ayarları: BM25 benzerliği.” Elasticsearch Referansı. 4. Neo4j. “Değer türlerinin eşitliği, sıralaması ve karşılaştırılması.” Cypher Manual. 5. Cormack, G.V., Clarke, C.L.A. ve Büttcher, S. (2009). “Reciprocal Rank Fusion Condorcet ve Bireysel Dereceli Öğrenme Yöntemlerinden Daha İyi Performans Gösteriyor.” SIGIR 2009. 6. PostgreSQL Küresel Geliştirme Grubu. “Satır Güvenliği Politikaları.” PostgreSQL Belgeleri. 7. OWASP Hile Sayfası Serisi. “LLM Prompt Injection Önleme.” 8. OWASP Hile Sayfası Serisi. “SQL Enjeksiyon Önleme.” 9. Model Bağlam Protokolü. “Mimari.” Spesifikasyon. 10. Model Bağlam Protokolü. “Araçlar.” Belirtim. 11. Model Bağlam Protokolü. “2026-07-28 MCP Spesifikasyon Sürümü Adayı.” 12. Cümle Transformatörleri. “Anlamsal Arama.” Belgeler.