API дахь Structured Outputs-ийг танилцуулж байна
Бид API-д Structured Outputs-ийг нэвтрүүлж байна—одоо загварын гаралт нь хөгжүүлэгчийн өгсөн JSON Schema-уудыг найдвартай дагана.

Өнгөрсөн жил DevDay дээр бид JSON горимыг танилцуулсан бөгөөд энэ нь манай загваруудаар найдвартай аппликейшн бүтээхийг хүссэн хөгжүүлэгчдэд хэрэгтэй суурь бүрэлдэхүүн байсан. JSON горим нь хүчинтэй JSON гаралт үүсгэхэд загварын найдвартай байдлыг сайжруулдаг ч загварын хариу тодорхой схемд нийцэнэ гэдгийг баталгаажуулдаггүй. Өнөөдөр бид API-д Structured Outputs-ийг танилцуулж байна. Энэ нь загвараар үүсгэсэн гаралт хөгжүүлэгчдийн өгсөн JSON Schema-уудтай яг таарахыг хангах зориулалттай шинэ боломж юм.
Бүтэцгүй оролтоос бүтцэт өгөгдөл үүсгэх нь өнөөдрийн аппликейшнуудад AI-ийн үндсэн хэрэглээний нэг юм. Хөгжүүлэгчид OpenAI API-г ашиглан функц дуудах(шинэ цонхонд нээгдэнэ)-аар өгөгдөл татах, асуултад хариулах чадвартай хүчирхэг туслахууд бүтээх, өгөгдөл оруулах зориулалтаар бүтцэт өгөгдөл гаргаж авах, мөн LLM-үүдэд үйлдэл хийх боломж олгодог олон алхамт агент урсгалууд бүтээдэг. Хөгжүүлэгчид энэ чиглэлд LLM-ийн хязгаарлалтыг даван туулахын тулд нээлттэй эхийн хэрэгслүүд, prompt ашиглах, мөн загварын гаралт өөрсдийн системтэй харилцан ажиллахад шаардлагатай форматтай таарахыг баталгаажуулахын тулд хүсэлтийг дахин дахин илгээх зэрэг аргыг удаан хугацаанд хэрэглэсээр ирсэн. Structured Outputs нь OpenAI-ийн загваруудыг хөгжүүлэгчийн өгсөн схемүүдтэй тааруулан хязгаарлах, мөн төвөгтэй схемүүдийг илүү сайн ойлгохоор загваруудаа сургах замаар энэ асуудлыг шийддэг.
Төвөгтэй JSON схемийг дагах манай үнэлгээн дээр Structured Outputs-тэй шинэ gpt-4o-2024-08-06 загвар 100%-ийн төгс оноо авсан. Харин gpt-4-0613 40%-иас бага оноо авсан.
Structured Outputs-ийн тусламжтайгаар gpt-4o-2024-08-06 нь манай үнэлгээн дээр 100% найдвартай байдалд хүрч, гаралтын схемүүдтэй төгс таарсан.
Бид API-д Structured Outputs-ийг хоёр хэлбэрээр нэвтрүүлж байна:
1. Функц дуудах: tools-ээр дамжих Structured Outputs нь таны функцийн тодорхойлолт дотор strict: true-г тохируулснаар боломжтой. Энэ боломж нь gpt-4-0613, gpt-3.5-turbo-0613 болон түүнээс хойших бүх загвар зэрэг хэрэгсэл дэмждэг бүх загварт ажиллана. Structured Outputs идэвхжсэн үед загварын гаралт нь өгсөн хэрэгслийн тодорхойлолттой таарна.
2. response_format параметрийн шинэ сонголт: хөгжүүлэгчид одоо response_format параметрийн шинэ сонголт болох json_schema-аар JSON Schema өгөх боломжтой. Энэ нь загвар хэрэгсэл дуудаж биш, харин хэрэглэгчид бүтцэт байдлаар хариулж байгаа үед хэрэгтэй. Энэ боломж манай хамгийн шинэ GPT‑4o загваруудтай ажиллана: өнөөдөр гарсан gpt-4o-2024-08-06 болон gpt-4o-mini-2024-07-18. response_format-ийг strict: true-тэй өгсөн үед загварын гаралт нь өгсөн схемтэй таарна.
Аюулгүй байдал нь OpenAI-ийн хамгийн чухал тэргүүлэх чиглэлүүдийн нэг бөгөөд шинэ Structured Outputs боломж нь манай одоогийн аюулгүй байдлын бодлогыг мөрдөж, загварт аюултай хүсэлтээс татгалзах боломжийг хэвээр олгоно. Хөгжүүлэлтийг илүү хялбар болгохын тулд API хариун дээр шинэ refusal string утга нэмэгдсэн бөгөөд энэ нь загвар схемд таарах гаралтын оронд татгалзсан хариу үүсгэсэн эсэхийг хөгжүүлэгчид программчилсан аргаар илрүүлэх боломж олгодог. Хариунд татгалзалт агуулагдаагүй бөгөөд загварын хариу хугацаанаасаа өмнө тасалдаагүй бол (finish_reason-оор илэрхийлэгдсэнчлэн) загварын хариу нь өгсөн схемтэй таарах хүчинтэй JSON-ийг найдвартай үүсгэнэ.
Манай Python болон Node SDK-ууд Structured Outputs-ийн уугуул дэмжлэгтэйгээр шинэчлэгдсэн. Хэрэгслүүдэд эсвэл хариу формат болгон схем өгөх нь Pydantic эсвэл Zod объект өгөхтэй адил хялбар болсон бөгөөд манай SDK-ууд өгөгдлийн төрлийг дэмжигдэх JSON схем болгон хөрвүүлэх, JSON хариуг төрлөөр тодорхойлогдсон өгөгдлийн бүтэц рүү автоматаар десериалчлах, мөн шаардлагатай үед татгалзалтыг задлан унших ажлыг хийнэ.
Дараах жишээнүүд нь функц дуудахтай Structured Outputs-ийн уугуул дэмжлэгийг харуулж байна.
response_format-д мөн уугуул Structured Outputs дэмжлэг бий.
Хөгжүүлэгчид янз бүрийн хэрэглээнд зориулан бүтцэт өгөгдөл үүсгэхдээ OpenAI-ийн загваруудыг түгээмэл ашигладаг. Нэмэлт жишээнүүдээс дурдвал:
Жишээлбэл, хөгжүүлэгчид Structured Outputs-ийг ашиглан код эсвэл UI үүсгэдэг аппликейшн хийж болно. Дараах бүх жишээ ижил response_format-ийг ашигладаг бөгөөд хэрэглэгчийн оролтоос хамааран янз бүрийн UI үүсгэхэд ашиглаж болно.
Та хэрэглэгчийн интерфэйсийн туслах юм. Таны ажил бол хэрэглэгчдэд өөрсдийн вэбсайт болон аппын санаагаа дүрслэн харахад нь туслах явдал юм.Хариуны эцсийн чанарыг сайжруулахын тулд загварт chain of thought-д зориулсан тусдаа талбар өгөх нь ашигтай байж болно.
Жишээлбэл, уулзалтын тэмдэглэлээс хийх ажлууд, дуусах хугацаа, хуваарилалтыг гаргаж авахыг загварт зааварлах.
JSON Schema-тай таарах загварын гаралтын найдвартай байдлыг сайжруулахын тулд бид хоёр хэсэгтэй арга хэрэглэсэн. Нэгдүгээрт, бид хамгийн шинэ загвар болох gpt-4o-2024-08-06-г төвөгтэй схемүүдийг ойлгож, тэдгээрт хамгийн сайн таарах гаралтыг хэрхэн үүсгэхийг сургаж бэлтгэсэн. Гэвч загварын зан төлөв угаасаа детерминистик бус—энэ загварын гүйцэтгэл сайжирсан ч (манай жишиг дээр 93%) хөгжүүлэгчдэд бат бөх аппликейшн бүтээхэд хэрэгтэй найдвартай түвшинд хүрээгүй. Тиймээс бид загварын гаралтыг хязгаарлаж 100% найдвартай байдалд хүргэхийн тулд инженерчлэлд суурилсан, детерминистик аргыг мөн хэрэглэсэн.
Манай арга нь constrained sampling буюу constrained decoding гэж нэрлэгддэг техник дээр суурилдаг. Анхдагчаар загвараас гаралт үүсгэхээр сэмпл хийх үед тэдгээр нь огт хязгаарлагдмал биш бөгөөд дараагийн гаралт болгон үгийн сан дахь ямар ч токеныг сонгож чадна. Энэ уян хатан байдал нь загварт алдаа гаргах боломж олгодог; жишээлбэл, хүчинтэй JSON үүсгэхгүй байсан ч хаалттай буржгар хаалт токеныг ерөнхийдөө хүссэн үедээ сэмпл хийж болно. Хүчинтэй гаралтыг албадуулахын тулд бид загваруудаа боломжит бүх токеноор биш, харин өгсөн схемийн дагуу хүчинтэй байх токенуудаар л хязгаарладаг.
Практикт энэ хязгаарлалтыг хэрэгжүүлэх нь төвөгтэй байж болно, учир нь хүчинтэй токенууд нь загварын гаралтын явцад байнга өөрчлөгддөг. Дараах схем бидэнд байна гэж үзье:
Гаралтын эхэнд хүчинтэй байх токенуудад {, {“, { зэрэг орно. Гэвч загвар {“val-ийг аль хэдийн сэмпл хийсэн бол { нь цаашид хүчинтэй токен байхаа болино. Иймээс бид динамик хязгаарласан декодчлолыг хэрэгжүүлж, хариуны эхэнд урьдчилан тогтоохын оронд токен бүр үүссэний дараа ямар токен хүчинтэйг тодорхойлох шаардлагатай болдог.
Үүнийг хийхийн тулд бид өгсөн JSON Schema-г контекстгүй дүрэм (CFG) болгон хувиргадаг. Дүрэм гэдэг нь хэлийг тодорхойлдог дүрмүүдийн цогц бөгөөд контекстгүй дүрэм нь тодорхой дүрмүүдэд нийцсэн дүрэм юм. JSON болон JSON Schema-г тухайн хэл дотор юу хүчинтэйг тодорхойлох дүрэмтэй тусгай хэлүүд гэж ойлгож болно. Англи хэлэнд үйл үггүй өгүүлбэр хүчинтэй биш байдагтай адил JSON-д төгсгөлд таслалтай байх нь хүчинтэй биш.
Иймээс JSON Schema бүрийн хувьд бид тухайн схемийг илэрхийлэх дүрмийг тооцоолж, загварын сэмпл хийх явцад хялбар хандахын тулд бүрэлдэхүүн хэсгүүдийг нь урьдчилан боловсруулдаг. Тиймээс шинэ схемтэй эхний хүсэлт саатлын нэмэлттэй байдаг—бид сэмпл хийх явцад үр ашигтай ашиглах энэ артефактыг үүсгэхийн тулд схемийг урьдчилан боловсруулах ёстой.
Сэмпл хийх явцад токен бүрийн дараа манай inference engine нь өмнө нь үүсгэсэн токенууд болон дараа нь ямар токен хүчинтэйг заадаг дүрмийн дүрмүүдэд үндэслэн дараагийн боломжит токенуудыг тодорхойлно. Дараа нь бид энэ токенуудын жагсаалтыг ашиглан дараагийн сэмпл хийх алхмыг масклаж, хүчинтэй бус токенуудын магадлалыг 0 болгон бууруулдаг. Бид схемийг урьдчилан боловсруулсан тул үүнийг хамгийн бага саатлын нэмэлттэйгээр үр ашигтай хийхийн тулд кэшлэгдсэн өгөгдлийн бүтцийг ашиглаж чадна.
Энэ асуудлын өөр аргууд нь хязгаарласан декодчлолд ихэвчлэн finite state machine (FSM) эсвэл regex (ерөнхийдөө FSM-ээр хэрэгжүүлдэг)-ийг ашигладаг. Эдгээр нь токен бүр үүссэний дараа ямар токен хүчинтэйг динамикаар шинэчилдгээрээ төстэй боловч CFG аргатай харьцуулахад хэд хэдэн гол ялгаатай. Ялангуяа, CFG нь FSM-ээс илүү өргөн ангиллын хэлүүдийг илэрхийлж чаддаг. Практикт энэ нь дээр харуулсан value схем шиг маш энгийн схемүүдэд тийм ч чухал биш. Гэвч үүрлэсэн эсвэл рекурсив өгөгдлийн бүтцийг агуулсан илүү төвөгтэй схемүүдийн хувьд энэ ялгаа утга учиртай гэж бид үздэг. Жишээлбэл, FSM нь ерөнхийдөө рекурсив төрлүүдийг илэрхийлж чаддаггүй бөгөөд энэ нь FSM-д суурилсан аргууд гүн үүрлэсэн JSON дахь хаалтуудыг тааруулахад бэрхшээлтэй байж болохыг илтгэнэ. Дараах нь Structured Outputs-тэй OpenAI API дээр дэмжигддэг боловч FSM-ээр илэрхийлэх боломжгүй рекурсив схемийн жишээ юм.
UI элемент бүр root схемийг рекурсив байдлаар заасан дурын хүүхэд элементүүдтэй байж болдгийг анхаарна уу. Энэ уян хатан байдлыг CFG арга олгодог.
Structured Outputs-ийг ашиглахдаа анхаарах хэд хэдэн хязгаарлалт бий:
- Structured Outputs нь зөвхөн JSON Schema-гийн нэг хэсгийг дэмждэг бөгөөд энэ талаар манай баримтжуулалтад(шинэ цонхонд нээгдэнэ) дэлгэрэнгүй тайлбарласан. Энэ нь бидэнд аль болох сайн гүйцэтгэлийг хангахад тусалдаг.
- Шинэ схемтэй эхний API хариу нэмэлт сааталтай байна, харин дараагийн хариунууд саатлын нэмэлтгүйгээр хурдан байна. Учир нь эхний хүсэлтийн үед бид дээр дурдсанчлан схемийг боловсруулж, дараа нь хурдан дахин ашиглахын тулд эдгээр артефактуудыг кэшилдэг. Ердийн схемүүд эхний хүсэлт дээр 10 секундээс бага хугацаанд боловсруулагддаг ч илүү төвөгтэй схемүүд нэг минут хүртэл хугацаа авч болно.
- Хэрэв загвар аюултай хүсэлтээс татгалзахаар шийдвэл схемийг дагаж чадахгүй байж болно. Татгалзсан тохиолдолд буцаах мессежийн
refusalboolean нь true болж үүнийг илтгэнэ. - Хэрэв үүсгэлт дуусахаас өмнө
max_tokensэсвэл өөр зогсоох нөхцөлд хүрвэл загвар схемийг дагаж чадахгүй байж болно. - Structured Outputs нь загварын бүх төрлийн алдааг сэргийлдэггүй. Жишээлбэл, загвар JSON объектын утгуудын дотор алдаа гаргаж болно (жиш., математикийн тэгшитгэлийн нэг алхмыг буруу хийх). Хэрэв хөгжүүлэгчид алдаа олбол системийн зааварт жишээ өгөх эсвэл ажлуудыг илүү энгийн дэд ажлуудад хуваахыг зөвлөж байна.
- Structured Outputs нь параллель функц дуудалттай нийцдэггүй. Параллель функц дуудалт үүссэн үед энэ нь өгсөн схемүүдтэй таарахгүй байж болно. Параллель функц дуудахыг идэвхгүй болгохын тулд
parallel_tool_calls: false-г тохируулна уу. - Structured Outputs-тэй өгсөн JSON Schema-ууд нь тэг өгөгдөл хадгалалт(шинэ цонхонд нээгдэнэ) (ZDR)-д хамрагдахгүй.
Structured Outputs өнөөдрөөс API-д ерөнхийд нь ашиглах боломжтой боллоо.
Функц дуудахтай Structured Outputs нь API дахь функц дуудахыг дэмждэг бүх загварт боломжтой. Үүнд манай хамгийн шинэ загварууд (gpt-4o, gpt-4o-mini), gpt-4-0613 болон gpt-3.5-turbo-0613-аас хойших бүх загвар, мөн функц дуудахыг дэмждэг аливаа fine-tuned загварууд орно. Энэ боломж нь Chat Completions API, Assistants API, болон Batch API дээр ашиглагдана. Функц дуудахтай Structured Outputs нь мөн vision оролттой нийцдэг.
Хариу форматын Structured Outputs нь gpt-4o-mini, gpt-4o-2024-08-06, мөн эдгээр загварт суурилсан аливаа fine-tune дээр боломжтой. Энэ боломж нь Chat Completions API, Assistants API, болон Batch API дээр ашиглагдана. Хариу форматын Structured Outputs нь мөн vision оролттой нийцдэг.
Шинэ gpt-4o-2024-08-06-д шилжсэнээр хөгжүүлэгчид gpt-4o-2024-05-13-тай харьцуулахад оролт дээр 50% ($2.50/1M input tokens), гаралт дээр 33% ($10.00/1M output tokens) хэмнэнэ.
Structured Outputs-ийг ашиглаж эхлэхийн тулд манай баримтжуулалтыг(шинэ цонхонд нээгдэнэ) үзнэ үү.
Structured Outputs нь нээлттэй эхийн хамтын нийгэмлэгийн гайхалтай ажлуудаас, тухайлбал outlines(шинэ цонхонд нээгдэнэ), jsonformer(шинэ цонхонд нээгдэнэ), instructor(шинэ цонхонд нээгдэнэ), guidance(шинэ цонхонд нээгдэнэ), болон lark(шинэ цонхонд нээгдэнэ) сангуудаас санаа авсан.
Зохиогч
Үндсэн хувь нэмэр оруулагчид
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