ஒரு டெவலப்பரின் “கனவு காணும்” (dreaming) pipeline ஒரு நாளைக்கு இருமுறை இயங்குகிறது. இது ஒரு LLM-agent-ன் மூல நிகழ்வுப் பதிவை (raw event log) சுருக்கமான, சரிபார்க்கப்பட்ட நினைவகச் சேமிப்பாக (vetted memory store) மாற்றி, டோக்கன் செலவைக் கணிசமாகக் குறைக்கிறது. இந்த நுணுக்கம் முக்கியமானது, ஏனெனில் பெரும்பாலான ஏஜென்ட் அமைப்புகள் தாங்கள் காணும் ஒவ்வொரு விவரத்தையும் அவற்றின் செயல்பாட்டு நினைவகத்தில் (working memory) திணித்துக் கொள்கின்றன; இது விரைவாக முரண்பாடுகள், மறக்கப்பட்ட சூழல் மற்றும் அதிகரித்து வரும் API செலவுகளுக்கு வழிவகுக்கிறது.
LLM முகவர்களுக்கு நினைவகம் ஏன் முக்கியம்
LLM முகவர்கள் ஒவ்வொரு பயனர் கோரிக்கை, கருவி அழைப்பு (tool call) அல்லது உள் அவதானிப்பையும் (internal observation) ஒரு புதிய “நிகழ்வாக” (event) கருதுகின்றன. எளிமையான அணுகுமுறையானது, ஒவ்வொரு நிகழ்வையும் அடுத்த முடிவெடுப்பதற்கான ப்ராம்ப்ட்டுடன் (prompt) இணைத்துக்கொண்டே இருக்கும். நடைமுறையில், இது ப்ராம்ப்ட்டில் தேவையற்ற இரைச்சலை (noise) நிரப்புகிறது, காலாவதியான உண்மைகளை மீண்டும் மதிப்பீடு செய்ய மாதிரியை (model) கட்டாயப்படுத்துகிறது மற்றும் டோக்கன் பயன்பாட்டை மிக உயர்ந்த விலை அடுக்கிற்குத் தள்ளுகிறது. இதன் விளைவாக: அதிக பிழைகள் மற்றும் ஒவ்வொரு தொடர்பிற்கும் ஏற்ப உயர்ந்து கொண்டே செல்லும் ஒரு மறைமுகக் கட்டணம் ஏற்படுகிறது.
இரவுநேரக் கனவு (nightly dreaming) எவ்வாறு செயல்படுகிறது
இந்த அமைப்பு எழுதும் பாதையை (write path - ஏஜென்ட்டின் நேரடிப் பதிவு) மற்றும் பணிப் பாதையை (work path - மாதிரியின் முடிவெடுக்கும் திறன்) தனித்தனியாகப் பிரிக்கிறது. ஒவ்வொரு நாளும் இருமுறை, “கனவு” (dream) என்று அழைக்கப்படும் ஒரு பின்னணிப் பணி, திரட்டப்பட்ட நிகழ்வுகளை மூன்று நிலைகள் மூலம் செயலாக்குகிறது:
- Reflect – ஒரு LLM தொடர்புடைய நிகழ்வுகளின் தொகுப்புகளை ஸ்கேன் செய்து, சுருக்கமான உண்மைகளை முன்மொழிந்து, எந்த நிகழ்வுகள் அந்த முன்மொழிவை ஆதரிக்கின்றன என்பதைப் பதிவு செய்கிறது.
- Score – ஒரு உண்மை போதுமான ஆதரவு நிகழ்வுகளைக் கொண்டுள்ளதா என்பதையும், அந்த நிகழ்வுகள் நம்பகமானதாக இருக்க போதுமான கால இடைவெளியில் உள்ளனவா என்பதையும் இந்த செயல்முறை சரிபார்க்கிறது.
- Judge – புதிய உண்மை ஏற்கனவே உள்ள நினைவகத்துடன் முரண்படவில்லை என்பதையும், அது ஒரு நகல் (duplicate) அல்ல என்பதையும் இரண்டு சரிபார்ப்புகள் உறுதி செய்கின்றன.
அனைத்துச் சரிபார்ப்புகளையும் கடந்து செல்லும் உண்மைகள் நிரந்தர நினைவகத்திற்கு (permanent memory) உயர்த்தப்படுகின்றன. தகுதியற்றவை ஒரு மறுஆய்வு வரிசையில் (review queue) வைக்கப்படுகின்றன; அங்கு ஒரு மனிதப் பணியாளர் ஒருமுறை அழுத்துவதன் மூலம் அவற்றை அங்கீகரிக்கலாம் அல்லது நிராகரிக்கலாம். ஒவ்வொரு அங்கீகாரமும் ஒரு git-பாணி கமிட்டை (git-style commit) உருவாக்குகிறது, இது நினைவகம் எப்போது, எப்படி மாற்றப்பட்டது என்பதற்கான முழுமையான தணிக்கைப் பாதையை (audit trail) வழங்குகிறது.
முக்கிய பொறியியல் கருத்துக்கள்
- எழுதும் பணியையும் செய்யும் பணியையும் பிரிக்கவும். ஏஜென்ட்கள் தங்களின் ஒவ்வொரு அவதானிப்பையும் ஒரு பதிவில் (log) கொட்ட அனுமதிக்கவும்; எது தங்குவது என்பதை ஒரு பிரத்யேக செயல்முறை தீர்மானிக்கட்டும்.
- உருவாக்கத்தில் அல்ல, நிராகரிப்பதில் கவனம் செலுத்துங்கள். யோசனைகளை உருவாக்குவது மலிவானது; நினைவகக் மாசுவை (memory pollution) தடுப்பதே கடினமான பகுதி.
- மலிவான சரிபார்ப்புப் புள்ளியில் மனிதக் கட்டுப்பாடு (Human gates). தானியங்கி வரைவு முறையைத் தொடர்ந்து ஒரு விரைவான கைமுறை அங்கீகாரம் பெறுவது, முழுமையான தன்னாட்சியை விட செலவு மற்றும் பாதுகாப்பில் சிறந்தது.
- ஒவ்வொரு சுற்றிலும் டோக்கன் செலவைக் கட்டுப்படுத்தவும். ஒரு dreaming run-க்கான டோக்கன்களுக்குக் கடுமையான வரம்பு விதிப்பது, கட்டுப்பாடற்ற செலவுகளைத் தடுக்கும்.
- அமைதியான தோல்விகளுக்காக (silent failures) தணிக்கை செய்யவும். ஒரு நிலை அடுத்த நிலையை விட வேறுபட்ட விதிகளைப் பயன்படுத்தினால், தரவுகள் கவனிக்கப்படாமல் மறைந்துவிடக்கூடும்; தெளிவான சரிபார்ப்புகள் இந்த முரண்பாடுகளைக் கண்டறியும்.
சாத்தியமான குறைபாடுகள்
இந்த ஒருங்கிணைப்பை (consolidation) ஆஃப்லைனில் இயக்குவது ஒரு தாமதத்தை (lag) ஏற்படுத்துகிறது: அடுத்த கனவுச் சுழற்சி வரை ஏஜென்ட் புதிதாகச் சரிபார்க்கப்பட்ட உண்மைகளைக் காண முடியாது. உடனடி கற்றல் தேவைப்படும் வேகமாக இயங்கும் பயன்பாடுகளில், இந்தத் தாமதம் ஒரு குறைபாடாக இருக்கலாம். மேலும், இந்த அமைப்பு ஒரு தனி மனித மறுஆய்வாளரைச் சார்ந்துள்ளது; தொழிலாளர் செலவை அதிகரிக்காமல் மறுஆய்வு வரிசையை விரிவுபடுத்துவது என்பது இன்னும் ஒரு சவாலான கேள்வியாகவே உள்ளது.
அடுத்து கவனிக்க வேண்டியவை
LLM முகவர்களுடன் பரிசோதனை செய்யும் டெவலப்பர்கள், டோக்கன் கட்டணங்கள் மற்றும் பிழைப் பதிவுகளைக் கண்காணித்து, “நினைவகக் மாசு” (memory pollution) – அதாவது மூல நிகழ்வுத் திரட்டலால் ஏற்படும் மீண்டும் மீண்டும் வரும் அல்லது முரண்பட்ட கூற்றுகள் – ஏற்படுகிறதா என்பதைக் கவனிக்க வேண்டும். ஒரு dreaming pipeline-ஐச் சேர்ப்பது, ஒரு தணிக்கை செய்யக்கூடிய நினைவக வரலாற்றைப் பெறுவதோடு மட்டுமல்லாமல், அந்தச் செலவுகளைக் குறைக்க ஒரு தெளிவான கட்டுப்பாட்டு கருவியையும் வழங்குகிறது. அதிகப்படியான குழுக்கள் இந்த split-log மாதிரியைப் பின்பற்று隨著, reflect-score-judge நிலைகளைத் தானியக்கமாக்கும் மற்றும் பதிப்பு-கட்டுப்பாட்டு-பாணி (version-control-style) மறுஆய்வுடன் ஒருங்கிணைக்கும் கருவிகள் வெளிவரக்கூடும், இது இந்த அணுகுமுறையை எளிமையாக்கும். உடனடித் தன்மைக்கும் தூய்மைக்கும் இடையிலான சமநிலை (trade-off), இந்த இரவுநேரக் கனவு LLM-agent கட்டமைப்பின் ஒரு தரநிலையான அங்கமாக எவ்வளவு தூரம் மாறும் என்பதைத் தீர்மானிக்கும்.