Ekspertyza · Bazy wiedzy i wyszukiwanie semantyczne

Budujemy korpus, z którego asystent ma prawo odpowiadać, z regułami dotyczącymi tego, co wchodzi, jak się dzieli, jak się wyszukuje i co się dzieje, gdy źródło się zmienia.

Asystent, który odpowiada klientom, jest dokładnie tak dobry, jak korpus, z którego czyta. Zajmujemy się korpusem: wyodrębnianiem z dokumentów i strony, dzieleniem na fragmenty, indeksowaniem, wyszukiwaniem, bramą zatwierdzenia przez człowieka i odświeżaniem. Obejmuje to odpowiedź na pytanie, kiedy NIE warto stosować wyszukiwania semantycznego.

Omów projekt

Już zbudowaneIstnieją własne implementacje dla każdego etapu, ale ich stan się różni i trzeba to powiedzieć wprost. Co działa z własnymi wektorami: pamięć wewnętrznego boardu używanego codziennie, z kolumną `vector(1536)`, indeksem `ivfflat` dla odległości kosinusowej, progiem podobieństwa 0,35 i pętlą, która co 30 minut reindeksuje tylko to, co się zmieniło. Co działa z wektorami u dostawcy: baza wiedzy agentów głosowych, synchronizowana do silnika wyszukiwania dostawcy z fragmentami po 500 i nakładką 100. Co działa w produkcji **bez** wektorów: baza wiedzy platformy asystentów tekstowych — ekstrakcja, dzielenie, konfiguracja per asystent i wyszukiwanie hybrydowe są napisane i działają, ale ścieżka indeksowania zapisuje kolumnę wektorową jako `null`, więc wynik hybrydowy degraduje do leksykalnego, a kod sam to nazywa etykietą `keyword-only`. Co jest napisane i jeszcze nie uruchomione w produkcji: własny pipeline na `pgvector` platformy głosowej, którego migracja ma w nagłówku wzmiankę „LOCAL ONLY — do not push to prod”. Usługa sprzedaje się z taką mapą na stole, nie bez niej.

Asystent, który rozmawia z klientami, niczego nie „wie”. Przy każdym pytaniu ktoś wcześniej wyszukuje kilka fragmentów tekstu i podaje je przed nim, a on formułuje odpowiedź z nich. Jakość odpowiedzi rozstrzyga się niemal w całości na tym etapie wyszukiwania, nie przy wyborze modelu. Dlatego ta usługa dotyczy korpusu i wyszukiwania, a nie modelu.

Praca ma cztery części, które psują się niezależnie od siebie. Ekstrakcja: z jakich plików i z jakich stron wyciągamy tekst użyteczny oraz co robimy, gdy nie możemy. Dzielenie: jak duże są fragmenty, jak bardzo się nakładają, gdzie tnie się zdanie. Wyszukiwanie: jak dobiera się fragmenty do konkretnego pytania, ile ich jest i według jakiego kryterium. Odświeżanie: co się dzieje, gdy dokument źródłowy się zmienia. System może być nienaganny w trzech z nich i bezużyteczny przez czwartą.

Jest jeszcze jeden etap, który wiele osób pomija, a który całkowicie zmienia wynik: bramka akceptacji. Korpus, który rośnie sam, z rozmów, szybko zaczyna zawierać odpowiedzi, których nikt nie zweryfikował. Pętla, którą zbudowaliśmy, działa odwrotnie: gdy agent mówi „nie mam tej informacji”, pytanie zapisuje się ze statusem „w oczekiwaniu”, osoba otrzymuje powiadomienie i odpowiada, a odpowiedź przechodzi do stanu „zatwierdzone” i dopiero wtedy trafia do korpusu. Wiedza rośnie z rzeczywistych braków, z osobą w łańcuchu.

