Тусгайлан тохируулсан RAG шийдлийн бодит жишээнүүд

Бодит жишээнүүд байгууллагын мэдлэгийн нарийн төвөгтэй асуудлыг зориулалтын RAG системээр хэрхэн шийдэж болохыг харуулна.

Сүүлийн үед RAG-ийг заримдаа муулах болсон. Учир нь хүмүүс үүнийг одоо маш энгийн гэж боддог (эхлүүлэхэд тийм ч, өргөжүүлэхэд тийм биш), эсвэл «агентлаг системүүд» халсан гэж үздэг (гэвч өнгөн доогуур нь жаахан ухвал ихэнх нь тун удалгүй RAG-тэй маш төстэй харагдана...)

Энэ нийтлэлд бид түгээмэл тулгардаг дараах асуудлуудыг хэрхэн шийддэгээ нэг, хоёр бодит жишээгээр тайлбарлана:

  • Текст ба тоон өгөгдлийг хослуулан боловсруулах нь яагаад энгийн RAG-ийг доголдуулдаг вэ: түлхүүр үгс давхцаж, тоонууд дангаараа утгын холбоо илэрхийлдэггүй.

  • Эхлээд хураангуйлж, дараа нь эмбеддинг үүсгэх нь яагаад тустай вэ: хэсэг бүрд богино тайлбар хураангуй үүсгээд, түүнд тулгуурлан эмбеддинг болон хайлт хийнэ.

  • Контексттэй хураангуй хэрхэн үүсгэх вэ: ижил бүтэцтэй статистикуудыг ялгахын тулд эх баримт бичгийн контекстийг оруулна.

  • Код болон Pydantic загварт хэзээ найдах вэ: агуулгыг үгчлэн хадгалах шаардлагатай үед найдвартай байдлыг хангахын тулд тусгай код болон/эсвэл Pydantic загварыг Том хэлний загварын (LLM) дуудлагатай хослуулна.

Тусгай RAG шийдэл бүтээх нь

Үндсэн ойлголт

RAG системүүд хэрэглэгчийн тусламжийн ботоос эхлээд байгууллагын дотоод мэдлэгийн туслах хүртэл олон зүйлийг ажиллуулдаг.

Үүний цаана ихэвчлэн дараах алхмууд хийгддэг:

  1. Эх баримт бичгүүдээ хэсэгчлэх

  2. Хэсэг бүрийг вектор орон зайд эмбед хийх

  3. Асуулга ирэхэд хамгийн тохирох K хэсгийг татаж авах

  4. Тэдгээр хэсэгт үндэслэн хариулт үүсгэх

LangChain, LlamaIndex, OpenAI-ийн Filestore зэрэг түгээмэл хэрэгслүүд эдгээр алхмыг бараг л хялбарчилчихсан. Гэвч бодит хэрэглээний дамжлагад дан нягт текстээс өөр өгөгдөл таарах бөгөөд суурь RAG үүн дээр бэрхшээлтэй тулгардаг. Дараах хэсгүүдэд өгөгдлийн бэрхшээлүүдийг бодит жишээгээр үзүүлж, нарийн төвөг нэмэгдэхийн хэрээр шийдлийг шат дараатай байгуулна.

Асуудал илүү төвөгтэй болох үед

  1. Өгөгдөл тань зөвхөн текст биш үед (үнэндээ түгээмэл тохиолддог)

Тоглоомын орчин дахь дараах өгөгдлийн хэсгийг авч үзье:

JSON

{ "Attack": { "Range": { "default": 5, "with_Draconic_Ascension": 5.5, }, "Speed": { "default": "2 seconds", "with_Draconic_Ascension": "2.2 seconds", }, "Damage": { "default": 10, "with_Draconic_Ascension": 12, } }} 

