AI ઍપને સંરચિત આઉટપુટની જરૂર કેમ પડે છે?
AI ઍપને માળખાબદ્ધ આઉટપુટની જરૂર છે, કારણ કે સૉફ્ટવેર વાતચીત જેવા ફકરાને વિશ્વસનીય રીતે વાંચી શકતું નથી; તેને દર વખતે એકસરખાં નામ અને પ્રકાર ધરાવતાં એકસરખાં ફીલ્ડ જોઈએ છે. એક વધારાનું વાક્ય કે એક ખૂટતું ફીલ્ડ તમારી ઍપનું આગળનું પગલું અટકાવી શકે છે.
12 લોકોની એક કાલ્પનિક લોજિસ્ટિક્સ સ્ટાર્ટ-અપ, પાર્સલવાઇઝની કલ્પના કરો. તેની ડેવલપર સના એવું સાધન બનાવી રહી છે જે ગ્રાહકોના ઇમેઇલ વાંચીને ડિલિવરીમાં ફેરફારનું ફોર્મ ભરે છે: ઓર્ડર સંદર્ભ, માગેલી તારીખ, નવું સરનામું અને ગ્રાહક રિફંડ માગે છે કે નહીં. સામાન્ય ઇમેઇલ આવો હોય છે: 'નમસ્તે, ઓર્ડર PW-88213, હું ગુરુવારે ઘરે નહીં હોઉં, તેના બદલે શનિવારે પહોંચાડી શકશો? અથવા નં. 14 પર મૂકી જજો. એ ન થાય તો કૃપા કરીને રદ કરીને રિફંડ આપી દેજો.' તેનું પ્રથમ સંસ્કરણ મોડેલને 'JSON માં જવાબ આપો' કહે છે. મોટાભાગના જવાબોનું પાર્સિંગ થઈ જાય છે, પરંતુ કેટલાક 'ચોક્કસ, અહીં JSON છે'થી શરૂ થાય છે, કેટલાક ફીલ્ડનું નામ 'requested_date'ને બદલે 'date' રાખે છે, અને એક તારીખ તરીકે 'શનિવાર' આપે છે.
JSONની સંરચનાની વ્યાખ્યા શું છે અને તે શા માટે મદદરૂપ થાય છે?
JSON સ્કીમા એટલે તમને અપેક્ષિત માહિતીનું ઔપચારિક વર્ણન: કયાં ક્ષેત્રો છે, કયાં જરૂરી છે, દરેકનો પ્રકાર શું છે અને કયાં મૂલ્યો માન્ય છે. મોડેલને સ્કીમા આપવાથી 'કૃપા કરીને JSONમાં જવાબ આપો' એવી વિનંતી તમારા કોડથી ચકાસી શકાય એવા કરારમાં ફેરવાય છે.
સના માટે સ્કીમા કહે છે: order_reference ફરજિયાત સ્ટ્રિંગ છે; requested_date તારીખના ફોર્મેટમાં ફરજિયાત સ્ટ્રિંગ છે, અથવા તારીખ આપવામાં ન આવી હોય તો null છે; new_address સ્ટ્રિંગ અથવા null છે; refund_requested ફરજિયાત બૂલિયન છે; અને અન્ય કોઈ ફીલ્ડની મંજૂરી નથી. છેલ્લો નિયમ મોડેલને ટિપ્પણીનાં ફીલ્ડ ઉમેરતાં અટકાવે છે.
મોડેલની એપીઆઈ નિર્ધારિત માળખામાં પરિણામ મેળવવામાં કેવી રીતે મદદ કરે છે?
મુખ્ય મોડેલની API તમને વિનંતી સાથે JSON સ્કીમા મોકલવા દે છે, અને મોડેલનું આઉટપુટ તેની સાથે મેળ ખાય તે રીતે મર્યાદિત કરવામાં આવે છે.
OpenAI
OpenAIની સંરચિત પરિણામોની સુવિધા, કડક મોડ ચાલુ હોય ત્યારે, જવાબોને આપેલા JSON સ્કીમા સુધી મર્યાદિત રાખે છે. તેના દસ્તાવેજો આ સુવિધાને જૂના JSON મોડથી અલગ પાડે છે. જૂનો મોડ માત્ર માન્ય JSONની ખાતરી આપે છે, તમારા સ્કીમાનું પાલન થવાની નહીં. જ્યાં ઉપલબ્ધ હોય ત્યાં સંરચિત પરિણામો વાપરવાની ભલામણ કરવામાં આવે છે.
Anthropic
Claudeનું API તમે આપેલા સ્કીમા સાથે મેળ ખાતાં JSON પરિણામો આપે છે. તે ઉપરાંત, સાધનોની વ્યાખ્યાઓમાં કડક વિકલ્પ આપે છે, જેથી સાધનને આપવામાં આવતી માહિતી તેના સ્કીમા સામે ચકાસવામાં આવે. તેના દસ્તાવેજોમાં સ્કીમાની કઈ સુવિધાઓ સમર્થિત છે અને કઈ સુવિધાઓ ભૂલ આપે છે તેની યાદી છે.
Gemini API જવાબો માટે JSON સ્કીમા સ્વીકારે છે અને સ્કીમાના કીવર્ડના નિર્ધારિત ઉપસમૂહને સમર્થન આપે છે. તેના દસ્તાવેજો કહે છે કે આઉટપુટ રચનાની દૃષ્ટિએ યોગ્ય JSON હોય તો પણ, તમારે તમારી એપ્લિકેશનમાં તેની કિંમતોની ચકાસણી કરવી જોઈએ.
તમારે હજી પણ ચકાસણી અને ફરી પ્રયાસ કરવાની જરૂર કેમ પડે છે?
તમારે હજી પણ ચકાસણી કરવી જરૂરી છે, કારણ કે સ્કીમા ડેટાનું માળખું નક્કી કરે છે, મૂલ્યો સાચાં છે કે નહીં તે નહીં. સંપૂર્ણ યોગ્ય માળખાવાળા જવાબમાં પણ ખોટી તારીખ, બનાવટી ઑર્ડર સંદર્ભ અથવા ગ્રાહકે ક્યારેય ન માગેલું રિફંડ સૂચક હોઈ શકે છે.
બે સ્તરે ચકાસણી કરો. પહેલાં, સ્કીમા લાઇબ્રેરીથી બંધારણ તપાસો, જેમ કે Pythonમાં Pydantic અથવા JavaScriptમાં Zod; OpenAI, Anthropic અને Googleના દસ્તાવેજોમાં આ બધાંનાં ઉદાહરણો છે. બીજું, વ્યવસાયના નિયમો તપાસો: શું ઓર્ડરનો સંદર્ભ નક્કી કરેલી રચના સાથે મેળ ખાય છે અને સિસ્ટમમાં હાજર છે, શું તારીખ ભવિષ્યની છે અને ડિલિવરીના દિવસે આવે છે, અને શું સરનામું ડિલિવરી વિસ્તારમાં છે? પ્રદાતાઓએ દસ્તાવેજોમાં જણાવેલી પરિસ્થિતિઓ પણ સંભાળો: જવાબ આપવાનો ઇનકાર, જે કદાચ તમારા સ્કીમાને અનુસરતો ન હોય, અને મહત્તમ ટોકન મર્યાદાને કારણે અધવચ્ચે કપાયેલો જવાબ, જેનાથી JSON અધૂરું રહે છે.
સાવચેતીથી ફરી પ્રયાસ કરો. કોઈ ચકાસણી નિષ્ફળ જાય તો ચોક્કસ ભૂલનો ઉલ્લેખ કરીને એક વાર ફરી વિનંતી મોકલો, જેમ કે 'requested_date તારીખ હોવી જોઈએ; ઇમેઇલમાં શનિવાર લખ્યું છે અને ઓર્ડરની તારીખ 14 ઑક્ટોબર છે'. ફરી પ્રયાસ કરવાની મર્યાદા એક કે બે રાખો, પછી ઇમેઇલ કોઈ વ્યક્તિને સોંપો.
નબળું અને મજબૂત સંરચિત પરિણામ કેવું હોય છે?
નબળું સંસ્કરણ: પ્રોમ્પ્ટ કહે છે 'વિગતો કાઢો અને JSON માં જવાબ આપો.' ઍપ જે પણ જવાબ આવે તે વાંચી લે છે. ઉપરના ઇમેઇલ માટે તેને order અને date નામનાં ફીલ્ડ મળે છે, તારીખનું મૂલ્ય 'શનિવાર' અને રિફંડનું મૂલ્ય true મળે છે, કારણ કે મોડેલે 'નહીં તો રદ કરી દો'ને સ્પષ્ટ વિનંતી માની લીધી. ફોર્મ ખોટી રીતે ભરાય છે અને ગ્રાહકને ન જોઈતું રિફંડ મળી જાય છે.
વધુ મજબૂત આવૃત્તિ: વિનંતીમાં સાનાનું સ્કીમા કડક મોડ સાથે સામેલ છે અને પ્રોમ્પ્ટ દરેક ફીલ્ડ સમજાવે છે, જેમાં 'ગ્રાહક કોઈ શરત વિના પૈસા પાછા માગે તો જ refund_requestedનું મૂલ્ય true હોય' તે પણ સામેલ છે. મોડેલ order_reference તરીકે PW-88213, requested_date તરીકે આવતા શનિવારની તારીખ, new_address તરીકે null અને refund_requested તરીકે false આપે છે. સાનાએ ખાસ આ કિસ્સા માટે સ્કીમામાં ઉમેરેલા conditional_request ફીલ્ડનું મૂલ્ય 'શનિવારે અથવા પાડોશીને પહોંચાડવું શક્ય ન હોય તો પૈસા પાછા આપો' રાખે છે. ચકાસણીથી ખાતરી થાય છે કે ઓર્ડર અસ્તિત્વમાં છે અને શનિવારે માલ પહોંચાડવામાં આવે છે. ઇમેઇલમાં શરતી વિનંતી હોવાથી નિયમો અંતિમ નિર્ણય માટે તેને કોઈ વ્યક્તિને સોંપે છે.
નિર્ધારિત માળખામાં આઉટપુટ મેળવતી વખતે થતી સામાન્ય ભૂલો કઈ છે?
સૌથી સામાન્ય ભૂલ એ છે કે માન્ય JSONને સાચો ડેટા માની લેવો. અન્ય ભૂલો: API માળખાનું પાલન ફરજિયાત કરાવી શકતું હોય છતાં ફક્ત પ્રોમ્પ્ટની સૂચનાઓ પર આધાર રાખવો, વર્ણન વિના અસ્પષ્ટ ક્ષેત્રનામો વાપરવાં, સાચો જવાબ null હોય ત્યારે પણ મૂલ્ય આપવાની ફરજ પાડવી, ઇનકાર અને અધૂરા જવાબો અવગણવા, અને શું ખોટું હતું તે મોડેલને જણાવ્યા વિના ફરી પ્રયાસ કરવો.
Tosheo.aiની અભ્યાસસૂચિમાં નિર્ધારિત માળખામાં મળતા પરિણામનું સ્થાન ક્યાં છે?
માળખાબદ્ધ પરિણામ એ AI ઍપ બનાવવાના અભ્યાસક્રમમાં, AI ઍપ નિર્માણ શ્રેણી હેઠળનો કોડનો પાઠ છે. તેમાં તમે ડેટાનું માળખું વ્યાખ્યાયિત કરો છો, API કૉલ કરો છો, જવાબોની માન્યતા તપાસો છો અને ફરી પ્રયાસ કરવાની વ્યવસ્થા ઉમેરો છો. કોડ સાથેનું આ સંપૂર્ણ પ્રાયોગિક સંસ્કરણ નોંધણી પછી કોડના અભ્યાસમાર્ગમાં ઉપલબ્ધ છે, જ્યાં દરેક પગલે મૂલ્યાંકનના માપદંડો અનુસાર પ્રતિસાદ મળે છે.