giriiş Bu makale size, korkunç "OpenAI Hız Sınırı" istisnasına boyun eğmeden herhangi bir LLM modelini kullanarak değerlendirmeleri nasıl çalıştıracağınızı öğretecektir. Şununla başlayabiliriz: Hız sınırının ne anlama geldiğini tanımlama ve bir benzetme kullanma OpenAI hız sınırlarının ne olduğunu anlamak Oran-Limit Sürecinin nasıl geliştirildiğini açıklamak Kuralların Uygulanmasının Açıklanması Kuralların Uygulanmasında kullanılan stratejinin özetlenmesi Hız sınırlama (ve Analoji açıklaması) nedir? Şu ana kadar Cloudflare açıklaması gördüğüm en iyisi: Hız sınırlama, ağ trafiğini sınırlamaya yönelik bir stratejidir. Bir kişinin belirli bir zaman dilimi içinde bir işlemi ne sıklıkta tekrarlayabileceğine (örneğin, bir hesaba giriş yapmaya çalışmak) bir sınır koyar. Basitçe söylemek gerekirse, balı seven dört çocuk annesi olduğunuzu hayal edin. Geçen sefer bal beklenenden daha erken tükendi. Şimdi, on bine kadar sayacak bir zamanlayıcı ayarladınız ve her çocuğa biraz bal alma sırası verdiniz. Zamanlayıcı, daha fazla bal alabilmeleri için belirli bir bekleme süresini zorunlu kıldığından oran sınırını temsil eder. Konsepti açıkladıktan sonra, OpenAI hız sınırlarını anlayalım ve Python kullanarak OpenAI'nin R/TPM'sini (dakika başına istek/jeton) yönetmek için bir hız sınırı mantığını nasıl uyguladığımı tartışalım. OpenAI Hız Limitlerini Anlamak OpenAI, bir kişinin AI modelleri için bir dakika içinde yapabileceği istek sayısına belirli kısıtlamalar getirmiştir. Bu sınırlamalar OpenAI tarafından sağlanan her yapay zeka modeli için farklıdır. Ücretsiz sürüm için: gpt-3.5-turbo modeli için kullanıcılar günde 40.000 token isteği veya dakikada 3 API çağrısı yapabilir. 1. seviye için: gpt-3.5-turbo modeli için kullanıcılara dakikada 60.000 jeton isteğine veya 3.500 API çağrısına izin verilir. gpt-4 modeli için sınır, dakikada 10.000 jeton isteği veya 500 API çağrısıdır. gpt-4-turbo-preview için kullanıcılar dakikada 150.000 jeton isteği veya 500 API çağrısı yapabilir. gpt-4-vision-preview için kullanıcılar dakikada 10.000 jeton isteği ve/veya 500 API çağrısı yapabilir. Diğer katmanların hız sınırları hakkında daha fazla bilgi için bakın. dokümanlara Bu kısıtlamaların nedeni şunları içerir: Yapay zeka modellerinin gerçekleştirdiği karmaşık görevler önemli miktarda kaynak gerektirdiğinden, hizmetlerin sorunsuz ve hızlı bir şekilde çalışmasını sağlamak. Tüm kullanıcılardaki talebi yönetmek ve sunucuları ve GPU'lar gibi mevcut altyapının istekleri aşırı yüklenmeden karşılayabildiğinden emin olmak. Kullanımdaki dalgalanmalara hazırlıklı olmak ve yüksek talep altında verimli çalışmayı sürdürmek. Bu sınırlamaların öngörülebilir gelecekte de tutarlı kalması beklenmektedir. Hız Limiti Sürecinin Açıklanması Süreç (aşağıdaki resme bakın), kullanıcıların kullanıcı arayüzünden LLM değerlendirmelerini çalıştırmalarına ve mantığı kendileri yazmaya gerek kalmadan LLM uygulamaları için hız sınırı parametrelerini yapılandırmalarına olanak sağlamayı içerir. Bu, partiyi hazırlayan ve çağıran bir fonksiyon aracılığıyla gerçekleştirilir. Gruptaki her çağrı, işlevini çağırır ve bu da, yeniden deneme mekanizmasıyla son işlevi ( ) çağırır. run_with_retry invoke_app Yukarıdaki işlemleri inceledikten sonra kod mantığını istediğiniz dilde yazabileceğinize eminim. Ne olursa olsun, sana benimkini nasıl yaptığımı göstereceğim. Daha fazla arka plan ve bağlam için öncelikle Agenta'da arka uç yazılım mühendisi olarak çalışıyorum. size hızlı mühendislik ve yönetim, ⚖️ değerlendirme, insan açıklamaları ve 🚀 konuşlandırma için araçlar sağlayan, açık kaynaklı, uçtan uca bir LLM geliştirici platformudur. Üstelik seçtiğiniz çerçeve, kitaplık veya modele herhangi bir kısıtlama getirilmeden. , geliştiricilerin ve ürün ekiplerinin üretim düzeyinde LLM destekli uygulamaları daha kısa sürede oluşturma konusunda işbirliği yapmasına olanak tanır. Agenta, Agenta Kullanıcılara LLM değerlendirmelerinin hız sınırlayıcı yapılandırmasını kullanıcı arayüzünden yapılandırma yeteneği vermek istedik, böylece LLM sağlayıcı hız sınırlayıcı istisnalarını atlayabilirler. Süreç diyagramına bakıldığında, uygulanacak ilk şey, partiyi (LLM çağrılarının) hazırlama ve çağırma mantığıdır. Hız sınırı konfigürasyonunun doğrulanması ve LLM çalışma hızı sınırını tanımlamak için bir veri doğrulama modelinin kullanılması önemlidir. Aşağıdaki model, toplu çağrının çalışması için gereken parametresini işler. 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) işlevi aşağıdaki parametreleri alır: batch_invoke uri: Yüksek Lisans başvurunuzun URL'si. testset_data: LLM uygulamanızın işlemesi gereken test seti verileri. parametreler: Yüksek Lisans başvurunuzun parametreleri. Rate_limit_config: Hız sınırı yapılandırması (yeni değerlendirme oluşturmak için yukarıdaki arayüzde görüldüğü gibi). 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 Grubu hazırlayıp çağırdıktan sonraki adım, mantığının yürütülmesini içerir. Bu özel uygulama, hız sınırlama işlevini içerir ve belirlenen gecikmeye ulaşıldıktan sonra yeniden deneyerek llm uygulamasının çağrılmasını yönetir. Üstel olarak artan bekleme süresiyle bir işlemi yeniden deneyen bir teknik olan üstel geri çekilme, maksimum yeniden deneme sayısına ulaşılana kadar kullanılır. 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)) Kullanımı: Maksimum yeniden deneme sayısını kullandıktan sonra bile bir istisnayı ele almak önemlidir. Bu şekilde, işlemeye çalıştığınız tüm verilerin çalıştırılmasına izin verirsiniz ve ardından neyin başarısız olduğunu ve neyin geçtiğini belirleyebilirsiniz. AppOutput'un Son adım, uygulamanın tek bir veri noktasıyla nasıl çağrılacağını belirlemek için LLM uygulamasının kullanarak uygulamayı çağırmaktır. openapi_parameters make_payload işlevi sizi ilgilendirmiyor. parametrelerine göre LLM uygulamasını çağırmak için yükü oluşturur. 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") Bu da süreci tamamlıyor. Özet Koddaki geri çekilme üstel stratejisi şu şekilde çalışır: Batch_invoke işlevi, test seti verilerini yapılandırılabilir boyutta daha küçük gruplara böler. Her parti sırayla işlenir. Toplu İşleme: Her toplu iş içinde, her veri noktası işlevi tarafından işlenir. Bu işlev, veri noktası için uygulamayı çağırmaya çalışır. Belirli ağ hataları (zaman aşımları, bağlantı sorunları) nedeniyle çağırma başarısız olursa, işlev bir gecikmeyle yeniden dener. Bu gecikme başlangıçta yapılandırılabilir bir değere ( ) ayarlanır ve aynı toplu iş içindeki sonraki her yeniden deneme girişiminde ikiye katlanır. Yeniden Deneme ile Bireysel Çağrılar: run_with_retry retry_delay Bu yaklaşım, bir arıza sonrasında uygulama sunucusunun tekrarlanan isteklerle aşırı yüklenmesini önlemeye yardımcı olur. Sunucuya kurtarması için zaman verir ve yeniden denemeden önce bekleyen istekler sırasının temizlenmesine olanak tanır. Strateji ayrıca sonsuz döngüleri önlemek için veri noktası başına yapılandırılabilir maksimum yeniden deneme sayısını da içerir. Uygulama sunucusu tarafından belirlenen hız sınırlarının aşılmasını önlemek için gruplar arasında bir gecikme ( ) da bulunur. delay_between_batches Umarım bu, bugünkü makalede öğrendiğiniz her şeyi özetlemektedir. Herhangi bir sorunuz varsa lütfen bana bildirin!
