LLM-ዎች በአንድ ጊዜ «ማየት» የሚችሉት ውስን መጠን ያለው ጽሑፍ ብቻ ነው (የአውድ መስኮት)። ይህ ለአነስተኛ ተግባራት ይሠራል፤ የዕውቀት ማከማቻው በሺዎች ገጾች ላይ ሲሰፋ ግን ውጤታማነቱን ያጣል። የአውድ መስኮቱ በቂ ቢሆንም፣ «በሳር ክምር ውስጥ መርፌ የመፈለግ» ችግር አፈጻጸሙን ሊያዳክም ይችላል።
RAG («retrieval augmented generation») በጣም የተለመደ ንድፍ ሆኗል። በዚህ ንድፍ የዕውቀት ማከማቻ (ሰነዶች፣ ዊኪዎች፣ ፖሊሲዎች፣ የንግግር ጽሑፎች ወዘተ) ይያዛል፤ የተጠቃሚው ጥያቄ በትርጉም ይፈለግና ኢምቤዲንጎችን በመጠቀም እጅግ ተዛማጅ የሆኑ ቁርጥራጮች ይመለሳሉ፤ ከዚያም እነዚያ ክፍሎች ከጥያቄው ጋር ለLLM ይሰጣሉ። ይህ የሞዴሉን አውድ ይገድባል፤ በትክክል ሲተገበርም የመልስ ጥራትን ሊያሻሽልና ቅዠቶችን ሊቀንስ ይችላል።
pgai በታመነው ክፍት ምንጭ ዳታቤዝ PostgreSQL ላይ «AI retrieval» የሥራ ፍሰቶችን ለመገንባት የሚያግዝ ክፍት ምንጭ የPostgres ቅጥያ (እና ተጓዳኝ መሣሪያዎች) ነው።
ዋናው ሐሳብ ዳታቤዙን ለኢምቤዲንጎች «ማከማቻ ብቻ» አድርጎ ከመጠቀም ይልቅ፣ አብዛኛውን መደበኛ የRAG ሂደት ወደ ዳታቤዝ ንብርብር ማስገባት ነው (ማስገባት → መከፋፈል → ኢምቤዲንግ መፍጠር → ኢምቤዲንጎችን እንደተመሳሰሉ ማቆየት)።
የመጀመሪያ ግምገማችን ተስፋ ሰጪ እንደሆነ ነው፤ ሆኖም የRAG ሂደትዎ ትንሽ እንኳ ውስብስብ ከሆነ—በተለይ የመከፋፈያ ዘዴዎቹ—ተስማሚ አይሆንም። ይህን ፕሮጀክት ግን በቅርብ እንከታተለዋለን።
RAGን ለመገንባት ብዙ መንገዶች አሉ፤ ስለተለያዩ የRAG አቀራረቦች ዝርዝር ማብራሪያ ለማግኘት ብጁ የRAG መፍትሔዎች ተግባራዊ ምሳሌዎችን ያንብቡ። ለጥራት ትኩረት ሲሰጥ የንድፍ አማራጮቹ በሚያስገርም ሁኔታ ይሰፋሉ፤ የተለመደው «ነባሪ» አቀራረብ ግን በአጠቃላይ ይህን ይመስላል፦
ብዙ ሰነዶችን ይውሰዱ።
ሰነዶቹን በክፍሎች ይከፋፍሏቸው። ይህን ለማድረግ ብዙ ዘዴዎች አሉ (ለምሳሌ፣ በአንቀጽ ወይም በትርጉም ተዛማጅነት መመደብ)።
እያንዳንዱን ክፍል ወደ ኢምቤዲንግ ይቀይሩ።
ኢምቤዲንጎቹን በቬክተር ዳታቤዝ (Pinecone፣ Milvus ወዘተ) ወይም pgvectorን በመጠቀም በPostgres ውስጥ ያከማቹ።
ጥያቄ ሲቀርብ በጣም ተዛማጅ የሆኑ ክፍሎችን ይፈልጉ `እና ለLLM ያስገቧቸው (እዚህም ይህን ለማድረግ ብዙ መንገዶች አሉ)።
በብዙ የቴክኖሎጂ ስብስቦች ውስጥ ደረጃዎች (1)–(3) ከዳታቤዙ ውጭ በመተግበሪያ ኮድ ወይም በውሂብ ሂደት ይከናወናሉ፤ ዳታቤዙ በአብዛኛው የሚያገለግለው ለሚከተሉት ነው፦
ኢምቤዲንጎችን ማከማቸት
ኢምቤዲንጎችን መፈለግ
pgai ይህን ድንበር ለማደብዘዝ የሚሞክር የPostgres ቅጥያ ነው (ክፍት ምንጭ፣ በTimescale የተዘጋጀ)።
ኢምቤዲንጎችን መተግበሪያዎ በእጅ እንደሚያስተዳድራቸው ነገር ከመቁጠር ይልቅ፣ pgai የዳታቤዝ ባህሪ ያደርጋቸዋል፦
ኢምቤዲንግ እንዲፈጠርለት የሚፈልጉትን ሠንጠረዥ ወይም ሰነዶች ይገልጻሉ።
የኢምቤዲንግ ሞዴሉንና የመከፋፈያ ስልቱን ይወስናሉ።
ምንጭ ውሂብዎ ሲቀየር ኢምቤዲንጎቹን ወቅታዊ ማድረግን ጨምሮ፣ ቀሪውን ሁሉ pgai ያስተዳድራል።
የሚሰጠው ተስፋ ማራኪ ነው፦
ጥገና የሚያስፈልገው ብጁ ማገናኛ ኮድ ይቀንሳል።
መሠረታዊ ምንጭ ሰነዶቹ ሲቀየሩ ኢምቤዲንጎቹን «ወቅታዊ» ማድረግ ቀላል ይሆናል።
Postgres/pgai ድጋሚ ሙከራዎችን፣ የፍጥነት ገደቦችን፣ ያልተሳኩ ሥራዎችን ወዘተ ያስተዳድራል።
ለአንባቢዎች ማስታወሻ፦ pgai pgvectorን (ሌላ በጣም ታዋቂ የRAG Postgres ቅጥያ) አካቶ ይዟል። pgvector በPostgres ላይ የቬክተር ማከማቻና የተመሳሳይነት ፍለጋ ያክላል፤ pgai ደግሞ በዚያ ላይ ተመሥርቶ እንደ መከፋፈል፣ ኢምቤዲንግ መፍጠርና ኢምቤዲንጎቹን ወቅታዊ ማድረግ ያሉ የRAG ሂደት ደረጃዎችን በራስ ሰር ያከናውናል።
1) ማስነሳቱ ቀላል ነው።
ሁሉም ነገር ሲሠራ ሂደቱ ቀላል ነው፦
የTimescale docker imagesን (ዳታቤዝ + worker) ያውርዱ።
የኢምቤዲንግ አቅራቢዎን API ቁልፍ ያቅርቡ።
vectoriserን ለመግለጽ ጥቂት SQL ያስኪዱ (በመሠረቱ፦ ምን ኢምቤድ እንደሚደረግ፣ እንዴት እንደሚከፋፈልና የትኛው ሞዴል እንደሚጠቀም)።
ከዚያ በኋላ pgai የvectoriser worker እንደ የተለየ ሂደት እንዲሠራና ኢምቤዲንጎችን በማይመሳሰል ጊዜ እንዲፈጥር ያደርጋል (ለምሳሌ፣ በየ5 ደቂቃው ወይም በፈለጉት የጊዜ ልዩነት)።
2) ሙሉውን ሂደት ከዳታቤዙ «አጠገብ» ማከናወን ጥሩ ነው።
pgai ይዘትን ከሠንጠረዦች ማስገባት ይችላል፤ እንዲሁም እንደ S3 ካሉ ቦታዎች ሰነዶችን ጭኖ መተንተን + መከፋፈል + ኢምቤዲንግ መፍጠር ይችላል። እንደ PDF፣ Markdown ወዘተ ያሉ የተለያዩ የጽሑፍ ሰነድ ቅርጸቶችንም መያዝ ይችላል።
1) ብዙ ቁጥጥር ያጣሉ (RAG ደግሞ አንዳንድ ጊዜ ቁጥጥር ይፈልጋል)።
ከመልስ ጥራት አንጻር ከፍተኛ አፈጻጸም ያላቸው የRAG ስርዓቶች ብዙውን ጊዜ እንደሚከተሉት ያሉ ብጁ ሂደቶችን ይፈልጋሉ፦
ብጁ የመከፋፈያ ደንቦች (በርዕስ፣ በገጽ፣ በተናጋሪ ተራ ወዘተ)
ሜታዳታን የሚያገናዝብ መከፋፈል (የክፍል ርዕሶችን፣ የጊዜ ማህተሞችን፣ ደራሲዎችንና የሰነድ ዓይነትን ማቆየት)
ለእያንዳንዱ የሰነድ ዓይነት የተለያዩ የኢምቤዲንግ ስልቶች
pgai ከላይ በተጠቀሱት ረገድ አነስተኛ ተለዋዋጭነት ይሰጣል።
በአሁኑ ጊዜ ሁለት ዋና የመከፋፈያ ስልቶች አሉ፦ character text splitter እና recursive character text splitter፤ በተጨማሪም ያለመከፋፈል አማራጭ አለ። ይህ ለአንዳንድ የአጠቃቀም ሁኔታዎች በቂ ሊሆን ይችላል፤ ብዙ የምርት ደረጃ RAG ስርዓቶች ግን የበለጠ ማበጀት ይፈልጋሉ።
Timescale እንደ Chonkie ባሉ ላይብረሪዎች የምናያቸውን የተራቀቁ የመከፋፈያ ስልቶች ማካተትና እንደ የAnthropic አውዳዊ ሰርስሮ ማውጣት ያሉ የላቁ ንድፎችን መደገፍ ቢችል እጅግ ጥሩ ይሆናል።
2) ጽሑፍ-ቀዳሚ እንጂ ባለብዙ ሞዳሊቲ አይደለም።
ብዙ አስደሳች የRAG ችግሮች ከእንግዲህ ጽሑፍ ብቻ አይደሉም፦
ሥዕላዊ መግለጫዎች ያሏቸው PDF-ዎች
የማያ ገጽ ቅጂዎች / ምስሎች
የድምፅ ቅጂዎች
የቪዲዮ ቅንጥቦች
ከእነዚህ ምንጮች «ጽሑፍ ማውጣት» ቢችሉም፣ ይህ ከእውነተኛ ባለብዙ ሞዳሊቲ የኢምቤዲንግ ሂደት ጋር ተመሳሳይ አይደለም።
pgai ወደፊት ባለብዙ ሞዳሊቲ ሞዴሎችን ከጫፍ እስከ ጫፍ ቢደግፍ—በS3 የተከማቹ ትልልቅ ምስሎችን፣ ድምፅንና ቪዲዮን በጠንካራ ማመሳሰል መጫን → መከፋፈል → ኢምቤዲንግ መፍጠር—አሳማኝ ይሆናል። ዛሬ ግን የጽሑፍ ኢምቤዲንግ የሥራ ፍሰት ነው።
3) ኢምቤዲንጎችን ብቻ ከፈለጉ፣ pgai ላያስፈልግዎ ይችላል።
የማስገቢያ ሂደትዎ አስቀድሞ ብጁ ከሆነ (ወይም ብጁ መሆን ካለበት)፣ «ለጽሑፍ ክፍሎች ኢምቤዲንግ መፍጠር» የRAG እጅግ አስቸጋሪው ክፍል አይደለም። በዚያ ሁኔታ pgai ቀላሉን የችግሩን ክፍል እየፈታ ነው።
በተጨማሪም፣ የዕውቀት ማከማቻዎ ብዙ ጊዜ የማይዘምን ከሆነ፣ ኢምቤዲንጎችን በራስ ሰር የማመሳሰል ጥቅም ያን ያህል ከፍተኛ አይደለም።
pgaiን በተለይ በጥሩ ሁኔታ የሚጠቀሙበት አንዱ መንገድ በዳታቤዞችዎ ላይ የtext-to-sql በይነገጽ መዘርጋት ነው። ይህን በpgai በሚቀርበው semantic_catalog ሞጁል በቀላሉ ማከናወን ይቻላል። እንዲህ በቀላሉ ያዋቅሩ፦
Bash
ከዚያም pgai semantic-catalog createን በመጠቀም semantic catalog የውሂብ መዝገበ ቃላትዎን እንዲሰበስብ ያድርጉ። ይህ ከውሂብ ማከማቻዎ እንደሚከተለው የሚመስል አውድ ይፈጥራል፦
Plain Text
ይህ አውድ አሁን ለpgai በተለያዩ መንገዶች ይገኛል፦
በትርጉም ፍለጋ፦
ይህ ጥያቄ ከተፈጥሯዊ ቋንቋ ጥያቄዎ ጋር ሊዛመዱ የሚችሉ ሠንጠረዦችን፣ ፋንክሽኖችንና ሌሎች ኦብጀክቶችን ይመልሳል፦
Bash
ጥሬ አውድ ያግኙ፦
ይህ ከተፈጥሯዊ ቋንቋ ጥያቄዎ ጋር የተያያዘውን ጥሬ YAML አውድ ያሳያል፦
Bash
SQL ይፍጠሩ፦
ወይም ጥያቄዎን ለመመለስ የሚያስፈልገውን ጥሬ SQL በቀጥታ መፍጠር ይችላሉ። ከቀደመው ደረጃ የተገኘው አውድ ወደ LLM ይላካል፣ ከዚያም መልስ ይፈጠራል፦
Bash
በአንጻራዊነት ቀላል የRAG ስርዓት እየገነቡ ከሆነ፣ የሚከተሉትን ከፈለጉ pgaiን መሞከር ተገቢ ነው፦
Postgresን እንደ ዋና የመረጃ ስርዓት፣
አነስተኛ ማገናኛ ኮድ፣
በራስ ሰር ተመሳስለው የሚቆዩ ኢምቤዲንጎች፣
text-to-SQLን በዳታቤዞችዎ ላይ በፍጥነት የመተግበሪያ መንገድ፣
አዳዲስ የRAG መሣሪያዎችንና የPostgres ቅጥያዎችን ለመሞከር።
የRAG ሂደትዎ ከሚከተሉት አንዱን የሚፈልግ ከሆነ፣ pgaiን ለመጠቀም መጠበቅ የተሻለ ሊሆን ይችላል፦
ብዙ ብጁ የማስገቢያ ወይም የመከፋፈያ ሎጂክ
የተለያዩ የትንተና መስፈርቶች ያሏቸው ብዙ የሰነድ ዓይነቶች
ባለብዙ ሞዳሊቲ ኢምቤዲንጎች
በመጨረሻም፣ pgvector በስፋት ጥቅም ላይ እንደዋለ ግልጽ ቢሆንም፣ pgai ተመሳሳይ የፍላጎትና የድጋፍ ደረጃ ይኖረው እንደሆነ ግልጽ አይደለም (ለ18 ወራት ገደማ ብቻ እንደቆየ ቢታወቅም)።
pgai ዳታቤዞች አብዛኛውን መደበኛ የክወና ሥራ እንዲሠሩና የመተግበሪያዎ ኮድ ቀላል እንዲሆን የሚያስችል አስደሳች የRAG አቀራረብ ነው።
በአሁኑ ጊዜ፦
ለቀላል የRAG ዝግጅቶች ጠቃሚና ለመጠቀም በእውነት ምቹ ነው
ለበለጠ ብጁ ሂደቶች—በተለይ ለባለብዙ ሞዳሊቲ—በቂ ተለዋዋጭነት የለውም
ተስፋ የሚሰጥ ሲሆን፣ ወደፊት እንዴት እንደሚሻሻል መከታተል በእርግጥ ተገቢ ነው።