Կարո՞ղ է Postgres-ը կառավարել ձեր RAG շղթան

• LLM-ները միաժամանակ կարող են «տեսնել» միայն սահմանափակ ծավալի տեքստ (համատեքստային պատուհան)։ Սա հարմար է փոքր առաջադրանքների համար, սակայն չի աշխատում, երբ գիտելիքների բազան հազարավոր էջեր է ընդգրկում։ Նույնիսկ երբ համատեքստային պատուհանը բավարար է, արդյունավետությունը կարող է նվազել «ասեղը խոտի դեզում» խնդրի պատճառով։

• RAG-ը («որոնմամբ ընդլայնված գեներացում») լայն տարածում ստացած մոտեցում է․ դուք պահպանում եք գիտելիքների բազա (փաստաթղթեր, վիքիներ, կանոնակարգեր, վերծանումներ և այլն), օգտատիրոջ հարցման հիման վրա իմաստային որոնում եք կատարում՝ վեկտորային ներկայացումների միջոցով գտնելով առավել համապատասխան հատվածները, ապա դրանք հարցի հետ փոխանցում LLM-ին։ Սա սահմանափակում է մոդելի համատեքստը և ճիշտ կիրառման դեպքում կարող է բարելավել պատասխանների որակն ու նվազեցնել հալյուցինացիաները։

• pgai-ն Postgres-ի բաց կոդով ընդլայնում է (և դրան ուղեկցող գործիքակազմ), որն օգնում է վստահելի բաց կոդով PostgreSQL տվյալների բազայի հիման վրա ստեղծել «AI որոնման» աշխատանքային հոսքեր։

• Հիմնական գաղափարը RAG-ի ստանդարտ շղթայի ավելի մեծ մասը տվյալների բազայի շերտ տեղափոխելն է (ներմուծում → հատվածավորում → վեկտորային ներկայացումների ստեղծում → դրանց համաժամացում), այլ ոչ թե ԲՏ-ն դիտարկել որպես վեկտորային ներկայացումների «պարզապես պահոց»։

• Նախնական տպավորությամբ այն խոստումնալից է, սակայն պիտանի չէ, երբ RAG շղթան թեկուզ փոքր-ինչ բարդանում է, հատկապես՝ հատվածավորման մոտեցումների առումով։ Այնուամենայնիվ, մենք ուշադիր հետևելու ենք այս նախագծին։

RAG ստեղծելու բազմաթիվ եղանակներ կան։ Տարբեր մոտեցումների ավելի մանրամասն վերլուծության համար կարդացեք «Անհատականացված RAG լուծումների գործնական օրինակներ» հոդվածը։ Երբ կարևոր է որակը, նախագծման տարբերակներն անսպասելիորեն շատանում են, իսկ տարածված «կանխադրված» մոտեցումն ընդհանուր առմամբ այսպիսին է։

1. Վերցրեք փաստաթղթերի մի հավաքածու։

2. Բաժանեք դրանք հատվածների։ Դա անելու բազմաթիվ եղանակներ կան (օրինակ՝ ըստ պարբերությունների կամ իմաստային խմբերի)։

3. Յուրաքանչյուր հատված վերածեք վեկտորային ներկայացման։

4. Վեկտորային ներկայացումները պահեք վեկտորային տվյալների բազայում (Pinecone, Milvus և այլն) կամ Postgres-ում՝ օգտագործելով pgvector-ը։