I niepopularna część: wyszukiwanie semantyczne nie zawsze jest właściwym wyborem. Dla własnej publicznej platformy odrzuciliśmy je celowo. Korpus to własny tekst platformy, podzielony na krótkie fragmenty, z których każdy niesie stronę, z której pochodzi, oznaczone nakładką słów. Bez wektorów, bez magazynu wektorowego, bez dodatkowego żądania sieciowego — i, co ważniejsze, bez żadnego źródła spoza repozytorium. Asystent może jedynie powtarzać to, co już jest napisane na stronie, a każda odpowiedź jest sprawdzana na stronie napisanej przez człowieka. To cały mechanizm antyinwencyjny.

Co obejmuje

Praca, komponent po komponencie

Wyciągamy tekst i jasno mówimy, kiedy nie możemy

Z tekstu prostego, markdown, logów, CSV, JSON, DOCX i PDF. DOCX jest rozpakowywany jak archiwum i odczytywany jest dokument XML wewnątrz; PDF przechodzi przez standardowy ekstraktor z zachowaniem układu strony, a jeśli go nie ma, istnieje rezerwa, która czyta operatory tekstu bezpośrednio z pliku. Ważny przypadek to ten, gdy się nie udaje: zeskanowany PDF, który jest obrazem, nie zawiera tekstu możliwego do zaznaczenia, a system zwraca jednoznaczną wiadomość — wgraj DOCX albo tekst, albo przepuść plik przez rozpoznawanie optyczne wcześniej. Rozpoznawania optycznego nie mamy zaimplementowanego i nie udajemy, że mamy.

Dzielimy na fragmenty z nakładką, tnąc między zdaniami, nie przez nie

Domyślne wartości, których używamy: 500 jednostek leksykalnych z 50 nakładki dla pipeline'u głosowego, 1.200 znaków z 150 nakładki dla tekstowego; po stronie dostawcy głosowego, 500 z 100. Nakładka istnieje, ponieważ zdanie przecięte w połowie między dwoma fragmentami staje się bezużyteczne dla obu. Separator zdań jest napisany dla języków, z którymi pracujemy: rozpoznaje koniec zdania po którym następuje wielka litera łacińska **lub cyrylica**, w tym rumuńskie znaki diakrytyczne. Separator napisany dla angielskiego tnie źle po rumuńsku i jeszcze gorzej po rosyjsku.

Indeksujemy wektorami tam, gdzie to uruchomiliśmy, i mówimy, gdzie nie

Domyślny model reprezentacji to `text-embedding-3-small`, z 1.536 wymiarami, zamawiany przez naszą bramkę modeli, nie bezpośrednio od dostawcy — dzięki temu można zmienić dostawcę bez dotykania kodu bazy wiedzy. W bazie kolumna ma typ vector z indeksem `ivfflat` na dystansie cosinusowym. Istnieje strategia rezerwowa zapisana w migracji: jeśli rozszerzenie wektorowe nie jest dostępne, schemat tworzy się zawsze z indeksem trigramowym na tekście, a wyszukiwanie przełącza się na podobieństwo leksykalne. To nie jest hipotetyczne — zostało napisane właśnie dlatego, że uprawnienia do rozszerzenia nie są gwarantowane w każdej instalacji.

Wyszukiwanie hybrydowe, z wagami na widoku

Wynik końcowy to 0,7 z podobieństwa wektorowego plus 0,3 z dopasowania słów, z normalizowaną częścią leksykalną. Punktowany jest zestaw kandydatów i zachowywane są pierwsze fragmenty, a kontekst wysyłany modelowi tnie każdy fragment do maksymalnej długości, aby jeden długi dokument nie zajął całej przestrzeni. Konfiguracja jest per asystent, w bazie: wyszukiwanie włączone albo wyłączone, maksymalna liczba fragmentów na pytanie (domyślnie 5, ograniczona między 1 a 20), próg podobieństwa, typ wyszukiwania — semantyczne, leksykalne albo hybrydowe — oraz waga części leksykalnej.

Brama zatwierdzania: wiedza rośnie z braków, z człowiekiem w pętli

