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ಗಳು ಹೇಗೆ ನೆರವಾಗುತ್ತವೆ?

ಪ್ರಮುಖ ಮಾದರಿಗಳ APIಗಳು ವಿನಂತಿಯೊಂದಿಗೆ JSON ರೂಪರೇಖೆಯನ್ನು ಕಳುಹಿಸಲು ಅವಕಾಶ ನೀಡುತ್ತವೆ. ಮಾದರಿಯ ಫಲಿತಾಂಶವು ಅದಕ್ಕೆ ಹೊಂದುವಂತೆ ನಿರ್ಬಂಧಿತವಾಗಿರುತ್ತದೆ.

OpenAI

ಕಟ್ಟುನಿಟ್ಟಿನ ಮೋಡ್ ಚಾಲನೆಯಲ್ಲಿರುವಾಗ, OpenAI ಯ ರಚನಾಬದ್ಧ ಫಲಿತಾಂಶಗಳ ವೈಶಿಷ್ಟ್ಯವು ಉತ್ತರಗಳು ಒದಗಿಸಿದ JSON ಸ್ಕೀಮಾಕ್ಕೆ ಹೊಂದುವಂತೆ ನಿರ್ಬಂಧಿಸುತ್ತದೆ. ಅದರ ದಾಖಲೆಗಳು ಇದಕ್ಕೂ ಹಳೆಯ JSON ಮೋಡ್‌ಗೂ ಇರುವ ವ್ಯತ್ಯಾಸವನ್ನು ವಿವರಿಸುತ್ತವೆ. ಹಳೆಯ ಮೋಡ್ ಮಾನ್ಯವಾದ JSON ಅನ್ನು ಮಾತ್ರ ಖಚಿತಪಡಿಸುತ್ತದೆ, ನಿಮ್ಮ ಸ್ಕೀಮಾಕ್ಕೆ ಅನುಗುಣವಾಗಿರುವುದನ್ನಲ್ಲ. ಲಭ್ಯವಿರುವಲ್ಲಿ ರಚನಾಬದ್ಧ ಫಲಿತಾಂಶಗಳನ್ನು ಬಳಸಲು ದಾಖಲೆಗಳು ಶಿಫಾರಸು ಮಾಡುತ್ತವೆ.

Anthropic

Claudeನ API ನೀವು ಒದಗಿಸುವ ಸ್ಕೀಮಾಕ್ಕೆ ಹೊಂದುವ JSON ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡುತ್ತದೆ. ಜೊತೆಗೆ, ಸಾಧನದ ಇನ್‌ಪುಟ್‌ಗಳನ್ನು ಅದರ ಸ್ಕೀಮಾಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಪರಿಶೀಲಿಸಲು ಸಾಧನದ ವ್ಯಾಖ್ಯಾನಗಳಲ್ಲಿ ಕಟ್ಟುನಿಟ್ಟಿನ ಆಯ್ಕೆಯನ್ನೂ ಒದಗಿಸುತ್ತದೆ. ಯಾವ ಸ್ಕೀಮಾ ವೈಶಿಷ್ಟ್ಯಗಳಿಗೆ ಬೆಂಬಲವಿದೆ ಮತ್ತು ಯಾವವು ದೋಷವನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ ಎಂಬುದನ್ನು ಅದರ ದಾಖಲೆಗಳು ಪಟ್ಟಿ ಮಾಡುತ್ತವೆ.

Google

Gemini API ಪ್ರತಿಕ್ರಿಯೆಗಳಿಗಾಗಿ JSON ಸ್ಕೀಮಾವನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಸ್ಕೀಮಾದ ನಿರ್ದಿಷ್ಟ ಕೀವರ್ಡ್‌ಗಳ ಉಪಸಮೂಹವನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. ಫಲಿತಾಂಶವು ವಾಕ್ಯರಚನೆಯ ದೃಷ್ಟಿಯಿಂದ ಸರಿಯಾದ JSON ಆಗಿದ್ದರೂ, ನಿಮ್ಮ ಅನ್ವಯದಲ್ಲಿ ಮೌಲ್ಯಗಳನ್ನು ಪರಿಶೀಲಿಸಬೇಕು ಎಂದು ಅದರ ದಾಖಲಾತಿ ಹೇಳುತ್ತದೆ.

ನಿಮಗೆ ಇನ್ನೂ ಪರಿಶೀಲನೆ ಮತ್ತು ಮರುಪ್ರಯತ್ನಗಳು ಏಕೆ ಬೇಕು?

