Razumijevanje krpe arhitekture i njegovih osnova

Šta je krpa arhitektura?

Široko gledano, proces krpnog sistema je jednostavan za razumijevanje. Počinje s korisnikom koji šalje brz – pitanje ili zahtjev. Ovaj brzi jezik i pridruženi upit uspoređuju se sa sadržajem baze znanja. Rezultati najbliži zahtevu rangirani su po reda redukcije, a čitav proces se zatim šalje u LLM da bi se odgovorio poslao nazad korisniku.

Kompanije koje su pokušale implementirati krpu saznale su specifičnosti takvog pristupa, počevši od podrške za različite komponente koje čine ragu mehanizam. Ove su komponente povezane sa koracima potrebnim za transformaciju podataka, da ga prenose u izvorni sustav za generiranje odgovora pomoću LLM-a.

Priprema podataka, nužnost čak i sa krpom

Prvi korak je prikupljanje dokumenata koje želite pretraživati. Iako je primamljivo gutati sve dostupne dokumente, ovo je pogrešna strategija. Pogotovo kao što morate odlučiti hoćete li ažurirati sistem u seriji ili kontinuirano.

“Failures come from the quality of the input. Some customers say to me: ‘I’ve got two million documents, you’ve got three weeks, give me a RAG’. Obviously, it doesn’t work,” Kaže Bruno Maillot, direktor AI za poslovnu praksu u Steriji Sopra Steria. “This notion of refinement is often forgotten, even though it was well understood in the context of machine learning. Generative AI doesn’t make Chocapic”.

LLM nije de facto alat za pripremu podataka. Preporučljivo je ukloniti duplikate i posredne verzije dokumenata i primijeniti strategije za odabir ažurnih stavki. Ovaj pre-izbor izbjegava preopterećenje sistema s potencijalno beskorisnim informacijama i izbjegava probleme sa performansama.

Jednom kada su dokumenti odabrani, RAW podaci – HTML stranice, PDF dokumenti, slike, doc datoteke, itd. – Potrebno je pretvoriti u koristan format, kao što su na primjer, izraženi u JSON datoteci. Ovaj metapodaci ne samo da dokumentuju strukturu podataka, već i njegove autore, porijeklo, datum stvaranja i tako dalje. Ovaj formatirani podaci se zatim pretvaraju u tokene i vektore.

Izdavači su brzo shvatili da je s velikim količinama dokumenata i dugim tekstovima bio neefikasan za vektorizu cijelog dokumenta.

Komad i njegove strategije

Otuda važnost implementacije a “chunking” Strategija. To uključuje razbijanje dokumenta u kratke ekstrakte. Ključni korak, prema Mistral AI, koji kaže, “It makes it easier to identify and retrieve the most relevant information during the search process”.

Ovdje postoje dva razmatranja – veličine fragmenata i načina na koji su dobiveni.

Veličina komada često se izražava kao broj znakova ili tokena. Veći broj komada poboljšava tačnost rezultata, ali množenja vektora povećava količinu resursa i vremena potrebnog za obradu njih.

Postoji nekoliko načina podijeliti tekst u komade.

• Prvi je narez prema fragmentima fiksne veličine – znakova, riječi ili žetona. “This method is simple, which makes it a popular choice for the initial phases of data processing where you need to browse the data quickly,” kaže Ziliz, vektorski uređivač baze podataka.
• Drugi pristup sastoji se od semantičkog kvara – to je na osnovu “natural” Probijanje: rečenicom, po odjeljku – definirano HTML zaglavom na primjer – subjekt ili odlomak. Iako je složeniji za implementaciju, ova metoda je preciznija. Često ovisi o rekurzivnom pristupu, jer uključuje upotrebu logičkih separatora, poput prostora, zareza, potpuno zaustavljanja, naslova i tako dalje.
• Treći pristup je kombinacija prethodne dvije. Hybrid Chunking kombinira početni fiksni prekid s semantičkom metodom kada je potreban vrlo precizan odgovor.

Pored ovih tehnika, moguće je uhvatiti fragmente zajedno, uzimajući u obzir da se neki sadržaj komada mogu preklapati.

“Overlap ensures that there is always some margin between segments, which increases the chances of capturing important information even if it is split according to the initial chunking strategy,” Prema dokumentaciji iz LLM platforme Koče. “Nedostatak ove metode je da generira višak.

Čini se da je najpopularnije rješenje držati fiksne fragmente od 100 do 200 riječi s preklapanjem od 20% do 25% sadržaja između komada.

Ovaj dijeljenje se često vrši pomoću Python biblioteka, poput šljokica ili ntlk-a, ili s “razdjelnicima za tekst” u okviru Langchain.

Pravi pristup općenito ovisi o preciznosti koje zahtijevaju korisnici. Na primjer, semantički raspad čini se prikladnijim kada je cilj pronaći konkretne informacije, poput članka pravnog teksta.

Veličina komada mora odgovarati kapacitetima modela ugradnje. To je upravo zašto je u prvom redu potreban komad. Ovo “allows you to stay below the input token limit of the embedding model”objašnjava Microsoft u svojoj dokumentaciji. “For example, the maximum length of input text for the Azure OpenAI text-embedding-ada-002 model is 8,191 tokens. Given that one token corresponds on average to around four characters with current OpenAI models, this maximum limit is equivalent to around 6,000 words”.

Vektorizacija i ugradnja modeli

Model ugradnje odgovoran je za pretvaranje komada ili dokumenata u vektore. Ti se vektori pohranjuju u bazu podataka.

