Amazon Bedrock ഇപ്പോൾ ഡെവലപ്പർമാർക്ക് പ്രോംപ്റ്റുകളുടെ ഭാഗങ്ങൾ കാഷെ (cache) ചെയ്യാൻ അനുവദിക്കുന്നു. ഇത് സ്റ്റാറ്റിക് പ്രോംപ്റ്റ് പ്രിഫിക്സ് (static prompt prefix) വീണ്ടും ഉപയോഗിക്കുന്ന ആപ്ലിക്കേഷനുകളിൽ ടോക്കൺ ഉപയോഗത്തിനുള്ള ബില്ലുകൾ 90% വരെ കുറയ്ക്കാനും റെസ്‌പോൺസ് ലേറ്റൻസി (response latency) 85% വരെ കുറയ്ക്കാനും സഹായിക്കുന്നു.

ഈ മാറ്റം പ്രധാനമാകുന്നത് എന്തുകൊണ്ട്

ഓൺ ഡിമാൻഡ് ലാർജ് ലാംഗ്വേജ് മോഡലുകൾ (large language models) പ്രവർത്തിപ്പിക്കുമ്പോൾ ഓരോ തവണ ടോക്കണുകൾ മോഡലിലേക്ക് അയക്കുമ്പോഴും പണം ചിലവാകുന്നു. ചാറ്റ്‌ബോട്ടുകൾ, കോഡ് അസിസ്റ്റന്റുകൾ, ഡോക്യുമെന്റ് സെർച്ച് ടൂളുകൾ എന്നിവ പലപ്പോഴും ഒരേ സിസ്റ്റം ഇൻസ്ട്രക്ഷൻസോ (system instructions) റഫറൻസ് മെറ്റീരിയലുകളോ വീണ്ടും അയക്കാറുണ്ട്, ഇത് ചിലവ് വർദ്ധിപ്പിക്കുകയും റെസ്‌പോൺസ് വേഗത കുറയ്ക്കുകയും ചെയ്യുന്നു.

പ്രോംപ്റ്റ് കാഷിംഗ് എങ്ങനെ പ്രവർത്തിക്കുന്നു

ഡെവലപ്പർമാർക്ക് പ്രോംപ്റ്റിന്റെ ഏതെങ്കിലും ഭാഗത്ത്—സാധാരണയായി സിസ്റ്റം ലെവൽ ഇൻസ്ട്രക്ഷനുകൾ, ദൈർഘ്യമേറിയ ബാക്ക്ഗ്രൗണ്ട് ഡോക്യുമെന്റുകൾ, അല്ലെങ്കിൽ ഒരു സെഷൻ സമയത്ത് മാറാത്ത ടൂൾ ഡെഫനിഷനുകൾ എന്നിവയിൽ—ചേർക്കാൻ സാധിക്കുന്ന ഒരു “cacheable” ഫ്ലാഗ് Bedrock ഉൾപ്പെടുത്തിയിട്ടുണ്ട്. ഒരു റിക്വസ്റ്റ് വരുമ്പോൾ, ഫ്ലാഗ് ചെയ്ത ഭാഗം നേരത്തെ സേവ് ചെയ്ത എൻട്രിയുമായി പൊരുത്തപ്പെടുന്നുണ്ടോ എന്ന് Bedrock പരിശോധിക്കുന്നു. അങ്ങനെയാണെങ്കിൽ, ആ ഭാഗം വീണ്ടും എൻകോഡ് ചെയ്യുന്നതും മോഡലിലൂടെ റൺ ചെയ്യുന്നതും ഒഴിവാക്കി, കാഷെയിൽ നിന്ന് നേരത്തെ തയ്യാറാക്കിയ റെപ്രസന്റേഷൻ (representation) സർവീസ് എടുക്കുന്നു.

കണക്കുകൾ

  • ഇൻപുട്ട്-ടോക്കൺ ചിലവ്: കാഷെ ചെയ്ത പ്രിഫിക്സ് ഓരോ തവണ വിളിക്കുമ്പോഴും ടോക്കണുകൾ ഉപയോഗിക്കാത്തതിനാൽ 90% വരെ കുറവ് ലഭിക്കുന്നു.
  • ലേറ്റൻസി (Latency): സ്റ്റാറ്റിക് ആയ ഭാഗത്തിന് മോഡലിന്റെ കഠിനമായ പ്രക്രിയകൾ ഒഴിവാക്കുന്നതിനാൽ 85% വരെ വേഗത വർദ്ധിക്കുന്നു.

