നിങ്ങളുടെ AI ബില്ല് ഒരു മോഡലിന്റെ പ്രശ്നമല്ല. അത് ഒരു ആർക്കിടെക്ചറിന്റെ പ്രശ്നമാണ്.
നിങ്ങളുടെ LLM ചിലവ് വർദ്ധിച്ചുകൊണ്ടിരിക്കുകയാണെങ്കിൽ, നിങ്ങൾ ഒരുപക്ഷേ കുറഞ്ഞ ചിലവുള്ള മറ്റൊരു മോഡലിലേക്ക് മാറാൻ ആഗ്രഹിക്കുന്നുണ്ടാകാം. നിങ്ങൾ GPT-4-ൽ നിന്ന് GPT-4-mini-ലേക്ക് മാറിക്കൊണ്ടിരിക്കാം. ഇത് അല്പം സഹായിക്കുമെങ്കിലും, യഥാർത്ഥ പ്രശ്നം പരിഹരിക്കാൻ ഇത് അപൂർവ്വമായി മാത്രമേ സഹായിക്കൂ.
യഥാർത്ഥ പ്രശ്നം നിങ്ങളുടെ വർക്ക്ഫ്ലോ (workflow) ആണ്. മിക്ക ആളുകളും ഓരോ ഘട്ടവും ഒരു LLM വഴി തന്നെ നടത്താൻ ശ്രമിക്കുന്നു. ആവശ്യമില്ലാത്ത ജോലികൾക്കായി പോലും അവർ ലാംഗ്വേജ് റീസണിംഗ് (language reasoning) ഉപയോഗിക്കുന്നു.
ഓരോ AI വർക്ക്ഫ്ലോയ്ക്കും നാല് ഭാഗങ്ങളുണ്ട്:
• Trigger: ജോലി ആരംഭിക്കുന്നു. ഇതിന്റെ ചിലവ് പൂജ്യത്തിന് അടുത്താണ്. • Deterministic ML: ഡാറ്റയെ തരംതിരിക്കുകയോ സ്കോർ ചെയ്യുകയോ ചെയ്യുന്നു. ഇത് ചിലവ് കുറഞ്ഞതാണ്. • LLM: വായിക്കുന്നു, എഴുതുന്നു, ചിന്തിക്കുന്നു (reasons). ഇത് ചിലവേറിയതാണ്. • Tool/API: ഡാറ്റ ശേഖരിക്കുകയോ എഴുതുകയോ ചെയ്യുന്നു. ഇത് ചിലവ് കുറഞ്ഞതാണ്.
Deterministic ML-ഉം LLM-ഉം തമ്മിലുള്ള വ്യത്യാസം വളരെ വലുതാണ്. ഒരു സാധാരണ ക്ലാസിഫയറിനേക്കാൾ (classifier) 100 മുതൽ 1000 മടങ്ങ് വരെ ചിലവ് LLM-ന് വരാം. ഓരോ ഘട്ടത്തിനും ശരിയായ ടൂൾ തിരഞ്ഞെടുത്തില്ലെങ്കിൽ, നിങ്ങൾ അറിയാതെ തന്നെ ചിലവേറിയ മാർഗ്ഗമാണ് തിരഞ്ഞെടുക്കുന്നത്.
ഒരു സപ്പോർട്ട് ടിക്കറ്റ് സിസ്റ്റം പരിശോധിച്ചു നോക്കൂ.
മോശമായ രീതിയിൽ നിർമ്മിച്ച ഒരു സിസ്റ്റം മുഴുവൻ ടിക്കറ്റും ഒരു LLM-ലേക്ക് അയക്കുന്നു. ടിക്കറ്റിന്റെ ഉദ്ദേശ്യം (intent) തരംതിരിക്കാനും, ടിക്കറ്റ് റൂട്ട് ചെയ്യാനും, മറുപടി തയ്യാറാക്കാനും, CRM അപ്ഡേറ്റ് ചെയ്യാനും ഇത് LLM-നോട് ആവശ്യപ്പെടുന്നു. ഇത് അമിത ചിലവുള്ള രീതിയാണ്. തരംതിരിക്കാൻ (Classification) ഒരു LLM ആവശ്യമില്ല. ടെക്സ്റ്റിനെ ഒരു കാറ്റഗറിയിലേക്ക് മാറ്റാൻ ഒരു ലളിതമായ മോഡൽ മാത്രം മതിയാകും.
മികച്ച രീതിയിലുള്ള ഒരു നിർമ്മാണം ഇപ്രകാരമായിരിക്കും:
- Trigger: ഒരു ടിക്കറ്റ് വരുന്നു.
- Deterministic ML: ടിക്കറ്റ് ബില്ലിംഗ് സംബന്ധമായതാണോ, സാങ്കേതികമായതാണോ അതോ സ്പാം ആണോ എന്ന് ഒരു വേഗതയേറിയതും ചിലവ് കുറഞ്ഞതുമായ മോഡൽ തീരുമാനിക്കുന്നു.
- LLM: സാധുവായ ടിക്കറ്റുകൾക്ക് മറുപടി തയ്യാറാക്കാൻ മാത്രം ഉപയോഗിക്കുന്നു.
- Tool/API: സിസ്റ്റം CRM അപ്ഡേറ്റ് ചെയ്യുന്നു.
ഈ രീതിയിൽ, സ്പാം ടിക്കറ്റുകൾ ഒരിക്കലും LLM-ൽ എത്തില്ല. അനാവശ്യമായ ജോലികൾക്കായി നിങ്ങൾ "LLLLM ടാക്സ്" നൽകുന്നത് ഒഴിവാക്കാം.
നിങ്ങളുടെ ആർക്കിടെക്ചർ ശരിയായി ക്രമീകരിച്ചാൽ, മോഡലുകൾ മാറ്റുന്നതിന് മുമ്പ് തന്നെ ഏറ്റവും ചിലവേറിയ കോളുകൾ ഒഴിവാക്കാൻ നിങ്ങൾക്ക് സാധിക്കും.
ചിലവ് കുറയ്ക്കാൻ ഈ ഘട്ടങ്ങൾ പിന്തുടരുക:
- നിങ്ങളുടെ വർക്ക്ഫ്ലോ മാപ്പ് ചെയ്യുക. ഏത് ഘട്ടങ്ങൾക്കാണ് യഥാർത്ഥമായ റീസണിംഗ് വേണ്ടതെന്നും ഏതെല്ലാം ഘട്ടങ്ങളാണ് വെറും ക്ലാസിഫിക്കേഷനോ എക്സ്ട്രാക്ഷനോ (extraction) മാത്രമെന്നും തിരിച്ചറിയുക.
- Deterministic ഘട്ടങ്ങളെ പ്രോംപ്റ്റിൽ (prompt) നിന്ന് ഒഴിവാക്കുക. റൂട്ടിംഗിനും സ്കോറിംഗിനും വേഗതയേറിയതും ചിലവ് കുറഞ്ഞതുമായ രീതികൾ ഉപയോഗിക്കുക.
- LLM-നെ നിയന്ത്രിക്കുക (Gate the LLM). ആവശ്യമില്ലാത്ത ജോലികൾക്കായി മറുപടികൾ നിർമ്മിക്കരുത്.
- മോഡലിന്റെ വലിപ്പം അവസാനം മാത്രം വിലയിരുത്തുക. നിങ്ങളുടെ ആർക്കിടെക്ചർ ലളിതമാക്കിയതിന് ശേഷം മാത്രം ജനറേഷൻ ഘട്ടത്തിനായി ഒരു ചെറിയ മോഡൽ തിരഞ്ഞെടുക്കുക.
ഏത് മോഡലാണ് ഓരോ ടോക്കണിനും (token) ഏറ്റവും കുറഞ്ഞ ചിലവ് നൽകുന്നത് എന്നതിനെക്കുറിച്ച് തർക്കിക്കുന്നത് നിർത്തുക. ആവശ്യമുള്ളപ്പോൾ മാത്രം ചിലവേറിയ എൻജിൻ ഉപയോഗിക്കുന്ന രീതിയിലുള്ള ആർക്കിടെക്ചറുകൾ നിർമ്മിക്കാൻ തുടങ്ങുക.
Source: https://dev.to/bakshiyogesh/your-ai-bill-isnt-a-model-problem-its-an-architecture-problem-1ole
Optional learning community: https://t.me/GyaanSetuAi