Uzmanlık · Bilgi tabanları ve semantik arama

Bir asistanın yanıt vermesine izin verilen korpusu, neyin dahil edildiği, nasıl bölündüğü, nasıl arandığı ve kaynak değiştiğinde ne olduğuna dair kurallarla birlikte oluşturuyoruz.

Müşterilere yanıt veren bir asistan, yalnızca okuduğu corpus kadar iyidir. Corpusla biz ilgileniyoruz: belgelerden ve siteden çıkarım, parçalara ayırma, indeksleme, geri getirme, insan onay kapısı ve yenileme. Anlamsal aramanın ne zaman DEĞERLİ OLMADIĞI sorusunun yanıtını da içerir.

Bir projeyi konuşalım

Zaten kurduklarımızHer aşama için yerel uygulamalar var, ancak durumları farklı ve açıkça söylenmeli. Kendi vektörleriyle çalışan: günlük kullanılan iç bir board’un belleği, `vector(1536)` sütunu, kosinüs mesafesi üzerinde `ivfflat` dizini, 0,35 benzerlik eşiği ve yalnızca değişenleri 30 dakikada bir yeniden dizine alan bir döngü. Sağlayıcı vektörleriyle çalışan: sesli ajanların bilgi tabanı, 500 parça ve 100 örtüşme ile sağlayıcının geri getirme motoruna senkronize edilir. Üretimde **vektörsüz** çalışan: metin asistanları platformunun bilgi tabanı — çıkarma, parçalama, asistan başına yapılandırma ve hibrit geri getirme yazıldı ve çalışıyor, ancak dizinleme yolu vektör sütununa `null` yazıyor; bu yüzden hibrit skor leksikale düşüyor ve kod bunu `keyword-only` etiketiyle kendi kendine söylüyor. Yazılı olup üretimde henüz başlatılmayan: sesli platformun kendi `pgvector` hattı; migrasyon başlığında «LOCAL ONLY — do not push to prod» ibaresi var. Bir hizmet bu haritayla satılır, onsuz değil.

Müşterilerle konuşan bir asistan hiçbir şeyi „bilmez”. Her soruda, biri önceden birkaç metin parçasını arar ve onları önüne koyar, o da yanıtı bunlardan oluşturur. Yanıt kalitesi neredeyse bütünüyle o arama aşamasında belirlenir, model seçiminde değil. Bu yüzden bu hizmet model hakkında değil, korpus ve geri getirme hakkındadır.

İş, birbirinden bağımsız olarak bozulan dört bölümden oluşur. Çıkarma: hangi dosyalardan ve hangi sayfalardan kullanılabilir metin aldığımız ve bunu yapamadığımızda ne yaptığımız. Bölme: parçalar ne kadar büyük, ne kadar örtüşüyor, bir cümleyi nerede kesiyoruz. Geri getirme: belirli bir soru için parçalar nasıl seçiliyor, kaç tane ve hangi kritere göre. Yenileme: kaynak belge değiştiğinde ne oluyor. Bir sistem bunların üçününde kusursuz olup dördüncüsü yüzünden işe yaramaz olabilir.

Birçok kişinin atladığı ve sonucu tamamen değiştiren ekstra bir aşama vardır: onay kapısı. Konuşmalardan kendi kendine büyüyen bir korpus, çok hızlı şekilde kimsenin doğrulamadığı yanıtlar içermeye başlar. Kurduğumuz döngü ters çalışır: ajan „bu bilgiye sahip değilim” dediğinde, soru „beklemede” durumuyla kaydedilir, bir kişi bildirim alır ve yanıt verir, ardından yanıtı „onaylandı” durumuna geçer ve ancak o zaman korpusa girer. Bilgi, gerçek eksikliklerden, zincirde bir insanla birlikte büyür.

