RAG-chunking AI čatbotiem: gudra satura sadalīšana

Tīmekļa vietnes čatbots var droši atbildēt tikai tad, ja tas īstajā brīdī atrod atbilstošo saturu. Tieši šeit izšķiroša nozīme ir RAG-chunking jeb satura sadalīšanai daļās: garas lapas, rokasgrāmatas un palīdzības teksti tiek sadalīti mazākās vienībās, kuras meklēšanas komponents var mērķtiecīgi izgūt. Pārāk lieli bloki satur daudz nevajadzīgas informācijas. Pārāk mazi bloki zaudē kontekstu. Tāpēc laba sadale aklai neseko skaitļiem, bet gan satura struktūrai, nozīmei un turpmākajam lietojumam.

Šī rokasgrāmata ir paredzēta tīmekļa vietņu, atbalsta un satura komandām. Tā paskaidro, kā semantiski sadalīt saturu, saglabāt metadatus, samazināt dublēšanos un ar reālistiskiem meklēšanas jautājumiem pārbaudīt, vai izvēlētā stratēģija darbojas. Pieeja ir neatkarīga no pakalpojumu sniedzēja un to var piemērot gan klasiskajai vektoru meklēšanai, gan hibrīdajām izgūšanas metodēm.

Kāpēc RAG-chunking ietekmē atbilžu kvalitāti

RAG (Retrieval-Augmented Generation) procesā sistēma vispirms meklē attiecīgos zināšanu blokus un pēc tam nodod tos valodas modelim. Tādējādi bloku (chunk) robežas nosaka to, kas vispār var tikt atrasts kopā un izmantots kā konteksts. Ja cenas nosacījums tiek nošķirts no tā izņēmuma, formāli pareiza meklēšana tomēr var sniegt nepilnīgu pamatu. Savukārt, ja bloks satur visu produkta lapu ar navigāciju, variantiem un kājeni, izšķirošais fragments konkurē ar lielu daudzumu traucējošas informācijas.

Satura sadalīšana ietekmē vairākas kvalitātes dimensijas vienlaikus:

• Atrodamība: Vai meklētais apgalvojums skaidri iekļaujas kompaktā vienībā?
• Konteksts: Vai virsraksts, paskaidrojums, ierobežojums un piemērs paliek kopā?
• Precizitāte: Vai atrastais fragments satur pēc iespējas mazāk no tēmas novirzošas informācijas?
• Izsekojamība: Vai fragmentu var attiecināt uz derīgu avotu, valodu un versiju?

Microsoft apraksta fiksētas, mainīgas un semantiskas metodes, uzsverot, ka virsrakstus un citus izkārtojuma signālus var izmantot jēgpilnu robežu noteikšanai. Arī AWS izdala fiksētas, hierarhiskas un semantiskas stratēģijas. Kopīgā praktiskā mācība: tehniskajai sadalīšanai seko satura struktūrai visur, kur tā ir uzticami pieejama.

Sāciet ar semantiskām sadaļām, nevis patvaļīgiem griezumiem

Labs sākumpunkts ir esošā lapas struktūra. H2 un H3 virsraksti, rindkopas, saraksti, FAQ jautājumi, tabulas un skaidri norobežotas norādes jau nes nozīmi. Sadaļai par atgriešanas termiņiem nevajadzētu beigties teikuma vidū vai starp noteikumu un izņēmumu. FAQ jautājumam kopā ar tā atbildi piederaties tam pašam blokam. Instrukciju gadījumā darbības solim, priekšnosacījumam un brīdinājuma norādei pēc iespējas jāpaliek kopā.

Praktiska robežu loģika

1. Vispirms daliet pie dokumentu, lapu un galvenajiem virsrakstiem.
2. Pārbaudiet, vai sadaļa apskata tieši vienu saprotamu galveno tēmu.
3. Sadaliet tikai tās sadaļas, kas ir par lielu izgūšanai vai modeļa kontekstam.
4. Apvienojiet ļoti īsus fragmentus ar atbilstošu blakus sadaļu.
5. Pievienojiet virsrakstu un struktūras ceļu kā kontekstu katrai daļai.

Izmantojot tīru HTML vai Markdown, šo metodi var viegli automatizēt. Nestrukturētiem PDF failiem, nevienmērīgiem eksportiem un skenētiem dokumentiem bieži vien ir nepieciešama iepriekšēja izkārtojuma vai teksta atpazīšana. Īpaši pārbaudiet tabulas, kolonnas, galvenes un lapu pārrāvumus: tas, kas vizuāli atrodas blakus, nolasīšanas laikā var nonākt nepareizā secībā.

Uztveriet bloka izmēru kā testa vērtību, nevis dogmu

Nav vienas universālas ideālās bloka (chunk) hronoloģijas vai izmēra. Microsoft min 512 žetonus (tokens) ar 25 procentu pārklāšanos kā iespējamo sākumpunktu noteiktiem scenārijiem, taču norāda, ka optimālais iestatījums ir atkarīgs no satura un modeļa. AWS arī dokumentē konfigurējamus izmērus un pārklāšanos. Šādas vērtības ir noderīgas sākuma hipotēzes, nevis kvalitātes pierādījums.

