Бид шуурхай дуу хоолойн AI-д зориулсан бодит цагийн системийг зургаан сарын дотор хэрхэн бүтээсэн бэ

Дуу хоолойн AI-ийн хувьд, хэзээ ярихаа мэдэх нь бодсоноос хэцүү. Хүмүүс секундийн өчүүхэн хэсэгт төвөггүй ээлжилж ярьдаг ч, өмнөх дуу хоолойн AI системүүд энэ хэмнэлийг гүйцдэггүй байв. Тэдний ээлжид суурилсан бүтэц ээлж илрүүлэгч хэмээх жижиг загваруудад тулгуурладаг байв. Тэдний үүрэг даалгавар амаргүй: хэт эрт таавал, хэрэглэгчийн үг тасарна, хэт оройтвол, хариу удаан санагдана. Илрүүлэгч шийдвэрээ гаргасны дараа л, түүнээс хавьгүй том LLM ажиллаж эхэлдэг байв.

Манай гурав дахь үеийн дуу хоолойн систем болох GPT‑Live⁠ нь ээлж илрүүлэгчийг аудио замаас хассан. Түүний дуу хоолойн загвар бүрэн дуплекс тул, нэгэн зэрэг сонсож, ярьж чадна. Ингэснээр, тусдаа илрүүлэгч хэрэггүй болж, яриа илүү шуурхай, ердийн мэт санагдана. Илүү гүнзгий сэтгэн бодох эсвэл хэрэгсэл ашиглах шаардлагатай үед, GPT‑Live ярианы урсгалыг таслахгүйгээр GPT‑5.5 зэрэг тэргүүлэгч загваруудтай зөвлөлдөж чадна. Эдгээр чадвар нийлснээр, GPT‑Live нь ярианы шуурхай байдал болон оюун ухааны урьд өмнө байгаагүй хослолыг бүрдүүлдэг.

Энэ туршлагыг өргөн хэмжээнд хүргэхийн тулд, бага хоцролтод оновчилсон шинэ системийн бүтэц шаардлагатай болсон. Ердийн хүсэлт-хариултын хиймэл оюуны хариултаас ялгаатай нь, манай систем ирж буй аудиог дуу хоолойн загвар руу, гарах яриаг хэрэглэгч рүү урсгалаар дамжуулахын зэрэгцээ, илгээлтийг тусдаа асинхрон замаар боловсруулдаг. Сүүлийн зургаан сарын хугацаанд бид яриаг эхнээс төгсгөл хүртэл жигд урсгахын тулд, загварын хиймэл оюуны хариулт, контекстийн удирдлага, медиа дамжуулалтыг шинэчилсэн.

Энэ бүтэц дуу хоолойн үндсэн зам ба аппликэйшний логикийн хооронд тодорхой зааг мөн бий болгодог. Ингэснээр, шуурхай ажиллагаанд нөлөөлөхгүйгээр аппликэйшний зан байдлыг хялбархан тохируулж болно. Энэ суурь нь ChatGPT Voice-ийн өсөн нэмэгдэж буй боломжуудыг дэмждэг. Үүнд ChatGPT‑ийн суурин компьютерийн апп дээр компьютероороо удирдах, агентуудаа зохицуулах шинээр нэвтрүүлсэн боломж багтана.

Энэ нийтлэлд өмнөх ээлжид суурилсан системүүд яагаад бидний хэрэгцээг хангаж чадаагүй, шинэ системийн давхарга бүрийг хэрхэн шуурхай ажиллагаанд зориулан бүтээснийг тайлбарлана. GPT‑Live‑ийг үнэхээр шууд мэт болгохын тулд, хамтран ажилладаг төлөв хадгалдаг хиймэл оюуны хариулт, динамик контекстийн удирдлага, асинхрон илгээлт, протоколын түвшний оновчлолыг авч үзнэ.