Gdy agent odpowiada, że nie ma informacji, pytanie jest zapisywane w tabeli ze stanem „w oczekiwaniu”, oznaczone kanałem, z którego przyszło — głos albo widget. Człowiek otrzymuje powiadomienie i odpowiada bezpośrednio na wiadomość; webhook pobiera odpowiedź, przenosi wpis do stanu „zatwierdzony”, a stamtąd trafia on do kontekstu agenta. Możliwe stany są cztery: w oczekiwaniu, zatwierdzony, zignorowany, duplikat — a duplikaty łączą się z pytaniem oryginalnym przez odwołanie, aby nie gromadziło się dziesięć sformułowań tego samego braku. Dostarczenie do agenta odbywa się tylko raz na każdy zatwierdzony wpis.

Odświeżanie: co się dzieje, gdy źródło się zmienia

Przy dodawaniu obliczany jest odcisk SHA-256 treści; jeśli tekst jest identyczny z czymś już zindeksowanym, używa się go ponownie i nie płaci się za nową reprezentację wektorową. Gdy dokument się zmienia, jego fragmenty są usuwane w całości i zapisywane od nowa — pełne zastąpienie na poziomie źródła, a nie częściowa aktualizacja, bo częściowa aktualizacja zostawia po sobie osierocone fragmenty ze starej wersji, a to one powodują odpowiedzi sprzeczne ze stroną. Źródło ma widoczny cykl stanów: w oczekiwaniu, w przetwarzaniu, w reprocesowaniu, gotowe albo nieudane, a ponowne indeksowanie można zażądać punktowo, dla źródła.

Nie reindeksujemy tego, co się nie zmieniło

W pętli uruchamianej co trzydzieści minut na liście, która tylko rośnie, przeliczanie reprezentacji dla nienaruszonego elementu jest powtarzalną opłatą za wektor, który nie miał prawa się poruszyć. Nasza pętla porównuje moment ostatniego dotknięcia z momentem ostatniego indeksowania i pomija to, co niezmienione. Reprezentacje są wywoływane w partiach, nie pojedynczo. To detale kosztów, ale miesięczny koszt bazy wiedzy jest tu ustalany niemal w całości.

Połączony katalog to nie załadowana lista

Różnica nie dotyczy formatu, lecz momentu. Załadowana lista jest prawdziwa w chwili wczytania: cena, stan i nowe produkty pozostają zamrożone, dopóki ktoś nie przypomni sobie o ponownym załadowaniu — a zwykle okazuje się, że nikt sobie nie przypomina, gdy klient pyta o cenę sprzed trzech miesięcy. Połączony katalog jest odczytywany w chwili pytania, z źródła, które prowadzi ewidencję. To, co zbudowaliśmy w tym kierunku: ekstraktor, który rozpoznaje kolekcje produktów z JSON lub CSV po zwyczajowych kluczach i, gdy struktura jest nietypowa, prosi o pomoc model z obowiązkiem odpowiedzi wyłącznie w danej formie; oraz parser, który odczytuje cenę z żywej strony sklepu. Najlepszą drogą pozostaje własny ustrukturyzowany interfejs sklepu, tam, gdzie istnieje — ale to sprawdza się per sklep, nie zakłada.

Przeszukiwanie strony: najpierw mapa, potem eksploracja

Najpierw szuka się mapy strony, w zwyczajowych wariantach nazwy, i rozwija się zagnieżdżone mapy na dwóch poziomach. Dopiero jeśli mapy nie ma, przechodzi się do eksploracji wszerz, wyłącznie po tym samym źródle, z konfigurowalnym limitem stron (domyślnie 50, ograniczonym do 200). Faktycznie użyta strategia jest raportowana z powrotem — mapa albo eksploracja — bo z niej odczytuje się, czy ubogi wynik wynika ze strony, czy z metody. Przestrzegany jest plik wykluczeń strony.

Jak to wygląda

Trasa, krok po kroku.

Ustalamy, co asystent może wiedzieć, przed jakimkolwiek importem