Īsas FAQ atbildes bieži darbojas kā patstāvīgas vienības. Detalizētām procedūru instrukcijām nepieciešams vairāk konteksta. Juridiskajos vai līgumu tekstos noteikumu, piemērošanas jomu un izņēmumu nedrīkst atdalīt. Savukārt produktu salīdzinājumi var būt jēgpilni pa rindām vai sadaļām, ja tiek nodrošināti kolonnu virsraksti un saikne ar produktu.

Kā atpazīt pārāk lielus vai pārāk mazus blokus

Pārāk liels bloks parasti ir tad, ja tajā ir sajaukti vairāki meklēšanas nolūki, svarīgais teikums pazūd starp navigāciju un papildinformāciju, vai daudzi meklēšanas rezultāti atgriež vienu un to pašu apjomīgo bloku. Pārāk mazs tas ir tad, ja vietniekvārdiem vairs nav piesaistes, trūkst virsrakstu, nosacījumi tiek atdalīti no apgalvojumiem vai ir nepieciešami vairāki meklēšanas meklēšanas meklējumi, lai saprastu vienkāršu jautājumu.

Tāpēc salīdziniet vismaz divus vai trīs variantus ar vienu un to pašu jautājumu kopu. Katru reizi mainiet tikai vienu parametru, piemēram, mērķa izmēru vai robežu loģiku. Tādējādi būs skaidri redzams, kas faktiski uzlabo meklēšanas kvalitāti un atbilžu atsauces.

Pārklāšanās aizsargā kontekstu – un vienlaikus rada dublikātus

Neliela pārklāšanās var novērst to, ka svarīgs teikums tiek zaudēts tieši uz bloka robežas. Tā ir īpaši noderīga, ja tehniskā sadalīšana pēc garuma ir neizbēgama. Tomēr pārāk liela pārklāšanās rada blakusparādības: gandrīz identiski rezultāti aizņem vairākas meklēšanas vietas, palielina konteksta apjomu un var mākslīgi dominēt pār apgalvojumu.

Tāpēc izmantojiet pārklāšanos mērķtiecīgi. Uz struktūru balstītām sadaļām bieži pietiek paņemt līdzi virsrakstu, struktūras ceļu un īsu pāreju. Garākiem teksta gabaliem var būt lietderīgi saglabāt nelielu iepriekšējās sadaļas daļu. Pēc tam nomēriet, vai atšķirīgi relevanti avoti paliek starp labākajiem rezultātiem, vai tos izstumj dublikāti.

Metadati padara bloku drošu lietošanai

Produktīvai zināšanu bāzei ar tīru tekstu vien reti kad pietiek. Katram blokam jāsaglabā sava izcelsme un piemērošanas joma. AWS apraksta metadatus kā pamatu filtrēšanai vaicājuma laikā. Tīmekļa vietnes zināšanu bāzē īpaši noderīgi ir šādi lauki:

• kanoniskais avota URL un lapas nosaukums,
• virsrakstu ceļš lapas ietvaros,
• valoda vai reģionālais iestatījums (locale),
• satura tips, piemēram, FAQ, instrukcija, vadlīnijas vai produkta informācija,
• publicēšanas vai izmaiņu datums,
• produkts, reģions vai mērķauditorija, ja tas ir būtiski nozares kontekstā,
• piekļuves un apstiprinājuma statuss nepubliskam saturam.

Tas ļauj, piemēram, meklēt tikai latviešu valodā esošu, pašlaik apstiprinātu atbalsta saturu. Turklāt avotu var saistīt ar saiti atbildē un mērķtiecīgi pārstrādāt vēlākas atjaunināšanas laikā. To, kā sistemātiski nodrošināt satura aktualitāti, parāda rokasgrāmata KI-Chatbot-Wissensbasis aktuell halten.

Mājaslapas šablona teksta un dublikātu dzēšana pirms indeksēšanas

Navigācija, paziņojumi par sīkfailiem, atkārtoti kontakta bloki un globālās kājenes nepieder katram blokam. Pretējā gadījumā veidojas simtiem gandrīz identisku ierakstu, kas var izstumt reālo saturu. Pirms sadalīšanas noņemiet atkārtotos lapas elementus un normalizējiet nevajadzīgās atstarpes, dekoratīvās zīmes un tehniskos fragmentus.

Pievērsiet uzmanību arī satura dublikātiem. Ja viens un tas pats atgriešanas noteikums ir formulēts atšķirīgi palīdzības, produktu un piegādes lapās, jānosaka atbildīgais pamata avots. Novecojušās kopijas tiek noņemtas, pāradresētas vai tām tiek piešķirta skaidri zemāka prioritāte. Satura sadalīšanas process nevar pārvērst pretrunīgus avotus par uzticamām zināšanām.

