API တွင် Structured Outputs မိတ်ဆက်ခြင်း
API တွင် Structured Outputs ကို ကျွန်ုပ်တို့ မိတ်ဆက်နေပါသည်—ယခု မော်ဒယ်ရလဒ်များသည် ဖွံ့ဖြိုးတိုးတက်သူပေး JSON Schemas များကို ယုံကြည်စိတ်ချစွာ လိုက်နာပါသည်။

ပြီးခဲ့သောနှစ် DevDay တွင် ကျွန်ုပ်တို့သည် JSON mode ကို မိတ်ဆက်ခဲ့သည်—၎င်းသည် ကျွန်ုပ်တို့၏ မော်ဒယ်များဖြင့် ယုံကြည်စိတ်ချရသော applications များ တည်ဆောက်လိုသော ဖွံ့ဖြိုးတိုးတက်သူများအတွက် အသုံးဝင်သော building block တစ်ခုဖြစ်သည်။ JSON mode သည် မှန်ကန်သော JSON ရလဒ်များ ထုတ်ပေးရာတွင် မော်ဒယ်၏ ယုံကြည်စိတ်ချရမှုကို တိုးတက်စေသော်လည်း မော်ဒယ်၏ တုံ့ပြန်မှုသည် သီးခြား စီမံချက်တစ်ခုနှင့် ကိုက်ညီမည်ကို မအာမခံပါ။ ယနေ့ ကျွန်ုပ်တို့သည် API တွင် Structured Outputs ကို မိတ်ဆက်နေပြီး ၎င်းမှာ ဖွံ့ဖြိုးတိုးတက်သူများ ပေးသော JSON Schemas များနှင့် မော်ဒယ်ထုတ်ပေးသော ရလဒ်များ အတိအကျ ကိုက်ညီစေရန် ရည်ရွယ်ထားသော feature အသစ်တစ်ခုဖြစ်သည်။
မတည်ဆောက်ထားသော input များမှ တည်ဆောက်ထားသော ဒေတာကို ထုတ်ပေးခြင်းသည် ယနေ့ခေတ် applications များတွင် AI ၏ အဓိက အသုံးပြုမှုများထဲမှ တစ်ခုဖြစ်သည်။ ဖွံ့ဖြိုးတိုးတက်သူများသည် OpenAI API ကို အသုံးပြု၍ ဒေတာကို ရယူပြီး လုပ်ဆောင်ချက် ခေါ်ဆိုမှု(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) မှတစ်ဆင့် မေးခွန်းများကို ဖြေဆိုနိုင်သော အစွမ်းထက် assistants များ တည်ဆောက်ခြင်း၊ ဒေတာထည့်သွင်းရေးအတွက် တည်ဆောက်ထားသော ဒေတာကို ထုတ်ယူခြင်း၊ နှင့် LLM များအား လုပ်ဆောင်ချက်များ လုပ်ဆောင်ခွင့်ပြုသော multi-step agentic workflows များ တည်ဆောက်ခြင်းတို့ကို ပြုလုပ်ကြသည်။ ဖွံ့ဖြိုးတိုးတက်သူများသည် ဤနယ်ပယ်တွင် LLM များ၏ ကန့်သတ်ချက်များကို ဖြေရှင်းရန် open source tooling, prompting နှင့် မော်ဒယ်ရလဒ်များသည် ၎င်းတို့၏ စနစ်များနှင့် အပြန်အလှန်လုပ်ဆောင်ရန် လိုအပ်သော format များနှင့် ကိုက်ညီစေရန် တောင်းဆိုမှုများကို ထပ်ခါတလဲလဲ retry လုပ်ခြင်းတို့ကို ကြာရှည်စွာ အသုံးပြုလာခဲ့ကြသည်။ Structured Outputs သည် OpenAI မော်ဒယ်များကို ဖွံ့ဖြိုးတိုးတက်သူပေး စီမံချက်များနှင့် ကိုက်ညီအောင် ကန့်သတ်ပေးခြင်းနှင့် ကျွန်ုပ်တို့၏ မော်ဒယ်များကို ရှုပ်ထွေးသော စီမံချက်များကို ပိုမိုကောင်းမွန်စွာ နားလည်စေရန် လေ့ကျင့်ပေးခြင်းဖြင့် ဤပြဿနာကို ဖြေရှင်းပေးသည်။
ရှုပ်ထွေးသော JSON schema လိုက်နာမှုဆိုင်ရာ ကျွန်ုပ်တို့၏ evals တွင် Structured Outputs နှင့်အတူ ကျွန်ုပ်တို့၏ မော်ဒယ်အသစ် gpt-4o-2024-08-06 သည် ပြည့်စုံသော 100% ရရှိသည်။ နှိုင်းယှဉ်ကြည့်လျှင် gpt-4-0613 သည် 40% ထက်နည်းသည်။
Structured Outputs ဖြင့် gpt-4o-2024-08-06 သည် ကျွန်ုပ်တို့၏ evals တွင် 100% ယုံကြည်စိတ်ချရမှုကို ရရှိပြီး output schemas များနှင့် အပြည့်အဝ ကိုက်ညီပါသည်။
ကျွန်ုပ်တို့သည် API တွင် Structured Outputs ကို ပုံစံနှစ်မျိုးဖြင့် မိတ်ဆက်နေပါသည်:
1. လုပ်ဆောင်ချက် ခေါ်ဆိုမှု: tools မှတစ်ဆင့် Structured Outputs ကို သင့် function definition အတွင်း strict: true သတ်မှတ်ခြင်းဖြင့် ရရှိနိုင်သည်။ ဤ feature သည် tools ကို ပံ့ပိုးသော မော်ဒယ်အားလုံးနှင့် အလုပ်လုပ်ပြီး gpt-4-0613 နှင့် gpt-3.5-turbo-0613 နှင့် ၎င်းနောက်ထွက် မော်ဒယ်အားလုံးပါဝင်သည်။ Structured Outputs ကို ဖွင့်ထားသောအခါ မော်ဒယ်ရလဒ်များသည် ပေးထားသော tool definition နှင့် ကိုက်ညီမည်ဖြစ်သည်။
2. response_format parameter အတွက် ရွေးချယ်စရာအသစ်တစ်ခု: ဖွံ့ဖြိုးတိုးတက်သူများသည် ယခု json_schema မှတစ်ဆင့် JSON Schema ကို response_format parameter ၏ ရွေးချယ်စရာအသစ်အဖြစ် ပေးနိုင်ပြီဖြစ်သည်။ ဤသည်မှာ မော်ဒယ်က tool တစ်ခုကို မခေါ်ဘဲ အသုံးပြုသူအား တည်ဆောက်ထားသော ပုံစံဖြင့် တုံ့ပြန်နေသောအခါ အသုံးဝင်သည်။ ဤ feature သည် ကျွန်ုပ်တို့၏ နောက်ဆုံးပေါ် GPT‑4o မော်ဒယ်များဖြစ်သော ယနေ့ ထုတ်ပြန်သည့် gpt-4o-2024-08-06 နှင့် gpt-4o-mini-2024-07-18 တို့တွင် အလုပ်လုပ်သည်။ response_format ကို strict: true ဖြင့် ပေးသောအခါ မော်ဒယ်ရလဒ်များသည် ပေးထားသော စီမံချက်နှင့် ကိုက်ညီမည်ဖြစ်သည်။
လုံခြုံရေးသည် OpenAI အတွက် အဓိက ဦးစားပေးဖြစ်သည်—Structured Outputs လုပ်ဆောင်နိုင်မှုအသစ်သည် ကျွန်ုပ်တို့၏ လက်ရှိလုံခြုံရေးမူဝါဒများကို လိုက်နာမည်ဖြစ်ပြီး မော်ဒယ်အနေဖြင့် မလုံခြုံသော တောင်းဆိုချက်ကို ငြင်းဆိုနိုင်ရန်လည်း ဆက်လက်ခွင့်ပြုမည်ဖြစ်သည်။ ဖွံ့ဖြိုးတိုးတက်မှုကို ပိုမိုလွယ်ကူစေရန် API responses များတွင် refusal string value အသစ်တစ်ခု ရှိလာပြီး ၎င်းက မော်ဒယ်သည် schema နှင့် ကိုက်ညီသော output အစား ငြင်းဆိုမှုတစ်ခု ထုတ်ပေးထားခြင်းရှိမရှိကို ဖွံ့ဖြိုးတိုးတက်သူများ programmatically စစ်ဆေးနိုင်စေသည်။ တုံ့ပြန်မှုတွင် refusal မပါဝင်ဘဲ မော်ဒယ်၏ တုံ့ပြန်မှုကို အချိန်မတိုင်မီ ဖြတ်တောက်ထားခြင်းလည်း မရှိပါက (finish_reason ဖြင့် ဖော်ပြသည့်အတိုင်း) မော်ဒယ်၏ တုံ့ပြန်မှုသည် ပေးထားသော စီမံချက်နှင့် ကိုက်ညီသော မှန်ကန်သော JSON ကို ယုံကြည်စိတ်ချစွာ ထုတ်ပေးမည်ဖြစ်သည်။
ကျွန်ုပ်တို့၏ Python နှင့် Node SDK များကို Structured Outputs အတွက် မူရင်းပံ့ပိုးမှုပါဝင်စေရန် အပ်ဒိတ်လုပ်ထားပါသည်။ tools အတွက်ဖြစ်စေ response format အဖြစ်ဖြစ်စေ schema တစ်ခု ပေးခြင်းသည် Pydantic သို့မဟုတ် Zod object တစ်ခု ပေးသလိုပင် လွယ်ကူပြီး ကျွန်ုပ်တို့၏ SDK များသည် data type ကို ပံ့ပိုးထားသော JSON schema အဖြစ် ပြောင်းလဲခြင်း၊ JSON response ကို typed data structure အဖြစ် အလိုအလျောက် deserializing လုပ်ခြင်းနှင့် ငြင်းဆိုမှုများ ဖြစ်ပေါ်လာပါက ၎င်းတို့ကို parsing လုပ်ခြင်းတို့ကို ကိုင်တွယ်ပေးမည်ဖြစ်သည်။
အောက်ပါ ဥပမာများသည် လုပ်ဆောင်ချက် ခေါ်ဆိုမှုနှင့်အတူ Structured Outputs အတွက် မူရင်းပံ့ပိုးမှုကို ပြသထားသည်။
response_format အတွက်လည်း မူရင်း Structured Outputs ပံ့ပိုးမှုကို ရရှိနိုင်ပါသည်။
ဖွံ့ဖြိုးတိုးတက်သူများသည် အသုံးပြုမှုအမျိုးမျိုးအတွက် တည်ဆောက်ထားသော ဒေတာကို ထုတ်ပေးရန် OpenAI ၏ မော်ဒယ်များကို မကြာခဏ အသုံးပြုကြသည်။ နောက်ထပ် ဥပမာအချို့မှာ:
ဥပမာအားဖြင့် ဖွံ့ဖြိုးတိုးတက်သူများသည် Structured Outputs ကို အသုံးပြု၍ code သို့မဟုတ် UI ထုတ်ပေးသော applications များကို ဖန်တီးနိုင်သည်။ အောက်ပါ ဥပမာအားလုံးသည် တူညီသော response_format ကို အသုံးပြုပြီး အသုံးပြုသူ input အပေါ် မူတည်၍ UI အမျိုးမျိုးကို ထုတ်ပေးရန် အသုံးပြုနိုင်သည်။
သင်သည် အသုံးပြုသူ အင်တာဖေ့စ် အကူအညီပေးသူ ဖြစ်သည်။ သင့်အလုပ်က အသုံးပြုသူများ၏ ဝက်ဘ်ဆိုက်နှင့်အက်ပ် အိုင်ဒီယာများကို မြင်ယောင်နိုင်အောင် ကူညီပေးရန်ဖြစ်သည်။တုံ့ပြန်မှု၏ နောက်ဆုံးအရည်အသွေးကို တိုးတက်စေရန် chain of thought အတွက် မော်ဒယ်အား သီးခြား field တစ်ခု ပေးထားခြင်းက အသုံးဝင်နိုင်သည်။
ဥပမာအားဖြင့် အစည်းအဝေးမှတ်စုများမှ လုပ်ဆောင်ရမည့်အရာများ၊ နောက်ဆုံးသတ်မှတ်ရက်များနှင့် တာဝန်ခွဲဝေမှုများကဲ့သို့သော အရာများကို ထုတ်ယူရန် မော်ဒယ်အား ညွှန်ကြားခြင်းဖြစ်သည်။
JSON Schema နှင့် ကိုက်ညီသော မော်ဒယ်ရလဒ်များ၏ ယုံကြည်စိတ်ချရမှုကို တိုးတက်စေရန် ကျွန်ုပ်တို့သည် အပိုင်းနှစ်ပိုင်းပါသော နည်းလမ်းကို အသုံးပြုခဲ့သည်။ ပထမအနေနှင့် ကျွန်ုပ်တို့၏ နောက်ဆုံးပေါ် မော်ဒယ် gpt-4o-2024-08-06 ကို ရှုပ်ထွေးသော စီမံချက်များကို နားလည်စေရန်နှင့် ၎င်းတို့နှင့် ကိုက်ညီသော ရလဒ်များကို အကောင်းဆုံးထုတ်ပေးနိုင်ရန် လေ့ကျင့်ပေးခဲ့သည်။ သို့သော် မော်ဒယ်၏ အပြုအမူသည် မူလအားဖြင့် non-deterministic ဖြစ်သည်—ဤမော်ဒယ်၏ စွမ်းဆောင်ရည်တိုးတက်မှုများ (ကျွန်ုပ်တို့၏ benchmark တွင် 93%) ရှိသော်လည်း ခိုင်မာသော application များ တည်ဆောက်ရန် ဖွံ့ဖြိုးတိုးတက်သူများ လိုအပ်သည့် ယုံကြည်စိတ်ချရမှုအဆင့်ကို မရောက်ရှိသေးပါ။ ထို့ကြောင့် 100% ယုံကြည်စိတ်ချရမှုကို ရရှိစေရန် မော်ဒယ်ရလဒ်များကို ကန့်သတ်သည့် deterministic engineering-based approach တစ်ခုကိုလည်း ကျွန်ုပ်တို့ အသုံးပြုခဲ့သည်။
ကျွန်ုပ်တို့၏ နည်းလမ်းသည် constrained sampling သို့မဟုတ် constrained decoding ဟု သိကြသော နည်းပညာတစ်ခုအပေါ် အခြေခံထားသည်။ ပုံမှန်အားဖြင့် မော်ဒယ်များကို ရလဒ်ထုတ်ပေးရန် sampling လုပ်သောအခါ ၎င်းတို့မှာ လုံးဝ မကန့်သတ်ထားဘဲ နောက်ထွက်လာမည့် output အဖြစ် vocabulary ထဲမှ မည်သည့်တိုကင်ကိုမဆို ရွေးချယ်နိုင်သည်။ ဤပြောင်းလွယ်ပြင်လွယ်မှုကြောင့် မော်ဒယ်များ အမှားလုပ်နိုင်သည်; ဥပမာအားဖြင့် ၎င်းတို့သည် မှန်ကန်သော JSON မဖြစ်စေသော်လည်း မည်သည့်အချိန်တွင်မဆို curly brace တိုကင်ကို ရွေးချယ်ရန် ယေဘုယျအားဖြင့် လွတ်လပ်ကြသည်။ မှန်ကန်သော ရလဒ်များကို အတင်းအကျပ် ဖြစ်စေရန် ကျွန်ုပ်တို့သည် မော်ဒယ်များကို ရရှိနိုင်သမျှ တိုကင်အားလုံးအစား ပေးထားသော စီမံချက်အရ မှန်ကန်မည့် တိုကင်များပဲ ရွေးချယ်နိုင်အောင် ကန့်သတ်ထားသည်။
မော်ဒယ်၏ output တစ်လျှောက် မှန်ကန်သော တိုကင်များ ကွဲပြားနေသောကြောင့် လက်တွေ့တွင် ဤကန့်သတ်မှုကို အကောင်အထည်ဖော်ရန် ခက်ခဲနိုင်သည်။ အောက်ပါ schema ရှိသည်ဟု ဆိုကြပါစို့:
output ၏ အစတွင် မှန်ကန်သော တိုကင်များတွင် {, {“, { စသည်တို့ ပါဝင်သည်။ သို့သော် မော်ဒယ်သည် {“val ကို ရွေးချယ်ပြီးသားဖြစ်သွားသောအခါ { သည် မှန်ကန်သော တိုကင် မဟုတ်တော့ပါ။ ထို့ကြောင့် dynamic constrained decoding ကို အကောင်အထည်ဖော်ရန် လိုအပ်ပြီး တုံ့ပြန်မှုအစတွင် ကြိုတင်သတ်မှတ်မည့်အစား တိုကင်တစ်ခုချင်းစီ ထုတ်ပေးပြီးနောက် မည်သည့်တိုကင်များ မှန်ကန်သည်ကို ဆုံးဖြတ်ရမည်ဖြစ်သည်။
ဤအရာကို ပြုလုပ်ရန် ပေးထားသော JSON Schema ကို context-free grammar (CFG) တစ်ခုအဖြစ် ပြောင်းလဲပါသည်။ grammar ဆိုသည်မှာ ဘာသာစကားတစ်ခုကို သတ်မှတ်ပေးသော စည်းမျဉ်းအစုတစ်ခုဖြစ်ပြီး context-free grammar ဆိုသည်မှာ သတ်မှတ်ထားသော စည်းမျဉ်းများနှင့် ကိုက်ညီသည့် grammar တစ်ခုဖြစ်သည်။ JSON နှင့် JSON Schema ကို ဘာသာစကားအတွင်း ဘာသည် မှန်ကန်သည်ကို သတ်မှတ်ပေးသော စည်းမျဉ်းများရှိသည့် သီးခြားဘာသာစကားများအဖြစ် တွေးနိုင်ပါသည်။ အင်္ဂလိပ်ဘာသာတွင် verb မပါသော စာကြောင်းတစ်ကြောင်း မမှန်ကန်သကဲ့သို့ JSON တွင်လည်း trailing comma ပါခြင်းသည် မမှန်ကန်ပါ။
ထို့ကြောင့် JSON Schema တစ်ခုစီအတွက် ၎င်း schema ကို ကိုယ်စားပြုသော grammar တစ်ခုကို တွက်ချက်ပြီး မော်ဒယ် sampling ပြုလုပ်နေစဉ် အလွယ်တကူ အသုံးပြုနိုင်ရန် ၎င်း၏ component များကို ကြိုတင်ပြုပြင်ဆောင်ရွက်ထားပါသည်။ ထို့ကြောင့် schema အသစ်တစ်ခုနှင့် ပထမဆုံး တောင်းဆိုမှုတွင် latency penalty ဖြစ်ပေါ်ခြင်းဖြစ်သည်—sampling အတွင်း ထိရောက်စွာ အသုံးပြုနိုင်မည့် ဤ artifact ကို ထုတ်လုပ်ရန် schema ကို ကြိုတင်ပြုပြင်ဆောင်ရွက်ရမည်ဖြစ်သည်။
sampling ပြုလုပ်နေစဉ် တိုကင်တိုင်းပြီးနောက် ကျွန်ုပ်တို့၏ inference engine သည် ယခင်ထုတ်ပေးထားသော တိုကင်များနှင့် grammar အတွင်း နောက်တစ်ဆင့်တွင် မည်သည့်တိုကင်များ မှန်ကန်ကြောင်း ညွှန်ပြထားသော စည်းမျဉ်းများအပေါ် အခြေခံ၍ နောက်ထုတ်ပေးနိုင်သော မှန်ကန်သည့် တိုကင်များကို သတ်မှတ်ပါမည်။ ထို့နောက် နောက် sampling step ကို mask လုပ်ရန် ဤတိုကင်စာရင်းကို အသုံးပြုပြီး မမှန်ကန်သော တိုကင်များ၏ ဖြစ်နိုင်ခြေကို အမှန်တကယ် 0 သို့ လျှော့ချပေးသည်။ schema ကို ကြိုတင်ပြုပြင်ဆောင်ရွက်ထားသောကြောင့် cached data structure ကို အသုံးပြု၍ latency overhead အနည်းဆုံးဖြင့် ထိရောက်စွာ ပြုလုပ်နိုင်ပါသည်။
ဤပြဿနာအတွက် အခြားနည်းလမ်းများတွင် constrained decoding အတွက် finite state machines (FSMs) သို့မဟုတ် regexes (ယေဘုယျအားဖြင့် FSMs ဖြင့် အကောင်အထည်ဖော်ထားသည်) ကို မကြာခဏ အသုံးပြုကြသည်။ ၎င်းတို့သည် တိုကင်တစ်ခုစီ ထုတ်ပေးပြီးနောက် မည်သည့်တိုကင်များ မှန်ကန်သည်ကို dynamic အနေဖြင့် update လုပ်ပေးသောကြောင့် ဆင်တူစွာ လုပ်ဆောင်သော်လည်း CFG approach နှင့် နှိုင်းယှဉ်လျှင် အရေးကြီးသော ကွာခြားချက်အချို့ ရှိပါသည်။ အထူးသဖြင့် CFG များသည် FSM များထက် ပိုမိုကျယ်ပြန့်သော language class ကို ဖော်ပြနိုင်သည်။ လက်တွေ့တွင် အထက်တွင် ဖော်ပြထားသော value schema ကဲ့သို့ အလွန်ရိုးရှင်းသော စီမံချက်များအတွက် ဤကွာခြားချက်သည် အရေးမကြီးပါ။ သို့သော် nested သို့မဟုတ် recursive data structures ပါဝင်သော ပိုမိုရှုပ်ထွေးသော စီမံချက်များအတွက် ဤကွာခြားချက်သည် အဓိပ္ပာယ်ရှိသည်ဟု ကျွန်ုပ်တို့ တွေ့ရှိခဲ့သည်။ ဥပမာအားဖြင့် FSM များသည် ယေဘုယျအားဖြင့် recursive types များကို မဖော်ပြနိုင်သဖြင့် FSM အခြေပြု နည်းလမ်းများသည် deeply nested JSON တွင် parentheses များကို ကိုက်ညီအောင်လုပ်ရန် ခက်ခဲနိုင်သည်။ အောက်ပါတို့သည် Structured Outputs နှင့်အတူ OpenAI API တွင် ပံ့ပိုးထားသော sample recursive schema တစ်ခုဖြစ်ပြီး FSM ဖြင့် ဖော်ပြရန် မဖြစ်နိုင်ပါ။
UI element တစ်ခုစီတွင် root schema ကို recursive အနေဖြင့် ကိုးကားသော arbitrary children များ ရှိနိုင်သည်ကို မှတ်သားပါ။ ဤပြောင်းလွယ်ပြင်လွယ်မှုသည် CFG approach က ပံ့ပိုးပေးသော အရာတစ်ခုဖြစ်သည်။
Structured Outputs ကို အသုံးပြုရာတွင် မှတ်ထားသင့်သော ကန့်သတ်ချက်အချို့ ရှိပါသည်:
- Structured Outputs သည် JSON Schema ၏ အစိတ်အပိုင်းတစ်စုကိုသာ ခွင့်ပြုပါသည်၊ အသေးစိတ်ကို ကျွန်ုပ်တို့၏ docs တွင်(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) ဖော်ပြထားပါသည်။ ၎င်းက ကျွန်ုပ်တို့အား အကောင်းဆုံးဖြစ်နိုင်သော စွမ်းဆောင်ရည်ကို သေချာစေရန် ကူညီပါသည်။
- စီမံချက်အသစ်တစ်ခုနှင့်အတူ ပထမဆုံး API တုံ့ပြန်မှုတွင် latency အပိုတိုးလာမည်ဖြစ်သော်လည်း နောက်ဆက်တွဲ တုံ့ပြန်မှုများမှာ latency penalty မရှိဘဲ မြန်ဆန်မည်ဖြစ်သည်။ အဘယ်ကြောင့်ဆိုသော် ပထမဆုံး တောင်းဆိုမှုအတွင်း အထက်တွင် ဖော်ပြထားသည့်အတိုင်း စီမံချက်ကို ပြုပြင်ဆောင်ရွက်ပြီး နောက်ပိုင်း အမြန်ပြန်လည်အသုံးပြုနိုင်ရန် ဤ artifact များကို cache လုပ်ထားသောကြောင့်ဖြစ်သည်။ ပုံမှန် စီမံချက်များသည် ပထမဆုံး တောင်းဆိုမှုတွင် 10 စက္ကန့်အောက်သာ လိုအပ်သော်လည်း ပိုမိုရှုပ်ထွေးသော စီမံချက်များမှာ တစ်မိနစ်အထိ ကြာနိုင်သည်။
- မော်ဒယ်သည် မလုံခြုံသော တောင်းဆိုချက်ကို ငြင်းဆိုရန် ရွေးချယ်ပါက စီမံချက်ကို မလိုက်နာနိုင်ပါ။ ၎င်းက ငြင်းဆိုရန် ရွေးချယ်လျှင် ပြန်လာသော message တွင်
refusalboolean ကို true အဖြစ် သတ်မှတ်ထားမည်ဖြစ်ပြီး ယင်းကို ညွှန်ပြမည်ဖြစ်သည်။ - ထုတ်လုပ်မှုသည် မပြီးမီ
max_tokensသို့မဟုတ် အခြား stop condition တစ်ခုသို့ ရောက်သွားပါက မော်ဒယ်သည် စီမံချက်ကို မလိုက်နာနိုင်ပါ။ - Structured Outputs သည် မော်ဒယ်အမှားအမျိုးအစားအားလုံးကို မကာကွယ်ပေးနိုင်ပါ။ ဥပမာအားဖြင့် မော်ဒယ်သည် JSON object အတွင်းရှိ တန်ဖိုးများထဲတွင် အမှားများ ပြုလုပ်နိုင်သေးသည် (ဥပမာ သင်္ချာညီမျှချက်တစ်ခု၏ အဆင့်တစ်ဆင့်ကို မှားခြင်း)။ ဖွံ့ဖြိုးတိုးတက်သူများအနေဖြင့် အမှားများကို တွေ့ရှိပါက system instructions တွင် ဥပမာများပေးခြင်း သို့မဟုတ် လုပ်ငန်းတာဝန်များကို ပိုမိုလွယ်ကူသော အလုပ်ခွဲများအဖြစ် ခွဲခြားခြင်းကို အကြံပြုပါသည်။
- Structured Outputs သည် parallel function calls နှင့် ကိုက်ညီမှုမရှိပါ။ parallel function call တစ်ခု ထုတ်လုပ်လိုက်သောအခါ ပေးထားသော စီမံချက်များနှင့် မကိုက်ညီနိုင်ပါ။ parallel function calling ကို ပိတ်ရန်
parallel_tool_calls: falseဟု သတ်မှတ်ပါ။ - Structured Outputs နှင့်အတူ ပေးထားသော JSON Schemas များသည် ဒေတာ လုံးဝသိမ်းဆည်းမထားခြင်း(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) (ZDR) အတွက် အကျုံးမဝင်ပါ။
Structured Outputs ကို ယနေ့ API တွင် အများပြည်သူအသုံးပြုနိုင်ရန် ရရှိနေပြီဖြစ်သည်။
လုပ်ဆောင်ချက် ခေါ်ဆိုမှုနှင့်အတူ Structured Outputs ကို API တွင် function calling ကို ပံ့ပိုးသော မော်ဒယ်အားလုံးတွင် ရရှိနိုင်သည်။ ၎င်းတွင် ကျွန်ုပ်တို့၏ နောက်ဆုံးပေါ် မော်ဒယ်များ (gpt-4o, gpt-4o-mini)၊ gpt-4-0613 နှင့် gpt-3.5-turbo-0613 အပါအဝင် ၎င်းနောက်ထွက် မော်ဒယ်အားလုံး၊ နှင့် function calling ကို ပံ့ပိုးသော fine-tuned မော်ဒယ်များ ပါဝင်သည်။ ဤလုပ်ဆောင်နိုင်မှုကို Chat Completions API၊ Assistants API နှင့် Batch API တို့တွင် ရရှိနိုင်သည်။ လုပ်ဆောင်ချက် ခေါ်ဆိုမှုနှင့်အတူ Structured Outputs သည် vision inputs များနှင့်လည်း ကိုက်ညီသည်။
response formats နှင့်အတူ Structured Outputs ကို gpt-4o-mini နှင့် gpt-4o-2024-08-06 တွင်သာမက ဤမော်ဒယ်များအပေါ် အခြေခံထားသော fine tunes များတွင်လည်း ရရှိနိုင်သည်။ ဤလုပ်ဆောင်နိုင်မှုကို Chat Completions API၊ Assistants API နှင့် Batch API တို့တွင် ရရှိနိုင်သည်။ response formats နှင့်အတူ Structured Outputs သည် vision inputs များနှင့်လည်း ကိုက်ညီသည်။
အသစ်သော gpt-4o-2024-08-06 သို့ ပြောင်းလဲအသုံးပြုခြင်းဖြင့် ဖွံ့ဖြိုးတိုးတက်သူများသည် gpt-4o-2024-05-13 နှင့် နှိုင်းယှဉ်လျှင် input များအတွက် 50% ($2.50/1M input tokens) နှင့် output များအတွက် 33% ($10.00/1M output tokens) သက်သာစေမည်ဖြစ်သည်။
Structured Outputs ကို စတင်အသုံးပြုရန် ကျွန်ုပ်တို့၏ စာတမ်းများ(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) ကို ကြည့်ပါ။
Structured Outputs သည် open source community ၏ ကောင်းမွန်သော လုပ်ဆောင်ချက်များမှ စိတ်ကူးရယူထားပြီး အထူးသဖြင့် outlines(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်), jsonformer(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်), instructor(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်), guidance(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) နှင့် lark(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) libraries များကို ဆိုလိုပါသည်။
ရေးသားသူ
အဓိက ပံ့ပိုးသူများ
Chris Colby, Melody Guan, Michelle Pokrass, Ted Sanders, Brian Zhang
ကျေးဇူးတင်လွှာ
John Allard, Filipe de Avila Belbute Peres, Ilan Bigio, Owen Campbell-Moore, Chen Ding, Atty Eleti, Elie Georges, Katia Gil Guzman, Jeff Harris, Johannes Heidecke, Beth Hoover, Romain Huet, Tomer Kaftan, Jillian Khoo, Karolis Kosas, Ryan Liu, Kevin Lu, Lindsay McCallum, Rohan Nuttall, Joe Palermo, Leher Pathak, Ishaan Singal, Felipe Petroski Such, Freddie Sulit, David Weedon