நினைவகத்தை வகைகளின் அடிப்படையில் கட்டமைப்பது, பெறப்படும் டோக்கன்களை (tokens) சுமார் 40% குறைக்கிறது.

ஒரு தட்டையான நினைவகச் சேமிப்பு (flat memory store) ஏன் தோல்வியடைகிறது

பெரும்பாலான தொடக்கநிலை பயிற்சிகள் (tutorials), ஒவ்வொரு புதிய தகவலையும் ஒரு தனிப் பட்டியலுடன் இணைத்து, ஒவ்வொரு முறையும் அந்தப் பட்டியலை மாடலுக்குத் திருப்பி அனுப்புவதன் மூலம் ஒரு LLM ஏஜென்ட் எவ்வாறு "நினைவில் கொள்ள வேண்டும்" என்பதைக் கற்பிக்கின்றன. இதன் குறியீடு (code) வெறும் மூன்று வரிகள் மட்டுமே, மேலும் இது ஒரு வேலை செய்யும் டெமோவை உருவாக்குகிறது. ஆனால் நடைமுறையில், அந்தப் பட்டியல் கட்டுக்கடங்காமல் வளர்கிறது. இதில் இரண்டு அறிகுறிகள் தென்படுகின்றன:

  • ஏஜென்ட் காலாவதியான தரவை இன்னும் உண்மையானது போலவே கருதுகிறது, உதாரணமாக பல மணிநேரங்களுக்கு முன்பே காலாவதியான ஒரு ETA-வை வழங்குகிறது.
  • பதிலில் எந்தத் தாக்கத்தையும் ஏற்படுத்தாத தேவையற்ற தகவல்களால் (trivia) கான்டெக்ஸ்ட் விண்டோ (context window) நிரம்புகிறது, இது API செலவுகளை அதிகரிப்பதோடு பதிலளிக்கும் நேரத்தையும் மெதுவாக்குகிறது.

ஒரு சாதாரண வெக்டர் ஸ்டோர் (vector store) அல்லது எளிய கீ-வேல்யூ கேச் (key-value cache) மூலம் பயனரின் பணிப் பதவியையும் தற்காலிகத் திட்ட நிலையையும் (project status) வேறுபடுத்திப் பார்க்க முடியாது. ஏஜென்ட் ஒரு செமாண்டிக் தேடலை (semantic search) மேற்கொள்ளும்போது, தரவு இனித் தேவையில்லை என்றாலும், வினவலில் (query) அதே வார்த்தைகள் இருப்பதால், ஒற்றுமை அல்காரிதம் (similarity algorithm) ஒரு பழைய ETA-வை முன்னிலைப்படுத்தலாம்.

கட்டமைக்கப்பட்ட நினைவகம்: நான்கு பிரிவுகள், ஒரு நோக்கம்

இதற்குத் தீர்வு என்னவென்றால், நினைவகத்தை ஒரு ஒற்றை அமைப்பாகக் கருதாமல், ஒவ்வொரு பதிவையும் நான்கு வகைகளில் ஒன்றாக வகைப்படுத்தத் தொடங்குவதே ஆகும்:

  • User facts – பயனரின் பங்கு (role), விருப்பமான மொழி அல்லது பாதுகாப்பு அனுமதி (security clearance) போன்ற நிலையான பண்புகள். இவை அரிதாகவே மாறும் மற்றும் முழு அமர்வுக்கும் (session) கேச் செய்யப்படலாம்.
  • Feedback – ஏஜென்ட் கண்டிப்பாகப் பின்பற்ற வேண்டிய தெளிவான விதிகள், உதாரணமாக, "தரவுத்தள கடவுச்சொற்களை ஒருபோதும் வெளிப்படுத்த வேண்டாம்" அல்லது "விதிமுறை வினவல்களில் நகைச்சுவையைத் தவிர்க்கவும்." இவை நடத்தையைத் தீர்மானிப்பதால், தேடக்கூடிய தொகுப்பில் (searchable pool) வைக்கப்படாமல் சிஸ்டம் பிராம்ப்ட்டில் (system prompt) இருக்க வேண்டும்.
  • Project state – தற்போதைய ETA-க்கள், பணி முன்னேற்றம் அல்லது தற்காலிக டோக்கன்கள் போன்ற வேகமாக மாறும் தரவுகள். இந்தத் தொகுப்பிற்கு காலாவதி சரிபார்ப்பு (expiry check) தேவை; ஒரு டைம்ஸ்டாம்ப் (timestamp) வரையறுக்கப்பட்ட காலத்திற்கு வெளியே சென்றவுடன், அந்தப் பதிவு நீக்கப்பட வேண்டும்.
  • References – வெளிப்புறச் சேவைகள், ஆவண ஐடிகள் (document IDs) அல்லது API எண்ட்பாயிண்ட்களுக்கான (API endpoints) குறிப்புகள். இவை காண்பிக்கப்பட வேண்டிய உள்ளடக்கங்கள் அல்ல, மாறாக தேவைப்படும்போது புதிய தரவைப் பெறுவதற்கான வழிகள் (routes) ஆகும்.

Mem0 டெவலப்பர்கள் ஒவ்வொரு நினைவகப் பதிவிற்கும் தன்னிச்சையான மெட்டாடேட்டாவை (metadata) இணைக்க அனுமதிக்கிறது. "kind" என்ற புலத்தின் (field) அடிப்படையில் குறியீடாக்கம் (indexing) செய்வதன் மூலம், LLM முடிவைப் பயன்படுத்துவது எப்படி என்று தீர்மானிப்பதற்கு முன்பே, ஒரு வினவல் தொடர்புடைய தொகுப்பை வடிகட்ட முடியும்.