ನೀವು ಇನ್ನೂ ಮೌಲ್ಯಗಳ ಸರಿತನವನ್ನು ಪರಿಶೀಲಿಸಬೇಕಾಗುತ್ತದೆ. ಏಕೆಂದರೆ ಸ್ಕೀಮಾ ದತ್ತಾಂಶದ ರಚನೆಯನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆಯೇ ಹೊರತು ಮೌಲ್ಯಗಳು ಸರಿಯಾಗಿವೆಯೇ ಎಂಬುದನ್ನಲ್ಲ. ಸಂಪೂರ್ಣವಾಗಿ ಸರಿಯಾದ ರಚನೆಯಲ್ಲಿರುವ ಉತ್ತರದಲ್ಲೂ ತಪ್ಪು ದಿನಾಂಕ, ಕಲ್ಪಿತ ಆರ್ಡರ್ ಉಲ್ಲೇಖ ಅಥವಾ ಗ್ರಾಹಕ ಎಂದಿಗೂ ಕೇಳದ ಮರುಪಾವತಿ ಸೂಚನೆ ಇರಬಹುದು.

ಎರಡು ಹಂತಗಳಲ್ಲಿ ಮೌಲ್ಯೀಕರಿಸಿ. ಮೊದಲು, Python‌ನ Pydantic ಅಥವಾ JavaScript‌ನ Zod ನಂತಹ ಸ್ಕೀಮಾ ಗ್ರಂಥಾಲಯದಿಂದ ರಚನೆಯನ್ನು ಪರಿಶೀಲಿಸಿ. OpenAI, Anthropic ಮತ್ತು Google ದಾಖಲಾತಿಗಳೆಲ್ಲವೂ ಇವುಗಳನ್ನು ಉದಾಹರಣೆಗಳಲ್ಲಿ ತೋರಿಸುತ್ತವೆ. ಎರಡನೆಯದಾಗಿ, ವ್ಯವಹಾರ ನಿಯಮಗಳನ್ನು ಪರಿಶೀಲಿಸಿ: ಆದೇಶದ ಉಲ್ಲೇಖವು ನಿಗದಿತ ಮಾದರಿಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆಯೇ ಮತ್ತು ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಇದೆಯೇ, ದಿನಾಂಕವು ಭವಿಷ್ಯದಲ್ಲಿದೆಯೇ ಮತ್ತು ವಿತರಣಾ ದಿನವಾಗಿದೆಯೇ, ವಿಳಾಸವು ವಿತರಣಾ ಪ್ರದೇಶದಲ್ಲಿದೆಯೇ? ಪೂರೈಕೆದಾರರು ದಾಖಲಿಸಿರುವ ಸಂದರ್ಭಗಳನ್ನೂ ನಿರ್ವಹಿಸಿ: ನಿಮ್ಮ ಸ್ಕೀಮಾವನ್ನು ಅನುಸರಿಸದಿರಬಹುದಾದ ನಿರಾಕರಣೆ ಮತ್ತು ಗರಿಷ್ಠ ಟೋಕನ್ ಮಿತಿಯಿಂದ ಮಧ್ಯದಲ್ಲೇ ಕಡಿತಗೊಂಡು ಅಪೂರ್ಣ JSON ಉಳಿಸುವ ಉತ್ತರ.

ಎಚ್ಚರಿಕೆಯಿಂದ ಮರುಪ್ರಯತ್ನಿಸಿ. ಪರಿಶೀಲನೆ ವಿಫಲವಾದರೆ, ನಿರ್ದಿಷ್ಟ ದೋಷವನ್ನು ಒಳಗೊಂಡ ಒಂದು ಮರುಪ್ರಯತ್ನವನ್ನು ಕಳುಹಿಸಿ. ಉದಾಹರಣೆಗೆ, 'requested_date ಒಂದು ದಿನಾಂಕವಾಗಿರಬೇಕು; ಇಮೇಲ್‌ನಲ್ಲಿ ಶನಿವಾರ ಎಂದು ಹೇಳಲಾಗಿದೆ ಮತ್ತು ಆರ್ಡರ್ ದಿನಾಂಕ 14 ಅಕ್ಟೋಬರ್ ಆಗಿದೆ'. ಮರುಪ್ರಯತ್ನಗಳನ್ನು ಒಂದು ಅಥವಾ ಎರಡಕ್ಕೆ ಮಿತಿಗೊಳಿಸಿ, ನಂತರ ಇಮೇಲ್ ಅನ್ನು ವ್ಯಕ್ತಿಯೊಬ್ಬರಿಗೆ ಕಳುಹಿಸಿ.

ದುರ್ಬಲ ರಚನಾತ್ಮಕ ಔಟ್‌ಪುಟ್ ಮತ್ತು ದೃಢವಾದ ರಚನಾತ್ಮಕ ಔಟ್‌ಪುಟ್ ಹೇಗಿರುತ್ತವೆ?