Apzināta īpašo gadījumu apstrāde

FAQ saturs

Saglabājiet jautājumu un atbildi kopā. Ļoti īsu atbilžu gadījumā papildiniet tās ar vispārējo tēmas jomu. Viena un tā paša jautājuma varianti var būt noderīgi meklēšanai, taču tos nedrīkst indeksēt kā vairākkārtēju atbildes tekstu.

Tabulas un saraksti

Tabulas rinda bez kolonnu virsrakstiem parasti ir nesaprotama. Tāpēc atkārtojiet vai norādiet attiecīgos galvenes terminus blokā. Garu sarakstu gadījumā katrai daļai jāsaglabā saraksta nosaukums un kopīgais ievads. Pēc ieguves pārbaudiet, vai vērtības joprojām ir piesaistītas pareizajai pazīmei.

Daudzvalodu lapas

Atdaliet saturu pēc valodas/reģiona (locale) un saglabājiet valodu kā metadatu. Vaicājumam latviešu valodā nevajadzētu nejauši atgriezt novecojušu angļu valodas sadaļu tikai tāpēc, ka tajā ir līdzīgi meklēšanas termini. Kopīgi tulkošanas vai lapu identifikatori palīdz savienot variantus, nesajaucot tos vienā teksta blokā.

Meklēšanas testu veikšana pirms atbilžu pārbaudes

Vispirms novērtējiet, vai meklēšanas sistēma atrod pareizo fragmentu. Tikai pēc tam izvērtējiet valodas modeļa formulējumu. Nelielai reālu lietotāju jautājumu kopai (Golden Set) jāsatur skaidri jautājumi, sinonīmi, vairākdaļīgi pieprasījumi, robežgadījumi un jautājumi, uz kuriem nav dokumentētas atbildes. Katram jautājumam iepriekš definējiet, kurš avots vai sadaļa tiek gaidīta.

Pārbaudiet vismaz:

• vai gaidītā sadaļa parādās starp pirmajiem rezultātiem,
• vai nerelevanti vai dublēti rezultāti neizstumj svarīgus avotus,
• vai visi nepieciešamie nosacījumi un izņēmumi ir sniegtajā kontekstā,
• vai avots un tā aktualitātes statuss paliek izsekojams,
• vai sistēma, trūkstot zināšanām, droši neizdomā atbildi.

Raksts KI-Chatbot-Antwortqualität mit Golden Set und RAG-Tests messen apraksta atbilstošo pārbaudes procesu. Redzamiem pierādījumiem rokasgrāmata Chatbot-Antworten mit Quellen belegen papildina perspektīvu par saišu pārbaudi un nenoteiktību.

Pārbaudes lapa ieviešanai

1. Veiciet satura inventarizāciju: apkopojiet lapu veidus, valodas, formātus un atbildīgos avotus.
2. Pārbaudiet ieguvi: pārbaudiet virsrakstus, tabulas un lasīšanas secību reprezentatīvos piemēros.
3. Definējiet robežas: dodiet priekšroku semantiskām sadaļām un izmantojiet fiksētus izmērus tikai kā rezerves loģiku.
4. Saglabājiet kontekstu: pievienojiet lapas nosaukumu, virsrakstu ceļu un nepieciešamās pārejas.
5. Plānojiet metadatus: strukturēti saglabājiet URL, valodu, aktualitāti, satura tipu un piekļuves statusu.
6. Iztīriet dublikātus: pirms indeksēšanas iztīriet šablona tekstus un pretrunīgas kopijas.
7. Pārbaudiet variantus: salīdziniet izmērus un pārklāšanos, izmantojot to pašu jautājumu kopu (Golden Set).
8. Pārraugiet darbību: regulāri izvērtējiet trūkstošos rezultātus, novecojušos avotus un lietotāju atsauksmes.

Secinājums: labi bloki ir saprotamas zināšanu vienības

RAG-chunking nav vienreizējs tehnisks iestatījums, bet gan satura arhitektūra mašīnizgūšanai (retrieval). Labi bloki atbild uz skaidri definētu apakšpieprasījumu, saglabā nepieciešamo kontekstu un ir attiecināmi uz derīgu avotu. Virsraksti, metadati un kontrolēta pārklāšanās ir tikpat svarīgi kā tīrais garums.

Sāciet ar dažiem reprezentatīviem satura veidiem, mēriet izgūšanas rezultātus pirms atbildes stila izvērtēšanas un dokumentējiet katru izmaiņu. Ja pēc tam vēlaties izveidot tīmekļa vietnes čatbotu uz strukturētas zināšanu bāzes pamata, atradīsiet piemērotu sākumu ChatReact funkciju pārskatā.

Avoti

• Microsoft Learn: Chunk large documents for vector search solutions in Azure AI Search
• Microsoft Learn: Chunk and vectorize by document layout
• AWS Bedrock: How content chunking works for knowledge bases
• AWS Bedrock: Include metadata in a data source