LLMలు ఒకేసారి పరిమిత పరిమాణంలోని పాఠ్యాన్ని మాత్రమే “చూడగలవు”. దీన్నే కాంటెక్స్ట్ విండో అంటారు. ఇది చిన్న పనులకు సరిపోతుంది. కానీ జ్ఞానభాండారం వేల పేజీలకు విస్తరించినప్పుడు విఫలమవుతుంది. కాంటెక్స్ట్ విండో సరిపడినప్పటికీ, “గడ్డివాములో సూది” సమస్య వల్ల పనితీరు తగ్గవచ్చు.
RAG అంటే ‘రిట్రీవల్ ఆగ్మెంటెడ్ జనరేషన్’. ఇందులో పత్రాలు, వికీలు, విధానాలు, లిప్యంతరీకరణలు మొదలైన వాటితో జ్ఞానభాండారాన్ని నిర్వహిస్తారు. వినియోగదారు ప్రశ్నపై అర్థాధారిత శోధన చేసి, ఎంబెడ్డింగ్ల ద్వారా అత్యంత సంబంధిత పాఠ్య భాగాలను పొందుతారు. తర్వాత ప్రశ్నతో పాటు ఆ భాగాలను LLMకు అందిస్తారు. ఇది చాలా సాధారణమైన విధానంగా మారింది. ఇది మోడల్కు అందే సందర్భాన్ని పరిమితం చేస్తుంది. సరిగ్గా అమలు చేస్తే సమాధానాల నాణ్యతను మెరుగుపరచడంతో పాటు కల్పిత సమాచారాన్ని తగ్గించవచ్చు.
pgai అనేది నమ్మకమైన ఓపెన్ సోర్స్ డేటాబేస్ PostgreSQLపై “AI సమాచార వెలికితీత” కార్యప్రవాహాలను రూపొందించడంలో సహాయపడే ఓపెన్ సోర్స్ 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 డాకర్ ఇమేజ్లను, అంటే డేటాబేస్, వర్కర్లను పొందండి.
మీ ఎంబెడ్డింగ్ ప్రదాత API కీని అందించండి.
వెక్టరైజర్ను ప్రకటించడానికి కొద్దిపాటి SQLను అమలు చేయండి. అంటే దేన్ని ఎంబెడ్ చేయాలి, ఎలా భాగాలుగా విభజించాలి, ఏ మోడల్ను ఉపయోగించాలో పేర్కొనండి.
ఆ తర్వాత వెెక్టరైజర్ వర్కర్ను ప్రత్యేక ప్రక్రియగా నడిపించి, ఎంబెడ్డింగ్లను అసమకాలికంగా రూపొందించేలా pgai ఏర్పాటు చేస్తుంది. ఉదాహరణకు ప్రతి 5 నిమిషాలకు లేదా మీకు కావాల్సిన విరామంలో దీన్ని నడపవచ్చు.
2) మొత్తం ప్రక్రియను డేటాబేస్కు “సమీపంలో” నిర్వహించడం బాగుంది.
pgai పట్టికల నుంచి విషయాన్ని స్వీకరించగలదు. S3 వంటి చోట్ల నుంచి పత్రాలను లోడ్ చేసి, వాటిని విశ్లేషించి, భాగాలుగా విభజించి, ఎంబెడ్ చేయగలదు. ఇది PDF, Markdown మొదలైన విభిన్న పాఠ్య పత్ర ఆకృతులను కూడా నిర్వహించగలదు.
1) మీరు చాలా నియంత్రణను కోల్పోతారు. RAGకు కొన్నిసార్లు ఆ నియంత్రణ అవసరం.
సమాధానాల నాణ్యత ఆధారంగా కొలిచినప్పుడు, అధిక పనితీరు గల RAG వ్యవస్థలకు తరచూ కింది విధమైన ప్రత్యేక ప్రక్రియలు అవసరమవుతాయి:
శీర్షికలు, పేజీలు, వక్త మార్పులు మొదలైన వాటి ఆధారంగా అనుకూల భాగ విభజన నియమాలు
మెటాడేటాను పరిగణించే భాగ విభజన. విభాగ శీర్షికలు, సమయముద్రలు, రచయితలు, పత్ర రకాన్ని ఉంచడం
ఒక్కో పత్ర రకానికి వేర్వేరు ఎంబెడ్డింగ్ వ్యూహాలు
పై అంశాల్లో pgai తక్కువ సౌలభ్యాన్ని అందిస్తుంది.
ప్రస్తుతం రెండు ప్రధాన భాగ విభజన వ్యూహాలున్నాయి: అక్షర పాఠ్య విభాజకం, పునరావృత అక్షర పాఠ్య విభాజకం. వీటితో పాటు భాగాలుగా విభజించని ఎంపిక కూడా ఉంది. కొన్ని వినియోగ సందర్భాలకు అది సరిపోవచ్చు. కానీ ఉత్పత్తి స్థాయి RAG వ్యవస్థల్లో చాలా వాటికి మరింత అనుకూలీకరణ అవసరం.
Chonkie వంటి గ్రంథాలయాల్లో కనిపించే అధునాతన భాగ విభజన వ్యూహాల్లో కొన్నింటిని Timescale చేర్చి, Anthropic సందర్భోచిత సమాచార వెలికితీత వంటి అధునాతన రూపకల్పనలకు కూడా మద్దతిస్తే అద్భుతంగా ఉంటుంది.
2) ఇది బహుమాధ్యమం కాదు, ప్రధానంగా పాఠ్యానికే ఉద్దేశించింది.
అనేక ఆసక్తికరమైన RAG సమస్యలు ఇప్పుడు కేవలం పాఠ్యానికి మాత్రమే పరిమితం కావడం లేదు:
రేఖాచిత్రాలున్న PDFలు
తెర చిత్రాలు / బొమ్మలు
శ్రవ్య రికార్డింగ్లు
దృశ్యమాలిక భాగాలు
ఈ మూలాల నుంచి “పాఠ్యాన్ని వెలికితీయగలిగినా”, అది నిజమైన బహుమాధ్యమ ఎంబెడ్డింగ్ ప్రక్రియతో సమానం కాదు.
S3లో నిల్వ చేసిన పెద్ద చిత్రాలు, శ్రవ్యం, దృశ్యమాలికలను లోడ్ చేయడం → భాగాలుగా విభజించడం → ఎంబెడ్ చేయడం వరకు, పటిష్ఠమైన సమకాలీకరణతో pgai భవిష్యత్తులో బహుమాధ్యమ మోడల్లకు సమగ్ర మద్దతిస్తే అది ఆకర్షణీయంగా ఉంటుంది. కానీ ప్రస్తుతం ఇది పాఠ్య ఎంబెడ్డింగ్ కార్యప్రవాహం మాత్రమే.
3) మీకు ఎంబెడ్డింగ్లు మాత్రమే అవసరమైతే, pgai అవసరం లేకపోవచ్చు.
మీ డేటా స్వీకరణ ప్రక్రియ ఇప్పటికే అనుకూలీకరించబడి ఉంటే లేదా అలా ఉండాల్సి వస్తే, “పాఠ్య భాగాలను ఎంబెడ్ చేయడం” RAGలో అత్యంత కష్టమైన పని కాదు. అలాంటి సందర్భంలో pgai సమస్యలోని అత్యంత సులభమైన భాగాన్ని మాత్రమే పరిష్కరిస్తోంది.
అలాగే, మీ జ్ఞానభాండారం అరుదుగా నవీకరించబడితే, ఎంబెడ్డింగ్ల స్వయంచాలక సమకాలీకరణ వల్ల అంతగా ప్రయోజనం ఉండదు.
మీ డేటాబేస్లపై పాఠ్యం-నుంచి-SQL ముఖాంతరాన్ని అమలు చేయడం pgaiని ఉపయోగించే ఒక ప్రత్యేకమైన మంచి మార్గం. pgai అందించే semantic_catalog మాడ్యూల్తో దీన్ని చాలా సులభంగా సాధించవచ్చు. ఈ విధంగా అమర్చండి:
Bash
తర్వాత pgai semantic-catalog createతో మీ డేటా నిఘంటువులను సేకరించేలా అర్థాధారిత జాబితాను అమలు చేయండి. ఇది మీ డేటా నిల్వ నుంచి సందర్భాన్ని రూపొందిస్తుంది. అది సుమారుగా ఇలా కనిపిస్తుంది:
Plain Text
ఈ సందర్భం ఇప్పుడు pgaiకి వివిధ మార్గాల్లో అందుబాటులో ఉంటుంది:
అర్థాధారిత శోధన ద్వారా:
మీ సహజ భాషా ప్రశ్నకు సంబంధించిన పట్టికలు, ఫంక్షన్లు, ఇతర వస్తువులను ఈ ప్రశ్న తిరిగి అందిస్తుంది:
Bash
ముడి సందర్భాన్ని పొందండి:
ఇది మీ సహజ భాషా ప్రశ్నకు సంబంధించిన ముడి YAML సందర్భాన్ని ప్రదర్శిస్తుంది:
Bash
SQLను రూపొందించండి:
లేదా మీ ప్రశ్నకు సమాధానం ఇవ్వడానికి అవసరమైన ముడి SQLను నేరుగా రూపొందించవచ్చు. మునుపటి దశలోని సందర్భాన్ని LLMకు పంపి, ప్రతిస్పందనను రూపొందిస్తారు:
Bash
మీరు సాపేక్షంగా సరళమైన RAG వ్యవస్థను రూపొందిస్తుంటే, కింది అవసరాల కోసం pgaiని ప్రయత్నించవచ్చు:
ప్రధాన ఆధార వ్యవస్థగా Postgres,
అతి తక్కువ అనుసంధాన సంకేతం,
స్వయంచాలకంగా సమకాలీకరణలో ఉండే ఎంబెడ్డింగ్లు,
మీ డేటాబేస్లకు పాఠ్యం-నుంచి-SQLను వేగంగా వర్తింపజేసే మార్గం,
కొత్త RAG సాధనాలు, Postgres పొడిగింపులతో ప్రయోగాలు చేయడం.
మీ RAG ప్రక్రియకు కింది వాటిలో ఏదైనా అవసరమైతే, pgai విషయంలో కొంతకాలం వేచి చూడటం మంచిది:
అత్యంత అనుకూలీకరించిన డేటా స్వీకరణ లేదా భాగాల విభజన తర్కం
వేర్వేరు విశ్లేషణ అవసరాలున్న అనేక పత్ర రకాలు
బహుమాధ్యమ ఎంబెడ్డింగ్లు
చివరిగా, pgvectorకు విస్తృత ఆదరణ లభించినట్లు స్పష్టంగా కనిపిస్తోంది. కానీ సుమారు 18 నెలల క్రితమే వచ్చిన pgaiకి అదే స్థాయి ఆసక్తి, తద్వారా మద్దతు లభిస్తాయో లేదో స్పష్టంగా లేదు.
సాధారణ నిర్వహణ పనుల్లో ఎక్కువ భాగాన్ని డేటాబేస్లే చేసేలా చేసి, మీ అనువర్తన సంకేతాన్ని సరళీకరించే ఆసక్తికరమైన RAG విధానం pgai.
ప్రస్తుతం ఇది:
సరళమైన RAG అమరికలకు ఉపయోగకరంగా, నిజంగానే సౌకర్యవంతంగా ఉంది
మరింత ప్రత్యేకంగా రూపొందించిన ప్రక్రియలకు, ముఖ్యంగా బహుమాధ్యమ ప్రక్రియలకు, తగినంత సౌలభ్యాన్ని ఇవ్వదు
ఇది ఆశాజనకంగా ఉంది. దీని పురోగతిని తప్పకుండా గమనించాలి.