Өмнөх дуу хоолойн бүтцүүд текстэн Том хэлний загварын (LLM) ээлжид суурилсан шинжийг өвлөсөн ч, ээлж бүрийг текстийн оронд тусдаа аудио багцаар дүрсэлдэг байв. Шаталсан системд, яриаг текст болгох, Том хэлний загвар (LLM), текстийг яриа болгох үйлдлүүд дараалан ажилладаг байв. Ийнхүү дараалуулах нь хоцролтыг нэмэгдүүлж, дуу хоолойн өнгө, хэмнэл зэрэг дохиог хэрэгсэхгүй болгодог байв.

Ярианаас ярианд буулгах загварууд аудиог шууд боловсруулснаар, энэ аргыг сайжруулсан. Загварыг яриаг шууд ойлгож, үүсгэдэг болгон сургаснаар, транскрипцийн үед алдагдах нарийн мэдээллийг хадгалж, илүү хурдан хариулах боломжтой болсон. Гэвч, хиймэл оюуны хариулт хэзээ эхлэхийг шийдэхдээ систем ээлж илрүүлэгчид тулгуурласан хэвээр байв. Загвар харилцан үйлчлэлийн илүү их хэсгийг хариуцдаг болсон ч, харилцаа ээлжид суурилсан хэвээр байв.

GPT‑Live дуу хоолойн загварт яриаг удирдах боломж өгдөг: аудио загвар руу орж, гарч байх зуур гүнзгий сэтгэн бодох болон хэрэгсэл ашиглах үйл явц асинхроноор явагдана. Системийн үндсэн үүрэг нь медиа гогцоог тасралтгүй ажиллуулах юм. Тэргүүлэгч загваруудыг дуудах, яриаг хадгалах зэрэг бусад ажил шууд замаас гадуур явагдана.

Энэ медиа гогцоог тасралтгүй ажиллуулах нь үргэлж амар байдаггүй. Дамжуулалт, боловсруулалт эсвэл хиймэл оюуны хариултын аливаа саатал сонсогдохуйц завсарлага эсвэл гажуудал болж болно. Өмнөх ээлжид суурилсан систем аудио багц ирэх цагийн багахан хэлбэлзлийг тэсвэрлэж чаддаг байв. Харин шууд медиа систем аудио фрейм бүрийг товлосон цагт хүргэх шаардлагатай.

ChatGPT Voice болон Realtime API дээрх өмнөх ажил бидэнд чухал суурь болсон. Бид аудио, видеог систем рүүгээ шууд оруулж, гаргахдаа хоцролтыг багасган илүү урьдчилан таамаглах боломжтой болгохын тулд дуу хоолойн дэд бүтцээ аль хэдийн шинэчилсэн⁠ байсан. GPT‑Live энэ загварыг улам хөгжүүлж, тасралтгүй ярианд зориулсан шинэ төлөв хадгалдаг хиймэл оюуны хариултын системээр медиаг загвар хүртэл урсгалаар дамжуулдаг болсон.

Гэхдээ урсгал хиймэл оюуны хариулт нь шийдлийн зөвхөн нэг хэсэг байв. Үүнийг боловсруулалтын орчинд сайн ажиллуулахын тулд клиентээс хиймэл оюуны хариултын стек хүртэл аудиог найдвартай хүргэхийн зэрэгцээ төлөв хадгалахтай холбоотой бэрхшээлийг шийдэх шаардлагатай болсон.

Бидний эрт гаргасан нэг шийдвэр бол медиа урсгалыг аппликэйшн болон бизнес логикоос зориуд тусгаарлах явдал байв. Аудио клиент ба дуу хоолойн загварын хооронд тусгай хурдан замаар дамжина. Илгээлт, хэрэгсэл ашиглалт болон аппликэйшний бусад ажил асинхрон RPC заагийн цаана явагдана. Удаан хэрэгслийн дуудлага эсвэл арын үйлчилгээ өөрийн үр дүнг саатуулж болох ч медиа урсгалыг зогсоож чадахгүй.

Энэ тусгаарлалт нь системд тохируулга хийх тодорхой зааг мөн бий болгодог. Аппликэйшнүүд аудиог тасралтгүй дамжуулах үүрэгтэй медиа урд талыг хөндөхгүйгээр хэрэгсэл, бодлого, арын системийн зан байдлаа өөрчилж болно. Шууд зам нь цомхон, урьдчилан таамаглах боломжтой хэвээр байж, бодит цагт заавал хийх ажилдаа төвлөрнө.