ದುರ್ಬಲ ಆವೃತ್ತಿ: ಸೂಚನೆಯಲ್ಲಿ 'ವಿವರಗಳನ್ನು ಹೊರತೆಗೆದು JSON ರೂಪದಲ್ಲಿ ಉತ್ತರಿಸಿ.' ಎಂದು ಹೇಳಲಾಗಿದೆ. ಏನು ಉತ್ತರ ಬಂದರೂ ಅಪ್ಲಿಕೇಶನ್ ಅದನ್ನು ಓದುತ್ತದೆ. ಮೇಲಿನ ಇಮೇಲ್‌ಗೆ ಅದಕ್ಕೆ order ಮತ್ತು date ಎಂಬ ಕ್ಷೇತ್ರಗಳು, ದಿನಾಂಕದ ಮೌಲ್ಯವಾಗಿ 'ಶನಿವಾರ', ಮತ್ತು ಮರುಪಾವತಿ ಮೌಲ್ಯವಾಗಿ true ಸಿಗುತ್ತವೆ. ಏಕೆಂದರೆ ಮಾದರಿಯು 'ಇಲ್ಲದಿದ್ದರೆ ರದ್ದುಮಾಡಿ' ಎಂಬುದನ್ನು ಖಚಿತ ವಿನಂತಿಯಾಗಿ ಪರಿಗಣಿಸಿದೆ. ಅರ್ಜಿಯಲ್ಲಿ ತಪ್ಪು ಮಾಹಿತಿ ತುಂಬುತ್ತದೆ ಮತ್ತು ಗ್ರಾಹಕರು ಬಯಸದ ಮರುಪಾವತಿ ಅವರಿಗೆ ಸಿಗುತ್ತದೆ.

ದೃಢವಾದ ಆವೃತ್ತಿ: ವಿನಂತಿಯಲ್ಲಿ ಕಟ್ಟುನಿಟ್ಟಿನ ಕ್ರಮದೊಂದಿಗೆ ಸನಾಳ ದತ್ತಾಂಶ ರಚನೆಯ ನಿರ್ದಿಷ್ಟತೆ ಸೇರಿದೆ. ಸೂಚನೆಯು ಪ್ರತಿಯೊಂದು ಕ್ಷೇತ್ರವನ್ನೂ ವಿವರಿಸುತ್ತದೆ; ಅದರಲ್ಲಿ 'ಗ್ರಾಹಕರು ಯಾವುದೇ ಷರತ್ತಿಲ್ಲದೆ ಹಣ ಮರುಪಾವತಿ ಕೇಳಿದರೆ ಮಾತ್ರ refund_requested ನಿಜವಾಗಿರುತ್ತದೆ' ಎಂಬುದೂ ಸೇರಿದೆ. ಮಾದರಿಯು order_reference ಅನ್ನು PW-88213 ಎಂದು, requested_date ಅನ್ನು ಮುಂದಿನ ಶನಿವಾರದ ದಿನಾಂಕವಾಗಿ, new_address ಅನ್ನು null ಎಂದು ಮತ್ತು refund_requested ಅನ್ನು false ಎಂದು ನೀಡುತ್ತದೆ. ನಿಖರವಾಗಿ ಇಂತಹ ಸಂದರ್ಭಕ್ಕಾಗಿಯೇ ಸನಾ ರಚನೆಯ ನಿರ್ದಿಷ್ಟತೆಗೆ ಸೇರಿಸಿದ conditional_request ಕ್ಷೇತ್ರವನ್ನು 'ಶನಿವಾರ ವಿತರಣೆ ಅಥವಾ ನೆರೆಹೊರೆಯವರಿಗೆ ವಿತರಣೆ ಸಾಧ್ಯವಾಗದಿದ್ದರೆ ಹಣ ಮರುಪಾವತಿ' ಎಂದು ಹೊಂದಿಸುತ್ತದೆ. ಪರಿಶೀಲನೆಯು ಆರ್ಡರ್ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಮತ್ತು ಶನಿವಾರ ವಿತರಣೆಯ ದಿನವಾಗಿದೆ ಎಂದು ದೃಢೀಕರಿಸುತ್ತದೆ. ಇಮೇಲ್‌ನಲ್ಲಿ ಷರತ್ತುಬದ್ಧ ವಿನಂತಿ ಇರುವುದರಿಂದ, ನಿಯಮಗಳು ಅಂತಿಮ ನಿರ್ಧಾರಕ್ಕಾಗಿ ಅದನ್ನು ವ್ಯಕ್ತಿಯೊಬ್ಬರಿಗೆ ಕಳುಹಿಸುತ್ತವೆ.

ನಿರ್ದಿಷ್ಟ ರಚನೆಯ ಫಲಿತಾಂಶಗಳನ್ನು ಪಡೆಯುವಾಗ ಸಾಮಾನ್ಯವಾಗಿ ಆಗುವ ತಪ್ಪುಗಳು ಯಾವುವು?