Ve popüler olmayan kısım: semantik arama her zaman doğru seçim değildir. Kendi halka açık platformumuz için onu bilinçli olarak reddettik. Korpus, platformun kendi metnidir; her biri geldiği sayfayı taşıyan kısa pasajlara bölünmüştür ve kelime örtüşmesiyle işaretlenir. Vektör yok, vektör deposu yok, ek ağ isteği yok — ve daha önemlisi, depo dışından hiçbir kaynak yok. Asistan yalnızca sitede zaten yazanı tekrar edebilir ve her yanıt, bir insanın yazdığı bir sayfada doğrulanır. Bu, bütün uydurma-karşıtı mekanizmadır.

Neleri kapsıyor

Çalışma, bileşenlerine ayrılmış hâliyle

Metni çıkarıyoruz ve yapamadığımızda bunu açıkça söylüyoruz

Düz metinden, markdown’dan, günlüklerden, CSV’den, JSON’dan, DOCX ve PDF’den. DOCX bir arşiv gibi açılır ve içindeki XML belgesi okunur; PDF, sayfa yerleşimini koruyan standart çıkarıcıdan geçer ve bu yoksa, metin operatörlerini doğrudan dosyadan okuyan bir yedek vardır. Önemli durum, çalışmadığı zamandır: taranmış bir PDF, yani bir görüntü, seçilebilir metin içermez ve sistem açık bir mesaj döndürür — DOCX veya metin yükleyin, ya da dosyayı önce optik tanımadan geçirin. Optik tanıma uygulamamız yok ve varmış gibi davranmıyoruz.

Parçaları örtüşmeyle bölüyoruz, cümlelerin arasından keserek, içlerinden değil

Kullandığımız varsayılan değerler: sesli pipeline için 50 örtüşmeyle 500 sözcüksel birim, metin için 150 örtüşmeyle 1.200 karakter; sesli sağlayıcı tarafında 100 örtüşmeyle 500. Örtüşme vardır çünkü iki parça arasında ortadan kesilen bir cümle her ikisi için de kullanılamaz hale gelir. Cümle ayırıcı, çalıştığımız diller için yazılmıştır: cümle sonunu, Romence diakritikler dahil, Latin **veya Kiril** büyük harfi izlediğinde tanır. İngilizce için yazılmış bir ayırıcı Romence’de kötü, Rusça’da daha da kötü keser.

Vektörlerle orada indexliyoruz, bunu nerede yapmadığımızı da söylüyoruz

Varsayılan temsil modeli `text-embedding-3-small`dır, 1.536 boyutludur ve doğrudan sağlayıcıdan değil, modeller kapımız üzerinden istenir — böylece bilgi tabanı koduna dokunmadan sağlayıcı değiştirilebilir. Veritabanında sütun, kosinüs mesafesi üzerinde `ivfflat` indexine sahip bir vector türündedir. Migration’da yazılmış bir yedek strateji vardır: vektör uzantısı mevcut değilse, şema her zaman metin üzerinde trigram indexiyle oluşturulur ve geri getirme leksikal benzerliğe geçer. Bu varsayımsal değildir — tam da uzantı haklarının her kurululumda garanti olmaması nedeniyle yazılmıştır.

Hibrit geri getirme, ağırlıklar görünür halde

Son puan 0,7 vektörel benzerlikten artı 0,3 kelime eşleşmesinden, sözlüksel kısım normalleştirilmiş olarak hesaplanır. Bir aday kümesi puanlanır ve ilk parçalar tutulur; modele gönderilen bağlam, her parçayı bir azami uzunlukta keser, böylece tek bir uzun belge tüm alanı kaplamaz. Yapılandırma, asistan başına temeldedir: geri getirme açık ya da kapalı, soru başına azami parça sayısı (varsayılan 5, 1 ile 20 arasında sınırlı), benzerlik eşiği, arama türü — semantik, sözcüksel veya hibrit — ve sözcüksel kısmın ağırlığı.

Onay kapısı: bilgi eksiklerden büyür, zincirde bir insanla