Lista dozwolonych źródeł i, równie ważne, lista odrzuconych, z powodem. Wewnętrzny plik cen zakupu, eksport kontaktów, archiwum e-maili — to dokładnie te rzeczy, które trafiają do korpusu „żeby był kontekst”, a potem stają się odpowiedzią dla klienta. Dostarczamy spis źródeł z decyzją i powodem dla każdego, plus regułę o tym, co nie może wejść nigdy.

Importujemy, dzielimy i sprawdzamy, co wyszło, czytając rzeczywiste fragmenty

Ekstrakcja, dzielenie z nakładaniem, indeksowanie. Etapu weryfikacji się nie pomija: czytane są losowe fragmenty z powstałego korpusu. Tam wychodzą tabele zamienione w ciągi sklejonych słów, skanowane PDF-y, które dały zero tekstu, i strony menu nawigacyjnego, które trafiły jako samodzielne dokumenty. Dostarczamy korpus plus raport z tym, czego nie udało się wyodrębnić i dlaczego.

Dopasowujemy wyszukiwanie do rzeczywistych pytań, nie do wygodnych pytań

Tworzony jest zestaw pytań z tego, o co klienci faktycznie pytają, w tym z niepoprawnie zapisanych form i tych w dwóch mieszanych językach, i dostosowywana jest liczba fragmentów, próg oraz waga części leksykalnej. Celem nie jest to, aby każde pytanie dostało odpowiedź, lecz to, aby pytania bez pokrycia w korpusie dostały „nie mam tej informacji”. Dostarczamy zestaw pytań z wynikami i konfiguracją końcową.

Wprowadzamy bramę zatwierdzania i pętlę wzrostu

Rejestrowanie pytań bez odpowiedzi, powiadomienie osoby zatwierdzającej, ścieżka odpowiedzi, przeniesienie do korpusu i łączenie duplikatów. Dostarczamy działającą pętlę oraz pisemną instrukcję dla osoby zatwierdzającej — w tym to, czego nie kopiuje się z pytania klienta.

Przekazujemy procedurę odświeżania, z nazwą osoby, która ją wykonuje

Które źródło jest odświeżane, jak często, kto naciska i jak widać, że to się stało. Tutaj otwarcie mówimy o ograniczeniu: na platformach, którymi operujemy, reindeksacja jest działaniem wymaganym, a nie uruchamianym automatycznie według harmonogramu. Procedura bez nazwiska osoby przy niej to procedura, która nie zostaje wykonana.

Droga pytania przez system: zatwierdzone źródła wchodzą do ekstrakcji i dzielenia, fragmenty trafiają do indeksu; przy pytaniu punktuje się kandydatów — wektorowo i leksykalnie — i tylko kilka fragmentów trafia do kontekstu; a gdy nic się nie znajdzie, pytanie wychodzi gałęzią zatwierdzenia przez człowieka i wraca do korpusu.

Dane

Czego dotykamy, gdzie to leży i jak długo zostaje

Pytania, które zadaje każdy, kto ma inspektora ochrony danych — postawione tutaj, zanim on je zada.