Эмбеддинг нь үгсийн утга, хэлзүйгээр дамжин сурсан харилцан холбоонд тулгуурлан ажилладаг. Дээрх өгөгдөлд текст, тоо холилдсон бөгөөд яг энэ контекстээс нь салгавал тоонууд үгстэй ямар ч холбоогүй. Тиймээс энэ өгөгдлийн хэсэг нь тодорхой хэмжээнд тайлбарласан үгсийн араас санамсаргүй тоонууд залгасан зүйл гэж хэлж болно.

Хэрэв бидэнд зөвхөн ийм төрлийн өгөгдөл байсан бол энэ нь асуудал биш. Учир нь цөөн хэдэн тайлбар үгийн эмбеддингт тулгуурлан холбогдох хэсгийг татаж авч болно (эсвэл text-to-sql ашиглаж болно). Харин энэ хэсэг ижил үгс орсон, текстээр нягт олон хэсгийн дунд дарагдсан байвал яах вэ? Жишээлбэл:

JSON

{"Draconic_Ascension": { "description": "Transform into dragon form. Attack range and speed are increased by 10%, damage is boosted by 20%.", "details": { "activation_conditions": "Can only be activated when HP is below 50%or Fury meter is full.", "visual_effects": "Wings unfurl, scales shimmer with embers, voice lines change to echoing growls.", "lore": "An ancient bloodline awakens. The bearer of the mark channels the soul of the last Flamewing Wyrm, becoming a living storm of fire and fury." } }}

Одоо бид “What is the attack range with Draconic Ascension?” гэсэн асуултад холбогдох хэсгийг татахыг хүссэн гэж төсөөлье. Ижил түлхүүр үгтэй бусад хэсгийн шуугианд дарагдсан тул хүссэн хэсгээ олох магадлал тун бага.

Нэг сэдвийн тухай өөр төрлийн мэдээлэл агуулж байгаа ч эдгээр өгөгдлийн хэсгийг сайн ялгаж чадахгүй байгаа нь үндсэн асуудал юм. Үүнийг ямар нэг аргаар баяжуулж, сайжруулж болох уу? Мэдээж болно:smile:

  1. Өгөгдлөө хураангуйлж баяжуул. Тийм ээ, та зөв уншлаа

Хэсгийг шууд эмбед хийхийн оронд эхлээд өгөгдөл юуны тухайг тайлбарласан хураангуй үүсгээд, түүнд тулгуурлан эмбеддинг болон хайлт хийж болно. Хариулт үүсгэх шатанд хураангуйтай холбоотой эх өгөгдлийг ашигласан хэвээр байна.

Тэгвэл дээрх хоёр хэсэгт дараах маягийн хураангуй үүсгэнэ:

  1. Довтолгооны зай, хурд, хохирлын статистик (үндсэн төлөв болон Draconic Ascension-тай үеийн).

  2. Идэвхжих нөхцөл, дүрслэлийн эффект, түүхэн тайлбарыг багтаасан Draconic Ascension-ы тодорхойлолт ба дэлгэрэнгүй мэдээлэл.

Дараа нь асуулгыг хураангуйтай «нийцүүлэхийн» тулд мөн баяжуулна. Жишээлбэл, “What is the attack range with Draconic Ascension?” гэдгийг “What is the statistics of attack range with Draconic Ascension?” болгон өөрчилнө. Техникийн бус хэрэглэгчид ~~«чөлөөт хэлбэрээр»~~ хүний ердийн хэлээр асуудаг үед энэ нь онцгой чухал. Эцсийн эцэст нарийвчлал, бүрэн хамралтыг дээд хэмжээнд хүргэхийн тулд RAG хэрхэн ажилладгийг мэдэх нь тэдний үүрэг ч биш, санаа тавих зүйл ч биш.

Асуудал илүү төвөгтэй болох үеийг харуулсан диаграмм.

  1. Аливааг контекстээс нь бүү салга (амьдралд ч ерөнхийдөө хамаатай)

Дараагийн нөхцөл бол доорх шиг ижил харагддаг асар олон өгөгдлийн хэсгийг боловсруулах явдал юм:

