በአሁኑ ጊዜ RAG አንዳንዴ መጥፎ ስም እያገኘ ነው፤ ሰዎች አሁን ፈጽሞ ቀላል እንደሆነ ስለሚያስቡ (መጀመር ቀላል ነው፣ ማስፋት ግን እንዲሁ አይደለም) ወይም ‘ወኪል-ተኮር ሥርዓቶች’ እንደተኩት ስለሚያስቡ ነው (በብዙ ጊዜ ውስጣቸውን ሲመረምሩ በፍጥነት RAGን መምሰል ይጀምራሉ…)።
ይህ የብሎግ ጽሑፍ የተለመዱ ችግሮችን እንዴት እንደምንፈታ ለማሳየት አንድ ሁለት የተሠሩ ምሳሌዎችን ያቀርባል፤ እነሱም፦
የተቀላቀለ ጽሑፍና ቁጥራዊ ውሂብን አያያዝ እና ይህ ቀላል RAGን ለምን እንደሚያስቸግር፦ ቁልፍ ቃላት ይጋጫሉ፣ ቁጥሮችም ትርጉማዊ ፍቺ የላቸውም።
ማጠቃለያን ቅድሚያ የሚሰጡ ኢምቤዲንጎችን መንደፍ ለምን ይጠቅማል፦ ለእያንዳንዱ ክፍል አጭር ገላጭ ማጠቃለያ ይፍጠሩ፣ ከዚያም በዚያ ማጠቃለያ ላይ ኢምቤዲንግና ፍለጋ ያከናውኑ።
ዐውዳዊ ማጠቃለያዎችን እንዴት መፍጠር እንደሚቻል፦ ተመሳሳይ ቅርጽ ያላቸው ስታቲስቲክሶች እንዳይምታቱ የዋናውን ሰነድ ዐውድ ያካትቱ።
በኮድና Pydantic ሞዴሎች መቼ መተማመን እንዳለብዎት፦ ይዘቱን ቃል በቃል ማቆየት በሚያስፈልግበት ጊዜ፣ አስተማማኝነትን ለማግኘት ብጁ ኮድን እና/ወይም Pydantic ሞዴልን ከLLM ጥሪዎች ጋር ያጣምሩ።
መሠረታዊ ነገሮች
የRAG ሥርዓቶች ከድጋፍ ቦቶች እስከ ውስጣዊ የዕውቀት ረዳቶች ድረስ ያሉ መሣሪያዎችን ያንቀሳቅሳሉ።
ከጀርባ በተለምዶ የሚከተሉትን ያደርጋሉ፦
የምንጭ ሰነዶችዎን ወደ ክፍሎች ይከፋፍሉ
እያንዳንዱን ክፍል ወደ ቬክተር ቦታ ኢምቤድ ያድርጉ
በፍለጋ ጊዜ ከፍተኛዎቹን K ክፍሎች ሰርስረው ያውጡ
በእነዚያ ክፍሎች ላይ የተመሠረተ መልስ ይፍጠሩ
LangChain፣ LlamaIndex እና የOpenAI Filestore ያሉ ታዋቂ መሣሪያ ስብስቦች እነዚህን ደረጃዎች እጅግ ቀላል ያደርጓቸዋል። ነገር ግን በተግባራዊ የሥራ ሂደቶች ውስጥ ጥቅጥቅ ያለ ጽሑፍ ብቻ ያልሆነ ውሂብ ያጋጥማል፤ መሠረታዊ RAGም በዚህ ሊቸገር ይችላል። በሚቀጥሉት ክፍሎች የውሂብ ችግሮችን በተጨባጭ ምሳሌዎች እናሳያለን፤ ውስብስብነቱ እየጨመረ ሲሄድም መፍትሔውን ቀስ በቀስ እንገነባለን።
ውሂብዎ ጽሑፍ ብቻ በማይሆንበት ጊዜ (ይህ በእርግጥ ያልተለመደ አይደለም)
በጨዋታ ዐውድ ውስጥ የሚከተለውን የውሂብ ክፍል እንመልከት፦
JSON
ኢምቤዲንጎች የሚሠሩት በትርጉማዊ ፍቺና በሰዋስው አማካይነት በቃላት መካከል ያሉትን የተማሩ ግንኙነቶች በመጠቀም ነው። ከላይ ያለው ውሂብ የጽሑፍና የቁጥሮች ድብልቅ ነው፤ ከዚህ ትክክለኛ ዐውድ ውጭ ቁጥሮቹ ከቃላቱ ጋር ምንም ግንኙነት የላቸውም። ስለዚህ ይህ የውሂብ ክፍል በመጠኑ ገላጭ የሆኑ ቃላትንና ከእነሱ በኋላ የሚመጡ የዘፈቀደ ቁጥሮችን ያጣመረ ነው ማለት እንችላለን።
ይህ ያለን ብቸኛው የውሂብ ዓይነት ቢሆን ኖሮ ችግር አይሆንም ነበር፤ ያሉትን ጥቂት ገላጭ ቃላት ኢምቤዲንጎች በመጠቀም አሁንም ሰርስረን ማውጣት እንችል ነበር (ወይም text-to-sql ብቻ መጠቀም እንችል ነበር)። ነገር ግን ይህ ክፍል ተመሳሳይ ቃላት ባሉባቸው ብዙ ጥቅጥቅ ያሉ የጽሑፍ ክፍሎች መካከል ተቀብሮ ቢገኝስ? ለምሳሌ፦
JSON
አሁን “What is the attack range with Draconic Ascension?” የሚለውን ሰርስረን ማውጣት እንፈልጋለን ብለን እናስብ። ተመሳሳይ ቁልፍ ቃላት ባሏቸው ሌሎች ክፍሎች ጫጫታ ውስጥ ስለተቀበረ፣ የምንፈልገውን ተዛማጅ ክፍል ማግኘት ላንችል እንችላለን።
መሠረታዊው ችግር፣ እነዚህ ክፍሎች ስለ አንድ ርዕስ የተለያዩ የመረጃ ዓይነቶችን ቢይዙም በቂ ልንለያቸው አለመቻላችን ነው። ታዲያ በሆነ መንገድ ልናበለጽገው ወይም ልናሻሽለው እንችላለን? በእርግጥ እንችላለን፦smile:
ውሂብዎን በማጠቃለል ያበልጽጉት፤ አዎ፣ በትክክል አንብበዋል
ክፍሉን በቀጥታ ኢምቤድ ከማድረግ ይልቅ፣ መጀመሪያ ውሂቡ ስለ ምን እንደሆነ የሚገልጽ ማጠቃለያ መፍጠር፣ ከዚያም በማጠቃለያው ላይ ኢምቤዲንግና ሰርስሮ ማውጣት እንችላለን። በማመንጨት ደረጃ ግን ከማጠቃለያው ጋር የተገናኘውን ዋናውን ውሂብ አሁንም እንጠቀማለን።
ስለዚህ ከላይ ለታዩት ሁለት የክፍል ምሳሌዎች እንደሚከተለው ያለ ማጠቃለያ እንፈጥራለን፦
የርቀት፣ የፍጥነትና የጉዳት የጥቃት ስታቲስቲክስ (በነባሪ እና Draconic Ascension ሲኖር)።
የማግበሪያ ሁኔታዎችን፣ የእይታ ውጤቶችንና ታሪኩን ጨምሮ የDraconic Ascension መግለጫና ዝርዝሮች።
ከዚያም ፍለጋው ከማጠቃለያው ጋር “እንዲጣጣም” እናሻሽለዋለን። ለምሳሌ፣ “What is the attack range with Draconic Ascension?” የሚለውን ወደ “What is the statistics of attack range with Draconic Ascension?” እንለውጠዋለን። ይህ በተለይ ከቴክኒክ መስኮች ውጭ ያሉ ተጠቃሚዎች በ~~“ነፃ ስልት”~~ በተለመደ የሰው ቋንቋ ሲጠይቁ አስፈላጊ ነው፤ ደግሞም ከሁሉም በኋላ ትክክለኛነትንና ሙሉነትን ለማሳደግ RAG እንዴት እንደሚሠራ ማወቅ የእነሱ ዕውቀት ወይም ጉዳይ አይደለም።
ነገሮችን ከዐውዳቸው አያውጡ (ይህ በአጠቃላይ ለሕይወትም ይሠራል)
ቀጣዩ ሁኔታ ከታች እንደሚታየው ተመሳሳይ የሚመስሉ በርካታ የውሂብ ክፍሎችን ማስተናገድ ነው፦
Plain Text
ተመሳሳዩን አቀራረብ ብንከተል፣ “what is character X’s attack range?” ብለን ብንጠይቅ እናስብ። አሁን የፈጠርናቸው ማጠቃለያዎችም በጣም ስለሚመሳሰሉ፣ በዕድል ላይ የተመሠረተ የግምት ጨዋታ እንጫወታለን። ታዲያ እንዴት ልንለያቸው እንችላለን?
ቀላሉ መልስ፦ ዐውድ ማቅረብ ነው። በውሂብ ክፍሉ ውስጥ ወደ ዋናው ሰነድ የሚጠቁም ማጣቀሻ ማካተት እንችላለን፤ በዚህ ሁኔታ ለምሳሌ {”character”: “X”}። በዚህም ስለ ገፀ ባህሪያት Y እና Z ተመሳሳይ ውሂብ ቢኖረንም፣ ለገፀ ባህሪ X ትክክለኛውን ውሂብ በትክክል ሰርስረን ማውጣት እንችላለን።
ነገር ግን የተሻለና በሰፊው ተግባራዊ የሚሆን አቀራረብ፣ ለክፍሉ ዐውዳዊ ማጠቃለያ መፍጠር ነው። ይህም ማለት የውሂብ ክፍሉን ብቻ ከማጠቃለል ይልቅ፣ ዋናውን ሰነድና ክፍሉን በአንድ ላይ በመላክ አጠቃላይ ዐውዳዊ ማጠቃለያ መፍጠር እንችላለን። በማጠቃለያውም ክፍሉ በዋናው ሰነድ ውስጥ እንዴት እንደሚገባ እናካትታለን፤ ለምሳሌ፦
ይህ ክፍል ለገፀ ባህሪ X የ… ዝርዝር ስታቲስቲክስ ያቀርባል። ክፍሉ፣ X በጥቃት ፍጥነት ያለውን ጥንካሬ በማሳየት ከሙሉው ሰነድ ጋር ይጣጣማል…
ይህ ክፍል ለገፀ ባህሪ Y የ… ዝርዝር ስታቲስቲክስ ያቀርባል። ክፍሉ፣ Y ልዩ ችሎታዋን ስትጠቀም የሚጨምሩትን ስታቲስቲክሶች በማሳየት ከሙሉው ሰነድ ጋር ይጣጣማል…
ይህ ክፍል ለገፀ ባህሪ Z የ… ዝርዝር ስታቲስቲክስ ያቀርባል። ክፍሉ፣ Z በቡድን ግጥሚያዎች ውስጥ እንደ ታንክ ሚና ለመጫወት የሚስማሙትን ስታቲስቲክሶች በማሳየት ከሙሉው ሰነድ ጋር ይጣጣማል…
ይህ ዘዴ (በከፊል በAnthropic የተነሳሳ) ከላይ ለታየው ምሳሌ ከመጠን ያለፈ ሊመስል ይችላል። ሆኖም “ከዐውድ ውጭ” በስህተት ሊተረጎሙ ለሚችሉ ክፍሎች እጅግ ውጤታማ ነው፤ ለሁሉም ክፍሎች የሚሠራ አንድ ወጥ አቀራረብም በማቅረብ የምሕንድስና ሂደቱን የተደራጀ ያደርገዋል።
~~ሁሉን መቆጣጠር የሚፈልጉ~~ ጥብቅ መሆን ሲያስፈልግዎ
በተለምዶ ውሂብን በሙሉ እንቀበልና ለRAG ሥርዓት ወደ ክፍሎች እከፋፍለዋለን። በዚህ ምሳሌ ግን ትንሽ የተለየ ነገር እናሳያለን፤ አስቀድሞ ወደ መጥፎ ክፍሎች የተከፋፈለ ውሂብ ነው። ክፍሎቹ በትክክል መልሰው መቧደን ካለባቸው አንድ ምክንያታዊ ክፍል የተወሰዱ የዘፈቀደ ክፍሎች ናቸው። ምክንያታዊ ክፍል ማለት በተፈጥሮ አብሮ መቀመጥ ያለበት የይዘት ክፍል ነው፤ ለምሳሌ የሰነድ ንዑስ ክፍል ወይም የተዋሃደ አንቀጽ።
በዚህ ውሂብ ያደረግነው የመጀመሪያ ሙከራ፣ ሁሉንም ነገር ወደ LLM ጥሪ ማስገባት፣ ተገቢ መስሎ በሚታየው መንገድ እንዲያቧድናቸው መጠየቅ እና ከዚያም የተቧደነውን ይዘት እንዲመልስ ማድረግ ነበር። LLM በዚህ በጣም ጥሩ መሆን አለበት፣ አይደል? መልካም፣ አዎም አይደለምም።
በሌሎች ብዙ አጋጣሚዎችም እንዳየነው፣ LLMዎች ሙሉና ትክክለኛ ይዘት ሲጠየቁ፣ በተለይ ዐውዱ ረጅም ሲሆን፣ በስንፍና የመሥራት ዝንባሌ ያሳያሉ እና አስተማማኝ አይደሉም። ይህም ፈጽሞ ምክንያታዊ ነው። ነገር ግን ለዚህ የተወሰነ የአጠቃቀም ሁኔታ ይህ በፍጹም ተቀባይነት የለውም፤ ይዘቱን ቃል በቃል በትክክል እንፈልጋለን—ማጠቃለያ አይደለም፣ ከዋናው ይዘትም አንድም ክፍል መዝለል የለበትም። ምንም ዝርዝር ሊያመልጠን አይችልም።
በእርግጥ “አዎ” የምንልበት ክፍል ደግሞ፣ የተሰባበሩትን ክፍሎች ትርጉምና አወቃቀር በመረዳት ጥሩ ሥራ መሥራቱ ነበር። ትክክለኛውን ይዘት መልሶ ለመጥቀስ እምቢ እስካላለ ድረስ። ወይ ጉድ:/
ታዲያ LLM በሚችለው ነገር እየተጠቀምን፣ አስተማማኝ ያልሆነበትን ክፍል እንዴት ማስወገድ እንችላለን? ወደ ድሮ ወዳጃችን ወደ ኮድ ተመለስን (ብጁ Python ፈንክሽን ማለት ነው)። እንዲሁም “ከዚህ በላይ ቀላል ሊሆን የማይችል” Pydantic ሞዴል። መፍትሔው ይህ ነው፦
አሁን ያለውን ምክንያታዊ ክፍል እያቆዩ በክፍሎቹ ውስጥ አንድ በአንድ ይለፉ
በእያንዳንዱ ክፍል LLMን ይጠይቁ፦ ይህ ክፍል አሁን ካለው ምክንያታዊ ክፍል ጋር ይዛመዳል? የPydantic ሞዴሉን በመከተል አዎ ወይም አይደለም ብሎ ይመልስ።
አዎ ከሆነ ክፍሉን ከምክንያታዊው ክፍል ጋር ያያይዙት፤ አይደለም ከሆነ፣ አሁን ያለው ምክንያታዊ ክፍል ስለተጠናቀቀ ያውጡትና በአዲሱ ክፍል ሌላ ይጀምሩ።
በእርግጥ ሙሉውን ይዘት በአንድ ጊዜ ከማስኬድ ይልቅ ትንሽ ተጨማሪ ቶከኖችን እንጠቀማለን። ሆኖም ትክክለኛውን ይዘት ማቆየት ቀዳሚ ጉዳይ ለሆነበት ለዚህ የተወሰነ አጠቃቀም፣ ትንሹ ተጨማሪ ወጪ ፈጽሞ የሚያዋጣ ነበር።
ይህ እጅግ ቀላል መፍትሔ ቢሆንም አንድ ጠቃሚ መርሕ ይከተላል፦ ጥብቅነት ሲያስፈልግ LLMዎች በመጨረሻ ዕድላዊ ስለሆኑ፣ በእነሱ ላይ ብቻ መተማመን አንፈልግም።
የLLMዎችን አቅም ሙሉ በሙሉ እየተጠቀምን፣ ሊተነበይና አስተማማኝ የሆነ ውጤት ለማግኘት ብጁ ኮድ/ፈንክሽኖችንና Pydantic ሞዴሎችን መጠቀም ይቻላል።
የማመንጨት AI መፍትሔ መገንባት የAI ፈተና ያህል የምሕንድስናም ፈተና ነው። እነዚህ ምሳሌዎች የራስዎን ልዩ ችግሮች ለመፍታት እንዳነሳሱዎት ተስፋ እናደርጋለን። ስለ ምሕንድስናን ቅድሚያ ስለሚሰጡ የማመንጨት AI መፍትሔዎች ተጨማሪ ለማንበብ፣ በራውተር ላይ ስለተመሠረተ የወኪል-ተኮር ሥርዓት ንድፍ የጻፍነውን የብሎግ ጽሑፍ ይመልከቱ።