OpenAI برای دنبال کردن سریع Jev موقعیت خوبی دارد

TypeSafe's Jev چرخشی جدیدی بر روی مدل های زبان بزرگ ارائه کرد که دنیای هوش مصنوعی را طوفانی کرده است. به گفته Vercel، "Jev سریعتر از هر مدل دیگری در تاریخ دروازه هوش مصنوعی اتخاذ شد." ... اما ابرهایی در افق شکل می گیرند. OpenAI بدون شک توجه دارد - و تصمیم می گیرد که چه کاری انجام دهد.

برای TypeSafe بهترین ها را آرزو می کنم، اما اگر آنها واقعا به وعده های خود عمل کنند، پس من نگران هستم که OpenAI برای دنبال کردن سریع - نه تنها برای تکرار محصول شاخص Jev، بلکه همچنین برای تطبیق این قابلیت در مدل ها و نمایندگان آینده و ارائه برخی رفتارهای واقعا مفید جدید که Jev برای بازتولید موقعیت مناسبی ندارد، موقعیت خوبی دارد.

در اینجا به طور خلاصه پایان نامه من است: OpenAI برای سال ها از LLM های خود به عنوان طبقه بندی کننده ضمنی استفاده کرده است. آنها فقط آنها را برای وظایف طبقه بندی عمومی آموزش نداده اند و طبقه بندی کلی را به عنوان یک محصول مستقل بسته بندی نکرده اند. اگر OpenAI بتواند آموزش را تکرار کند، می‌تواند Jev را در کوتاه‌مدت تکرار کند. علاوه بر این، OpenAI برای استفاده از این طبقه‌بندی‌کننده جدید در داخل مدل‌ها و عوامل موجود خود قرار دارد که می‌تواند برای انتخاب سریع مدل، تفکر کارآمدتر، نرده‌های امنیتی بهتر و به طور کلی مدل‌های هوشمندتر، سریع‌تر و ارزان‌تر مفید باشد.

عامل اصلی تصمیم گیری در مورد همه اینها این است که آیا TypeSafe خندقی برای محافظت از خود دارد یا خیر. بزرگترین خندقی که من می بینم در داده های آموزشی و فرآیندهای آموزشی TypeSafe است.

قبل از اینکه به ادعای خود بپردازم، اجازه دهید فرضیات خود را بیان کنم و با برخی از تاریخچه و نمونه های مرتبط از OpenAI از آنها حمایت کنم.

فرض اصلی من این است که Jev از چیزی بسیار نزدیک به یک مدل زبان بزرگ معمولی استفاده می کند. به عنوان شاهدی بر این موضوع، فضای پنهان گزارش می دهد که بسیاری از کلون های اولیه در واقع مبتنی بر LLM هستند.

ایده اینجاست. با توجه به یک وضعیت و مجموعه ای از سؤالات، Jev's LLM یک توکن واحد تولید می کند یا به طور دقیق تر، توزیع احتمال را بر روی تمام نشانه های ممکن بعدی ایجاد می کند. logprob های مرتبط با هر توکن ممکن در آن یک مرحله سپس به هر فرمتی که Jev برای بازگشت نیاز دارد ماساژ داده می شود. (از اینجا به بعد من فقط به جای "logprobs" "احتمالات" را می گویم - برای اهداف ما آنها قابل تعویض هستند.)

برای یک سوال پوچ، Jev فقط به دو نشانه درست و نادرست نگاه می کند، همه چیزهای دیگر را نادیده می گیرد و احتمالات آنها را در یک احتمال واحد که پاسخ درست است عادی می کند. برای یک سوال انتخابی، از Jev می توان لیستی از احتمالات را درخواست کرد - مثلا A=خوشحال، B= غمگین، C= عصبانی، D=ترس - و به احتمالات نسبی آن چهار نشانه برای ایجاد توزیع کامل نگاه می کند و بالاترین را به عنوان برنده انتخاب می کند.

