ప్రధాన నావిగేషన్

అనుకూలీకరించిన 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, } }} 

అర్థం, వ్యాకరణం ద్వారా పదాల మధ్య నేర్చుకున్న సంబంధాల కారణంగానే ఎంబెడింగ్‌లు పనిచేస్తాయి. పై డేటాలో వచనం, సంఖ్యలు కలిసి ఉన్నాయి. ఈ నిర్దిష్ట సందర్భం బయట ఆ సంఖ్యలకు పదాలతో ఎలాంటి సంబంధం ఉండదు. కాబట్టి ఈ డేటా భాగం కొంత వివరణాత్మకమైన పదాలు, వాటి తర్వాత కొన్ని యాదృచ్ఛిక సంఖ్యల కలయిక అని చెప్పవచ్చు.

మన వద్ద ఉన్న డేటా రకం ఇదొక్కటే అయితే ఇది సమస్య అయ్యేది కాదు. అందుబాటులో ఉన్న కొద్దిపాటి వివరణాత్మక పదాల ఎంబెడింగ్‌లతోనే దాన్ని తిరిగి పొందవచ్చు (లేదా వచనం నుంచి 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." } }}

ఇప్పుడు “Draconic Ascensionతో దాడి పరిధి ఎంత?” అనే ప్రశ్నకు సంబంధించిన సమాచారాన్ని పొందాలనుకుందాం.అదే కీలకపదాలు ఉన్న ఇతర భాగాల సందడిలో అవసరమైన భాగం మరుగున పడటంతో, దాన్ని మనం తిరిగి పొందలేకపోయే అవకాశమే ఎక్కువ.

ఒకే అంశంపై విభిన్న రకాల సమాచారం ఉన్నప్పటికీ, ఈ డేటా భాగాల మధ్య తేడాను స్పష్టంగా గుర్తించలేకపోవడమే అసలు సమస్య. దాన్ని ఏదో విధంగా మరింత సమృద్ధిగా లేదా మెరుగ్గా చేయగలమా? తప్పకుండా చేయగలం:smile:

  1. మీ డేటాను సంగ్రహించి మరింత సమృద్ధిగా చేయండి. అవును, మీరు చదివింది నిజమే.

భాగాన్నే నేరుగా ఎంబెడ్ చేయడానికి బదులుగా, ముందుగా ఆ డేటా దేనికి సంబంధించినదో వివరించే సారాంశాన్ని రూపొందించవచ్చు. తర్వాత ఆ సారాంశాన్ని ఎంబెడ్ చేసి, దాని ఆధారంగా సమాచారాన్ని తిరిగి పొందవచ్చు. సమాధానాన్ని రూపొందించే దశలో సారాంశానికి అనుసంధానించిన అసలు డేటానే ఉపయోగిస్తాము.

కాబట్టి పైన చూపిన రెండు భాగాల కోసం ఇలాంటి సారాంశాలను రూపొందిస్తాము:

  1. పరిధి, వేగం, నష్టానికి సంబంధించిన దాడి గణాంకాలు (సాధారణ స్థితిలో, Draconic Ascensionతో).

  2. సక్రియం కావడానికి అవసరమైన పరిస్థితులు, దృశ్య ప్రభావాలు, నేపథ్య కథతో సహా Draconic Ascension వివరణ, వివరాలు.

ఆ తర్వాత ప్రశ్నను కూడా సారాంశంతో “సరిపోలేలా” మెరుగుపరుస్తాము. ఉదాహరణకు, “Draconic Ascensionతో దాడి పరిధి ఎంత?” అనే ప్రశ్నను ఇలా మారుస్తాము.“Draconic Ascensionతో దాడి పరిధి గణాంకాలు ఏమిటి?”సాంకేతిక రంగాలకు వెలుపల ఉన్న వినియోగదారులు ~~“ఇష్టానుసారంగా”~~ సాధారణ మానవ భాషలో ప్రశ్నించినప్పుడు ఇది మరింత ముఖ్యం. ఎందుకంటే ఖచ్చితత్వం, సమగ్రతను గరిష్ఠం చేయడానికి RAG ఎలా పనిచేస్తుందో తెలుసుకోవడం వారి పరిజ్ఞాన పరిధిలోనో ఆసక్తిలోనో ఉండదు.

పరిస్థితి మరింత క్లిష్టమైనప్పుడు ఏమవుతుందో చూపే రేఖాచిత్రం.

  1. విషయాలను సందర్భం నుంచి వేరు చేయవద్దు (జీవితంలోనూ సాధారణంగా వర్తిస్తుంది).

తదుపరి సందర్భంలో, కిందివాటిలా ఒకేలా కనిపించే భారీ సంఖ్యలో డేటా భాగాలను నిర్వహించాల్సి వస్తుంది:

Plain Text

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

ఇదే విధానాన్ని కొనసాగిస్తే, “పాత్ర X దాడి పరిధి ఎంత?” అని అడిగినట్లు ఊహించండి.మనం ఇప్పుడే రూపొందించిన సారాంశాలు కూడా ఒకేలా కనిపిస్తాయి కాబట్టి, వాటితో అదృష్టంపై ఆధారపడిన ఊహాగానాల ఆట ఆడుతున్నట్లే ఉంటుంది. మరి వాటి మధ్య తేడాను ఎలా గుర్తించగలం?

సరళమైన సమాధానం: సందర్భాన్ని అందించాలి. డేటా భాగంలో దాని మూల పత్రానికి సంబంధించిన సూచనను చేర్చవచ్చు. ఉదాహరణకు, ఈ సందర్భంలో {”పాత్ర”: “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లు సంభావ్యత ఆధారంగా పనిచేస్తాయి కాబట్టి వాటిపైనే పూర్తిగా ఆధారపడకూడదు.

LLMల సామర్థ్యాలను పూర్తిగా వినియోగించుకుంటూనే, ఊహించదగిన, విశ్వసనీయ ఫలితాన్ని సాధించేందుకు అనుకూల కోడ్ లేదా ఫంక్షన్‌లను, Pydantic మోడళ్లను ఉపయోగించవచ్చు.

ముగింపు

ఉత్పాదక కృత్రిమ మేధ పరిష్కారాన్ని నిర్మించడం కృత్రిమ మేధ సవాలు ఎంతగా ఉంటుందో, ఇంజినీరింగ్ సవాలు కూడా అంతగానే ఉంటుంది. మీ ప్రత్యేక సవాళ్లను పరిష్కరించేందుకు ఈ ఉదాహరణలు మీకు స్ఫూర్తినిచ్చాయని ఆశిస్తున్నాము. ఇంజినీరింగ్‌కు ప్రాధాన్యమిచ్చే ఉత్పాదక కృత్రిమ మేధ పరిష్కారాల గురించి మరింత తెలుసుకోవడానికి, రూటర్ ఆధారిత స్వయంప్రతిపత్తి వ్యవస్థ రూపకల్పనపై మా బ్లాగ్ కథనాన్ని చదవండి.

రచయిత

Cynthia Yu