AI ਐਪਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਢਾਂਚੇ ਵਾਲੇ ਨਤੀਜਿਆਂ ਦੀ ਲੋੜ ਕਿਉਂ ਹੁੰਦੀ ਹੈ?
AI ਐਪਾਂ ਨੂੰ ਤੈਅ ਢਾਂਚੇ ਵਿੱਚ ਨਤੀਜੇ ਚਾਹੀਦੇ ਹਨ ਕਿਉਂਕਿ ਸੌਫਟਵੇਅਰ ਗੱਲਬਾਤ ਵਾਲਾ ਪੈਰਾ ਭਰੋਸੇਯੋਗ ਢੰਗ ਨਾਲ ਨਹੀਂ ਪੜ੍ਹ ਸਕਦਾ; ਇਸ ਨੂੰ ਹਰ ਵਾਰ ਉਹੀ ਖਾਨੇ, ਉਹੀ ਨਾਂ ਅਤੇ ਉਹੀ ਕਿਸਮਾਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਇੱਕ ਵਾਧੂ ਵਾਕ ਜਾਂ ਇੱਕ ਗ਼ਾਇਬ ਖਾਨਾ ਤੁਹਾਡੀ ਐਪ ਦੇ ਅਗਲੇ ਪੜਾਅ ਨੂੰ ਰੋਕ ਸਕਦਾ ਹੈ।
ਪਾਰਸਲਵਾਈਜ਼ ਨਾਂ ਦੀ ਇੱਕ ਕਾਲਪਨਿਕ 12-ਵਿਅਕਤੀਆਂ ਵਾਲੀ ਲੌਜਿਸਟਿਕਸ ਨਵੀਂ ਕੰਪਨੀ ਦੀ ਕਲਪਨਾ ਕਰੋ। ਇਸ ਦੀ ਡਿਵੈਲਪਰ, ਸਨਾ, ਇੱਕ ਅਜਿਹਾ ਟੂਲ ਬਣਾ ਰਹੀ ਹੈ ਜੋ ਗਾਹਕਾਂ ਦੀਆਂ ਈਮੇਲਾਂ ਪੜ੍ਹ ਕੇ ਡਿਲਿਵਰੀ ਬਦਲਣ ਦਾ ਫਾਰਮ ਭਰਦਾ ਹੈ: ਆਰਡਰ ਦਾ ਹਵਾਲਾ, ਮੰਗੀ ਗਈ ਤਾਰੀਖ਼, ਨਵਾਂ ਪਤਾ ਅਤੇ ਕੀ ਗਾਹਕ ਪੈਸੇ ਵਾਪਸ ਮੰਗ ਰਿਹਾ ਹੈ। ਇੱਕ ਆਮ ਈਮੇਲ ਇਸ ਤਰ੍ਹਾਂ ਹੈ: 'ਸਤ ਸ੍ਰੀ ਅਕਾਲ, ਆਰਡਰ PW-88213, ਮੈਂ ਵੀਰਵਾਰ ਨੂੰ ਘਰ ਨਹੀਂ ਹੋਵਾਂਗਾ, ਕੀ ਤੁਸੀਂ ਇਸ ਦੀ ਥਾਂ ਸ਼ਨੀਵਾਰ ਨੂੰ ਲਿਆ ਸਕਦੇ ਹੋ? ਜਾਂ ਨੰ. 14 ਕੋਲ ਛੱਡ ਦਿਓ। ਜੇ ਨਹੀਂ ਤਾਂ ਕਿਰਪਾ ਕਰਕੇ ਰੱਦ ਕਰ ਕੇ ਪੈਸੇ ਵਾਪਸ ਕਰ ਦਿਓ।' ਉਸ ਦਾ ਪਹਿਲਾ ਸੰਸਕਰਣ ਮਾਡਲ ਨੂੰ 'JSON ਵਿੱਚ ਜਵਾਬ ਦਿਓ' ਕਹਿੰਦਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਜਵਾਬ ਮਸ਼ੀਨੀ ਤੌਰ 'ਤੇ ਪੜ੍ਹੇ ਜਾ ਸਕਦੇ ਹਨ, ਪਰ ਕੁਝ 'ਜ਼ਰੂਰ, ਇਹ ਰਿਹਾ JSON' ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ, ਕੁਝ ਖੇਤਰ ਦਾ ਨਾਂ 'requested_date' ਦੀ ਥਾਂ 'date' ਰੱਖਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਤਾਰੀਖ਼ ਵਜੋਂ 'ਸ਼ਨੀਵਾਰ' ਵਾਪਸ ਕਰਦਾ ਹੈ।
JSON ਸਕੀਮਾ ਕੀ ਹੁੰਦਾ ਹੈ ਅਤੇ ਇਹ ਮਦਦਗਾਰ ਕਿਉਂ ਹੈ?
JSON ਸਕੀਮਾ ਤੁਹਾਡੇ ਉਮੀਦ ਕੀਤੇ ਡਾਟੇ ਦਾ ਰਸਮੀ ਵੇਰਵਾ ਹੁੰਦਾ ਹੈ: ਕਿਹੜੇ ਖੇਤਰ ਹਨ, ਕਿਹੜੇ ਲਾਜ਼ਮੀ ਹਨ, ਹਰੇਕ ਦੀ ਕਿਸਮ ਕੀ ਹੈ ਅਤੇ ਕਿਹੜੇ ਮੁੱਲ ਮਨਜ਼ੂਰ ਹਨ। ਮਾਡਲ ਨੂੰ ਸਕੀਮਾ ਦੇਣ ਨਾਲ 'ਕਿਰਪਾ ਕਰਕੇ JSON ਵਿੱਚ ਜਵਾਬ ਦਿਓ' ਇੱਕ ਅਜਿਹੇ ਇਕਰਾਰ ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ ਜਿਸ ਨੂੰ ਤੁਹਾਡਾ ਕੋਡ ਜਾਂਚ ਸਕਦਾ ਹੈ।
ਸਨਾ ਲਈ ਸਕੀਮਾ ਕਹਿੰਦਾ ਹੈ: order_reference ਇੱਕ ਲਾਜ਼ਮੀ ਸਟ੍ਰਿੰਗ ਹੈ; requested_date ਤਾਰੀਖ਼ ਦੇ ਫਾਰਮੈਟ ਵਿੱਚ ਇੱਕ ਲਾਜ਼ਮੀ ਸਟ੍ਰਿੰਗ ਹੈ, ਜਾਂ ਜੇ ਕੋਈ ਤਾਰੀਖ਼ ਨਹੀਂ ਦਿੱਤੀ ਗਈ ਤਾਂ null; new_address ਇੱਕ ਸਟ੍ਰਿੰਗ ਜਾਂ null ਹੈ; refund_requested ਇੱਕ ਲਾਜ਼ਮੀ ਬੂਲੀਅਨ ਹੈ; ਅਤੇ ਕਿਸੇ ਹੋਰ ਖੇਤਰ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਹੈ। ਇਹ ਆਖ਼ਰੀ ਨਿਯਮ ਮਾਡਲ ਨੂੰ ਟਿੱਪਣੀਆਂ ਵਾਲੇ ਖੇਤਰ ਜੋੜਨ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਮਾਡਲ ਦੇ APIs ਤੈਅ ਢਾਂਚੇ ਵਾਲਾ ਨਤੀਜਾ ਦੇਣ ਵਿੱਚ ਕਿਵੇਂ ਮਦਦ ਕਰਦੇ ਹਨ?
ਪ੍ਰਮੁੱਖ ਮਾਡਲਾਂ ਦੇ APIs ਵਿੱਚ ਤੁਸੀਂ ਬੇਨਤੀ ਨਾਲ 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 ਨੂੰ ਕਾਲ ਕਰਦੇ ਹੋ, ਜਵਾਬਾਂ ਦੀ ਵੈਧਤਾ ਜਾਂਚਦੇ ਹੋ ਅਤੇ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦਾ ਪ੍ਰਬੰਧ ਜੋੜਦੇ ਹੋ। ਹਰ ਕਦਮ 'ਤੇ ਅੰਕਣ ਦੇ ਮਾਪਦੰਡਾਂ ਅਨੁਸਾਰ ਫੀਡਬੈਕ ਮਿਲਦੀ ਹੈ।