الگوی انتخاب تقریبا همان چیزی است که من در سال 2025 در Supercharging LLM Classifications with Logprobs در وبلاگ نوشتم، و حتی بدون تنظیم دقیق قبلا نویدبخش بود. (آه... در مورد ایده ها و اهمیت اجرا چه می گویند؟) من در مورد نمره ابتدایی خیلی فکر نکرده ام، اما گمان می کنم که یک نوع از همان الگو باشد.

بخشی از فرضیه این پست این است که OpenAI ممکن است به سرعت از این ایده استفاده کند، و اگر بفهمید که چگونه می‌توانید این موضوع را روشن‌تر کنید. OpenAI حداقل از زمان معرفی فراخوانی ابزار به طور ضمنی از مدل های زبان بزرگ به عنوان طبقه بندی کننده های تخصصی استفاده می کند.

در اوایل سال 2024 من ابزار Invocation – نشان دادن شگفتی انعطاف پذیری GPT را نوشتم، جایی که یک مدل GPT را تشویق کردم که دقیقا چگونه تصمیم می گیرد یک ابزار را نامگذاری کند. در زیر به شکل داخلی یک جلسه چت است. در اینجا یک پیام کاربر وجود دارد، سپس یک پاسخ دستیار بدون تماس ابزار و سپس یک پیام کاربر با یک تماس ابزار وجود دارد:

من متن را برای نشان دادن مرزهای نشانه کد رنگی کرده ام. اگر قبلا ChatML را ندیده‌اید، این زبان نشانه‌گذاری داخلی است که OpenAI برای سازماندهی درخواست‌های مکالمه کاربر-عامل معرفی کرده است. <|im_start|> و <|im_end|> نشانه‌های رزرو شده‌ای هستند که پیام‌ها را محدود می‌کنند و اولین نشانه پس از <|im_start|> گوینده، کاربر یا دستیار را مشخص می‌کند.

درست بعد از <|im_start|>دستیار، اولین نشانه ای که مدل پیش بینی می کند، \n یا to=function است. . اگر \n پیش‌بینی کند، با یک پاسخ طبیعی به زبان طبیعی ادامه می‌دهد. اگر به=عملکرد را پیش بینی کند. ، سپس آن دنباله توکن ها به طور موثر به عنوان یک طبقه بندی عمل می کند که تصمیم می گیرد آیا یک ابزار اصلا باید فراخوانی شود یا خیر. تعداد انگشت شماری از توکن‌های بعدی مشخص می‌کنند که کدام ابزار را فراخوانی کنیم - get_temperature - طبقه‌بندی‌کننده دیگری، این بار از فهرست ابزارهای موجود انتخاب می‌شود.

پس از آن، مدل نام‌های آرگومان و سپس مقادیر آرگومان را تولید می‌کند که می‌توانند به‌طور مبهم به‌عنوان طبقه‌بندی‌کننده یا تخمین‌گر در نظر گرفته شوند. در نهایت، زمانی که مدل یک نشانه <|im_end|> تولید می کند، آن نیز یک طبقه بندی است که زمانی که مدل معتقد است پیام کامل شده است، "درست" می خواند.

برخی از LLM ها فقط نمی دانند چه زمانی باید سکوت کنند - یک چیز خنده دار به کنار.

زمانی که در GitHub مشغول کار بر روی Copilot بودم، این فرصت را داشتم که با یک API داخلی بسیار جدید و بسیار خام برای GPT-4 کار کنم. خارج از دروازه، ما می دانستیم که چیزی بسیار دور از ذهن است، زیرا پس از یک پاسخ بسیار منسجم اولیه، مدل در بسته بندی با مشکل مواجه می شود. هر پاسخی را با چیزی مانند "اگر سوال دیگری دارید به من اطلاع دهید. روز خوبی داشته باشید. هفته خوبی داشته باشید. اوقات خوبی داشته باشید. زندگی فوق العاده ای داشته باشید. روز خاصی داشته باشید..." پایان می یابد و به همین ترتیب ادامه می یابد تا زمانی که به حد مجاز پاسخ برسد.