Asistan bilginin olmadığını yanıtladığında, soru “beklemede” durumuyla bir tabloda yazılır, geldiği kanal ile işaretlenir — ses veya widget. Bir insan bildirim alır ve doğrudan mesaja yanıt verir; bir webhook yanıtı alır, girişi “onaylandı” durumuna geçirir ve oradan asistanın bağlamına girer. Olası durumlar dörttür: beklemede, onaylandı, yok sayıldı, yinelendi — ve yinelenenler, aynı eksikliğin on farklı ifadesi birikmesin diye, özgün soruya bir referansla bağlanır. Asistana teslim, onaylanan her giriş için bir kez yapılır.

Yenileme: kaynak değiştiğinde ne olur

Eklemede içeriğin SHA-256 fingerprint’i hesaplanır; metin zaten indekslenmiş bir şeyle aynıysa yeniden kullanılır ve yeni bir vektör temsili ödenmez. Belge değiştiğinde, parçaları bütünüyle silinir ve yeniden yazılır — kaynak bazında tam değiştirme, kısmi güncelleme değil; çünkü kısmi güncelleme eski sürümden yetim parçalar bırakır ve bunlar sitenin çelişen yanıtlar üretmesine yol açar. Kaynağın görünür bir durum döngüsü vardır: beklemede, işleniyor, yeniden işleniyor, hazır veya başarısız; yeniden indeksleme kaynağa özel olarak noktasal istenebilir.

Değişmeyeni yeniden indekslemiyoruz

Sadece büyüyen bir liste üzerinde her otuz dakikada bir çalışan bir döngüde, dokunulmamış bir öğe için temsilin yeniden hesaplanması, kıpırdayamayacak bir vektör için tekrarlanan bir ödemedir. Döngümüz son dokunulma anını son indeksleme anıyla karşılaştırır ve değişmemiş olanı atlar. Temsiller toplu halde istenir, tek tek değil. Bunlar maliyet ayrıntılarıdır, ama bir bilgi tabanının aylık maliyeti neredeyse tamamen burada belirlenir.

Bağlı bir katalog, yüklenmiş bir liste değildir

Fark biçimde değil, zamanda. Yüklenmiş bir liste, yükleme anında doğrudur: fiyat, stok ve yeni ürünler, biri yeniden yüklemeyi hatırlayana kadar donmuş kalır — ve genelde, bir müşteri üç aylık eski bir fiyatı sorunca, kimsenin hatırlamadığı anlaşılır. Bağlı bir katalog soru anında, kaydı tutan kaynaktan okunur. Bu yönde yaptığımız şey: olağan anahtarlar üzerinden bir JSON veya CSV’de ürün koleksiyonlarını tanıyan bir çıkarıcı ve yapı alışılmadık olduğunda, kesin olarak verilen bir biçimde yanıt verme yükümlülüğüyle bir modelden yardım isteyen bir araç; ve mağazanın canlı sayfasından fiyatı okuyan bir tarayıcı. En iyi yol, varsa, mağazanın kendi yapılandırılmış arayüzü olmaya devam eder — ama bu mağaza bazında doğrulanır, varsayılmaz.

Bir siteyi tarama: önce harita, sonra keşif

Önce, yaygın adlandırma varyantlarında site haritası aranır ve iç içe haritalar iki düzey boyunca açılır. Yalnızca harita yoksa, aynı kaynak üzerinde katı biçimde genişlik öncelikli keşfe geçilir; sayfa limiti yapılandırılabilir (varsayılan 50, 200 ile sınırlandırılmış). Fiilen kullanılan strateji geri raporlanır — harita veya keşif — çünkü zayıf bir sonucun siteden mi yöntemden mi geldiği ondan okunur. Sitenin hariç tutma dosyası uygulanır.

Nasıl görünüyor

Süreç, adım adım.

Asistanın neyi bilmeye hakkı olduğunu, herhangi bir importtan önce belirliyoruz

İzin verilen kaynakların listesi ve, en az onun kadar önemli olarak, reddedilenlerin listesi, nedeni ile birlikte. Bir iç satın alma fiyatları dosyası, bir iletişim dışa aktarımı, bir e-posta arşivi — bunlar tam olarak “bağlamı olsun” diye korpusa giren ve sonra bir müşteriye yanıt olan şeylerdir. Karar ve her biri için neden ile birlikte kaynak envanterini, ayrıca asla girmemesi gerekenlere dair kuralı teslim ediyoruz.

