LLM geta aðeins „séð“ takmarkað magn texta í einu (samhengisgluggann). Þetta virkar fyrir lítil verkefni en bregst þegar þekkingargrunnur spannar þúsundir síðna. Jafnvel þegar samhengisglugginn er nógu stór geta afköst versnað vegna vandans við að „finna nál í heystakki“.
RAG („myndun með aukinni upplýsingaleit“) er orðið mjög algengt mynstur þar sem haldið er utan um þekkingargrunn (skjöl, wiki-síður, reglur, afrit o.fl.), merkingarfræðileg leit er gerð út frá fyrirspurn notanda til að sækja viðeigandi textabúta með vigurgreypingum og þeir síðan sendir til LLM ásamt spurningunni. Þetta takmarkar samhengi líkansins og getur, ef rétt er að staðið, bætt svör og dregið úr ranghugmyndum.
pgai er opinn Postgres-viðauki (ásamt tengdum verkfærum) sem auðveldar gerð verkferla fyrir „upplýsingaleit með gervigreind“ ofan á trausta, opna gagnagrunninum PostgreSQL.
Meginhugmyndin er að færa stærri hluta hefðbundins RAG-ferlis í gagnagrunnslagið (lesa inn → búta → greypa → halda vigurgreypingum samstilltum), í stað þess að nota gagnagrunninn „aðeins sem geymslu“ fyrir vigurgreypingar.
Fyrstu kynni lofa góðu, en um leið og RAG-ferlið verður örlítið flókið (sérstaklega bútunaraðferðirnar) hentar lausnin ekki lengur. Við munum þó fylgjast náið með þessu verkefni.
Það eru margar leiðir til að byggja RAG. Ítarlegri umfjöllun um ólíkar aðferðir má finna í Hagnýtum dæmum um sérsniðnar RAG-lausnir. Þegar gæði skipta máli reynist hönnunarsviðið furðudjúpt, en algenga „sjálfgefna“ aðferðin er yfirleitt á þessa leið:
Safna saman skjölum.
Skipta þeim í búta. Til þess eru margar ólíkar aðferðir (t.d. málsgreinar og merkingarfræðilegir hópar).
Breyta hverjum bút í vigurgreypingu.
Geyma vigurgreypingarnar í vigurgagnagrunni (Pinecone, Milvus o.fl.) eða í Postgres með pgvector.
Þegar fyrirspurn berst er leitað að líkustu bútunum `og þeir sendir til LLM (aftur ... það eru líka margar leiðir til þess).
Í mörgum tæknistæðum fara skref (1)–(3) fram utan gagnagrunnsins, í forritskóða eða gagnavinnsluferli, en gagnagrunnurinn er einkum notaður til að:
geyma vigurgreypingar
leita í vigurgreypingum
pgai er opinn Postgres-viðauki, þróaður af Timescale, sem reynir að má út þessi mörk.
Í stað þess að vigurgreypingum sé handstýrt af forritinu gerir pgai þær að eiginleika gagnagrunnsins:
Þú tilgreinir hvaða töflu eða skjöl á að greypa.
Þú tilgreinir greypingarlíkanið og bútunaraðferð.
pgai sér um afganginn, þar á meðal að uppfæra vigurgreypingarnar þegar upprunagögnin breytast.
Fyrirheitið er heillandi:
Minni sérsniðinn tengikóði sem þarf að viðhalda.
Auðveldara ætti að vera að halda vigurgreypingunum „ferskum“ þegar upprunaskjölin breytast.
Postgres/pgai sér um endurtilraunir, tíðnitakmarkanir, misheppnuð verk o.fl.
Athugasemd til lesenda: pgai inniheldur pgvector (annan mjög vinsælan Postgres-viðauka fyrir RAG). pgvector bætir vigurgeymslu og skyldleikaleit við Postgres, en pgai byggir ofan á það og sjálfvirknivæðir skref RAG-ferlisins, svo sem bútun, greypingu og uppfærslu vigurgreypinganna.
1) Einfalt er að koma því í gang.
Auðveldasta leiðin er tiltölulega einföld:
Sækja Docker-myndir Timescale (gagnagrunn + vinnsluþjón).
Gefa upp API-lykil greypingarveitunnar.
Keyra nokkrar SQL-skipanir til að skilgreina vigurgreypinn (í grunninn: hvað á að greypa, hvernig á að búta það og hvaða líkan á að nota).
Eftir það lætur pgai sérstakt ferli keyra vinnsluþjón vigurgreypisins og búa ósamstillt til vigurgreypingar (t.d. á fimm mínútna fresti eða með þeirri tíðni sem óskað er).
2) Þægilegt er að keyra allt ferlið „nálægt“ gagnagrunninum.
pgai getur lesið inn efni úr töflum og einnig sótt skjöl frá stöðum á borð við S3, síðan þáttað þau, bútað og greypað. Það ræður einnig við ýmis textaskjalasnið, svo sem PDF, Markdown o.fl.
1) Þú missir mikla stjórn (og RAG krefst stundum stjórnunar).
Afkastamikil RAG-kerfi (miðað við gæði svara) þurfa oft sérsniðin ferli, svo sem:
sérsniðnar bútunarreglur (eftir fyrirsögnum, síðum, mælendaskiptum o.s.frv.)
bútun sem tekur mið af lýsigögnum (varðveitir kaflaheiti, tímamerki, höfunda og skjalagerð)
ólíkar greypingaraðferðir eftir skjalagerð
pgai býður minni sveigjanleika hvað þetta varðar.
Sem stendur eru tvær meginbútunaraðferðir: einfaldur textaskiptir eftir stafafjölda og endurkvæmur textaskiptir eftir stafafjölda, auk möguleika á engri bútun. Það kann að duga í sumum tilfellum, en mörg RAG-kerfi í framleiðslu krefjast meiri sérsniðningar.
Frábært væri ef Timescale gæti innleitt sumar af þróaðri bútunaraðferðunum sem finnast í söfnum á borð við Chonkie og jafnframt stutt háþróaða hönnun á borð við samhengisbundna upplýsingaleit Anthropic.
2) Texti er í forgrunni, ekki fjölhátta gögn.
Mörg áhugaverð RAG-verkefni snúast ekki lengur eingöngu um texta:
PDF-skjöl með skýringarmyndum
skjámyndir / myndir
hljóðupptökur
myndskeið
Jafnvel þótt hægt sé að „draga út texta“ úr þessum heimildum jafngildir það ekki raunverulegu fjölhátta greypingarferli.
Ef pgai styður síðar fjölhátta líkön frá upphafi til enda (lesa inn → búta → greypa stórar myndir, hljóð og myndskeið sem geymd eru í S3, með traustri samstillingu) yrði það mjög áhugavert. Í dag er þetta hins vegar ferli fyrir textagreypingar.
3) Ef þú þarft aðeins vigurgreypingar þarftu ef til vill ekki pgai.
Ef innlestrarferlið er þegar sérsniðið (eða þarf að vera það) er „greyping textabúta“ ekki erfiðasti hluti RAG. Við þær aðstæður leysir pgai auðveldasta hluta vandans.
Ef þekkingargrunnurinn er sjaldan uppfærður er sjálfvirk samstilling vigurgreypinga einnig minna virði.
Sérlega góð leið til að nota pgai væri að setja texta-í-SQL-viðmót ofan á gagnagrunnana. Þetta má gera nokkuð auðveldlega með semantic_catalog-einingunni sem pgai býður upp á. Settu það einfaldlega upp svona:
Bash
og láttu merkingarfræðilega skrána lesa gagnalýsingarnar með pgai semantic-catalog create. Þetta býr til samhengi úr gagnageymslunni sem lítur einhvern veginn svona út:
Plain Text
pgai getur nú nýtt þetta samhengi á ýmsa vegu:
Með merkingarfræðilegri leit:
Þessi fyrirspurn skilar töflum, föllum og öðrum hlutum sem gætu átt við fyrirspurn þína á náttúrulegu máli:
Bash
Sækja hrátt samhengi:
Þetta birtir hráa YAML-samhengið sem tengist fyrirspurn þinni á náttúrulegu máli:
Bash
Mynda SQL:
Einnig er hægt að mynda beint þann hráa SQL-kóða sem þarf til að svara fyrirspurninni. Samhengið úr fyrra skrefi er sent til LLM og svar myndað:
Bash
Ef þú ert að byggja tiltölulega einfalt RAG-kerfi er þess virði að prófa pgai ef þú vilt:
nota Postgres sem aðalgagnakerfi,
lágmarka tengikóða,
vigurgreypingar sem haldast sjálfkrafa samstilltar,
fljótlega leið til að tengja texta-í-SQL við gagnagrunnana,
prófa ný RAG-verkfæri og Postgres-viðauka.
Líklega er rétt að bíða með pgai ef RAG-ferlið krefst einhvers af eftirfarandi:
mikillar sérsniðinnar innlestrar- eða bútunarvirkni
margra skjalagerða með ólíkar þáttunarkröfur
fjölhátta vigurgreypinga
Að lokum er ljóst að pgvector hefur náð mikilli útbreiðslu, en óvíst er hvort pgai veki jafnmikinn áhuga og fái þar með sambærilegan stuðning (þó að það hafi aðeins verið til í um 18 mánuði).
pgai er áhugaverð RAG-nálgun sem lætur gagnagrunna sinna stærri hluta venjubundins rekstrar og einfaldar þannig forritskóðann.
Eins og er er það:
nothæft og virkilega þægilegt fyrir einfaldar RAG-uppsetningar
ekki nógu sveigjanlegt fyrir sérsniðnari ferli (sérstaklega fjölhátta)
Það lofar góðu og er sannarlega þess virði að fylgjast með þróuninni.