همانطور که مشخص است، API از ما خواسته است که مقداری سرصفحه را تنظیم کنیم که به مدل اجازه می‌دهد از آن جداکننده‌های پیام خاص <|im_start|> و <|im_end|> استفاده کند. در واقع ما به مدل اجازه نمی‌دادیم تا پایان پاسخ خود را پیش‌بینی کند – این مدل به معنای واقعی کلمه هیچ توانایی درونی برای بسته شدن خود نداشت!

نکته ای که من در آن پست قدیمی به آن اشاره کردم این بود که OpenAI سال هاست که از توکن های منفرد به عنوان ریز طبقه بندی کننده های کوچک استفاده می کند. هر توکن دارای یک احتمال بود: آیا از ابزاری استفاده کنیم یا نه، از کدام ابزار استفاده کنیم، دستیار تمام شده است. این واقعا کل ترفند Jev است، به جز یک چیز مهم: این میکرو طبقه‌بندی‌کننده‌ها متخصص هستند، فقط برای این کارهای کوچک مناسب هستند، در حالی که طبقه‌بندی‌کننده‌های Jev عمومی هستند.

اما یک یا دو قدم به عقب برگردید و می‌بینید که در نهایت این ممکن است یک چیز کوچک باشد، زیرا یک LLM به طور موثر یک طبقه‌بندی‌کننده عمومی فوق‌العاده است که دائما یک توزیع احتمال را برای هر توکن بعدی اختصاص می‌دهد.

من در واقع دارم برای Jev روت می کنم. من فکر می کنم آنها چیز بسیار جالبی پیدا کرده اند که در تمام مدت زیر بینی ما پنهان شده است.

از نظر معماری، به دلایلی که در بالا ذکر شد، فکر نمی‌کنم خندقی وجود داشته باشد. من فکر می کنم TypeSafe از یک مدل زبان معمولی بزرگ برای Jev یا چیزی نزدیک به آن استفاده می کند. و حتی اگر نه، LLM های معمولی برای کارهای طبقه بندی کلی مناسب به نظر می رسند.

شاید خندق واقعی در خود داده های آموزشی باشد. نه داده‌های خام، بلکه تکنیک تبدیل آن به چیزی که Jev را برای «کالیبره شدن» آموزش می‌دهد. دیوگو آلمیدا، یکی از بنیانگذاران TypeSafe، زمانی که کسی پیشنهاد داد که داده ها بیشتر از معماری مهم هستند، گفت:

شما ممکن است اولین کسی باشید که در مورد داده ها در مورد معماری صحبت می کند! 🥲 ما خود را یک آزمایشگاه تحقیقات داده می دانیم! اکثریت قریب به اتفاق تحقیقات بر روی ایجاد داده‌هایی بود که واقعا عمومی هستند (الا یک هسته شناختی) و 100٪ داده‌های ما مصنوعی هستند (اما بدیهی است که نوع مزخرفی نیست که فقط از یک LLM خارج می‌شود)

اگر من آن مجموعه داده را ایجاد می‌کردم، انبوهی از مثال‌ها را می‌خواستم که در آن نتیجه از قبل مشخص است - بلیط‌های پشتیبانی و اینکه واقعا چگونه مسیریابی شدند، رزومه‌ها و اینکه آیا آن نامزد واقعا استخدام شده است، بررسی‌های محصول و رتبه‌بندی ستاره‌های واقعی آنها، صف‌های تعدیل و احکام واقعی آن‌ها، بازارهای پیش‌بینی و نحوه حل آنها - هر کدام از آنها قبلا با یک سؤال درست پاسخ داده‌ام. نکته این نیست که به Jev در مورد بلیط های پشتیبانی یا رزومه به طور خاص آموزش دهید.