Mem0 மூலம் இரண்டு படிநிலை மீட்டெடுப்பு (Two-step retrieval)

  1. வகை வாரியாக நினைவகங்களை எடுத்தல் – ஒரு சிறிய வடிகட்டி வினவல் (filter query) Mem0-விடம் "அனைத்து பின்னூட்டங்களையும்" (all feedback) அல்லது "குறுகிய கால இடைவெளியை விடப் புதிய திட்ட நிலை பதிவுகளை" (project-state entries newer than a short interval) கேட்கிறது. இதன் விளைவாகக் கிடைக்கும் தொகுப்பு ஏற்கனவே பொருத்தமான வகைக்குக் குறைக்கப்பட்டு இருக்கும்.
  2. LLM-ஐத் தீர்மானிக்க விடுங்கள் – வடிகட்டப்பட்ட சிறு துணுக்குகள் பயனரின் தற்போதைய கேள்வியுடன் பிராம்ப்ட்டில் சேர்க்கப்படுகின்றன. இப்போது மாடல் தேவையற்ற உண்மைகளைத் தேட வேண்டிய அவசியமின்றி, அவற்றைப் பற்றிச் சிந்திக்க முடியும்.

ஒரு தெளிவான உதாரணம்: "தரவுத்தளத்தை கேலி செய்ய வேண்டாம்" என்ற விதியை ஒரு செமாண்டிக் பொருத்தம் (semantic match) மூலம் கண்டறியக் காத்திருக்காமல், டெவலப்பர் அந்த விதியை அமர்வு தொடக்கத்திலேயே நேரடியாக சிஸ்டம் பிராம்ப்ட்டில் சேர்த்து, முழு உரையாடலுக்கும் அதை கேச் செய்கிறார். பயனரின் வினவலில் தரவுத்தளங்கள் பற்றிய நேரடித் தகவல் இல்லாவிட்டாலும், மாடலுக்கு அந்தத் தடை ஏற்கனவே தெரியும்.

செலவைக் குறைக்க உதவும் நடைமுறை யுக்திகள்

  • Feedback விதிகளை கேச் செய்யவும் – ஒவ்வொரு முறையும் மீண்டும் தேடுவதற்குப் பதிலாக, விதிகளின் தொகுப்பை ஒரு அமர்வுக்கு ஒருமுறை சேமித்து அதை மீண்டும் பயன்படுத்தவும். இது ஒவ்வொரு சுற்றிலும் டோக்கன் பயன்பாட்டைக் குறைக்கிறது.
  • தேவையற்ற போது திட்ட நிலைத் தேடல்களைத் தவிர்க்கவும் – பயனர் முற்றிலும் ஒரு கருத்தியல் கேள்வியைக் கேட்டால் ("supervised மற்றும் reinforcement learning ஆகியவற்றிற்கு இடையிலான வேறுபாடு என்ன?"), எந்த ETA அல்லது பணி முன்னேற்றத் தரவையும் எடுக்க வேண்டிய அவசியமில்லை.

இந்த இரண்டு பழக்கங்களையும் பின்பற்றுவதன் மூலம், ஒரு சாதாரண தட்டையான நினைவக அணுகுமுறையுடன் (naïve flat memory approach) ஒப்பிடும்போது டோக்கன் பயன்பாட்டை சுமார் 40% குறைக்க முடியும். இந்தச் சேமிப்பு நேரடியாகக் குறைந்த API கட்டணங்களாகவும் மற்றும் விரைவான பதிலளிப்புத் திறனாகவும் மாறும், குறிப்பாகப் பல உரையாடல்களைத் தொடரும் ஏஜென்ட்களுக்கு இது மிகவும் பயனுள்ளதாக இருக்கும்.

யாருக்கு லாபம், யார் கவலைப்பட வேண்டும்

வெற்றியாளர்கள் – வாடிக்கையாளர் ஆதரவு பாட்கள் (customer-support bots), உள் பணிப்பாய்வு உதவியாளர்கள் (internal workflow assistants) அல்லது எந்தவொரு மல்டி-டர்ன் LLM இடைமுகத்தையும் (multi-turn LLM interface) உருவாக்கும் குழுக்கள். அவர்கள் மிகவும் நம்பகமான பதில்களைப் பெறுகிறார்கள், காலாவதியான தரவுகளால் ஏற்படும் சங்கடமான தவறுகளைத் தவிர்க்கிறார்கள் மற்றும் தங்கள் பட்ஜெட்டைச் சிறப்பாகப் பயன்படுத்துகிறார்கள்.

முக்கியக் கருத்து (Takeaway)

நீண்ட அமர்வு காலங்களிலும் துல்லியமாகச் செயல்படும் ஒரு LLM ஏஜென்ட்டை நீங்கள் விரும்பினால், ஒவ்வொரு தகவலையும் ஒரு தனி கான்டெக்ஸ்ட் விண்டோவில் திணிக்க வேண்டாம். ஒவ்வொரு நினைவகத்தையும் user fact, feedback, project state அல்லது reference எனத் தகுந்த முறையில் குறியிடுங்கள் (tag), தேவைப்படும் இடங்களில் காலாவதி முறையைச் செயல்படுத்துங்கள், மேலும் Mem0 போன்ற ஒரு கருவி கடினமான வேலைகளைச் செய்ய அனுமதியுங்கள். இதன் விளைவாகப் புதிய பதில்கள், குறைவான தேவையற்ற டோக்கன்கள் மற்றும் இயக்கச் செலவுகளில் குறிப்பிடத்தக்கக் குறைவு ஆகியவை கிடைக்கும்.