ভূমিকা এই নিবন্ধটি আপনাকে শেখাবে কীভাবে ভয়ঙ্কর "ওপেনএআই রেট লিমিট" ব্যতিক্রমের শিকার না হয়ে যেকোনো এলএলএম মডেল ব্যবহার করে মূল্যায়ন চালাতে হয়। আমরা এর দ্বারা শুরু করব: হার-সীমা বলতে কী বোঝায় এবং একটি উপমা ব্যবহার করে তা নির্ধারণ করা OpenAI হার-সীমা কি তা বোঝা রেট-লিমিট প্রক্রিয়া কীভাবে তৈরি হয়েছিল তা ব্যাখ্যা করা কোড বাস্তবায়ন ব্যাখ্যা কোড বাস্তবায়নে ব্যবহৃত কৌশলটির সারসংক্ষেপ হার-সীমাবদ্ধকরণ (এবং সাদৃশ্য ব্যাখ্যা) কি? এখন পর্যন্ত, ক্লাউডফ্লেয়ার ব্যাখ্যাটি আমার দেখা সেরা: নেটওয়ার্ক ট্র্যাফিক সীমিত করার জন্য হার-সীমাবদ্ধকরণ একটি কৌশল। এটি একটি নির্দিষ্ট সময়-ফ্রেমের মধ্যে কতবার কেউ একটি ক্রিয়া পুনরাবৃত্তি করতে পারে তার উপর একটি ক্যাপ রাখে - উদাহরণস্বরূপ, একটি অ্যাকাউন্টে লগ ইন করার চেষ্টা করা। সহজ কথায় বলতে গেলে, চারটি বাচ্চার মা হওয়ার কথা কল্পনা করুন যারা সবাই মধু ভালোবাসে। গতবার, মধু প্রত্যাশার চেয়ে তাড়াতাড়ি ফুরিয়ে গিয়েছিল। এখন, আপনি দশ হাজার পর্যন্ত গণনা করার জন্য একটি টাইমার সেট করেছেন এবং প্রতিটি শিশুকে কিছু মধু খাওয়ার পালা দিয়েছেন। টাইমারটি হার-সীমাকে প্রতিনিধিত্ব করে, কারণ এটি আরও মধু পাওয়ার আগে একটি নির্দিষ্ট অপেক্ষার সময় প্রয়োগ করে। ধারণাটি ব্যাখ্যা করার পর, আসুন OpenAI রেট-লিমিট বুঝতে পারি এবং পাইথন ব্যবহার করে OpenAI এর R/TPM (প্রতি মিনিটে অনুরোধ/টোকেন) পরিচালনা করার জন্য আমি কীভাবে একটি রেট-সীমা যুক্তি প্রয়োগ করেছি তা নিয়ে আলোচনা করি। OpenAI হারের সীমা বোঝা ওপেনএআই তার AI মডেলগুলির জন্য এক মিনিটের মধ্যে অনুরোধের সংখ্যার উপর নির্দিষ্ট সীমাবদ্ধতা নির্ধারণ করেছে। OpenAI দ্বারা প্রদত্ত প্রতিটি AI মডেলের জন্য এই সীমাবদ্ধতাগুলি আলাদা। বিনামূল্যে সংস্করণের জন্য: gpt-3.5-টার্বো মডেলের জন্য, ব্যবহারকারীরা প্রতিদিন 40,000 টোকেন অনুরোধ বা প্রতি মিনিটে 3টি API কল করতে পারে। স্তর 1 এর জন্য: gpt-3.5-টার্বো মডেলের জন্য, ব্যবহারকারীদের প্রতি মিনিটে 60,000 টোকেন অনুরোধ বা 3,500 API কল করার অনুমতি দেওয়া হয়। gpt-4 মডেলের জন্য, সীমা হল 10,000 টোকেন অনুরোধ বা প্রতি মিনিটে 500 API কল। gpt-4-turbo-preview-এর জন্য, ব্যবহারকারীরা প্রতি মিনিটে 150,000 টোকেন অনুরোধ বা 500 API কল করতে পারে। gpt-4-ভিশন-প্রিভিউ-এর জন্য, ব্যবহারকারীরা প্রতি মিনিটে 10,000 টোকেন অনুরোধ এবং/অথবা 500টি API কল করতে পারে। অন্যান্য স্তরের হার-সীমা সম্পর্কে আরও তথ্যের জন্য দেখুন.. ডক্স এই বিধিনিষেধের কারণগুলির মধ্যে রয়েছে: পরিষেবাগুলি সুচারুভাবে এবং প্রতিক্রিয়াশীলভাবে চালানো নিশ্চিত করা, কারণ AI মডেলগুলি দ্বারা সম্পাদিত জটিল কাজগুলির জন্য যথেষ্ট সংস্থান প্রয়োজন৷ সমস্ত ব্যবহারকারীর চাহিদা পরিচালনা করা এবং নিশ্চিত করা যে উপলব্ধ পরিকাঠামো, যেমন তাদের সার্ভার এবং GPU, ওভারলোড না হয়ে অনুরোধগুলি পরিচালনা করতে পারে। ব্যবহার বৃদ্ধির জন্য প্রস্তুতি এবং উচ্চ চাহিদার অধীনে দক্ষ অপারেশন বজায় রাখা। এই সীমাবদ্ধতাগুলি অদূর ভবিষ্যতের জন্য সামঞ্জস্যপূর্ণ থাকবে বলে আশা করা হচ্ছে। হার-সীমা প্রক্রিয়া ব্যাখ্যা করা প্রক্রিয়াটি (নীচের চিত্রটি দেখুন) ব্যবহারকারীদের UI থেকে LLM মূল্যায়ন চালাতে সক্ষম করে এবং তাদের LLM অ্যাপগুলির জন্য রেট-লিমিট প্যারামিটারগুলি কনফিগার করে নিজেদের যুক্তি লেখার প্রয়োজন ছাড়াই জড়িত৷ এটি একটি ফাংশনের মাধ্যমে অর্জন করা হয় যা ব্যাচকে প্রস্তুত করে এবং আহ্বান করে। ব্যাচের প্রতিটি কল ফাংশনকে আহ্বান করে, যা পুনরায় চেষ্টা করার পদ্ধতির সাথে চূড়ান্ত ফাংশন ( ) আহ্বান করে। run_with_retry invoke_app আমি নিশ্চিত যে আপনি উপরের প্রক্রিয়াটি দেখার পরে আপনার পছন্দের যেকোনো ভাষায় কোড-লজিক লিখতে পারেন। যাই হোক না কেন, আমি আপনাকে দেখাব কিভাবে আমি আমার কাজ করেছি। আরও পটভূমি এবং প্রসঙ্গের জন্য, আমি প্রাথমিকভাবে Agenta এ ব্যাকএন্ড সফ্টওয়্যার ইঞ্জিনিয়ার হিসাবে কাজ করি। হল একটি ওপেন সোর্স এন্ড-টু-এন্ড LLM ডেভেলপার প্ল্যাটফর্ম যা আপনাকে প্রম্পট ইঞ্জিনিয়ারিং এবং ম্যানেজমেন্ট, ⚖️ মূল্যায়ন, হিউম্যান অ্যানোটেশন এবং 🚀 স্থাপনার জন্য টুল সরবরাহ করে। ফ্রেমওয়ার্ক, লাইব্রেরি বা মডেলের আপনার পছন্দের উপর কোনো বিধিনিষেধ আরোপ না করেই। ডেভেলপার এবং প্রোডাক্ট টিমকে কম সময়ে প্রোডাকশন-গ্রেড LLM-চালিত অ্যাপ্লিকেশন তৈরিতে সহযোগিতা করার অনুমতি দেয়। Agenta Agenta আমরা ব্যবহারকারীদের UI থেকে তাদের LLM মূল্যায়নের হার-সীমিত কনফিগারেশন কনফিগার করার ক্ষমতা দিতে চেয়েছিলাম যাতে তারা তাদের LLM প্রদানকারীর হার-সীমিত ব্যতিক্রমকে বাইপাস করতে পারে। প্রসেস ডায়াগ্রামের দিকে তাকালে, ব্যাচের (এলএলএম কলগুলির) প্রস্তুতি এবং আহ্বান করার জন্য প্রথম জিনিসটি প্রয়োগ করা হবে। হার সীমা কনফিগারেশন যাচাই করা এবং LLM রান রেট সীমা নির্ধারণ করতে একটি ডেটা বৈধতা মডেল ব্যবহার করা গুরুত্বপূর্ণ। নিচের মডেলটি ব্যাচ ইনভোক ফাংশনের জন্য প্রয়োজনীয় প্যারামিটার পরিচালনা করে। rate_limit_config from pydantic import BaseModel, Field class LLMRunRateLimit(BaseModel): batch_size: int = Field(default=10) max_retries: int = Field(default=3) retry_delay: int = Field(default=3) delay_between_batches: int = Field(default=5) ফাংশন নিম্নলিখিত পরামিতি গ্রহণ করে: batch_invoke uri: আপনার LLM আবেদনের URL। testset_data: টেস্টসেট ডেটা যা আপনার LLM অ্যাপ্লিকেশনকে প্রক্রিয়া করতে হবে। পরামিতি: আপনার LLM আবেদনের পরামিতি। rate_limit_config: হার সীমা কনফিগারেশন (নতুন মূল্যায়ন তৈরি করতে উপরের ইন্টারফেসে দেখা গেছে)। async def batch_invoke( uri: str, testset_data: List[Dict], parameters: Dict, rate_limit_config: Dict ) -> List[AppOutput]: """ Invokes the LLm app in batches, processing the testset data. Args: uri (str): The URI of the LLm app. testset_data (List[Dict]): The testset data to be processed. parameters (Dict): The parameters for the LLm app. rate_limit_config (Dict): The rate limit configuration. Returns: List[AppOutput]: The list of app outputs after running all batches. """ batch_size = rate_limit_config[ "batch_size" ] # Number of testset to make in each batch max_retries = rate_limit_config[ "max_retries" ] # Maximum number of times to retry the failed llm call retry_delay = rate_limit_config[ "retry_delay" ] # Delay before retrying the failed llm call (in seconds) delay_between_batches = rate_limit_config[ "delay_between_batches" ] # Delay between batches (in seconds) list_of_app_outputs: List[AppOutput] = [] # Outputs after running all batches openapi_parameters = await get_parameters_from_openapi(uri + "/openapi.json") async def run_batch(start_idx: int): print(f"Preparing {start_idx} batch...") end_idx = min(start_idx + batch_size, len(testset_data)) for index in range(start_idx, end_idx): try: batch_output: AppOutput = await run_with_retry( uri, testset_data[index], parameters, max_retries, retry_delay, openapi_parameters, ) list_of_app_outputs.append(batch_output) print(f"Adding outputs to batch {start_idx}") except Exception as exc: import traceback traceback.print_exc() print( f"Error processing batch[{start_idx}]:[{end_idx}] ==> {str(exc)}" ) # Schedule the next batch with a delay next_batch_start_idx = end_idx if next_batch_start_idx < len(testset_data): await asyncio.sleep(delay_between_batches) await run_batch(next_batch_start_idx) # Start the first batch await run_batch(0) return list_of_app_outputs ব্যাচ প্রস্তুত এবং আহ্বান করার পরে, পরবর্তী ধাপে লজিক কার্যকর করা জড়িত। এই কাস্টম বাস্তবায়নে হার-সীমিত কার্যকারিতা রয়েছে এবং সেট বিলম্বে পৌঁছানোর পরে পুনরায় চেষ্টা করে llm অ্যাপের আহ্বান পরিচালনা করে। এক্সপোনেনশিয়াল ব্যাকঅফ, এমন একটি কৌশল যা দ্রুতগতিতে বর্ধিত অপেক্ষার সময় সহ একটি অপারেশন পুনরায় চেষ্টা করে, সর্বোচ্চ পুনঃপ্রচেষ্টা গণনা না হওয়া পর্যন্ত ব্যবহার করা হয়। run_with_retry async def run_with_retry( uri: str, input_data: Any, parameters: Dict, max_retry_count: int, retry_delay: int, openapi_parameters: List[Dict], ) -> AppOutput: """ Runs the specified app with retry mechanism. Args: uri (str): The URI of the app. input_data (Any): The input data for the app. parameters (Dict): The parameters for the app. max_retry_count (int): The maximum number of retries. retry_delay (int): The delay between retries in seconds. openapi_parameters (List[Dict]): The OpenAPI parameters for the app. Returns: AppOutput: The output of the app. """ retries = 0 last_exception = None while retries < max_retry_count: try: result = await invoke_app(uri, input_data, parameters, openapi_parameters) return result except (httpx.TimeoutException, httpx.ConnectTimeout, httpx.ConnectError) as e: last_exception = e print(f"Error in evaluation. Retrying in {retry_delay} seconds:", e) await asyncio.sleep(retry_delay) retries += 1 # If max retries reached, return the last exception return AppOutput(output=None, status=str(last_exception)) ব্যবহার: এটি তার সর্বাধিক পুনঃপ্রচারগুলি ব্যবহার করার পরেও একটি ব্যতিক্রম পরিচালনা করা গুরুত্বপূর্ণ। এইভাবে, আপনি যে সমস্ত ডেটা প্রক্রিয়া করার চেষ্টা করছেন তা চালানোর অনুমতি দেন এবং তারপর আপনি নির্ধারণ করতে পারেন কী ব্যর্থ হয়েছে এবং কী পাস হয়েছে। অ্যাপআউটপুট একটি একক ডেটাপয়েন্টের সাহায্যে কীভাবে এটি চালু করা যায় তা নির্ধারণ করতে LLM অ্যাপের ব্যবহার করে চূড়ান্ত ধাপে অ্যাপটি চালু করা হচ্ছে। openapi_parameters make_payload ফাংশন আপনার উদ্বেগ করা উচিত নয়. এটি তার প্যারামিটারের উপর ভিত্তি করে LLM অ্যাপ চালু করার জন্য পেলোড তৈরি করে। OpenAPI async def invoke_app( uri: str, datapoint: Any, parameters: Dict, openapi_parameters: List[Dict] ) -> AppOutput: """ Invokes an app for one datapoint using the openapi_parameters to determine how to invoke the app. Args: uri (str): The URI of the app to invoke. datapoint (Any): The data to be sent to the app. parameters (Dict): The parameters required by the app taken from the db. openapi_parameters (List[Dict]): The OpenAPI parameters of the app. Returns: AppOutput: The output of the app. Raises: httpx.HTTPError: If the POST request fails. """ url = f"{uri}/generate" payload = await make_payload(datapoint, parameters, openapi_parameters) async with httpx.AsyncClient() as client: try: logger.debug(f"Invoking app {uri} with payload {payload}") response = await client.post( url, json=payload, timeout=httpx.Timeout(timeout=5, read=None, write=5) ) response.raise_for_status() llm_app_response = response.json() app_output = ( llm_app_response["message"] if isinstance(llm_app_response, dict) else llm_app_response ) return AppOutput(output=app_output, status="success") except: return AppOutput(output="Error", status="error") এবং যে প্রক্রিয়া বৃত্তাকার আপ. সারসংক্ষেপ কোডে ব্যাকঅফ সূচকীয় কৌশলটি নিম্নরূপ কাজ করে: batch_invoke ফাংশন টেস্টসেট ডেটাকে একটি কনফিগারযোগ্য আকারের সাথে ছোট ব্যাচে বিভক্ত করে। প্রতিটি ব্যাচ ক্রমানুসারে প্রক্রিয়া করা হয়। ব্যাচ প্রসেসিং: প্রতিটি ব্যাচের মধ্যে, প্রতিটি ডেটা পয়েন্ট ফাংশন দ্বারা প্রক্রিয়া করা হয়। এই ফাংশনটি ডেটা পয়েন্টের জন্য অ্যাপটিকে আহ্বান করার চেষ্টা করে। নির্দিষ্ট নেটওয়ার্ক ত্রুটির (টাইমআউট, সংযোগ সমস্যা) কারণে আহ্বান ব্যর্থ হলে, ফাংশনটি বিলম্বের সাথে পুনরায় চেষ্টা করে। এই বিলম্বটি প্রাথমিকভাবে একটি কনফিগারযোগ্য মান ( ) এ সেট করা হয়েছে এবং একই ব্যাচের মধ্যে প্রতিটি পরবর্তী পুনঃপ্রয়াসের জন্য দ্বিগুণ করা হয়েছে। পুনঃপ্রচারের সাথে স্বতন্ত্র আমন্ত্রণ: run_with_retry retry_delay এই পদ্ধতিটি ব্যর্থতার পরে বারবার অনুরোধের সাথে অ্যাপ সার্ভারকে ওভারলোড করা এড়াতে সহায়তা করে। এটি সার্ভারকে পুনরুদ্ধার করার সময় দেয় এবং পুনরায় চেষ্টা করার আগে মুলতুবি থাকা অনুরোধের সারি সাফ করার অনুমতি দেয়। কৌশলটিতে অসীম লুপ প্রতিরোধ করার জন্য প্রতি ডেটা পয়েন্টে একটি কনফিগারযোগ্য সর্বাধিক সংখ্যক পুনঃপ্রচার অন্তর্ভুক্ত রয়েছে। অ্যাপ সার্ভার দ্বারা নির্ধারিত হারের সীমা অতিক্রম এড়াতে ব্যাচগুলির মধ্যে একটি বিলম্ব ( ) অন্তর্ভুক্ত করা হয়েছে৷ delay_between_batches আমি আশা করি এটি আজকের নিবন্ধে আপনি যা শিখেছেন তার সমস্ত কিছুর সংক্ষিপ্তসার। আপনার কোনো প্রশ্ন থাকলে আমাকে জানান!