این برای نشان دادن هزاران موقعیت در دامنه های بسیار متفاوت و ایجاد عضله برای تعمیم طبقه بندی ها در دامنه های گسترده است.

سپس یادگیری تقویتی وجود دارد. من تعجب می کنم که این چه معنایی دارد. عوامل مستقل تصمیمات را با مجموعه‌ای از گزینه‌های محدود مانند نسخه نمایشی ویکی‌پدیا یا نسخه نمایشی Doom که در سایت خود می‌سازند، هدایت می‌کنند؟ شاید پیش بینی نتایج وقایعی که پس از پایان تمرین رخ داد؟ من نمی دانم، اما اگر سس مخفی وجود دارد، احتمالا اینجاست.

توجه داشته باشید که هیچ یک از اینها خندق نیست مگر اینکه Jev واقعا دقیق باشد. سرعت، هزینه و سهولت استفاده واضح است، اما دقت تنها چیزی است که بررسی آن سخت است. من قبلا دامنه‌هایی را پیدا کرده‌ام که احتمالات Jev در آنها قابل قبول نیست. زمان نشان خواهد داد که آیا Jev به اندازه کافی کلی و دقیق برای مواردی است که افراد سعی می کنند از آن استفاده کنند.

بنابراین حرکت بعدی OpenAI در اینجا چیست؟ یکی از بدیهیات این است که فقط Jev را کپی کنید و آن را به عنوان یک مدل جدید ارسال کنید. Jev به وضوح محبوب است، و اگر خندق کم عمق باشد، OpenAI مهارت، سخت‌افزار و بودجه لازم برای انجام آن را دارد.

اما OpenAI می‌تواند کاری جالب‌تر از کپی کردن Jev انجام دهد، آن‌ها می‌توانند قابلیت طبقه‌بندی را در یک LLM معمولی جمع کنند و پاداش‌های جالبی به دست آورند.

آن نحو خاص را به خاطر بسپارید که سیگنال فراخوانی ابزار، to=function را نشان می داد. ? OpenAI می‌تواند کاری مشابه را در اینجا انجام دهد: نحو جدیدی را معرفی کند، مثلا یک برچسب جدید، <پیش‌بینی>، که مدل می‌تواند هر زمان که نیاز به قضاوت طبقه‌بندی‌کننده سریع داشته باشد، در زمینه خود قرار دهد. در اینجا مثالی از نحوه ظاهر آن آورده شده است

یک تفاوت جالب با فراخوانی ابزار معمولی وجود دارد. با فراخوانی ابزار معمولی، مدل نام تابع و آرگومان‌ها را تولید می‌کند، سپس تولید متوقف می‌شود - مهار عامل باید کار را به دست بگیرد، در واقع تابع را فراخوانی کرده و نتیجه را در یک نوبت جدید بازگرداند. اینجا، هیچ انتقالی وجود ندارد. طبقه بندی کننده ابزاری نیست که خارج از مدل زندگی می کند، بلکه قابلیتی است که در خود مدل تعبیه شده است. مدل سوال خود را می پرسد و در همان نفس به آن پاسخ می دهد، بدون اینکه هرگز از GPU خارج شود.

رمزگشایی عادی به این صورت عمل می‌کند: در هر موقعیت، مدل مجموعه‌ای از لاجیت‌ها را تولید می‌کند، یکی در هر نشانه واژگانی. آنها از طریق softmax به توزیع احتمال تبدیل می شوند. و سپس برخی از استراتژی رمزگشایی (طمع، top-p، هر چیزی) یک توکن را انتخاب می‌کند که به دنباله اضافه می‌شود و برای مرحله بعدی بازخورد می‌شود. اما در نقطه ای که مدل احتمال نوشته شده است: ، ما رمزگشایی معمولی نمی خواهیم. این ادعا به عنوان یک بیانیه بیان می شود، بنابراین در زیر سرپوش مدل واقعا هنوز دو نتیجه ضمنی دارد - درست یا نادرست.