Бид өмнөх Python asyncio хэрэгжүүлэлтийг сольж, медиа урд тал болон хиймэл оюуны хариултын логикийг Go хэлээр бичсэн. Ингэснээр фрейм хүргэлтийн жигд байдал эрс сайжирч, шинэ системийн p95 нь өмнөх системийн p50-тай тэнцсэн.

WebRTC нь дамжуулалтын суурийг бүрдүүлдэг. Энэ нь хоцролт багатай медиад зориулагдсан бөгөөд пакет алдагдах, цагийн зөрүү үүсэх, клиентийн холболт өөрчлөгдөх үед ч үргэлжлэн ажиллана. Пакет оройтож ирвэл, WebRTC завсар гарахаас сэргийлж аудиог үл ялиг сунгаад, бодит цагтай дахин зэрэгцүүлэхийн тулд тоглуулалтыг түр хурдасгаж чадна.

Системийн хэмжээнд буферлэлт болон блоклолтыг багасгаснаар хүмүүсийн ярианаас хүлээдэг нэг секундээс богино хариу үйлдлийг хангаж чадна.

Төлөв хадгалдаг хиймэл оюуны хариулт өөрийн гэсэн ажиллагааны солилцоонуудтай. Дуу хоолойн холболт удаан хугацаанд идэвхтэй байж болох ч контекст нь тасралтгүй өсөж, загварын хувилбарууд эрэлтээс хамааран асаж, унтарна.

Эдгээр асуудлыг шийдэхийн тулд, бид загварын хувилбарын хооронд тасралтгүй шилжүүлэх механизм бүтээсэн. Шилжилт шаардлагатай үед, одоо ажиллаж буй хувилбартай зэрэгцүүлэн орлуулах загварын хувилбарыг халааж, одоогийн холболтын контекстээр урьдчилан дүүргэн, хоёуланд нь хиймэл оюуны хариултыг зэрэг ажиллуулаад шинэ хувилбар бүрэн бэлэн болмогц шилжүүлж болно.

Үүнтэй ижил үндсэн механизм динамик контекстийн шахалтыг мөн дэмждэг. Яриа үргэлжлэх тусам хуримтлагдсан контекст нь эцэстээ загварын контекстийн хязгаараас давж болно. Шахалт контекстийн хэмжээг хязгаарт багтаан бууруулж болох ч, энэ үйлдэл хугацаа шаарддаг. Мөн өмнөх контекстийг өөрчилдөг тул, урьд нь боловсруулсан токенуудын анхаарлын түлхүүр ба утгыг хадгалдаг загварын түлхүүр-утгын (KV) кэшийг хүчингүй болгоно. Тэр төлөвийг дахин бүрдүүлэхэд шинээр урьдчилан дүүргэх шаардлагатай тул, нэмэлт саатал үүснэ.

Үүний оронд, бид шахалтыг удирдлагатай өөр нэг шилжилт гэж үздэг. Анхны загварын хувилбар яриагаа үргэлжлүүлэх зуур систем контекстийг шахаж, шинэ контексттэй орлуулах загварын хувилбарыг бэлтгэнэ. Тэр хувилбар бэлэн болмогц, медиаг огт таслахгүйгээр шилжиж болно. Ингэснээр, систем урт дуудлагыг дэмжиж, шаардлагатай үед шахалт хийж чадна.

Хүнд боловсруулалтыг шууд замаас гадуур хийдэг тул, шилжүүлэх үед ч ярианы хэмнэл огт алдагдахгүй.

GPT‑Live одоо байгаа тэргүүлэгч загваруудыг дуудах чадвартай тул, ихээхэн хүчирхэг бөгөөд “ярих” үйлдлийг гүнзгий “бодох”-оос бодитоор салгадаг. Гэхдээ хоёр загвартай энэ бүтцийг нэг систем мэт мэдрүүлэхийн тулд, хоорондоо холбоотой инженерчлэлийн хоёр асуудлыг шийдэх шаардлагатай болсон.