Plain Text

# Chunk one{ "Attack": { "Range": { "default": 9, }, ... }}# Chunk two{ "Attack": { "Range": { "default": 6, }, ... }}# Chunk three{ "Attack": { "Range": { "default": 7, }, ... }}

Өмнөх аргаа хэвээр хэрэглээд “what is character X’s attack range?” гэж асуулаа гэж төсөөлье. Бидний сая үүсгэсэн хураангуйнууд хоорондоо тун төстэй харагдах тул азад найдсан тааврын тоглоом болно. Тэгвэл тэдгээрийг хэрхэн ялгах вэ?

Энгийн хариулт нь контекст өгөх. Өгөгдлийн хэсэгт эх баримт бичгийнх нь лавлагааг шууд оруулж болно. Энэ тохиолдолд, жишээлбэл, {”character”: “X”}. Ингэснээр Y, Z дүрийн ижил өгөгдөл байсан ч X дүрийн зөв өгөгдлийг нарийн татаж авч чадна.

Гэхдээ илүү сайн, өргөн хүрээнд хэрэглэх боломжтой арга нь тухайн хэсгийн контексттэй хураангуй үүсгэх юм. Өөрөөр хэлбэл, зөвхөн өгөгдлийн хэсгийг хураангуйлахын оронд эх баримт бичиг болон тухайн хэсгийг хоёуланг нь оруулж, контексттэй ерөнхий хураангуй үүсгэнэ. Ингэхдээ тухайн хэсэг эх баримт бичигтээ ямар байр суурьтайг хураангуйд оруулна. Жишээлбэл:

  1. Энэ хэсэгт X дүрийн ...-ийн нарийвчилсан статистикийг өгсөн. Энэ хэсэг нь X-ийн довтолгооны хурдны давуу талыг харуулснаар бүрэн баримт бичигтэй холбогдоно...

  2. Энэ хэсэгт Y дүрийн ...-ийн нарийвчилсан статистикийг өгсөн. Энэ хэсэг нь Y тусгай чадвараа ашиглахад статистик нь хэрхэн өсдөгийг харуулснаар бүрэн баримт бичигтэй холбогдоно...

  3. Энэ хэсэгт Z дүрийн ...-ийн нарийвчилсан статистикийг өгсөн. Энэ хэсэг нь Z-ийн статистик багийн тоглолтод танк үүрэг гүйцэтгэхэд тохиромжтойг харуулснаар бүрэн баримт бичигтэй холбогдоно...

Энэ арга (Anthropic-оос хэсэгчлэн санаа авсан) нь дээрх жишээнд хэтрүүлэг мэт санагдаж болох ч «контекстээс нь салгавал» буруу ойлгогдох хэсгүүдэд маш үр дүнтэй. Мөн бүх хэсэгт тохирох нэгдсэн арга бий болгож, инженерчлэлийн дамжлагыг цэгцтэй байлгана.

Асуудал илүү төвөгтэй болох үеийг харуулсан диаграмм.

  1. ~~Бүхнийг хянахыг хүсэх~~ нягт нямбай байх шаардлагатай үед

Ерөнхийдөө өгөгдлийг бүтнээр нь аваад RAG системд зориулан хэсэгчлэн хуваадаг. Энэ жишээнд арай өөр зүйл буюу муу хэсгүүдэд хуваагдсан өгөгдлийг авч үзнэ. Эдгээр нь логик нэг хэсгийн санамсаргүй тасархайнууд тул буцаан нэгтгэх шаардлагатай. Логик хэсэг гэдэг нь баримт бичгийн дэд хэсэг эсвэл утга санаа нь уялдсан догол мөр зэрэг жам ёсоороо хамт байх ёстой агуулгыг хэлнэ.

Асуудал илүү төвөгтэй болох үеийг харуулсан диаграмм.