ഏറ്റവും അനുയോജ്യമായ സാഹചര്യങ്ങൾ

പ്രോംപ്റ്റിൽ മാറ്റമില്ലാത്ത ഒരു വലിയ ഭാഗവും അതിനുശേഷം മാറിക്കൊണ്ടിരിക്കുന്ന ചെറിയൊരു യൂസർ ക്വറിയും വരുമ്പോഴാണ് ഈ ഫീച്ചർ കൂടുതൽ ഫലപ്രദമാകുന്നത്. സാധാരണയായി കാണപ്പെടുന്ന രീതികൾ ഇവയാണ്:

  • ഓരോ ക്വറിക്കും ഒരു ഡോക്യുമെന്റ് മുൻകൂട്ടി ചേർക്കുന്ന Retrieval-augmented generation (RAG) പൈപ്പ്‌ലൈനുകൾ.
  • ഒരേ പോളിസി സ്റ്റേറ്റ്‌മെന്റോടോ (policy statement) ടോൺ സെറ്റിംഗ് ടെക്സ്റ്റോടോ എപ്പോഴും തുടങ്ങുന്ന കസ്റ്റമർ സപ്പോർട്ട് ബോട്ടുകൾ.
  • ഡെവലപ്പറുടെ കോഡ് സ്നിപ്പറ്റിന് (snippet) മുൻപായി ഒരു നിശ്ചിത ലാംഗ്വേജ്-ടൂൾ ഡെഫനിഷൻ ലോഡ് ചെയ്യുന്ന കോഡിംഗ് അസിസ്റ്റന്റുകൾ.

ഡെവലപ്പർമാർ എന്ത് മാറ്റമാണ് വരുത്തേണ്ടത്

സ്റ്റാറ്റിക് ആയ ഉള്ളടക്കം പ്രോംപ്റ്റിന്റെ തുടക്കത്തിൽ തന്നെ വരാനും ഓരോ തവണയും അത് മാറ്റമില്ലാതെ (byte-for-byte identical) നിലനിൽക്കാനും ഡെവലപ്പർമാർ പ്രോംപ്റ്റ് ക്രമീകരിക്കേണ്ടതുണ്ട്. കാഷെ ചെയ്ത പ്രിഫിക്സിന് ശേഷം മാറിക്കൊണ്ടിരിക്കുന്ന യൂസർ ഇൻപുട്ട് വരണം. ഇതിനായി മോഡൽ മാറ്റേണ്ടതില്ല; നിലവിലുള്ള Bedrock എൻഡ്‌പോയിന്റുകൾ തന്നെ റിക്വസ്റ്റ് കൈകാര്യം ചെയ്യും.

ആർക്കാണ് ഗുണം, ആര് ശ്രദ്ധിക്കണം

പ്രിഫിക്സ് യഥാർത്ഥത്തിൽ സ്റ്റാറ്റിക് ആയി തുടരുന്ന വർക്ക്‌ലോഡുകൾക്ക് മാത്രമേ ഇതിന്റെ ഗുണം ലഭിക്കൂ. ഓരോ യൂസർക്കും അനുസരിച്ച് സിസ്റ്റം ഇൻസ്ട്രക്ഷനുകൾ വ്യക്തിഗതമാക്കുന്നതോ അല്ലെങ്കിൽ കോൺടെക്സ്റ്റ് (context) ഇടയ്ക്കിടെ മാറ്റുന്നതോ ആയ ആപ്ലിക്കേഷനുകൾക്ക് ഇതിൽ നിന്ന് വലിയ പ്രയോജനം ലഭിക്കില്ല. അതിനാൽ, പ്രോംപ്റ്റിംഗിലെ സങ്കീർണ്ണതയും ലഭിക്കുന്ന നേട്ടവും തമ്മിൽ താരതമ്യം ചെയ്യേണ്ടതുണ്ട്.

ചുരുക്കത്തിൽ: ആപ്ലിക്കേഷനുകൾക്ക് വീണ്ടും ഉപയോഗിക്കാവുന്ന ഒരു പ്രോംപ്റ്റ് പ്രിഫിക്സ് വേർതിരിക്കാൻ കഴിയുമെങ്കിൽ, AI പ്രവർത്തനച്ചെലവ് കുറയ്ക്കാനും റെസ്‌പോൺസ് സമയം മെച്ചപ്പെടുത്താനും പ്രോംപ്റ്റ് കാഷിംഗ് Bedrock ഉപയോക്താക്കൾക്ക് എളുപ്പവഴിയൊരുക്കുന്നു.