Нэгдүгээрт, үргэлжилж буй ярианд үр дүн нь аль болох хурдан ирэх ёстой тул чиглүүлэлт, өгөгдөл боловсруулалтаас эхлээд хиймэл оюуны хариулт, хэрэгслийн дуудлага хүртэлх бүх илгээлтийн замын хоцролтыг багасгах шаардлагатай байв. Үүний зэрэгцээ, бүтээгдэхүүний бусад системд тусдаа мессежүүд хэрэгтэй хэвээр тул, үргэлжилж буй яриаг тэдний ойлгох хэлбэрээр дүрслэх шаардлагатай болсон.

Илгээлтийг хийхдээ, тэргүүлэгч загвар ярианд хэрэгтэй зүйл гаргах хүртэлх хугацааг оновчилдог. Тэргүүлэгч загвар сэтгэн бодох эсвэл хэрэгсэл ашиглах зуур дуу хоолойн загвар яриаг богино хугацаанд үргэлжлүүлж чадах ч, хэт удаан хариуг далдалж чадахгүй. Тиймээс, бид чиглүүлэлт, өгөгдөл боловсруулалт, хиймэл оюуны хариулт, хэрэгслийн дуудлагаас бүрдэх илгээлтийн бүтэн гогцоог шуурхай ажиллагааны төсөвт оруулсан.

Эхний оновчлол нь илгээлт хүсэхээс өмнө тэргүүлэгч загвар болон түүнд хэрэгтэй бүх хэрэгслийг бэлтгэх явдал юм. Дуу хоолойн холболт эхлэхэд аппликэйшний сервер тэргүүлэгч загварт хиймэл оюуны хариултын холболт үүсгэн, ярианы эхний контекстээр урьдчилан дүүргэдэг. Ингэснээр, эхний даалгасан хүсэлтээс өмнө өгөгдлийг бүрэн боловсруулсан байна.

Дараа нь бид тэр хиймэл оюуны хариултын холболтыг дуу хоолойн ярианы турш бэлэн байлгаж, дараалсан хүсэлтүүдэд тогтвортой холболтын хамаарал ашигладаг. Өгөгдлийн кэштэй хослоход, эдгээр арга хоцролтыг сайжруулахын зэрэгцээ ажиллагчийн доголдлоос хялбар сэргээх боломжийг хадгална.

Сэтгэн бодох хүчин чармайлт, гаралтын хязгаар, хэрэгслийн схем, загвар ба хэрэгслийн хоорондын давтан солилцоо нь яриа хэрэгтэй үр дүнг хэзээ авахад мөн нөлөөлдөг тул, бид хурдан хариу авахын тулд эдгээр тохиргоог тааруулсан. Илгээлтийн замд шаардагдах ажлыг багасгаснаар, дуу хоолойн загвар тэргүүлэгч загваруудын үр дүнг хурдан ашиглах боломжтой болсон.

Дуу хоолойн загвар ярианы тасралтгүй урсгал дээр ажилладаг ч, ChatGPT‑ийн ярианы UI болон манай аналитик, аюулгүй байдлын дэд бүтцийн зарим хэсэг зэрэг эргэн тойрны олон систем хэрэглэгч ба туслахын ээлжээр ажилласаар байна. Тиймээс, аппликэйшний сервер давхцсан, заримдаа хоёрдмол утгатай яриаг салгаж, тусдаа мессежүүд болгодог.

Аудио ирэхэд, сервер хэсэгчилсэн транскрипт болон хугацааны дохионд тулгуурлан хэн ярьж байгааг тодорхойлж, мессежийн дараалал үүсгэнэ. Хамгийн сүүлийн мессеж түр төлөвтэй үлдэнэ; яриа нэмж ирэхийн хэрээр текст, хугацаа, яригчийн оноолт бүгд өөрчлөгдөж болно. Яригч хангалттай удаан үргэлжлүүлж, оноолт найдвартай болмогц, сервер холбогдох мессежийг эцэслэнэ.