Эхний оролдлогоороо бүх өгөгдлийг Том хэлний загварын (LLM) дуудлагад оруулж, тохиромжтой гэж үзсэнээрээ бүлэглээд, нэгтгэсэн агуулгыг буцаахыг хүссэн. Том хэлний загвар (LLM) үүнийг сайн хийх ёстой биз дээ? Тийм ч, үгүй ч.

Бусад хэд хэдэн тохиолдлоос ч бид Том хэлний загвар (LLM) залхуурах хандлагатай бөгөөд бүрэн, яг таг агуулга шаардахад, ялангуяа контекст урт бол найдвартай бус байдгийг олж мэдсэн. Энэ нь ч ойлгомжтой. Гэвч энэ хэрэглээнд энэ нь хүлээн зөвшөөрөх аргагүй байв. Учир нь бидэнд агуулгыг үг бүрээр нь яг хэвээр хадгалах шаардлагатай байсан—хураангуйлахгүй, эх агуулгын аль ч хэсгийг алгасахгүй. Нэг ч дэлгэрэнгүй мэдээллийг орхиж болохгүй.

Харин «тийм» гэсний учир нь эвдэрхий хэсгүүдийн утга, бүтцийг маш сайн ойлгосон явдал байлаа. Гагцхүү яг агуулгыг нь буцаан эшлэхээс татгалзахгүй бол шүү дээ. Өө, яана аа:/

Тэгвэл Том хэлний загварын (LLM) сайн чадварыг ашиглахын зэрэгцээ найдваргүй талыг нь хэрхэн тойрох вэ? Бид хуучны сайн найз болох коддоо хандлаа (үүнийг тусгайлан бичсэн Python функц гэж ойлгоорой). Мөн «үүнээс энгийн байх аргагүй» Pydantic загвар ашиглав. Шийдэл нь энэ:

  • Одоогийн логик хэсгийг хадгалангаа дэд хэсгүүдээр дараалан давтах

  • Дэд хэсэг бүр дээр Том хэлний загвараас (LLM) «Энэ дэд хэсэг одоогийн логик хэсэгт хамаарах уу?» гэж асуугаад, Pydantic загварын дагуу тийм эсвэл үгүй гэж хариулахыг шаардана.

  • Тийм бол дэд хэсгийг логик хэсэгт нэмнэ. Үгүй бол одоогийн логик хэсэг бүрдэж дууссан тул түүнийг гаргаад, тухайн дэд хэсгээр шинийг эхлүүлнэ.

Асуудал илүү төвөгтэй болох үеийг харуулсан диаграмм.

Мэдээж бүх агуулгыг нэг удаа боловсруулахтай харьцуулахад арай олон токен ашиглана. Гэхдээ яг агуулгыг бүрэн хадгалах нь нэн тэргүүний шаардлага байсан энэ хэрэглээнд багахан нэмэлт зардал нь бүрэн үнэ цэнтэй байв.

Энэ бол маш энгийн шийдэл боловч нэг чухал зарчим баримталдаг: нягт нямбай байдал шаардлагатай үед магадлалд тулгуурладаг Том хэлний загварт (LLM) дангаар нь найдах хэрэггүй.

Тусгай код, функц болон Pydantic загвар ашигласнаар Том хэлний загварын (LLM) чадварыг бүрэн ашиглахын зэрэгцээ үр дүнг урьдчилан таамаглахуйц, найдвартай болгож болно.

Дүгнэлт

Үүсгүүрт хиймэл оюуны шийдэл бүтээх нь хиймэл оюуны төдийгүй инженерчлэлийн сорилт юм. Эдгээр жишээ таны онцлог бэрхшээлийг шийдэх урам өгсөн гэж найдаж байна. Инженерчлэлийг нэн тэргүүнд тавьсан үүсгүүрт хиймэл оюуны шийдлийн талаар дэлгэрүүлэн унших бол чиглүүлэгчид суурилсан агентлаг системийн дизайны тухай нийтлэлийг үзнэ үү.

Зохиогч

Cynthia Yu