İçeri aktarıyoruz, bölüyoruz ve gerçekten parçaları okuyarak ne çıktığını doğruluyoruz

Çıkarma, örtüşmeli bölme, indeksleme. Doğrulama aşaması atlanmaz: ortaya çıkan korpustan rastgele parçalar okunur. Orada tabloların bitişik kelime dizilerine dönüşmüş hâli, sıfır metin üreten taranmış PDF’ler ve kendi başına belge olarak giren menü sayfaları ortaya çıkar. Korpusu artı neyin çıkarılamadığını ve nedenini içeren raporu teslim ediyoruz.

Geri getirmeyi rahat sorulara değil, gerçek sorulara göre ayarlıyoruz

Gerçekte müşterilerin ne sorduğundan, kötü yazılmış ifadeler ve iki dilin karıştığı ifadeler dahil, bir soru seti oluşturulur ve parça sayısı, eşik ile sözcüksel kısmın ağırlığı ayarlanır. Hedef, her sorunun bir yanıt alması değil; korpus içinde karşılığı olmayan soruların “bu bilgiye sahip değilim” almasıdır. Sonuçlar ve son yapılandırma ile soru setini teslim ediyoruz.

Onay gate’ini ve büyüme döngüsünü kuruyoruz

Yanıtlanmamış soruların kaydı, onaylayan kişiye bildirim, yanıt yolu, corpus’a aktarma ve kopyaların bağlanması. Çalışan döngüyü ve onaylayan kişi için yazılı talimatı teslim ediyoruz — müşterinin sorusundan neyin kopyalanmayacağı dahil.

Yenileme prosedürünü, onu uygulayan kişinin adıyla birlikte teslim ediyoruz

Hangi kaynak yenilenir, ne sıklıkla, kim basar ve bunun gerçekleştiği nasıl görülür. Burada sınırı açıkça söylüyoruz: işlettiğimiz platformlarda yeniden indeksleme otomatik olarak zamanlanan bir şey değil, talep edilen bir işlemdir. Adı olmayan bir prosedür, uygulanmayan bir prosedürdür.

Bir sorunun sistem içindeki yolu: onaylı kaynaklar çıkarma ve parçalamaya girer, parçalar dizine gider; soruda adaylar — vektörel ve leksikal — puanlanır ve yalnızca birkaç parça bağlama girer; hiçbir şey bulunmadığında soru insan onayı dalına çıkar ve korpusa geri döner.

Veriler

Neye dokunuyoruz, nerede duruyorlar ve ne kadar kalıyorlar

Veri koruma sorumlusu olan herkesin soracağı sorular — o sormadan önce burada sorulmuş hâliyle.