Яригчид давхцах нь үүнийг улам төвөгтэй болгодог. Хэрэглэгч ярьж байх үед, туслахын өгсөн богино хариу дохио (жишээ нь “мм-хм” эсвэл “за”) заавал тусдаа мессеж болох албагүй. Харин туслахын утга агуулгатай хөндлөнгийн үг ихэвчлэн тусдаа мессеж болох ёстой. Үүнтэй адилаар, хэрэглэгч дундуур нь ярьсан ч дэлгэцэд харагдах туслахын хариу уялдаатай байхыг бид чухалчилдаг.

Хэсэгчлэх бодлого бүр шуурхай байдал ба баттай байдлын хооронд тэнцвэр тогтоодог. Хэт эрт баталгаажуулбал, түүх тасарч, дараалал тогтворгүй болно; хэт удаан хүлээвэл, транскрипт болон түүнд тулгуурладаг функцүүд саатна. Тиймээс, систем яриаг хоёр холбоотой дүрслэлээр хадгалдаг: одоогийн төлөвийн урьдчилсан дүрслэл болон хэлсэн зүйлийн албан ёсны бүртгэл. Аппликэйшний UI дахь ярианы харагдац шинэчлэлтийг боловсруулж чаддаг тул, урьдчилсан дүрслэлийг ашиглана. Харин аналитикийн дамжуулах шугамд бүртгэхэд эцсийн транскрипт шаардлагатай.

Ингэснээр, шууд дуу хоолойн замд ээлжлэн ярих дэг тулгалгүйгээр ChatGPT‑ийн бусад хэсэгт харилцан ярианы тогтвортой дүрслэл өгдөг.

Шуурхай ажиллагаа нь хэрэглэгч товчлуурыг дарах мөчөөс эхэлнэ. GPT‑Live-ийн хувьд яриа эхлэхээс өмнө, систем медиа замыг байгуулж, аудиог загвараар дамжуулж эхлэх ёстой. Ингэснээр, эхлүүлэх дарааллын хэсэг бүр чухал замд орно.

Дээр дурдсанчлан, WebRTC нь бодит цагийн бат бөх суурь болдог ч, ердийн WebRTC холболтыг эхлүүлэхэд санаанд оромгүй олон протоколын гар барилт, сүлжээний нааш-цааш солилцоо шаарддаг. WebRTC нь QUIC зэрэг дараагийн протоколуудыг тодорхойлсон нааш-цааш солилцоог багасгах чиг хандлагаас өмнө бий болсон. Тиймээс, түүний суурь протоколуудыг хамтад нь ашиглахад заримдаа нэг ажлыг давтан хийдэг. Жишээлбэл, WebRTC-ийн бүтэн стекийн хүрээнд шаардлагагүй байсан ч, протокол бүр DoS халдлагаас хамгаалах өөрийн механизмтай байв.

Бид стекийг шинжилж, медиа ба өгөгдөл эхлэхэд шаардлагатай сүлжээний зургаан удаагийн нааш-цааш солилцоог ердөө нэг болгодог WebRTC Abridged Roundtrip Protocol (WARP⁠(шинэ цонхонд нээгдэнэ))-ыг боловсруулсан. WARP нь өмнөх хувилбаруудтай нийцтэй протоколын хэд хэдэн сайжруулалтаар үүнийг хэрэгжүүлдэг: DTLS гар барилтыг ICE дээр давхар дамжуулах (SPED⁠(шинэ цонхонд нээгдэнэ)), илүү хурдан DTLS 1.3⁠(шинэ цонхонд нээгдэнэ) гар барилт ашиглах, SCTP гар барилтыг урьдчилан тохиролцох (SNAP⁠(шинэ цонхонд нээгдэнэ)), мөн DCEP⁠(шинэ цонхонд нээгдэнэ) ашиглахын оронд өгөгдлийн сувгуудыг урьдчилан тохиролцох.

Өргөн хүрээний экосистемд энэ ажлын үр шимийг хүртээхийн тулд, бид WebRTC нийгэмлэгийн хамтрагчидтай ажиллан WARP-ыг нээлттэй техникийн тодорхойлолтуудын багц болгон зохиосон. Бид саналуудыг IETF-ийн TSVWG ажлын бүлгээр ахиулж байгаа бөгөөд WARP дэмжлэгийг libwebrtc болон Pion-д аль хэдийн нэмсэн. WebRTC-ийн бусад хэрэгжүүлэлтэд мөн ажил үргэлжилж байна.

