AWS അതിന്റെ Bedrock സേവനത്തിൽ query-aware compression ചേർത്തു. ഇത് ഡെവലപ്പർമാരെ ലാംഗ്വേജ് മോഡലിലേക്ക് എത്തുന്നതിന് മുമ്പ് പ്രസക്തമല്ലാത്ത ഡോക്യുമെന്റ് ഭാഗങ്ങൾ ഒഴിവാക്കാൻ സഹായിക്കുന്നു. മോഡലിലേക്ക് അയക്കുന്ന ടോക്കണുകളുടെ എണ്ണം കുറയ്ക്കുന്നതിലൂടെ, Retrieval-Augmented Generation (RAG) പൈപ്പ്‌ലൈനുകളുടെ കമ്പ്യൂട്ട് ബില്ല് കുറയ്ക്കാൻ ഈ ഫീച്ചറിന് കഴിയും.
എന്തുകൊണ്ടാണ് RAG പൈപ്പ്‌ലൈനുകൾക്ക് ഇത്രയധികം ചിലവ് വരുന്നത്
RAG സിസ്റ്റങ്ങൾ ആദ്യം ഒരു നോളജ് ബേസിൽ (knowledge base) നിന്ന് ടെക്സ്റ്റ് ഭാഗങ്ങൾ ശേഖരിക്കുകയും, തുടർന്ന് ഉപയോക്താവിന്റെ ചോദ്യത്തിന് ഉത്തരം നൽകുന്നതിനായി ആ ഭാഗങ്ങൾ ഒരു ജനറേറ്റീവ് മോഡലിലേക്ക് നൽകുകയും ചെയ്യുന്നു. മിക്കപ്പോഴും, ശേഖരിച്ച ഭാഗങ്ങളിൽ വലിയൊരു ഭാഗം ചോദ്യവുമായി ബന്ധമില്ലാതിരുന്നിട്ടും, അവയെല്ലാം നേരിട്ട് മോഡലിലേക്ക് അയക്കുന്നു എന്നതാണ് പതിവ്. ഓരോ അധിക വാക്കും ഒരു ടോക്കൺ ആയി മാറുന്നു, കൂടാതെ മോഡൽ പ്രോസസ്സ് ചെയ്യുന്ന ഓരോ ടോക്കണും ഉപയോഗിക്കുന്ന API-യുടെ ചിലവ് വർദ്ധിപ്പിക്കുന്നു. സപ്പോർട്ട് ബോട്ടുകളോ ഇന്റേണൽ സെർച്ച് ടൂളുകളോ നടത്തുന്ന ചെറുകിട ഇടത്തരം കമ്പനികളെ സംബന്ധിച്ചിടത്തോളം, ടോക്കൺ ചിലവ് മോഡൽ കോളുകളുടെ ചിലവിനേക്കാൾ വേഗത്തിൽ വർദ്ധിച്ചേക്കാം.
എന്താണ് query-aware compression ചെയ്യുന്നത്
പുതിയ Bedrock കപ്പാബിലിറ്റി, റിട്രീവലും ജനറേഷനും ഇടയിൽ ഒരു ഫിൽട്ടറിംഗ് ഘട്ടം ഉൾപ്പെടുത്തുന്നു:
- സിസ്റ്റം ഇപ്പോഴും ഒരേ ഡോക്യമെന്റുകൾ തന്നെ ക്വറിക്കായി ശേഖരിക്കുന്നു.
- മോഡൽ ഏതെങ്കിലും ടെക്സ്റ്റ് കാണുന്നതിന് മുമ്പ്, ഒരു ലൈറ്റ് വെയ്റ്റ് പ്രോസസ്സർ ഓരോ ഭാഗവും നൽകിയിട്ടുള്ള ചോദ്യവുമായി താരതമ്യം ചെയ്യുന്നു.
- പ്രസക്തമെന്ന് കണ്ടെത്തിയ ഭാഗങ്ങൾ മാത്രം നിലനിർത്തുന്നു; ബാക്കിയുള്ളവ നോയിസ് (noise) ആയി കണക്കാക്കി ഒഴിവാക്കുന്നു.
ഇതിനായി നിങ്ങൾക്ക് പുതിയൊരു ഇൻഡക്സോ, എംബെഡിംഗ് മോഡലോ (embedding model), അല്ലെങ്കിൽ ഫൈൻ ട്യൂൺ ചെയ്ത ലാംഗ്വേജ് മോഡലോ ആവശ്യമില്ല. പൈപ്പ്‌ലൈനിൽ കംപ്രഷൻ ലെയർ ഉൾപ്പെടുത്തുന്ന രീതിയിൽ ചെറിയൊരു മാറ്റം വരുത്തിയാൽ മാത്രം മതി.
ബിസിനസ്സ് ഇംപാക്ട്
മോഡലിലേക്ക് അയക്കുന്ന ടെക്സ്റ്റിന്റെ അളവ് കൂടുന്നതിനനുസരിച്ച് ടോക്കൺ ഫീസും വർദ്ധിക്കുന്നതിനാൽ, പ്രസക്തമല്ലാത്ത ഭാഗങ്ങൾ ഒഴിവാക്കുന്നത് ബില്ലിലെ ഓരോ നിരക്കും കുറയ്ക്കാൻ സഹായിക്കും. ഉപയോഗം കൂടുന്നതിനനുസരിച്ച് RAG ചിലവുകൾ വർദ്ധിക്കുന്നത് കണ്ടുകൊണ്ടിരിക്കുന്ന കമ്പനികൾക്ക് ഇതിലൂടെ വലിയ നേട്ടമുണ്ടാകും.
ഇനി ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ
- നിങ്ങളുടെ സ്വന്തം ഡാറ്റയിൽ ഈ ഫീച്ചർ പരീക്ഷിച്ച് നോക്കുക: ഒരു സാധാരണ RAG ഫ്ലോയും query-aware compression ഉൾപ്പെടുത്തിയ ഫ്ലോയും തമ്മിൽ സൈഡ്-ബൈ-സൈഡ് ടെസ്റ്റ് നടത്തുക. ടോക്കൺ എണ്ണം, ലേറ്റൻസി (latency), ഉത്തരത്തിന്റെ പ്രസക്തി എന്നിവ അളക്കുക.
- വെണ്ടർ സുതാര്യത (Vendor transparency): തേർഡ് പാർട്ടി RAG പ്ലാറ്റ്‌ഫോമുകൾ വിലയിരുത്തുമ്പോൾ, അവരുടെ റിട്രീവൽ പൈപ്പ്‌ലൈനുകളിൽ കംപ്രഷനോ ഫിൽട്ടറിംഗോ ഉപയോഗിക്കുന്നുണ്ടോ എന്ന് ചോദിക്കുക. റോ (raw) ഡാറ്റ നേരിട്ട് അയക്കുന്ന വെണ്ടർമാർ ഉയർന്ന മാസ ബില്ലുകൾ നൽകാൻ സാധ്യതയുണ്ട്.
ചുരുക്കത്തിൽ
മോഡലിലേക്ക് എത്തുന്നതിന് മുമ്പ് പ്രസക്തമല്ലാത്ത ടെക്സ്റ്റ് ഒഴിവാക്കുന്ന പൈപ്പ്‌ലൈനിലെ ചെറിയൊരു മാറ്റം, മറഞ്ഞിരിക്കുന്ന ഒരു ചിലവിനെ നിയന്ത്രിക്കാവുന്ന ഒരു നിരക്കായി മാറ്റാൻ സഹായിക്കും. നിലവിൽ Bedrock അടിസ്ഥാനമാക്കിയുള്ള RAG ഉപയോഗിക്കുന്ന സ്ഥാപനങ്ങൾക്ക്, query-aware compression പ്രവർത്തനസജ്ജമാക്കുന്നത് കുറഞ്ഞ പരിശ്രമമുള്ള ഒരു പരീക്ഷണമാണ്; എന്നാൽ ഇതിലൂടെയുള്ള ലാഭം നിങ്ങളുടെ ഡാറ്റയുടെ സ്വഭാവത്തെ ആശ്രയിച്ചിരിക്കും.