Corpus’a ne girer: Yalnızca açıkça onaylananlar: yüklenen belgeler, seçilen sayfalar, soru-cevap çiftleri, el yazısıyla yazılmış metinler. Kaynaklar türlendirilmiştir — metin, belge, site, soru-cevap çiftleri — ve belirtilmiş bir amaca sahiptir: ürünler, dokümantasyon, sık sorulan sorular ya da başkaları. Her kaynağın kendi anahtarı vardır ve bu anahtar, yalnızca arayüzde değil, her geri getirme sorgusunda kontrol edilir — kapalı bir kaynak yanlışlıkla bile bağlama giremez.
Parçalar ve temsilleri nerede durur: İlgili platformun veritabanında, müşterinin diğer verilerinin yanında, ayrı bir dış arama hizmetinde değil. PostgreSQL kurulumlarında, vektörel uzantı açıkça etkinleştirilmiş kendi tablolarında; metin asistanı platformunda ise MySQL’de, JSON sütununda temsil edilerek ve mesafe hesabı uygulamada yapılarak. İkinci model küçük ölçekte çalışır ve yüz binlerce parçaya ölçeklenmez — bu, mimari bir sınırlamadır ve olduğu gibi söylenir.
Konuşmalardaki kişisel veriler: Corpus kişisel veri içermemelidir, ancak öğrenme döngüsü bunları içeri getirebilir, çünkü bir müşterinin sorusu müşterinin yazdığı metindir. Bu yüzden corpus’a giriş bir insan onayından geçer: orada filtrelenir. Bununla birlikte gelen operasyonel kural şudur: yanıtları onaylayan kişi, orijinal sorudaki adları, telefon numaralarını veya sipariş ayrıntılarını corpus’a kopyalamaması için açık talimat alır.
Sorgular hakkında ne tutulur: Geri getirme sorgularının bir günlük tablosu vardır; elde edilen puanlar, geri getirme süresi ve dönen parça sayısı kaydedilir. Bu, „neden böyle söyledi” sorusuna cevap veren araçtır — bu olmadan eşiklerin ayarlanması tahmine dönüşür. Günlük, ayarlama için faydalı olduğu sürece saklanır ve platformun saklama sürelerine girer, ayrı bir rejime değil.
Ne yoktur ve olduğu gibi beyan edilmiştir: Belgelere bir son kullanma süresi uygulanması yoktur: alan şemada tanımlanmıştır, ancak hiçbir şey onu okumaz; dolayısıyla bir belge corpus’tan kendiliğinden kaybolmaz. Müşteri platformlarında otomatik, zamanlanmış yeniden indeksleme yoktur — yenileme açıkça, kaynak bazında talep edilir. Özel bir modelle yeniden sıralama yoktur ve BM25 türü sözcüksel puanlama da yoktur; „hibrit” dediğimiz şey, sözcük eşleşmesi ile vektörel mesafenin ağırlıklı toplamıdır ve doğru ifade budur.

Bir vaka

Ajanın yanıtlamayı bilmediği sorulardan büyüyen bir bilgi tabanı

Durum

Teslimat yapan bir restoran zincirinin telefonda bir voice agent’ı ve web sayfasında bir asistanı vardı. Başlangıç corpus’u lansmanda bir kez yüklenmişti. Sorun ajanın hata yapması değildi; corpus yazılırken kimsenin öngörmediği, tamamen makul sorularda sık sık „bu bilgiye sahip değilim” demesiydi. Böyle her yanıt kaybedilmiş bir konuşmaydı ve listeleri hiçbir yerde yoktu.

Ne kurduk

Eksikliği sistem girdisine dönüştürdük. Ajan bilgiye sahip olmadığını söylediğinde, soru „beklemede” durumuyla ve geldiği kanal ile birlikte bir tabloya yazılır — ses ya da widget. Müşteri tarafındaki sorumlu kişi, zaten kullandığı mesajlaşma kanalında bir bildirim alır ve doğrudan mesaja yanıt vermesi için talimat verilir. Bir webhook yanıtı alır, girdiyi „onaylandı” durumuna geçirir ve oradan yanıt ajanın bağlamına girer. Aynı eksikliğin farklı ifadeleri, orijinal girdiye bir referansla bağlanır ve ajana teslimat her giriş için bir kez yapılır; böylece onaylı bir yanıt her döngüde yeniden enjekte edilmez.

Ne çıktı

Corpus, lansmanda yüklenen tek bir dosya olmaktan çıktı ve varsayımlarımıza göre değil, müşteriler tarafından sıralanan gerçek eksikliklerin listesi haline geldi. Onaylayan kişi, tam olarak neyin sorulduğunu ve hangi kanalda olduğunu görür; dolayısıyla yanıtı kullanılacağı biçimde yazar. Durumlar dörttür — beklemede, onaylandı, yoksayıldı, kopya — çünkü „yoksayıldı” meşru bir sonuçtur: bazı soruların asla otomatik yanıt almaması gerekir.

Vakanın söylemedikleri