می‌خواهیم لوجیت‌های نشانه‌های درست و نادرست را در آن موقعیت بخوانیم، فقط آن دو را در مقابل هم عادی کنیم، و احتمال حاصل را به‌جای هر توکنی که معمولا برنده می‌شود، به صورت متن، 0.04 در دنباله بنویسیم. سپس مدل به رمزگشایی ادامه می‌دهد که انگار خودش آن عدد را ایجاد کرده است، زیرا تا آنجا که به بقیه پاس‌های رو به جلو مربوط می‌شود، این کار را انجام داده است. این ترفند عجیبی است، اما این همان نوع رمزگشایی هدایت‌شده است که کتابخانه‌های خروجی محدود در زمان استنتاج انجام می‌دهند - فقط به جای دستور زبان، روی احتمالات اعمال می‌شود.

ترفند دیگر این است که این یک موقعیت خاص باید متفاوت از یک پیش‌بینی توکن معمولی رفتار کند. به طور معمول مدل در حال تخمین "چه نشانه بعدی در این متن است". در اینجا ما به آن نیاز داریم تا چیزی نزدیکتر به "پاسخ واقعی به این سوال چیست" که یک مهارت مرتبط اما متمایز است، تخمین بزنیم. این روزها هر مدل مرزی ترکیبی از متخصصان است، بنابراین تصور این که چند دور تنظیم دقیق می‌تواند متخصصی را پیدا کند که دقیقا در این نوع قضاوت فوری مدرج تخصص دارد، طولانی نیست، در حالی که بقیه مدل‌ها همان کاری را که قبلا به خوبی انجام می‌دهند، انجام می‌دهند.

(من مسیریابی MoE را به طور قابل توجهی ساده می کنم، اما گمان می کنم متوجه شده اید که چگونه ممکن است این مسیر به یک سیستم واقعی نگاشت شود.)

نگاه کنید که چگونه مدل در آن مثال دانی و جس از خود استفاده کرد. اگر TypeSafe درست باشد، این قضاوت‌های کوچک Jev-مانند کاملا دقیق خواهند بود – و کمتر مستعد توهم هستند تا اینکه فقط از یک مدل بخواهید مقدار اطمینان را در متن ساده بیان کند. (احتیاط‌ها اعمال می‌شوند – به خلاصه خود TypeSafe در مورد لبه‌های ناهموار Jev مراجعه کنید. Jev برای قضاوت‌های سریع، سیستم یک، نه استدلال ریاضی یا چند هاپ بهترین کار را دارد.)

بهترین بخش این واقعیت ذکر شده است که ما هرگز مجبور نیستیم GPU را ترک کنیم تا از این سیستم طبقه بندی عمومی جدید و سریع برق آسا استفاده کنیم. همانطور که در بالا نشان داده شده است، LLM به معنای واقعی کلمه می تواند از خود بپرسد، همانجا در بلوک تفکر. بازده فوری است: استدلال خود مدل دقیق‌تر و مستدل‌تر می‌شود، زیرا مفروضات خود را بر اساس تخمین‌های کالیبره‌شده آموزش‌دیده بررسی می‌کند به جای انعکاس نشانه‌های احتمالی بعدی.

و هنگامی که یک مدل به‌خوبی تنظیم شد تا یک <پیش‌بینی> را در تفکر خود بیاندازد، دلیلی برای توقف در توصیه‌های عاشقانه وجود ندارد. چند الگوی دیگر به ذهنم می رسد:

در طول یک ردیابی استدلال طولانی، مدل می‌تواند به صورت دوره‌ای بررسی کند که آیا واقعا انجام شده است یا خیر، و اگر نه، در ادامه با کدام کار مقابله کند:

این یک راه ارزان برای اتصال کوتاه یک ردپای استدلالی است که سرگردان است، به جای اینکه منتظر بمانید تا مدل خودش را متوقف کند.