Co trafia do korpusu: Tylko to, co jest wyraźnie zatwierdzone: wgrane dokumenty, wybrane strony, pary pytanie-odpowiedź, teksty pisane ręcznie. Źródła są typowane — tekst, dokument, strona, pary pytanie-odpowiedź — i mają zadeklarowany cel: produkty, dokumentację, często zadawane pytania lub inne. Każde źródło ma własny przełącznik, a przełącznik jest sprawdzany przy każdym zapytaniu wyszukiwania, nie tylko w interfejsie — wyłączone źródło nie może trafić do kontekstu nawet przez pomyłkę.
Gdzie są fragmenty i ich reprezentacje: W bazie danych danej platformy, obok pozostałych danych klienta, a nie w osobnej zewnętrznej usłudze wyszukiwania. Dla instalacji na PostgreSQL, w osobnych tabelach z jawnie włączonym rozszerzeniem wektorowym; dla platformy asystentów tekstowych, w MySQL, z reprezentacją w kolumnie JSON i obliczaniem odległości wykonywanym w aplikacji. Drugi model działa w małej skali i nie skaluje się do setek tysięcy fragmentów — to ograniczenie architektury, powiedziane wprost.
Dane osobowe w rozmowach: Korpus nie powinien zawierać danych osobowych, ale pętla uczenia może je tam wprowadzać, ponieważ pytanie klienta jest tekstem napisanym przez klienta. Dlatego wejście do korpusu przechodzi przez zatwierdzenie przez człowieka: tam następuje filtracja. Zasada operacyjna, która temu towarzyszy: osoba zatwierdzająca odpowiedzi otrzymuje wyraźną instrukcję, aby nie kopiować do korpusu nazw, numerów telefonu ani szczegółów zamówienia z oryginalnego pytania.
Co jest przechowywane o zapytaniach: Istnieje tabela dziennika zapytań wyszukiwania, z uzyskanymi wynikami, czasem wyszukiwania i liczbą zwróconych fragmentów. To narzędzie, którym odpowiada się na „dlaczego to powiedział” — bez niego dostrajanie progów zamienia się w zgadywanie. Dziennik jest przechowywany tak długo, jak jest przydatny do strojenia, i podlega terminom retencji platformy, a nie osobnemu reżimowi.
Czego nie ma i co jest tak właśnie zadeklarowane: Nie ma zastosowania terminu wygaśnięcia do dokumentów: pole jest zadeklarowane w schemacie, ale nic go nie odczytuje, więc dokument nie znika sam z korpusu. Nie ma automatycznej reindeksacji zaplanowanej na platformach klienta — odświeżenie jest żądane wprost, dla źródła. Nie ma przestawiania kolejności przez dedykowany model ani leksykalnego punktowania typu BM25; to, co nazywamy „hybrydowym”, jest ważoną sumą dopasowania słów i odległości wektorowej, i właśnie to sformułowanie jest poprawne.

Przykład

Baza wiedzy, która urosła z pytań, na które agent nie umiał odpowiedzieć

Sytuacja

Sieć restauracji z dostawą miała agenta głosowego przez telefon i asystenta na stronie internetowej. Początkowy korpus został wgrany jednorazowo, przy uruchomieniu. Problemem nie było to, że agent się mylił, lecz że często mówił „nie mam tych informacji” — przy całkiem rozsądnych pytaniach, których nikt nie przewidział podczas pisania korpusu. Każda taka odpowiedź była utraconą rozmową, a lista tych odpowiedzi nie istniała nigdzie.

Co zbudowaliśmy

Zamieniliśmy brak na wpis systemowy. Gdy agent odpowiada, że nie ma informacji, pytanie zapisuje się w tabeli ze statusem „w oczekiwaniu” i z kanałem, z którego przyszło — głos lub widget. Osoba odpowiedzialna po stronie klienta otrzymuje powiadomienie na kanale komunikacyjnym, którego i tak używa, z instrukcją, by odpowiedzieć bezpośrednio na wiadomość. Webhook pobiera odpowiedź, zmienia wpis na stan „zatwierdzony”, a stamtąd odpowiedź trafia do kontekstu agenta. Różne sformułowania tego samego braku są łączone z oryginalnym wpisem przez odwołanie, a dostarczenie do agenta odbywa się tylko raz na wpis, aby zatwierdzona odpowiedź nie była reinicjowana przy każdym cyklu.

Co z tego wyszło

Korpus przestał być plikiem wgranym przy uruchomieniu i stał się listą realnych braków, uporządkowaną przez klientów, a nie przez nasze założenia. Osoba zatwierdzająca widzi dokładnie, o co pytano i w jakim kanale, więc zapisuje odpowiedź w formie, w jakiej będzie użyta. Stany są cztery — w oczekiwaniu, zatwierdzony, zignorowany, duplikat — ponieważ „zignorowany” jest wynikiem legalnym: niektóre pytania nigdy nie powinny otrzymać automatycznej odpowiedzi.

