సమాధానం లేకపోవడం కంటే, తప్పుగా చెప్పే నమ్మకమైన సమాధానం ఎందుకు ప్రమాదకరం?
మీరు మీ సంస్థ కోసం అంతర్గత చాట్బాట్ను నిర్మించడం పూర్తి చేశారు. మీ కంపెనీకి సంబంధించిన ప్రతి HR పాలసీ, ఇంజనీరింగ్ స్పెసిఫికేషన్ మరియు ఆన్బోర్డింగ్ డాక్యుమెంట్ను దానికి అందించారు. ఒక కొత్త ఉద్యోగి క్లయింట్ డిన్నర్ల కోసం ప్రయాణ ఖర్చు పరిమితి (travel expense limit) గురించి అడుగుతాడు. బాట్ వెంటనే స్పందిస్తుంది. అది చాలా నమ్మకంగా సమాధానం ఇస్తుంది. ఆ పరిమితి ఒక్కొక్కరికి $75 అని చెబుతుంది.
కానీ అసలు పాలసీ ప్రకారం అది $50 మాత్రమే. బాట్ ఆ సమాధానాన్ని సొంతంగా కల్పించింది. అది మీ ఫైళ్లను ఎప్పుడూ చూడలేదు. కేవలం సంవత్సరాల క్రితం దాని శిక్షణ డేటాలో ఉన్న నమూనాల (patterns) ఆధారంగా ఊహించింది. ప్రైవేట్ డాక్యుమెంట్లపై నేరుగా లార్జ్ లాంగ్వేజ్ మోడల్స్ను (LLMs) ఉపయోగించినప్పుడు ఎదురయ్యే కఠినమైన వాస్తవం ఇదే. వాటికి మీ అంతర్గత జ్ఞానంపై ఎటువంటి ప్రాప్యత (access) ఉండదు. వాటికి కావాల్సిన వాస్తవాలు వాటి శిక్షణ డేటాలో లేనప్పుడు, అవి తెలియదని ఒప్పుకోవడానికి బదులుగా తప్పుడు సమాచారాన్ని సృష్టిస్తాయి. ప్రొడక్షన్లో ఉన్నప్పుడు, ఇది కేవలం వినోదంగా కాకుండా ఒక నష్టదాయకమైన అంశంగా (liability) మారుతుంది.
Retrieval-Augmented Generation, లేదా RAG సరిగ్గా దీనిని పరిష్కరించడానికే రూపొందించబడింది. మోడల్ను ప్రతిదీ గుర్తుంచుకోమని అడగడానికి బదులుగా, అవసరమైన సమాచారాన్ని వెతికి తెలుసుకోవడానికి మీరు దానికి అనుమతి ఇస్తారు.
ఊహించడం నుండి చదవడం వరకు
ఒక సాధారణ LLMని ఫోటోగ్రాఫిక్ మెమరీ ఉన్న ఒక తెలివైన సహోద్యోగిగా ఊహించుకోండి, కానీ వారు మీరు కంపెనీలో చేరకముందే సంస్థను వదిలి వెళ్ళిపోయారు. వారు చక్కని గద్యం రాయగలరు, లాజిక్ పజిల్స్ను పరిష్కరించగలరు మరియు క్లిష్టమైన విషయాలను సరళంగా వివరించగలరు. అయితే, గత త్రైమాసికంలోని API మార్పుల గురించి వారిని అడిగితే, వారు కేవలం నమ్మశక్యంగా అనిపించే ఏదో ఒకటి సృష్టించి చెబుతారు. వారికి వేరే మార్గం లేదు.
RAG ఆ సహోద్యోగికి ఒక ఫైలింగ్ క్యాబినెట్ను అందిస్తుంది. వినియోగదారుడు ఒక ప్రశ్న అడిగినప్పుడు, సిస్టమ్ ఆ ప్రశ్నను నేరుగా మోడల్కు పంపదు. మొదట అది సంబంధిత డాక్యుమెంట్లను వెలికితీస్తుంది (retrieves), వాటిని సందర్భం (context) కోసం ప్రాంప్ట్లోకి చేరుస్తుంది, ఆ తర్వాతే మోడల్ను చదివి సమాధానం ఇవ్వమని అడుగుతుంది. మోడల్ కేవలం విషయాలను గుర్తుంచుకోవడం నుండి, తన ముందు ఉన్న వాస్తవాలను అర్థం చేసుకోవడం వైపు మారుతుంది.
ఈ ప్రక్రియ రెండు భాగాలుగా విభజించబడింది: ఆఫ్లైన్ పునాది (offline groundwork) మరియు ఆన్లైన్ స్పందన (online response).
దశ 1: తయారీ దశ (ఆఫ్లైన్)
ఎవరైనా ప్రశ్న టైప్ చేయకముందే, మీరు మీ గందరగోళంగా ఉన్న డాక్యుమెంట్ కలెక్షన్ను వెతకగలిగే నాలెడ్జ్ బేస్గా మార్చాలి. మీ RAG సిస్టమ్ విజయవంతం కావాలా లేదా విఫలం కావాలా అనేది ఈ పునాదిపైనే ఆధారపడి ఉంటుంది.
Document loaders మీ ప్రారంభ బిందువు. ఈ కనెక్టర్లు PDFలు, Notion వర్క్స్పేస్లు, SharePoint ఫోల్డర్లు, వెబ్ పేజీలు మరియు అంతర్గత వికీల నుండి ముడి వచనాన్ని (raw text) సేకరిస్తాయి. ఇక్కడే అసలు సవాలు మొదలవుతుంది. ఒక లోడర్ Word డాక్యుమెంట్ నుండి స్పష్టమైన వచనాన్ని సేకరించవచ్చు, కానీ టెక్స్ట్ లేని ఇమేజ్ రూపంలో ఉన్న స్కాన్ చేసిన PDFని చూసి విఫలం కావచ్చు. అప్పుడు లోడర్ ఖాళీ స్ట్రింగ్ను అందిస్తుంది, మీ డేటాబేస్లో ఏమీ నిక్షిప్తం కాదు, మరియు వినియోగదారుడికి ఎటువంటి హెచ్చరిక లేకుండా "నాకు తెలియదు" అనే సమాధానం వస్తుంది. మీ లోడర్లు నిజంగా ఏమి సేకరించాయో ఎల్లప్పుడూ తనిఖీ చేయండి. పైప్లైన్ను నమ్మే ముందు ప్రతి మూలం నుండి కొన్ని డాక్యుమెంట్లపై తనిఖీలు (spot checks) చేయండి.
తర్వాత text splitting, దీనినే chunking అని కూడా పిలుస్తారు. మీరు ఎనభై పేజీల సెక్యూరిటీ పాలసీని ఒకేసారి ప్రాంప్ట్లోకి పంపలేరు; అలా చేస్తే కాంటెక్స్ట్ పరిమితులను దాటిపోవడమే కాకుండా, ముఖ్యమైన సమాచారం నాయిస్లో కలిసిపోతుంది. దానికి బదులుగా, మీరు డాక్యుమెంట్లను చిన్న చిన్న ముక్కలుగా (chunks) విడగొడతారు. సరైన పరిమాణాన్ని ఎంచుకోవడమే ఇందులో అసలైన చిక్కు. వాక్యాల వంటి చాలా చిన్న చంక్స్ (chunks) తరచుగా కీలకమైన సందర్భాన్ని కోల్పోతాయి. ఉదాహరణకు, "అన్ని అభ్యర్థనలను మేనేజర్ ఆమోదించాలి" అని ఉన్న ఒక చంక్, ఈ నియమం అంతర్జాతీయ ప్రయాణాలకు మాత్రమే వర్తిస్తుందని చెప్పడం మర్చిపోవచ్చు. పూర్తి అధ్యాయాల వంటి చాలా పెద్ద చంక్స్, ఎంబెడ్డింగ్ను బలహీనపరుస్తాయి మరియు ఒకేసారి పదిహేను వేర్వేరు అంశాలను కవర్ చేయడం వల్ల రిట్రీవల్ (retrieval) ప్రక్రియను అయోమయానికి గురిచేస్తాయి. ఆచరణలో, చాలా బృందాలు 300 నుండి 500 టోకెన్ల మధ్య చంక్ పరిమాణంతో ప్రారంభిస్తాయి, మరియు వాక్యాలు విడిపోకుండా ఉండటానికి 50-టోకెన్ ఓవర్లాప్ (overlap) ఉపయోగిస్తాయి. మీ కంటెంట్ ఆధారంగా దీనిని మార్చుకోండి. API డాక్యుమెంటేషన్ చిన్న చంక్స్ను తట్టుకోగలదు. చట్టపరమైన ఒప్పందాలకు (Legal contracts) కండిషనల్ లాజిక్ను కాపాడటానికి తరచుగా పెద్ద చంక్స్ అవసరమవుతాయి.
చంక్ చేసిన తర్వాత, ప్రతి భాగాన్ని embeddingగా మారుస్తారు. అంటే, ఆ వచనాన్ని ఒక మోడల్ ద్వారా పంపి, ఆ చంక్ యొక్క అర్థాన్ని (semantic meaning) సూచించే సంఖ్యల జాబితాను (వెక్టర్ - vector) పొందడం. ఇలా చేయడం వల్ల ఒకే రకమైన ఆలోచనలు ఈ గణిత అంతరాళంలో (mathematical space) దగ్గరగా ఉంటాయి. ఉదాహరణకు, "401k matching policy" మరియు "retirement contribution rules" అనేవి "401k matching policy" మరియు "office printer setup" కంటే దగ్గరగా ఉంటాయి. ఈ వెక్టర్లు Pinecone, Weaviate లేదా Chroma వంటి ఓపెన్-సోర్స్ ప్రత్యామ్నాయాల వంటి vector databaseలో నిక్షిప్తం చేయబడతాయి. వెక్టర్ స్టోర్ అనేది కేవలం డేటాను దాచే చోటు మాత్రమే కాదు. ఇది 'approximate nearest-neighbor search' కోసం ఆప్టిమైజ్ చేయబడిన ఒక ఇండెక్స్, ఇది మిలియన్ల కొద్దీ డాక్యుమెంట్ల నుండి కూడా మిల్లీసెకన్లలో అత్యంత సంబంధిత చంక్స్ను కనుగొనడానికి మీకు సహాయపడుతుంది.
దశ 2: లైవ్ పాత్ (ఆన్లైన్)
ఒక వినియోగదారు చివరకు, "క్లయింట్ డిన్నర్ల కోసం మా ప్రయాణ ఖర్చుల రీయింబర్స్మెంట్ పాలసీ ఏమిటి?" అని అడిగినప్పుడు, లైవ్ పైప్లైన్ పనిచేయడం ప్రారంభిస్తుంది.
ఆ