یا درست پس از تماس ابزار، مدل می‌تواند قبل از اجرای واقعی آن تماس را بررسی کند که آیا خود تماس ایمن است یا خیر:

همین الگو برای اسکن پاسخ ابزار برای تزریق سریع کار می کند. و از آنجایی که همیشه یک سوال یکسان پرسیده می شود، تصور اینکه این سوال به چیزی شبیه <safety_score>0.94</safety_score> کاهش می یابد، آسان است، با دستورالعملی که در مدل وجود دارد که اگر امتیاز خیلی پایین بیاید، تولید را متوقف کند.

همین ترفند می تواند کار را بین مدل ها هدایت کند: با پرسیدن دوره ای "آیا این به یک مدل بزرگتر، یک مدل کوچکتر یا این مدل نیاز دارد؟" و اجازه دهید کمی یادگیری تقویتی پاسخ را به سمت ارزانترین چیزی سوق دهد بدون اینکه دقت را به خطر بیندازد.

بعلاوه، اگر واقعا یک "متخصص" اختصاصی در آنجا وجود داشته باشد که در این قضاوت های فوری متخصص باشد، ممکن است مدل در بیشتر مواقع حتی به نحو ویژه <پیش بینی> نیاز نداشته باشد. هر زمان که قضاوت فوری ضروری باشد، می تواند به عنوان بخشی عادی از پاس رو به جلو، در وسط جمله - بدون نیاز به برچسب، هدایت شود. تنظیم دقیق آن متخصص در داخل مدلی که هر کاری را که یک LLM انجام می دهد نیز انجام می دهد، حتی ممکن است اثرات هم افزایی داشته باشد و LLM را در قضاوت های فوری هوشمندتر و در طبقه بندی ها انعطاف پذیرتر و عمومی تر کند.

در نهایت، همه به محض اینکه بتوانند آن را دریافت کنند، می خواهند طبقه بندی برای تصاویر و گفتار داشته باشند. اگر بتوان طبقه‌بندی به سبک Jev را در یک متن معمولی LLM مانند آنچه در اینجا ترسیم کردم تا کرد، به زودی OpenAI طبقه‌بندی کلی را برای تصاویر و گفتار در دسترس قرار می‌دهد. برعکس، طبقه‌بندی که در یک مدل گفتار پخته می‌شود، مخصوصا برای چیزی مانند یک عامل صوتی زنده مفید است - تصمیم‌گیری در زمان واقعی که آیا قطع شود، تشدید شود یا فقط به گوش دادن ادامه دهید.

زمان نشان خواهد داد که آیا ادعاهای Jev در مورد دقت و کلیت واقعا در سراسر طیف کامل وظایفی که مردم در حال حاضر انجام می‌دهند، جواب می‌دهد یا خیر. اگر آنها این کار را انجام دهند، بقای TypeSafe به خندق ختم می شود: واقعا چقدر سخت است که داده های آموزشی و فرآیند یادگیری تقویتی آنها را تکرار کنیم. اگر واقعا سخت باشد، احتمالا خوب خواهند بود - و حتی ممکن است در موقعیت غیرمعمول خوبی قرار گیرند تا به‌طور کامل توسط OpenAI خریداری شوند، نه اینکه توسط آنها رقابت کنند.

همه چیزهایی که در بالا ترسیم کردم، یک ارتقای واقعی قابلیت برای یک آزمایشگاه مرزی است: تفکر سریع‌تر، تفکر ارزان‌تر، و قضاوت دقیق‌تر System One که مستقیما در مدل پرچم‌دار ساخته شده است.

اگر خندق نازک باشد، OpenAI فقط آن را خودش می سازد و پنجره TypeSafe به سرعت بسته می شود.

در همین حال، دیوگو آلمیدا، مدیر عامل مؤسس TypeSafe اطمینان دارد که "اگر کیفیت مدل مهم باشد، ما برای مدت طولانی در موقعیت بسیار خوبی خواهیم بود." (از مصاحبه او با فضای پنهان)