Czego nie mówi ten przypadek

Pętla działa dokładnie tak długo, jak działa człowiek w niej. Jeśli nikt nie odpowiada na powiadomienia, wpisy „w oczekiwaniu” się gromadzą, a agent nadal nic nie wie — mechanizm uwidacznia brak, nie rozwiązuje go sam. Drugie ograniczenie, równie ważne: implementacja została okablowana pod przepływ tego klienta, z tabelą, powiadomieniem i wstrzyknięciem napisanymi dla niego. Jako funkcja ogólna, dostępna z interfejsu dla każdego konta, jeszcze nie istnieje.

Pytania

O co pytają ludzie, zanim zadzwonią

Dlaczego asystent odpowiada błędnie, jeśli informacja jest w wgranych dokumentach?

Prawie zawsze dlatego, że właściwy fragment nie został odnaleziony, a nie dlatego, że model byłby „głupi”. Częste przyczyny, w kolejności, w jakiej je sprawdzamy: zbyt duże fragmenty, w których użyteczna informacja ginie między innymi; cięcie w połowie zdania, bez nakładania się; zbyt mało fragmentów wprowadzonych do kontekstu; albo korpus, w którym ta sama informacja występuje w trzech różnych wersjach i stara punktuje lepiej. Dziennik zapytań, ze zdobytymi wynikami, pokazuje, który z tych przypadków zachodzi — bez niego się zgaduje.

Czy naprawdę wszędzie używacie wyszukiwania semantycznego?

Nie, i uczciwiej jest powiedzieć dokładnie gdzie. Z własnymi wektorami: pamięć wewnętrznej tablicy używanej codziennie, na kolumnie wektorowej z indeksem na odległość cosinusową i progiem podobieństwa 0,35. Z wektorami u dostawcy: baza wiedzy agentów głosowych, synchronizowana do silnika wyszukiwania dostawcy. **Bez** wektorów, dziś, w produkcji: baza wiedzy platformy asystentów tekstowych — ścieżka indeksowania zapisuje pustą kolumnę wektorową, więc wyszukiwanie działa leksykalnie, a kod sam oznacza swój moduł jako `keyword-only`. Istnieje też w pełni napisany własny pipeline, z migracją oznaczoną „nie publikować w produkcji” do czasu potwierdzenia praw do rozszerzenia wektorowego. To jest rzeczywista mapa.

Co się dzieje, gdy modyfikujemy już zindeksowany dokument?

Fragmenty źródła są usuwane w całości i zapisywane ponownie z nowej wersji. Wybraliśmy pełne zastąpienie zamiast częściowej aktualizacji, bo trudna część to nie dodawanie, lecz usuwanie: fragmenty pozostałe ze starej wersji nadal są odnajdywane i dają odpowiedzi, którym klient zaprzecza stroną z przodu. Przy dodawaniu istnieje też sprawdzanie odcisku zawartości — jeśli tekst jest identyczny, nic nie jest przeliczane i nie płaci się bez potrzeby.

Czy aktualizuje się samo, gdy zmienia się strona lub katalog?

Nie automatycznie, na platformach, którymi operujemy dziś. Reindeksowanie trzeba zlecić jawnie, dla źródła, przez dedykowaną akcję. Istnieje jeden wyjątek, w naszym wewnętrznym systemie, gdzie pętla działa co trzydzieści minut i reindeksuje tylko to, co się zmieniło. Automatyczne planowanie można zbudować i jest to osobny etap; tego, czego nie robimy, to sugerowanie, że już istnieje. Istnieje też zadeklarowane w schemacie pole wygaśnięcia, którego nic nie odczytuje — więc dokument sam nie znika z korpusu.

Jaka jest różnica między podłączonym katalogiem a wgraną listą produktów?

