Том хэлний загварууд (LLM) нэг дор хязгаарлагдмал хэмжээний текстийг л «харж» чадна. Үүнийг контекстийн цонх гэдэг. Энэ нь жижиг даалгаварт тохиромжтой ч мэдлэгийн сан хэдэн мянган хуудас хамарвал үр дүнгүй болдог. Контекстийн цонх хангалттай байсан ч «өвсөн дундаас зүү хайх» асуудлаас болж гүйцэтгэл муудаж болно.
RAG («хайлтаар баяжуулсан үүсгэл») нь түгээмэл болсон арга юм. Та мэдлэгийн сангаа (баримт бичиг, вики, бодлого, ярианы хуулбар гэх мэт) хадгалж, хэрэглэгчийн асуултаар семантик хайлт хийн эмбеддинг ашиглан хамгийн хамааралтай хэсгүүдийг олж, дараа нь тэдгээрийг асуултын хамт Том хэлний загварт (LLM) өгнө. Ингэснээр загварын контекстийг хязгаарлах бөгөөд зөв хэрэгжүүлбэл хариултын чанарыг сайжруулж, хийсвэр зохиомжийг багасгана.
pgai нь итгэл даасан нээлттэй эхийн PostgreSQL өгөгдлийн сан дээр «AI хайлт»-ын ажлын урсгал бүтээхэд туслах Postgres-ийн нээлттэй эхийн өргөтгөл болон дагалдах хэрэгслүүд юм.
Гол санаа нь өгөгдлийн санг эмбеддингийн «зүгээр л хадгалах сан» гэж үзэхийн оронд стандарт RAG дамжлагын илүү олон алхмыг өгөгдлийн сангийн түвшинд оруулах явдал юм (оруулах → хэсэглэх → эмбеддинг үүсгэх → эмбеддингүүдийг синк байлгах).
Анхны сэтгэгдлээр бол ирээдүйтэй ч RAG дамжлага тань бага зэрэг л төвөгтэй болоход, ялангуяа хэсэглэх арга нь нарийсахад тохиромжгүй. Гэсэн ч бид энэ төслийг анхааралтай ажиглана.
RAG бүтээх олон арга бий. Тэдгээрийн дэлгэрэнгүй харьцуулалтыг Тусгайлан тохируулсан RAG шийдлүүдийн практик жишээ нийтлэлээс уншина уу. Чанарыг чухалчилж эхлэхэд шийдлийн хувилбарууд санаанд оромгүй нарийн болдог. Түгээмэл «анхдагч» арга нь ерөнхийдөө ийм байна:
Бөөн баримт бичиг авна.
Тэдгээрийг хэсгүүдэд хуваана. Үүнийг хийх олон арга бий (жишээ нь догол мөрөөр эсвэл утгын бүлгээр).
Хэсэг бүрээс эмбеддинг үүсгэнэ.
Эмбеддингүүдийг вектор өгөгдлийн санд (Pinecone, Milvus гэх мэт) эсвэл pgvector ашиглан Postgres-д хадгална.
Асуулга ирэхэд хамгийн ойр хэсгүүдийг хайж, `тэдгээрийг Том хэлний загварт (LLM) өгнө (үүнийг ч мөн олон аргаар хийж болно).
Олон технологийн багцад (1)–(3) алхмыг өгөгдлийн сангаас гадуур, аппын код эсвэл өгөгдөл боловсруулах дамжлагад гүйцэтгэдэг. Харин өгөгдлийн санг голдуу дараахад ашиглана:
эмбеддинг хадгалах
эмбеддинг хайх
pgai нь энэ заагийг бүдгэрүүлэхийг зорьдог Postgres-ийн өргөтгөл юм (нээлттэй эхтэй, Timescale хөгжүүлсэн).
Апп эмбеддингүүдийг гараар удирдахын оронд pgai тэдгээрийг өгөгдлийн сангийн боломж болгодог:
Ямар хүснэгт, баримт бичгээс эмбеддинг үүсгэхээ тодорхойлно.
Эмбеддингийн загвар болон хэсэглэх стратегийг заана.
Эх өгөгдөл өөрчлөгдөхөд эмбеддингүүдийг шинэчилж синк байлгах зэрэг бусад ажлыг pgai хариуцна.
Амласан боломжууд нь сонирхол татна:
Арчлах шаардлагатай тусгай холбох код багасна.
Эх баримт бичиг өөрчлөгдөхөд эмбеддингүүдийг «шинэ» хэвээр байлгахад хялбар болно.
Дахин оролдох, хурдны хязгаар, бүтэлгүйтсэн ажлууд зэргийг Postgres/pgai удирдана.
Уншигчид өгөх тайлбар: pgai нь RAG-д зориулсан өөр нэг түгээмэл Postgres өргөтгөл болох pgvector-ийг багтаадаг. pgvector нь Postgres-д вектор хадгалалт болон төстэй байдлын хайлт нэмдэг. Харин pgai үүн дээр тулгуурлан хэсэглэх, эмбеддинг үүсгэх, тэдгээрийг шинэчилж байх зэрэг RAG дамжлагын алхмыг автоматжуулдаг.
1) Ажиллуулж эхлэхэд хялбар.
Үндсэн хувилбараар ажиллуулах нь нэлээд энгийн:
Timescale-ийн Docker image-үүдийг (өгөгдлийн сан + worker) татна.
Эмбеддинг үйлчилгээ үзүүлэгчийнхээ API түлхүүрийг өгнө.
Векторжуулагчийг зарлах цөөн хэдэн SQL ажиллуулна (юунаас эмбеддинг үүсгэх, хэрхэн хэсэглэх, аль загварыг ашиглахыг заана).
Үүний дараа pgai векторжуулагч worker-ийг тусдаа процессоор ажиллуулж, эмбеддингүүдийг асинхроноор үүсгэнэ (жишээ нь 5 минут тутамд эсвэл таны хүссэн давтамжаар).
2) Бүх дамжлагыг өгөгдлийн сангийн «ойролцоо» ажиллуулах нь тохиромжтой.
pgai хүснэгтээс контент оруулж болохын зэрэгцээ S3 зэрэг эх үүсвэрээс баримт бичиг ачаалан, задлан боловсруулж, хэсэглээд эмбеддинг үүсгэж чадна. Мөн PDF, Markdown зэрэг төрөл бүрийн текст баримт бичгийн форматтай ажиллана.
1) Хяналтын ихэнхийг алддаг (харин RAG-д заримдаа нарийн хяналт хэрэгтэй).
Хариултын чанараар хэмжихэд өндөр гүйцэтгэлтэй RAG системүүдэд дараах мэт тусгай дамжлага ихэвчлэн шаардлагатай:
хэсэглэх тусгай дүрэм (гарчиг, хуудас, яригчийн ээлж гэх мэтээр)
мета өгөгдлийг харгалзсан хэсэглэлт (бүлгийн гарчиг, цагийн тэмдэг, зохиогч, баримт бичгийн төрлийг хадгалах)
баримт бичгийн төрөл бүрд өөр эмбеддингийн стратеги
Дээрх зүйлсийн хувьд pgai уян хатан чанар багатай.
Одоогоор тэмдэгтээр текст хуваах, тэмдэгтээр рекурсив хуваах гэсэн хоёр үндсэн стратеги болон огт хэсэглэхгүй байх сонголт бий. Энэ нь зарим хэрэглээнд хангалттай байж болох ч үйлдвэрлэлийн олон RAG системд илүү нарийн тохируулга шаардлагатай.
Timescale нь Chonkie зэрэг сангуудад байдаг илүү боловсронгуй хэсэглэх стратегиудыг нэвтрүүлж, Anthropic-ийн контекстэд суурилсан хайлт зэрэг дэвшилтэт загварыг дэмжвэл гайхалтай байх болно.
2) Олон төрлийн өгөгдөлд бус, текстэд төвлөрсөн.
RAG-ийн олон сонирхолтой асуудал дан ганц текстээр хязгаарлагдахаа больсон:
диаграмтай PDF файлууд
дэлгэцийн зураг / зургууд
аудио бичлэгүүд
видео клипүүд
Эдгээр эх үүсвэрээс «текст гаргаж авах» боломжтой байсан ч энэ нь жинхэнэ олон төрлийн өгөгдлийн эмбеддинг дамжлагатай адил биш.
Хэрэв pgai эцэст нь олон төрлийн өгөгдлийн загваруудыг эхнээс нь дуустал дэмждэг болбол (S3-д хадгалсан том зураг, аудио, видеог найдвартай синк хийж, ачаалах → хэсэглэх → эмбеддинг үүсгэх) маш сонирхол татна. Харин өнөөдөр энэ нь текстийн эмбеддинг үүсгэх ажлын урсгал хэвээр байна.
3) Зөвхөн эмбеддинг хэрэгтэй бол pgai шаардлагагүй байж мэднэ.
Хэрэв өгөгдөл оруулах дамжлага тань аль хэдийн тусгай болсон эсвэл тийм байх шаардлагатай бол «текстийн хэсгүүдээс эмбеддинг үүсгэх» нь RAG-ийн хамгийн хэцүү хэсэг биш. Ийм нөхцөлд pgai асуудлын хамгийн хялбар хэсгийг л шийдэж байна.
Мөн мэдлэгийн сан тань ховор шинэчлэгддэг бол эмбеддингүүдийг автоматаар синк байлгахын ач холбогдол төдийлөн их биш.
pgai-г ашиглах онцгой сайн аргуудын нэг нь өгөгдлийн сангууд дээрээ текстээс SQL үүсгэх интерфэйс нэвтрүүлэх явдал юм. Үүнийг pgai-ийн semantic_catalog модулиар нэлээд хялбар хэрэгжүүлж болно. Ердөө ингэж тохируулна:
Bash
Дараа нь pgai semantic-catalog create командаар semantic catalog-оор өгөгдлийн толиудаа уншуулна. Ингэснээр таны өгөгдлийн сангаас ойролцоогоор дараах хэлбэрийн контекст үүснэ:
Plain Text
Энэ контекстийг pgai одоо хэд хэдэн аргаар ашиглах боломжтой;
Семантик хайлтаар:
Энэ асуулга нь таны энгийн хэлээр бичсэн асуулгатай холбоотой байж болох хүснэгт, функц болон бусад объектыг буцаана:
Bash
Боловсруулаагүй контекст авах:
Энэ нь таны энгийн хэлээр бичсэн асуулгатай холбоотой боловсруулаагүй YAML контекстийг харуулна:
Bash
SQL үүсгэх:
Эсвэл асуулгад тань хариулахад шаардлагатай боловсруулаагүй SQL-ийг шууд үүсгэж болно. Өмнөх алхмын контекстийг Том хэлний загварт (LLM) илгээж, хариулт үүсгэнэ:
Bash
Харьцангуй энгийн RAG систем бүтээж байгаа бол дараах зүйлс хэрэгтэй үед pgai-г туршаад үзэхэд илүүдэхгүй:
Postgres-ийг үндсэн бүртгэлийн систем болгох,
холбох кодыг хамгийн бага байлгах,
эмбеддингүүдийг автоматаар синк байлгах,
өгөгдлийн сандаа текстээс SQL үүсгэх аргыг хурдан нэвтрүүлэх,
RAG-ийн шинэ хэрэгслүүд болон Postgres өргөтгөлүүдийг туршиж үзэх.
Таны RAG дамжлагад дараах зүйлсийн аль нэг хэрэгтэй бол pgai-г ашиглахаа түр азнасан нь дээр:
оруулах эсвэл хэсэглэх нарийн тусгай логик
задлан боловсруулах шаардлага нь өөр олон төрлийн баримт бичиг
олон төрлийн өгөгдлийн эмбеддинг
Эцэст нь, pgvector өргөн нэвтэрсэн нь тодорхой боловч pgai ижил хэмжээнд сонирхол татаж, дэмжлэг авах эсэх нь тодорхойгүй хэвээр байна. Гэхдээ pgai гараад ердөө 18 орчим сар болж буйг анхаарах хэрэгтэй.
pgai нь өдөр тутмын үйл ажиллагааны ажлыг өгөгдлийн санд илүү ихээр хариуцуулж, аппын кодыг хялбарчлах сонирхолтой RAG арга юм.
Одоогоор энэ нь:
энгийн RAG тохиргоонд ашиглахад боломжийн, үнэхээр эвтэйхэн
илүү тусгай дамжлагад, ялангуяа олон төрлийн өгөгдөлтэй ажиллахад хангалттай уян хатан биш
Ирээдүйтэй харагдаж байгаа тул хэрхэн хөгжихийг нь ажиглах нь гарцаагүй зүйтэй.