5. Հարցման պահին գտեք ամենամոտ հատվածները `և փոխանցեք դրանք LLM-ին (կրկին՝ սա ևս անելու բազմաթիվ եղանակներ կան)։

Բազմաթիվ տեխնոլոգիական փաթեթներում (1)–(3) քայլերը կատարվում են տվյալների բազայից դուրս՝ հավելվածի կոդում կամ տվյալների մշակման շղթայում, իսկ տվյալների բազան հիմնականում օգտագործվում է՝

• վեկտորային ներկայացումները պահելու համար

• վեկտորային ներկայացումներում որոնելու համար

pgai-ն Postgres-ի ընդլայնում է (բաց կոդով, մշակված Timescale-ի կողմից), որը փորձում է վերացնել այդ սահմանը։

Ձեր հավելվածի կողմից ձեռքով կառավարվող բաղադրիչ լինելու փոխարեն pgai-ն վեկտորային ներկայացումները դարձնում է տվյալների բազայի գործառույթ։

• Դուք սահմանում եք, թե որ աղյուսակը կամ փաստաթղթերն են պետք վերածել վեկտորային ներկայացումների։

• Նշում եք վեկտորային ներկայացումների մոդելն ու հատվածավորման ռազմավարությունը։

• Մնացածը կառավարում է pgai-ն, այդ թվում՝ սկզբնաղբյուրի տվյալների փոփոխվելուն զուգընթաց թարմացնում է վեկտորային ներկայացումները։

Խոստումը գրավիչ է։

• Ավելի քիչ հատուկ կապակցող կոդ, որը պետք է սպասարկել։

• Սկզբնաղբյուր փաստաթղթերի փոփոխվելուն զուգընթաց վեկտորային ներկայացումները «թարմ» պահելը պետք է ավելի հեշտ լինի։

• Postgres-ը/pgai-ն կառավարում է կրկնափորձերը, հաճախականության սահմանափակումները, ձախողված առաջադրանքները և այլն։

Նշում ընթերցողին․ pgai-ն իր կազմում ներառում է pgvector-ը (Postgres-ի մեկ այլ՝ շատ տարածված RAG ընդլայնում)։ pgvector-ը Postgres-ին ավելացնում է վեկտորների պահպանում և նմանության որոնում, իսկ pgai-ն դրա հիման վրա ավտոմատացնում է RAG շղթայի քայլերը՝ հատվածավորումը, վեկտորային ներկայացումների ստեղծումն ու դրանց թարմացումը։

1) Այն հեշտ է գործարկել։

Սովորական սցենարը բավական պարզ է։

• Ներբեռնեք Timescale-ի Docker պատկերները (տվյալների բազա + աշխատող գործընթաց)։

• Տրամադրեք վեկտորային ներկայացումների ծառայության API բանալին։

• Կատարեք փոքրածավալ SQL՝ վեկտորիզատորը սահմանելու համար (այսինքն՝ ինչը վերածել վեկտորային ներկայացման, ինչպես հատվածավորել և որ մոդելն օգտագործել)։

Դրանից հետո pgai-ն վեկտորիզատորի աշխատող գործընթացը գործարկում է առանձին և ասինխրոն ստեղծում վեկտորային ներկայացումներ (օրինակ՝ յուրաքանչյուր 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 մոդուլի միջոցով։ Պարզապես կազմաձևեք այսպես․

1OPENAI_API_KEY="your-OpenAPI-key-goes-here"2TARGET_DB="postgres://user:password@host:port/database"3CATALOG_DB="postgres://user:password@host:port/database"

և semantic catalog-ին հանձնարարեք ուսումնասիրել ձեր տվյալների բառարանները՝ օգտագործելով pgai semantic-catalog create։ Սա ձեր տվյալների պահոցից ստեղծում է մոտավորապես այսպիսի համատեքստ․

1---2schema: postgres_air3name: aircraft4type: table5description: Lists aircraft models with performance characteristics and unique codes.6columns:7- name: model8  description: Commercial name of the aircraft model.9- name: range10  description: Maximum flight range in kilometers.11- name: class12  description: Airframe class category or configuration indicator.13- name: velocity14  description: Cruising speed of the aircraft.15- name: code16  description: Three-character aircraft code serving as the primary key.17...

Այժմ այս համատեքստը pgai-ին հասանելի է տարբեր եղանակներով․

Իմաստային որոնման միջոցով․

Այս հարցումը կվերադարձնի աղյուսակները, գործառույթներն ու այլ օբյեկտները, որոնք կարող են առնչվել բնական լեզվով ձեր հարցմանը․

1pgai semantic-catalog search -p "Your natural language question goes here!"

Ստանալ չմշակված համատեքստը․

Սա կարտածի բնական լեզվով ձեր հարցմանն առնչվող չմշակված YAML համատեքստը․

1pgai semantic-catalog search -p "Your natural language question goes here!" --render

Գեներացնել SQL․

Կամ կարող եք անմիջապես գեներացնել ձեր հարցմանը պատասխանելու համար անհրաժեշտ չմշակված SQL-ը։ Նախորդ քայլի համատեքստն ուղարկվում է LLM-ին, և գեներացվում է պատասխան․

1pgai semantic-catalog generate-sql -p "Your natural language question goes here!"

Եթե համեմատաբար պարզ RAG համակարգ եք ստեղծում, արժե փորձել pgai-ն, եթե ցանկանում եք՝

• Postgres-ը՝ որպես տվյալների հիմնական համակարգ,

• նվազագույն կապակցող կոդ,

• ավտոմատ համաժամացվող վեկտորային ներկայացումներ,

• տվյալների բազաներում տեքստից SQL լուծում արագ կիրառելու եղանակ,

• փորձարկել RAG-ի նոր գործիքներն ու Postgres-ի ընդլայնումները։

Թերևս արժե առայժմ չօգտագործել pgai-ն, եթե ձեր RAG շղթային անհրաժեշտ է հետևյալից որևէ մեկը՝

• մեծածավալ հատուկ ներմուծման կամ հատվածավորման տրամաբանություն

• փաստաթղթերի բազմաթիվ տեսակներ՝ մշակման տարբեր պահանջներով

• բազմամոդալ վեկտորային ներկայացումներ

Վերջապես, թեև ակնհայտ է, որ pgvector-ը լայն տարածում է գտել, պարզ չէ՝ արդյոք pgai-ն նույնքան հետաքրքրություն և, հետևաբար, աջակցություն կստանա (հաշվի առնելով նաև, որ այն գոյություն ունի ընդամենը մոտ 18 ամիս)։

pgai-ն RAG-ի նկատմամբ հետաքրքիր մոտեցում է, որը տվյալների բազաներին է հանձնում ավելի շատ ընթացիկ աշխատանք՝ պարզեցնելով հավելվածի կոդը։

Այս պահին այն՝

• պիտանի և իսկապես հարմար է RAG-ի պարզ կազմաձևերի համար

• բավականաչափ ճկուն չէ ավելի անհատականացված շղթաների համար (հատկապես՝ բազմամոդալ)

Այն խոստումնալից է, և միանշանակ արժե հետևել հետագա զարգացմանը։