Döngü, içindeki insanın çalıştığı kadar çalışır. Hiç kimse bildirimlere yanıt vermezse, “beklemede” girişler birikir ve ajan hâlâ bilmez durumda kalır — mekanizma eksikliği görünür kılar, onu kendi başına çözmez. En az bunun kadar önemli ikinci sınırlama: uygulama, bu müşterinin akışı için, tablo, bildirim ve enjeksiyon onun için yazılmış şekilde kablolanmıştır. Arayüzden herhangi bir hesap için kullanılabilen genel bir işlev olarak, henüz yoktur.

Sorular

İnsanların aramadan önce bize sordukları

Yüklenen belgelerde bilgi varsa asistan neden yanlış yanıt veriyor?

Neredeyse her zaman doğru parçanın bulunamamasından, modelin “kötü” olmasından değil. Sık nedenler, kontrol ettiğimiz sırayla: yararlı bilginin diğerleri arasında kaybolduğu çok büyük parçalar; örtüşme olmadan cümlenin ortasından kesme; bağlama getirilen çok az parça; ya da aynı bilginin üç farklı sürümde yer aldığı ve eski sürümün daha iyi puan aldığı bir korpus. Alınan puanlarla birlikte sorgu günlüğü, hangisinin söz konusu olduğunu gösterir — onsuz tahmin edilir.

Her yerde semantik arama mı kullanıyorsunuz?

Hayır, ve tam olarak nerede olduğunu söylemek daha dürüst. Kendi vektörlerimizle: günlük kullanılan bir iç board’un belleği, kosinüs uzaklığı indeksi ve 0,35 benzerlik eşiği olan vektör sütunu üzerinde. Sağlayıcıdaki vektörlerle: sesli ajanların bilgi tabanı, sağlayıcının geri getirme motoruna senkronize edilir. **Vektör olmadan**, bugün, üretimde: metin asistanları platformunun bilgi tabanı — indeksleme yolu boş vektör sütunu yazar, dolayısıyla geri getirme leksikal çalışır ve kod modunu kendi kendine `keyword-only` olarak etiketler. Ayrıca tamamen yazılmış bir kendi pipeline’ımız da var; vektör uzantısı üzerindeki haklar doğrulanana kadar geçiş “üretimde yayınlanmamalı” olarak işaretlenmiştir. Gerçek harita budur.

Zaten indekslenmiş bir belgeyi değiştirdiğimizde ne olur?

Kaynak parçaları tamamen silinir ve yeni sürümden yeniden yazılır. Kısmi güncelleme yerine tam değiştirmeyi seçtik, çünkü zor olan eklemek değil, kaldırmaktır: eski sürümden kalan parçalar hâlâ geri getirilir ve müşterinin ön sayfadaki sayfayla çeliştiği yanıtlar üretir. Eklemede ayrıca içerik parmak izi kontrolü vardır — metin aynıysa hiçbir şey yeniden hesaplanmaz ve boş yere ödeme yapılmaz.

Site veya katalog değişince kendi kendine güncelleniyor mu?

Bugün işlettiğimiz platformlarda otomatik değil. Yeniden indeksleme, kaynak başına, özel bir eylemle açıkça istenir. Yalnızca bizim bir iç sistemimizde, her otuz dakikada bir çalışan ve sadece değişeni yeniden indeksleyen bir döngü vardır. Otomatik planlama da kurulabilir ve ayrı bir aşamadır; yapmadığımız şey, bunun zaten varmış izlenimi vermektir. Şemada tanımlanmış bir süre dolma alanı da vardır ve hiçbir şey onu okumaz — yani bir belge korpusdan kendi kendine çıkmaz.

Bağlı bir katalog ile yüklenmiş bir ürün listesi arasındaki fark nedir?

Gerçeğin anı. Yüklenmiş liste, yüklendiği gün doğrudur; ertesi günden itibaren fiyat, stok ve yeni ürünler sessizce ayrışır ve ayrışma, bir müşteri artık var olmayan bir fiyat istediğinde ortaya çıkar. Bağlı katalog, sorunun sorulduğu anda, kayıt tutan sistemden okunur; dolayısıyla geride kalamaz. Maliyeti başkadır: o sistemin erişilebilirliğine bağlılık ortaya çıkar ve kaynak yanıt vermediğinde asistanın ne söyleyeceğine karar vermek gerekir — doğru yanıtın “fiyatı şu anda doğrulayamam” olması, son bilinen değer değil.