ಮಾನ್ಯವಾದ JSON ಅನ್ನು ಸರಿಯಾದ ದತ್ತಾಂಶವೆಂದು ನಂಬುವುದು ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ತಪ್ಪು. ಇತರವು: API ದತ್ತಾಂಶ ರಚನೆಯ ನಿಯಮಗಳನ್ನು ಕಡ್ಡಾಯಗೊಳಿಸುವ ಸೌಲಭ್ಯ ನೀಡಿದರೂ ಕೇವಲ ಸೂಚನೆಗಳನ್ನೇ ಅವಲಂಬಿಸುವುದು, ವಿವರಣೆಗಳಿಲ್ಲದೆ ಅಸ್ಪಷ್ಟ ಕ್ಷೇತ್ರ ಹೆಸರುಗಳನ್ನು ಬಳಸುವುದು, ಪ್ರಾಮಾಣಿಕ ಉತ್ತರ null ಆಗಿರುವಾಗ ಮೌಲ್ಯವನ್ನು ಬಲವಂತವಾಗಿ ತುಂಬಿಸುವುದು, ನಿರಾಕರಣೆಗಳು ಮತ್ತು ಅಪೂರ್ಣ ಉತ್ತರಗಳನ್ನು ಕಡೆಗಣಿಸುವುದು, ಮತ್ತು ಏನು ತಪ್ಪಾಗಿದೆ ಎಂದು ಮಾದರಿಗೆ ತಿಳಿಸದೆ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುವುದು.

Tosheo.ai ಪಠ್ಯಪಟ್ಟಿಯಲ್ಲಿ ನಿಗದಿತ ರಚನೆಯ ಫಲಿತಾಂಶ ಯಾವ ಭಾಗಕ್ಕೆ ಸೇರುತ್ತದೆ?

ರಚನಾಬದ್ಧ ಫಲಿತಾಂಶವು AI ಆ್ಯಪ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುವುದು ಎಂಬ ವಿಭಾಗದ AI ಆ್ಯಪ್‌ಗಳ ನಿರ್ಮಾಣ ಕೋರ್ಸ್‌ನಲ್ಲಿರುವ ಕೋಡ್ ಪಾಠವಾಗಿದೆ. ನೀವು ದತ್ತಾಂಶದ ರಚನೆಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವುದು, API ಕರೆ ಮಾಡುವುದು, ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಪರಿಶೀಲಿಸುವುದು ಮತ್ತು ಮರುಪ್ರಯತ್ನವನ್ನು ಸೇರಿಸುವುದನ್ನು ಒಳಗೊಂಡ ಸಂಪೂರ್ಣ ಪ್ರಾಯೋಗಿಕ ಕೋಡ್ ಆವೃತ್ತಿಯು ನೋಂದಣಿಯ ನಂತರ ಕೋಡ್ ಕಲಿಕಾ ಮಾರ್ಗದಲ್ಲಿ ಲಭ್ಯವಿದೆ. ಪ್ರತಿ ಹಂತದಲ್ಲೂ ಮೌಲ್ಯಮಾಪನ ಮಾನದಂಡಗಳ ಆಧಾರದ ಮೇಲೆ ಪ್ರತಿಕ್ರಿಯೆ ಸಿಗುತ್ತದೆ.

ಮೂಲಗಳು ಮತ್ತು ವ್ಯಾಪ್ತಿ

OpenAI API ದಾಖಲೆಗಳು, ರಚನಾಬದ್ಧ ಫಲಿತಾಂಶಗಳ ಮಾರ್ಗದರ್ಶಿ, JSON ಮೋಡ್ ಹೋಲಿಕೆ ಮತ್ತು ನಿರಾಕರಣೆಗಳು (ಪರಿಶೀಲಿಸಿದ ದಿನಾಂಕ 19 October 2026) ↗

Anthropic Claude ದಸ್ತಾವೇಜುಗಳು, ರಚನಾಬದ್ಧ ಫಲಿತಾಂಶಗಳು ಮತ್ತು ಕಟ್ಟುನಿಟ್ಟಿನ ಸಾಧನ ಬಳಕೆ (19 October 2026 ರಂದು ಪರಿಶೀಲಿಸಲಾಗಿದೆ) ↗

Google Gemini ಅನ್ವಯ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಅಂತರಸಂಪರ್ಕದ ದಾಖಲೆಗಳು, ರಚನಾಬದ್ಧ ಫಲಿತಾಂಶ ಮತ್ತು ಮೌಲ್ಯೀಕರಣದ ಸಲಹೆ (19 October 2026 ರಂದು ಪರಿಶೀಲಿಸಲಾಗಿದೆ) ↗