Moment prawdy. Wgrana lista jest poprawna w dniu wgrania; od następnego dnia cena, stan i nowe produkty cicho się rozjeżdżają, a rozbieżność wychodzi na jaw, gdy klient prosi o cenę, której już nie ma. Podłączony katalog jest odczytywany w momencie pytania, z systemu, który prowadzi ewidencję, więc nie może zostać w tyle. Koszt jest inny: pojawia się zależność od dostępności tego systemu i trzeba zdecydować, co asystent mówi, gdy źródło nie odpowiada — a poprawną odpowiedzią jest „nie mogę teraz potwierdzić ceny”, nie ostatnia znana wartość.

Czy można indeksować zeskanowane PDF-y?

Nie bezpośrednio. Zeskanowany PDF to obraz w opakowaniu PDF i nie zawiera tekstu, który można zaznaczyć; nasz ekstraktor to wykrywa i zwraca jasny komunikat zamiast indeksować pusty dokument — najgorszym możliwym wynikiem byłoby źródło oznaczone jako „gotowe”, które nic nie zawiera. Rozwiązaniem jest rozpoznawanie optyczne przed importem albo dostarczenie dokumentu w DOCX lub tekście. Rozpoznawania optycznego nie mamy wdrożonego w obecnym łańcuchu.

Czy działa po rumuńsku i rosyjsku?

Tak, i jest jeden detal, który ma większe znaczenie, niż wygląda. Dzielenie na fragmenty tnie między zdaniami, a nasza reguła rozpoznaje koniec zdania po którym następuje wielka litera łacińska **lub** cyrylica, w tym rumuńskie znaki diakrytyczne. Separator napisany dla angielskiego nie rozpoznaje początku zdania w cyrylicy i tworzy sklejone fragmenty, co bezpośrednio wpływa na jakość wyszukiwania. Po stronie głosowej model reprezentacji używany u dostawcy jest wielojęzyczny.

Kiedy NIE opłaca się wyszukiwanie semantyczne?

Gdy korpus jest mały, stabilny i napisany przez was — na przykład zawartość własnej strony. W publicznej własnej platformie wybraliśmy celowo wyszukiwanie przez nakładanie się słów nad własnym tekstem platformy, podzielonym na krótkie akapity, z których każdy niesie stronę źródłową. Bez wektorów, bez magazynu wektorowego, bez dodatkowego żądania w sieci i, co najważniejsze, bez żadnego źródła spoza repozytorium. Asystent może tylko powtarzać to, co już mówi strona, a każdą odpowiedź można sprawdzić na stronie napisanej przez człowieka. Gdy główną stawką jest to, by nic nie zostało zmyślone, to przebija wyszukiwanie semantyczne.

Trzymacie nas w waszej platformie w niewoli?

Źródła są wasze i pozostają w oryginalnej formie; fragmenty i reprezentacje znajdują się w bazie danych waszej instalacji, a nie w zewnętrznej usłudze wyszukiwania, do której dostęp mamy tylko my. Model reprezentacji jest jednak zamawiany przez własną bramkę modeli, więc zmiana dostawcy nie dotyka kodu bazy wiedzy. Reprezentacje wektorowe są jednak powiązane z modelem, który je stworzył: zmiana modelu wymaga ponownego indeksowania całego korpusu. To operacja obliczeniowa, a nie darmowa, i lepiej wiedzieć to na początku niż dowiedzieć się w połowie.

Na czym opierają się powyższe stwierdzenia (29 źródeł)

29 z nich to kod i pliki z naszych repozytoriów. Nie publikujemy ich nazw ani numerów linii: razem, na jednej stronie, opisałoby to zbyt dokładnie, jak zbudowane są systemy, które nie należą tylko do nas. Przechodzimy je razem z Tobą, w repozytorium, na życzenie — weryfikacja pozostaje możliwa, tylko odbywa się w rozmowie.

Jak pracujemy Wszystkie usługi

Co chcesz, żeby działało lepiej?

Opowiedz nam o swoim procesie. Wspólnie ustalimy, co warto zbudować, co da się połączyć i jak sprawdzimy wynik.

Porozmawiajmy