Ovdje opet, postoji nekoliko vrsta ugradnje modela, uglavnom gustih i rijetkih modela. Gusti modeli uglavnom proizvode vektore fiksne veličine, izražene u X broju dimenzija. Potonji generirajte vektore čija veličina ovisi o dužini ulaznog teksta. Treći pristup kombinira dva do vektorise kratkih ekstrakata ili komentara (prskanje, colbert, IBM rijetko ugrađivanje-30m).

Izbor broja dimenzija odredit će tačnost i brzinu rezultata. Vektor s mnogim dimenzijama bilježi više konteksta i nijanse, ali može zahtijevati više resursa za stvaranje i pretrešavanje. Vektor sa manje dimenzija bit će manje bogati, ali brži za pretraživanje.

Izbor modela ugradnje ovisi i o bazi podataka u kojoj će se vektori pohraniti, veliki jezik koji će biti povezani i zadatak koji će se izvesti. Mjerila poput MTEB rangiranja su neprocjenjivi. Ponekad je moguće koristiti model ugradnje koji ne dolazi iz iste LLM kolekcije, ali potrebno je koristiti isti model ugrađivanja za vektorise na bazi dokumenata i pitanja korisnika.

Imajte na umu da je ponekad korisno za fino podešavanje modela ugrađenim ugrađenim kada ne sadrži dovoljno znanja o jeziku koji se odnosi na određenu domenu, na primjer, onkologiju ili sistemima inženjerstva.

Vektorska baza podataka i njen algoritam za retriver

Vektorske baze podataka čine više od jednostavnih vektora – oni uglavnom uključuju algoritam semantičkog pretraživanja na temelju najbliže susjedske tehnike za indeksiranje i preuzimanje informacija koje odgovaraju pitanju. Većina izdavača je implementirala hijerarhijski plovni plovidbeni algoritam (HNSW). Microsoft je također utjecajan sa Dispann, algoritmom otvorenog koda dizajniran za postizanje idealnog omjera performansi s velikim količinama vektora, na štetu tačnosti. Google je odlučio razviti vlasnički model, SCANN, također dizajniran za velike količine podataka. Proces pretraživanja uključuje prelazak dimenzija vektorskog grafa u potrazi za najbližim približnim susjedom, a zasnovan je na kosinusnom ili euklidskom proračunu udaljenosti.

Kosinus udaljenost je efikasniji prilikom identificiranja semantičke sličnosti, dok je euklidejska metoda jednostavnija, ali manje zahtjevna u pogledu računarskog resursa.

Budući da se većina baza podataka temelji na približnoj potrazi za najbližim susjedima, sustav će vratiti nekoliko vektora koji bi potencijalno odgovarao odgovoru. Moguće je ograničiti broj rezultata (TOP-K CUTOFF). Ovo je čak potrebno, jer želimo korisnikov upit i informacije koje se koriste za stvaranje odgovora na uklapanje unutar prozora LLM kontekst. Međutim, ako baza podataka sadrži veliki broj vektora, može doći do preciznosti ili rezultat koji tražimo može biti izvan granice nametnutog granica.

Hibridna pretraga i reranje

Kombiniranjem tradicionalnog modela pretraživanja kao što je BM25 sa retriverom HNSW-u, može biti koristan za dobivanje dobre omjere troškova i performanse, ali će se također ograničiti na ograničen broj rezultata. Sve što više ne podržavaju sve vektore baze podataka podržavaju kombinaciju HNSW modela sa BM25 (poznatim i kao hibridna pretraga).

Model ponovnog preuzimanja može pomoći da pronađe više sadržaja koji se smatra korisnim za odgovor. To uključuje povećanje granice rezultata koje vraćaju “retriever” Model. Zatim, kako njeno ime sugerira, rearker reordovao komade prema njihovoj relevantnosti za pitanje. Primjeri rerankera uključuju Kohoj Rerank, BGe, Janus AI i elastičnu rerank. S druge strane, takav sustav može povećati kašnjenje rezultata vraćenih korisniku. Možda će biti potrebno i za ponovno osposobiti ovaj model ako je rječnik korišten u bazi dokumenata specifičan. Međutim, neki smatraju korisnim – Relevantno rezultati su korisni podaci za nadgledanje performansi krpnog sistema.

Reranker ili ne, potrebno je poslati odgovore na LLMS. Ovdje se opet nisu stvorene svi LLMS jednaki – veličina njihovog kontekstnog prozora, njihova brzina odgovora i njihova sposobnost da odgovore faktički (čak bez pristupa dokumentima) su svi kriteriji koji se moraju procijeniti. U tom pogledu, Google Deepmind, Openai, Mistral AI, meta i antropski trenirali su svoje LLM-ove da podrže ovu službu za upotrebu.

Procjena i promatranje

Pored reranja, LLM se može koristiti kao sudac za procjenu rezultata i identificirati potencijalne probleme s LLM-om koji bi trebao generirati odgovor. Neki API se oslanjaju umjesto na pravila za blokiranje štetnih sadržaja ili zahtjeva za pristup povjerljivim dokumentima za određene korisnike. Okvir za prikupljanje mišljenja mogu se koristiti i za pročišćavanje krpne arhitekture. U ovom slučaju korisnici su pozvani da bi ocijenili rezultate kako bi se identificirali pozitivne i negativne tačke RAG sistema. Konačno, opasnost svakog od građevinskih blokova potrebna je kako bi se izbjegli problemi troškova, sigurnosti i performansi.