Taranmış PDF’leri indeksleyebilir misiniz?

Doğrudan değil. Taranmış bir PDF, PDF ambalajı içinde bir görüntüdür ve seçilebilir metin içermez; çıkarıcımız bunu algılar ve boş bir belgeyi indekslemek yerine açık bir mesaj döndürür — mümkün olan en kötü sonuç, hiçbir şey içermeyen “hazır” olarak işaretlenmiş bir kaynaktır. Çözüm, içe aktarmadan önce optik karakter tanıma ya da belgenin DOCX veya metin olarak sağlanmasıdır. Mevcut zincirde optik tanıma uygulanmış değildir.

Rumence ve Rusça çalışıyor mu?

Evet, ve göründüğünden daha önemli bir ayrıntı vardır. Parçalara bölme cümlelerin arasını keser ve kuralımız cümle sonunu Latin **veya** Kiril büyük harfiyle algılar; buna Romen diakritikleri de dahildir. İngilizce için yazılmış bir ayırıcı, Kiril’de bir cümlenin başlangıcını tanımaz ve birbirine yapışmış parçalar üretir; bunun geri getirmenin kalitesi üzerinde doğrudan etkisi vardır. Ses tarafı için, sağlayıcıda kullanılan temsil modeli çok dilli bir modeldir.

Ne zaman semantik arama KULLANILMAZ?

Korpus küçük, sabit ve sizin tarafınızdan yazılmış olduğunda — örneğin kendi sitenizin içeriği. Kendi kamu platformumuzda, platformun kendi metni üzerinde, her biri kaynak sayfayı taşıyan kısa pasajlara bölünmüş sözcük örtüşmesiyle geri getirmeyi bilinçli olarak seçtik. Vektör yok, vektör deposu yok, ağda ek istek yok ve, en önemlisi, depo dışından hiçbir kaynak yok. Asistan yalnızca sitenin zaten söylediğini tekrar edebilir ve her yanıt bir insan tarafından yazılmış bir sayfada doğrulanabilir. Ana hedef hiçbir şeyin uydurulmamasıysa, bu semantik aramayı yener.

Bizi platformunuzda esir mi tutuyorsunuz?

Kaynaklar sizindir ve orijinal biçimde kalır; parçalar ve temsiller sizin kurulumunuzun veritabanında durur, yalnızca bizim erişimimiz olan harici bir arama hizmetinde değil. Temsil modeli kendi model kapınız üzerinden istenir, bu yüzden sağlayıcı değişikliği bilgi tabanı koduna dokunmaz. Ancak vektörel temsiller onları üreten modele bağlıdır: model değişikliği tüm korpusun yeniden indekslenmesini gerektirir. Bu, hesaplanması gereken bir işlemdir, ücretsiz olan değil, ve ortasında öğrenmektense en başta bilinmesi daha iyidir.

Yukarıdaki iddialar neye dayanıyor (29 kaynak)

Bunlardan 29 tanesi depolarımızdaki kod ve dosyalardır. Adlarını ya da satırlarını yayımlamıyoruz: hepsi bir arada, tek bir sayfada, yalnızca bize ait olmayan sistemlerin nasıl kurulduğunu fazla net anlatırdı. İstek üzerine, depoda sizinle birlikte gözden geçiriyoruz — doğrulama hâlâ mümkün, sadece bir görüşme içinde yapılıyor.

Nasıl çalışıyoruz Tüm hizmetler

Neyin daha iyi çalışmasını isterdiniz?

Bize sürecinizi anlatın. Neyin kurulmaya değer olduğuna, neyi bağlayabileceğimize ve sonucu nasıl doğrulayacağımıza birlikte karar verelim.

Hadi konuşalım