AWS தனது Bedrock சேவையில் query-aware compression வசதியைச் சேர்த்துள்ளது, இது டெவலப்பர்கள் ஒரு மொழி மாதிரியை (language model) சென்றடைவதற்கு முன்பே தேவையற்ற ஆவணத் துண்டுகளை (document chunks) குறைக்க அனுமதிக்கிறது. மாதிரியால் கையாளப்படும் டோக்கன்களின் எண்ணிக்கையைக் குறைப்பதன் மூலம், இந்த அம்சம் Retrieval-Augmented Generation (RAG) pipelines-க்கான கணினிச் செலவைக் குறைக்க முடியும்.
RAG pipelines ஏன் அதிக செலவை ஏற்படுத்துகின்றன
RAG அமைப்புகள் முதலில் ஒரு knowledge base-லிருந்து உரைப்பகுதிகளைப் பெறுகின்றன, பின்னர் அந்தப் பகுதிகளை ஒரு generative model-க்கு பயனர் கேட்கும் கேள்விக்கு பதிலளிக்க வழங்குகின்றன. பெரும்பாலான அமலாக்கங்கள் (implementations), மீட்டெடுக்கப்பட்ட ஒவ்வொரு துண்டையும் நேரடியாக மாதிரியிடம் அனுப்புகின்றன, உரையின் பெரும்பகுதி வினவலுடன் எந்தத் தொடர்பும் இல்லாதபோது கூட இது நடக்கிறது. ஒவ்வொரு கூடுதல் சொல்லும் ஒரு டோக்கனாக மாறுகிறது, மேலும் மாதிரி செயலாக்கும் ஒவ்வொரு டோக்கனும் அடிப்படையான API கட்டணத்தை அதிகரிக்கிறது. ஆதரவு பாட்கள் (support bots) அல்லது உள் தேடல் கருவிகளை இயக்கும் சிறிய மற்றும் நடுத்தர நிறுவனங்களுக்கு, டோக்கன் செலவு மாதிரிக்கான அழைப்புகளின் (model calls) செலவை விட மிக வேகமாக அதிகரிக்கக்கூடும்.
query-aware compression என்ன செய்கிறது
புதிய Bedrock திறன், retrieval மற்றும் generation ஆகியவற்றுக்கு இடையில் ஒரு filtering step-ஐ இணைக்கிறது:
- வினவலுக்குத் தேவையான அதே ஆவணத் தொகுப்பை அமைப்பு இன்னும் பெறுகிறது.
- மாதிரி எந்த உரையையும் பார்ப்பதற்கு முன்பே, ஒரு lightweight processor ஒவ்வொரு பகுதியையும் குறிப்பிட்ட கேள்வியுடன் ஒப்பிட்டு மதிப்பீடு செய்கிறது.
- பொருத்தமானதாகக் கருதப்படும் பகுதிகள் மட்டுமே வைக்கப்படுகின்றன; மற்ற அனைத்தும் noise எனக் கருதப்பட்டு நீக்கப்படுகின்றன.
உங்களுக்குப் புதிய index, embedding model அல்லது fine-tuned language model தேவையில்லை. இந்த மாற்றம் என்பது வெறும் compression layer-ஐ அழைப்பதற்கான pipeline-ஐ மறுசீரமைப்பதே ஆகும்.
வணிகத் தாக்கம்
மாதிரியிடம் அனுப்பப்படும் உரையின் அளவு அதிகரிக்கும் போது token fees உயருவதால், தேவையற்ற துண்டுகளை நீக்குவது பில் தொகையை வரி வரியாகக் குறைக்க உதவும். பயன்பாடு அதிகரிக்கும் போது தங்கள் RAG செலவுகள் அதிகரிப்பதைப் பார்த்த நிறுவனங்கள் இதிலிருந்து மிகப்பெரிய பலனைப் பெறுவார்கள்.
அடுத்து கவனிக்க வேண்டியவை
- உங்கள் சொந்தத் தரவுகளில் இந்த அம்சத்தைச் சோதிக்கவும்: ஒரு நிலையான RAG flow-க்கும், query-aware compression உள்ள flow-க்கும் இடையே ஒரு ஒப்பீட்டுச் சோதனையைச் செய்யவும். Token count, latency மற்றும் பதிலின் பொருத்தத்தன்மை ஆகியவற்றை அளவிடவும்.
- விற்பனையாளர் வெளிப்படைத்தன்மை: மூன்றாம் தரப்பு RAG தளங்களை மதிப்பீடு செய்யும் போது, அவர்கள் தங்கள் retrieval pipelines-ல் compression அல்லது filtering முறையைப் பயன்படுத்துகிறார்களா என்று கேளுங்கள். Raw chunks-களை அப்படியே அனுப்பும் ஒரு விற்பனையாளர் அதிக மாதாந்திர இன்வாய்ஸ்களை (invoices) உருவாக்கக்கூடும்.
இறுதி முடிவு
ஒரு சிறிய pipeline மாற்றம்—மாதிரியைச் சென்றடைவதற்கு முன்பே தேவையற்ற உரையை வடிகட்டுவது—மறைமுகச் செலவை ஒரு கட்டுப்படுத்தக்கூடிய செலவுப் பட்டியலாக மாற்றும். ஏற்கனவே Bedrock அடிப்படையிலான RAG-க்காகப் பணம் செலுத்தும் நிறுவனங்களுக்கு, query-aware compression-ஐச் செயல்படுத்துவது குறைந்த முயற்சியுடன் கூடிய ஒரு பரிசோதனையாகும், ஆனால் சேமிப்பு என்பது உங்கள் குறிப்பிட்ட தரவைப் பொறுத்தே அமையும்.