Медиа гар барилтыг оновчилсны дараа, нэг саатал онцгойрон үлдсэн: WebRTC холбогдохоос өмнө SDP параметрүүдийг хуваалцахад ашигладаг дохиоллын солилцоо. Тэр солилцоог чухал замаас хасахын тулд, бид Instant Connect гэх аргыг боловсруулсан. Энэ нь серверийн хүчин чадлыг нөөцлөхгүй, одоо байгаа WebRTC хэрэгжүүлэлтүүдийг өөрчлөхгүйгээр эдгээр параметрийг урьдчилан тохиролцоно.

Instant Connect стандарт дохиоллын урсгалтай зэрэгцэн ажиллана. Урьдчилан тохиролцсон параметрүүд хүчинтэй бол эхний медиа пакет ирэхэд, сервер холболтыг бодитоор үүсгэж чадна. Хэрэв тэдгээр нь хуучирсан эсвэл хүчингүй бол, дохиоллын урсгал аль хэдийн эхэлсэн байх тул, клиент нэмэлт хоцролтгүйгээр стандарт горимд шилжинэ.

Instant Connect болон WARP хамтдаа хэрэглэгчийн үйлдлээс шууд медиа урсгал эхлэх хүртэлх хугацааг эрс багасгадаг. SDP солилцоог чухал замаас гаргаж, WARP дамжуулалтын гар барилтыг нэгтгэснээр, клиент одоо ганц UDP пакетаар холболт эхлүүлж чадна. Сервер нэн даруй хариулах боломжтой болж, системийн бусад хэсэг хэрэглэгчийн үнэхээр хүсдэг зүйл болох сонсох, хариулах ажлыг эхлүүлнэ.

Систем цаасан дээр хурдан харагдавч, бодит дуу хоолойн урсгалын үед гацаж болно. GPT‑Live-ийг хэрэглэгчидтэй харилцуулахаас өмнө, бид боловсруулалт дахь ChatGPT Voice холболтын багахан, аажмаар нэмэгдэх хувийг одоогийн дэвшилтэт дуу хоолойн горим болон шинэ систем рүү зэрэг чиглүүлсэн чимээгүй туршилт хийсэн. Дэвшилтэт дуу хоолойн горим хэрэглэгчдэд хэвийн үйлчилсэн хэвээр байхад далд зам зөвхөн унших горимоор хиймэл оюуны хариултыг ажиллуулсан. Ингэснээр хэрэглэгчдийн сонсох зүйлд өөрчлөлт оруулахгүйгээр системийг бодит клиент, сүлжээ, холболтын үргэлжлэх хугацаа, газарзүйн тархалттай тулган туршсан.

Эхний сургамжуудын нэг нь хүчин чадлыг зөвхөн GPU-ийн нэвтрүүлэх чадамжаар хэмжиж болохгүй явдал байв. дуу хоолойн холболтууд нээлттэй хэвээр байж фреймийг тасралтгүй илгээдэг тул CPU талын урсгал зохицуулагч, дараалал, сүлжээний замууд хиймэл оюуны хариулттай зэрэгцэн өргөжих ёстой. Бодит ачааллын үед нэг туслах бүрэлдэхүүн хэсэг ачааллын туршилтын тооцооллоос эрт дээд хүчин чадалдаа хүрч, хиймэл оюуны хариултын хүсэлтүүд хуримтлагдан, хоцролт улам нэмэгдсэн. Бид хүчин чадлын талаарх асуултаа “Нэг GPU хэдэн хүсэлт боловсруулах вэ?” гэдгээс “Фрейм бүрийг хугацаанд нь дамжуулахын зэрэгцээ систем хэдэн холболтыг нэгэн зэрэг тогтвортой ажиллуулах вэ?” болгон өөрчилсөн.

Туршилт мөн газарзүйн байршлыг эн тэргүүний асуудал болгосон. Холболтыг алслагдсан хүчин чадал руу чиглүүлэхэд эхлүүлэх болон урсгалаар дамжуулах явцын хэд хэдэн цэгт саатал нэмэгдэж болно. Бид загварын шинэ хувилбарыг бүс нутгийн хүчин чадал, урсгал чиглүүлэх тохиргоотой хамтатган баталгаажуулж, дараа нь хоцролтыг эх үүсвэрийн газарзүйн байршлаар задалж шинжилдэг болсон. Хиймэл оюуны хариултыг хэрэглэгчдэд ойртуулах нь тус болсон ч илүү өргөн хүрээний сургамжийг бататгасан: эхнээс төгсгөл хүртэлх шуурхай ажиллагаа зөвхөн загварын серверээс бус, зам дахь үйлчилгээ бүрээс хамаарна.

Бусад доголдол зөвхөн бодитой холболтын ашиглалтын хугацааны явцад илэрсэн. Удаан үргэлжилсэн холболтууд санах ой болон өгөгдөл хадгалалтын ачааллыг ил болгосон. Дахин холболтууд шахалт болон төлөв сэргээх үйлдлийг туршсан. Клиентийн ердийн салалтууд унтраах гар барилтын үеийн уралдаант нөхцөлийг илрүүлсэн. Эдгээр асуудал хугацаа, хуримтлагдсан төлөв, үйлчилгээ хоорондын зан төлөвөөс шалтгаалдаг тул богино ачааллын туршилтаар ховор илэрдэг байв.

Эцэст нь, боловсруулалтын туршилт ажиглалт болон нэвтрүүлэлтийн хяналтаа сайжруулахад хүргэсэн. Бид хоцролтын өөр өөр эх үүсвэрийг хольж хэмжсэн үзүүлэлтүүд, нэгтгэсэн дүнгээрээ доголдолтой хөдөлгүүрүүдийг далдалсан хянах самбарууд, туршсан ба нэвтрүүлсэн системүүдийн тохиргооны зөрүүг илрүүлсэн. Үүний хариуд бид илүү нарийвчилсан телеметр, найдвартай нь батлагдсан тохиргоотой тулгах баталгаажуулалт, үе шаттай нэмэгдүүлэлт, зам тус бүрийг хурдан тусгаарлах эсвэл идэвхгүй болгох боломж нэмсэн. Чимээгүй туршилт нь систем хэр их урсгал хүлээн авч чадахыг төдийгүй доголдлыг хэр хурдан илрүүлж, хязгаарлан, сэргээж чадахыг шалгасан нээлтийн өмнөх бэлтгэл болсон.

GPT‑Live-ийг ChatGPT‑ийн хэмжээнд хүргэхийн тулд нэг үндсэн зарчимд тулгуурласан цоо шинэ систем хэрэгтэй болсон: дуу хоолой тасралтгүй урсах ёстой. Хиймэл оюуны хариулт дамжуулалт бүрэн дуплекс загварыг аудиогоор тасралтгүй хангана. Тусгай медиа зам фреймийг найдвартай хүргэнэ. Асинхрон илгээлт нь гүнзгий сэтгэн бодох үйл явцыг давхар ажиллуулна. Оновчтой дамжуулалт хэрэглэгчид хүрэх бүх замд шуурхай ажиллагааг хадгална.

GPT‑Live-ийн суурь бүтэц бодит цагийн харилцан үйлчлэлийн илүү өргөн платформ болон хөгжиж эхэлсэн. Энэ нь ChatGPT Voice-ийг харилцан ярианаас агентын зохицуулалт руу өргөжихөд нь дэмжиж, удахгүй гарах GPT‑Live API-ийн суурь болно. Цаашдаа дуу хоолойн харилцан яриаг шууд мэт болгодог шуурхай чанарыг алдагдуулахгүйгээр илүү олон төхөөрөмж, апп, горимд дуу хоолойн туршлагыг түгээх боломж олгоно.

Хэрэв та ийм инженерчлэлийн асуудлуудыг шийдэхийг хүсдэг бол манай багт нэгдээрэй⁠.