ಓಪನ್-ವೇಟ್ ಲಾರ್ಜ್ ಲ್ಯಾಂಗ್ವೇಜ್ ಮಾಡೆಲ್‌ಗಳು (Open-weight large language models) ಎಂಜಿನಿಯರಿಂಗ್ ತಂಡಗಳು AI ಮೂಲಸೌಕರ್ಯದ (AI infrastructure) ಬಗ್ಗೆ ಯೋಚಿಸುವ ರೀತಿಯನ್ನು ಬದಲಿಸಿವೆ. ಪ್ರೊವೈಡರ್ ಹಾರ್ಡ್‌ವೇರ್, ಮಾಡೆಲ್ ವೇಟ್ಸ್ ಮತ್ತು ಬಿಡುಗಡೆಯ ವೇಳಾಪಟ್ಟಿಯನ್ನು ನಿಯಂತ್ರಿಸುವ ಕ್ಲೋಸ್ಡ್ APIಗಳಿಗಿಂತ ಭಿನ್ನವಾಗಿ, ಓಪನ್-ವೇಟ್ ಮಾಡೆಲ್‌ಗಳು ಈ ನಿರ್ಧಾರಗಳನ್ನು ನಿಮ್ಮ ಕೈಗೆប្រತಿಕ್ರಿಯಿಸುತ್ತವೆ. ಮಾಡೆಲ್ ಎಲ್ಲಿ ಇರಬೇಕು, ಅದನ್ನು ಹೇಗೆ ಟ್ಯೂನ್ ಮಾಡಬೇಕು ಮತ್ತು ಯಾವಾಗ—ಅಥವಾ ಎಂದಾದರೂ—ಹೊಸ ಚೆಕ್‌ಪಾಯಿಂಟ್‌ಗೆ ಅಪ್‌ಡೇಟ್ ಮಾಡಬೇಕು ಎಂಬುದನ್ನು ನೀವೇ ನಿರ್ಧರಿಸುತ್ತೀರಿ. ಈ ಮಟ್ಟದ ಮಾಲೀಕತ್ವವು ಶಕ್ತಿಯುತವಾಗಿದೆ, ಆದರೆ ಇದರರ್ಥ ಇಂಟಿಗ್ರೇಷನ್ ಕೆಲಸದ ಸಂಪೂರ್ಣ ಜವಾಬ್ದಾರಿ ನಿಮ್ಮ ಮೇಲಿರುತ್ತದೆ ಎಂದರ್ಥ.

ನೀವು OpenAI ನ GPT-4 ಅಥವಾ Anthropic ನ Claude ನಂತಹ ಮ್ಯಾನೇಜ್ಡ್ API ನಿಂದ ಬರುತ್ತಿದ್ದರೆ, ಒಳ್ಳೆಯ ವಿಷಯವೆಂದರೆ ಅನೇಕ ಓಪನ್-ವೇಟ್ ಹೋಸ್ಟಿಂಗ್ ಪ್ರೊವೈಡರ್‌ಗಳು ಮತ್ತು ಇನ್ಫರೆನ್ಸ್ ಇಂಜಿನ್‌ಗಳು ಈಗ ಒಂದೇ ರೀತಿಯ ಭಾಷೆಯನ್ನು ಮಾತನಾಡುತ್ತವೆ: HTTP POST, JSON ಪೇಲೋಡ್‌ಗಳು ಮತ್ತು ಬೇರರ್ ಟೋಕನ್ ಅಥೆಂಟಿಕೇಶನ್. ಕಾರ್ಯವಿಧಾನಗಳು ಪರಿಚಿತವಾಗಿರಬಹುದು, ಆದರೆ ವಿವರಗಳು ಹೆಚ್ಚು ಮುಖ್ಯವಾಗಿವೆ ಏಕೆಂದರೆ ಪ್ರೊವೈಡರ್ ಅಲ್ಲ, ನೀವೇ ವಿಶ್ವಾಸಾರ್ಹತೆ, ವೆಚ್ಚ ನಿಯಂತ್ರಣ ಮತ್ತು ವರ್ತನೆಯನ್ನು ರೂಪಿಸುವ ಜವಾಬ್ದಾರಿಯನ್ನು ಹೊಂದಿರುತ್ತೀರಿ.

API ಕಾಲ್‌ನ ಮೂಲಭೂತ ಅಂಶಗಳು

ಇದರ ಮೂಲತಃ, ಇಂಟಿಗ್ರೇಷನ್ ಒಂದು POST ರಿಕ್ವೆಸ್ಟ್ ಆಗಿದೆ. ನೀವು Authorization ಹೆಡರ್‌ನಲ್ಲಿ ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಬೇರರ್ ಟೋಕನ್ ಮೂಲಕ ಅಥೆಂಟಿಕೇಟ್ ಮಾಡಿಕೊಳ್ಳುತ್ತೀರಿ. ಬಾಡಿ ಒಂದು JSON ಆಬ್ಜೆಕ್ಟ್ ಆಗಿರುತ್ತದೆ ಮತ್ತು ಅದರ ಅತ್ಯಂತ ಪ್ರಮುಖ ಕ್ಷೇತ್ರವು messages ಅರೇ ಆಗಿದೆ. ಆ ಅರೇ ಪರಿಚಿತ ಚಾಟ್ ಫಾರ್ಮ್ಯಾಟ್ ಅನ್ನು ಅನುಸರಿಸುತ್ತದೆ: ಸಿಸ್ಟಮ್, ಯೂಸರ್ ಮತ್ತು ಅಸಿಸ್ಟೆಂಟ್ ರೋಲ್‌ಗಳ ಬದಲಾವಣೆ.

ಪ್ರಾಯೋಗಿಕವಾಗಿ ಕನಿಷ್ಠ ರಿಕ್ವೆಸ್ಟ್ ರಚನೆ ಹೀಗಿರುತ್ತದೆ:

  • Authorization ಹೆಡರ್ ಅನ್ನು Bearer <your-token> ಗೆ ಸೆಟ್ ಮಾಡಿ.
  • ಕನಿಷ್ಠ ಪಕ್ಷ ಒಂದು model ಐಡೆಂಟಿಫೈಯರ್ ಮತ್ತು messages ಪಟ್ಟಿಯನ್ನು ಒಳಗೊಂಡಿರುವ JSON ಪೇಲೋಡ್ ಅನ್ನು ಕಳುಹಿಸಿ.
  • ನೀವು ನಿರ್ಣಾಯಕ (deterministic) ಅಥವಾ ಸೃಜನಾತ್ಮಕ ನಿಯಂತ್ರಣವನ್ನು ಬಯಸಿದರೆ max_tokens ಮತ್ತು temperature ಅನ್ನು ಸೇರಿಸಿ.

ರೆಸ್ಪಾನ್ಸ್ choices ಅರೇ ಮತ್ತು usage ಆಬ್ಜೆಕ್ಟ್‌ನೊಂದಿಗೆ ಬರುತ್ತದೆ. ಆ usage ಬ್ಲಾಕ್ ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸಬೇಡಿ. ಇದು prompt_tokens, completion_tokens ಮತ್ತು ಒಟ್ಟು ಮೊತ್ತವನ್ನು ಒಳಗೊಂಡಿದೆ. ನೀವು ಸೆಲ್ಫ್-ಹೋಸ್ಟ್ ಮಾಡುತ್ತಿದ್ದರೆ, ಒಂದು ನಿರ್ದಿಷ್ಟ ಬಳಕೆದಾರರ ಸಂವಹನವು ದುಬಾರಿಯಾಗಿದೆಯೇ ಎಂಬುದನ್ನು ತಿಳಿಯಲು ಇದು ನಿಮ್ಮ ಸಂಕೇತವಾಗಿದೆ. ನೀವು ಥರ್ಡ್-ಪಾರ್ಟಿ ಇನ್ಫರೆನ್ಸ್ ಪ್ರೊವೈಡರ್‌ಗೆ ಹಣ ಪಾವತಿಸುತ್ತಿದ್ದರೆ, ಇದು ನಿಮ್ಮ ಬಿಲ್ಲಿಂಗ್ ಡೇಟಾ ಆಗಿದೆ. ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲೂ, ಮೊದಲ ದಿನದಿಂದಲೇ ಇದನ್ನು ಲಾಗ್ ಮಾಡಿ.

ಸ್ಟ್ರೀಮಿಂಗ್ ಮತ್ತು ನೀವು ಅದನ್ನು ಏಕೆ ಬಳಸಬೇಕು

ಒಂದು ಪಠ್ಯದ ತುಣುಕು ಕಾಣಿಸಿಕೊಳ್ಳುವ ಮೊದಲು ಮೂರು ಸೆಕೆಂಡುಗಳ ಕಾಲ ಲೋಡಿಂಗ್ ಸ್ಪಿನ್ನರ್ ಅನ್ನು ನೋಡುವುದನ್ನು ಯಾರೂ ಇಷ್ಟಪಡುವುದಿಲ್ಲ. ಸ್ಟ್ರೀಮಿಂಗ್ ಅದನ್ನು ಸರಿಪಡಿಸುತ್ತದೆ. ಮಾಡೆಲ್ ಇಡೀ ಪೂರ್ಣಗೊಳಿಸುವಿಕೆಗಾಗಿ ಕಾಯುವ ಬದಲು, ಸರ್ವರ್ ಟೋಕನ್‌ಗಳನ್ನು ಅವು ಜನರೇಟ್ ಆಗುತ್ತಿದ್ದಂತೆ ಹೊರಸೂಸುತ್ತದೆ. ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ಸರ್ವರ್-ಸೆಂಟ್ ಇವೆಂಟ್ಸ್ (Server-Sent Events) ಅಥವಾ ಚಂಕ್ಡ್ HTTP ರೆಸ್ಪಾನ್ಸ್‌ಗಳನ್ನು ಪಡೆಯುತ್ತದೆ ಮತ್ತು ಪದಗಳು ಬಂದ ತಕ್ಷಣವೇ ಅವುಗಳನ್ನು ರেন্ডರ್ ಮಾಡಬಹುದು.

ನಿಮ್ಮ JSON ಪೇಲೋಡ್‌ನಲ್ಲಿ stream: true ಫ್ಲಾಗ್ ಅನ್ನು ಸೆಟ್ ಮಾಡುವ ಮೂಲಕ ಸ್ಟ್ರೀಮಿಂಗ್ ಅನ್ನು ಎನೇಬಲ್ ಮಾಡಿ. ಕ್ಲೈಂಟ್ ಕಡೆಯಿಂದ, ನೀವು ಸಾಮಾನ್ಯವಾಗಿ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಸಾಲು ಸಾಲಾಗಿ ಪಾರ್ಸ್ ಮಾಡುತ್ತೀರಿ ಮತ್ತು data: ಪ್ರಿಫಿಕ್ಸ್ಸ್‌ಗಾಗಿ ಕಾಯುತ್ತೀರಿ. ಸ್ಟ್ರೀಮ್ ಮಧ್ಯದಲ್ಲಿ ಕನೆಕ್ಷನ್ ಕಡಿತಗೊಂಡರೆ, ಮರುಸಂಪರ್ಕಿಸಲು ಅಥವಾ ನಾನ್-ಸ್ಟ್ರೀಮಿಂಗ್ ರಿಟ್ರೈಗೆ ಬದಲಾಯಿಸಲು ಸಿದ್ಧರಿರಿ. ನಿಮ್ಮ ಚಾಟ್ ಆಪ್‌ನ ಲೇಟೆನ್ಸಿ (latency) ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆಯಾಗುತ್ತದೆ ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ಸಿಸ್ಟಮ್ ಅವರ ವಿನಂತಿಯನ್ನು ಬ್ಯಾಚ್-ಪ್ರೊಸೆಸ್ ಮಾಡುವ ಬದಲು ಅವರೊಂದಿಗೆ ಯೋಚಿಸುತ್ತಿದೆ ಎಂಬ ಭಾವನೆ ಮೂಡುತ್ತದೆ.

ನೈಜ-ಪ್ರಪಂಚದ ವರ್ಕ್‌ಫ್ಲೋಗಳಿಗಾಗಿ ಫಂಕ್ಷನ್ ಕಾಲಿಂಗ್

ಕೇವಲ ಪಠ್ಯವನ್ನು ಮಾತ್ರ ನೀಡುವ ಮಾಡೆಲ್ ಉಪಯುಕ್ತವಾಗಿದೆ, ಆದರೆ ಪರಿಕರಗಳನ್ನು (tools) ಬಳಸಬಲ್ಲ ಮಾಡೆಲ್ ಹೆಚ್ಚು ಉಪಯುಕ್ತವಾಗಿದೆ. ಫಂಕ್ಷನ್ ಕಾಲಿಂಗ್ ನಿಮಗೆ ಲಭ್ಯವಿರುವ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ವಿವರಿಸುವ JSON ಸ್ಕೀಮಾವನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಲು ಅನುಮತಿಸುತ್ತದೆ—ಉದಾಹರಣೆಗೆ, search_orders ಅಥವಾ update_profile—ಮತ್ತು ಮಾಡೆಲ್ ಅವುಗಳನ್ನು ಯಾವಾಗ ಬಳಸಬೇಕೆಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. ಬಳಕೆದಾರರಿಗೆ ಅನುಸರಣಾ ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳುವ ಬದಲು, ಇದು ಸಂಭಾಷಣೆಯಿಂದ ಹೊರತೆಗೆಯಲಾದ ಆರ್ಗ್ಯುಮೆಂಟ್‌ಗಳೊಂದಿಗೆ ರಚನಾತ್ಮಕ ಫಂಕ್ಷನ್ ಕಾಲ್ ಅನ್ನು ಹೊರಸೂಸುತ್ತದೆ.

ಉದಾಹರಣೆಗೆ, ಬಳಕೆದಾರರು “ನನ್ನ ಕೊನೆಯ ಆರ್ಡರ್ ಯಾವುದು?” ಎಂದು ಕೇಳಿದರೆ, ನಿಮ್ಮ ಸ್ಕೀಮಾ limit ಪ್ಯಾರಾಮೀಟರ್‌ನೊಂದಿಗೆ get_recent_orders ಫಂಕ್ಷನ್ ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಬಹುದು. ಮಾಡೆಲ್ ಟೂಲ್ ಕಾಲ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ನಿಮ್ಮ ಬ್ಯಾಕೆಂಡ್ ನಿಮ್ಮ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಕ್ವೆರಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ನೀವು ಫಲಿತಾಂಶವನ್ನು ಫಂಕ್ಷನ್ ರೆಸ್ಪಾನ್ಸ್ ಮೆಸೇಜ್ ಆಗಿ ಮಾಡೆಲ್‌ಗೆ ಹಿಂತಿರುಗಿಸುತ್ತೀರಿ. ನಂತರ ಮಾಡೆಲ್ ನೈಸರ್ಗಿಕ ಭಾಷೆಯ ಉತ್ತರವನ್ನು ಸಿದ್ಧಪಡಿಸುತ್ತದೆ.

ಇದನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸಲು:

  • ನಿಮ್ಮ ಪೇಲೋಡ್‌ನಲ್ಲಿ tools ಅಥವಾ functions ಅರೇ ಅನ್ನು ಒದಗಿಸಿ.
  • ಪ್ರತಿ ಟೂಲ್ ಅನ್ನು name, description, ಮತ್ತು parameters ಸ್ಕೀಮಾದೊಂದಿಗೆ ವ್ಯಾಖ್ಯಾನಿಸಿ.
  • ಟೂಲ್-ಕಾಲ್ಸ್ ಫಿನಿಶ್ ರೀಸನ್ ಅಥವಾ ಅಂತಹ ಸಂಕೇತಕ್ಕಾಗಿ ರೆಸ್ಪಾನ್ಸ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಿ.
  • ನಿಮ್ಮ ಬ್ಯಾಕೆಂಡ್‌ನಲ್ಲಿ ಕಟ್ಟುನಿಟ್ಟಾದ ವ್ಯಾಲಿಡೇಶನ್‌ನೊಂದಿಗೆ ಫಂಕ್ಷನ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿ. ನಿಮ್ಮ ಡೇಟಾಬೇಸ್‌ಗೆ ಅನ್‌ಸ್ಯಾನಿಟೈಸ್ಡ್ (unsanitized) ಮಾಡೆಲ್ ಔಟ್‌ಪುಟ್‌ಗಳನ್ನು ನೇರವಾಗಿ ಬಳಸಲು ಎಂದಿಗೂ ನಂಬಬೇಡಿ.
  • ಫಂಕ್ಷನ್ ಫಲಿತಾಂಶವನ್ನು ಮೆಸೇಜ್ ಇತಿಹಾಸಕ್ಕೆ ಸೇರಿಸಿ ಮತ್ತು ಫಾಲೋ-ಅಪ್ ರಿಕ್ವೆಸ್ಟ್ ಕಳುಹಿಸಿ ಇದರಿಂದ ಮಾಡೆಲ್ ಅಂತಿಮ ಉತ್ತರವನ್ನು ನೀಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.

ಈ ಮಾದರಿಯು ಜನರೇಟಿವ್ ಟೆಕ್ಸ್ಟ್ ಮತ್ತು ನಿರ್ಣಾಯಕ (deterministic) ಸಿಸ್ಟಮ್‌ಗಳ ನಡುವಿನ ಅಂತರವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ನೀವು ಪ್ರತಿಯೊಂದು ಬ್ರಾಂಚ್ ಅನ್ನು ಹಾರ್ಡ್-ಕೋಡ್ ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲದೆ ನಿಮ್ಮ AI ಕ್ಯಾಲೆಂಡರ್‌ಗಳನ್ನು ಓದಬಹುದು, API ಗಳನ್ನು ಕ್ವೆರಿ ಮಾಡಬಹುದು ಅಥವಾ ವೆಬ್‌ಹುಕ್‌ಗಳನ್ನು (webhooks) ಟ್ರಿಗ್ಗರ್ ಮಾಡಬಹುದು.

ಪ್ರೊಡಕ್ಷನ್ ಬಳಕೆಗಾಗಿ ಸಿದ್ಧತೆ

ಪ್ರೊಡಕ್ಷನ್‌ನಲ್ಲಿ ಓಪನ್-ವೇಟ್ ಮಾಡೆಲ್‌ಗಳನ್ನು ಚಲಾಯಿಸುವುದು ನಿಮ್ಮನ್ನು ಯಾವುದೇ ವಿತರಿಸಿದ ಸಿಸ್ಟಮ್‌ನಂತೆ (distributed system) ವಿಫಲತೆಯ ಸಾಧ್ಯತೆಗಳಿಗೆ ಒಡ್ಡುತ್ತದೆ, ಜೊತೆಗೆ ಕೆಲವು ವಿಶಿಷ್ಟ ಸಮಸ್ಯೆಗಳಿಗೂ ಒಡ್ಡುತ್ತದೆ. ಮಾಡೆಲ್ ಇನ್ಫರೆನ್ಸ್ ಕಂಪ್ಯೂಟ್-ಸಂಮೂಲ intensive ಆಗಿದೆ ಮತ್ತು ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳು ಲೋಡ್ ಅಡಿಯಲ್ಲಿ ಕುಸಿಯಬಹುದು. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸ್ಥಿರವಾಗಿಡಲು ಇಲ್ಲಿವೆ ಕೆಲವು ಮಾರ್ಗಗಳು.

ದೋಷಗಳು ಮತ್ತು ಮರುಪ್ರಯತ್ನಗಳು

  • 429 Too Many Requests: ಇದು ರೇಟ್-ಲಿಮಿಟ್ (rate-limit) ಸಂಕೇತವಾಗಿದೆ. ಎಕ್ಸ್‌ಪೋನೆನ್ಶಿಯಲ್ ಬ್ಯಾಕಆಫ್ ವಿತ್ ಜಿಟ್ಟರ್ (exponential backoff with jitter) ಅನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳಿ. ಸಣ್ಣ ವಿಳಂಬದೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿ, ಪದೇ ಪದೇ 429 ಎರ್‌ರರ್‌ಗಳು ಬಂದರೆ ಅದನ್ನು ದ್ವಿಗುಣಗೊಳಿಸಿ, ಮತ್ತು ಸರ್ವರ್ ಮೇಲೆ ಹೆಚ್ಚಿನ ಒತ್ತಡ ಬರದಂತೆ ಕೆಲವು ಸೆಕೆಂಡುಗಳಿಗಿಂತ ಹೆಚ್ಚು ಮಾಡಬೇಡಿ.
  • 5xx Server Errors: ಇವು ಸಾಮಾನ್ಯವಾಗಿ ತಾತ್ಕಾಲಿಕವಾಗಿದ್ದು, ವಿಶೇಷವಾಗಿ ನೀವು GPU ವರ್ಕರ್ಸ್ ಪೂಲ್‌ಗೆ ರೂಟಿಂಗ್ ಮಾಡುತ್ತಿದ್ದರೆ ಹೀಗೆ ಇರುತ್ತದೆ. ಇವುಗಳನ್ನು ಮರುಪ್ರಯತ್ನಿಸಿ (retry), ಆದರೆ ಪ್ರಯತ್ನಗಳ ಸಂಖ್ಯೆಗೆ ಒಂದು ಮಿತಿಯನ್ನು ಇರಿಸಿ—ಮೂರು ಎಂಬುದು ಸಾಮಾನ್ಯ ಡಿಫಾಲ್ಟ್ ಆಗಿದೆ.
  • 4xx Client Errors: ಇವುಗಳನ್ನು ಕುರುಡಾಗಿ ಮರುಪ್ರಯತ್ನಿಸಬೇಡಿ. 400 ಎಂದರೆ ನಿಮ್ಮ ಪೇಲೋಡ್ (payload) ತಪ್ಪಾಗಿದೆ, 401 ಎಂದರೆ ನಿಮ್ಮ ಟೋಕನ್ ತಪ್ಪಾಗಿದೆ, ಮತ್ತು 404 ಎಂದರೆ ಆ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ನಲ್ಲಿ ಮಾಡೆಲ್ ಐಡಿ (model ID) ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ ಎಂದರ್ಥ. ಲೂಪ್ ಮಾಡುವ ಬದಲು ವಿನಂತಿಯನ್ನು (request) ಸರಿಪಡಿಸಿ.

ಟೈಮೌಟ್‌ಗಳು ಮತ್ತು ಹ್ಯಾಂಗಿಂಗ್ ಪ್ರಕ್ರಿಯೆಗಳು (Timeouts and Hanging Processes)

ಕ್ಯೂಗಳು (queues) ತುಂಬಿದಾಗ ಅಥವಾ ಜನರೇಷನ್ ನಡುವೆ ವರ್ಕರ್ ಕ್ರ್ಯಾಶ್ ಆದಾಗ ಇನ್ಫರೆನ್ಸ್ (Inference) ವಿಳಂಬವಾಗಬಹುದು. ಯಾವಾಗಲೂ ರಿಕ್ವೆಸ್ಟ್ ಟೈಮೌಟ್ ಅನ್ನು ಸೆಟ್ ಮಾಡಿ. ನಿಮ್ಮ HTTP ಕ್ಲೈಂಟ್ ಡಿಫಾಲ್ಟ್ ಇನ್ಫಿನಿಟಿ (infinity) ಆಗಿದ್ದರೆ, ಅದನ್ನು ಬದಲಾಯಿಸಿ. ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಕಂಪ್ಲೀಷನ್‌ಗಳಿಗೆ 30 ರಿಂದ 60 ಸೆಕೆಂಡುಗಳು ಒಂದು ಸಮಂಜಸವಾದ ಆರಂಭಿಕ ಬಿಂದುವಾಗಿದೆ, ಹೆಲ್ತ್ ಚೆಕ್‌ಗಳಿಗೆ ಇನ್ನೂ ಕಡಿಮೆ ಇರಲಿ. ಟೈಮೌಟ್ ಸಂಭವಿಸಿದರೆ, ಅದನ್ನು ವೈಫಲ್ಯವೆಂದು ಪರಿಗಣಿಸಿ, ಲಾಗ್ ಮಾಡಿ ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ಸುಗಮವಾದ ಎರ್‌ರರ್ ತೋರಿಸಬೇಕೆ ಅಥವಾ ಫಾಲ್‌ಬ್ಯಾಕ್ ಮಾಡೆಲ್‌ನಲ್ಲಿ ಮರುಪ್ರಯತ್ನಿಸಬೇಕೆ ಎಂದು ನಿರ್ಧರಿಸಿ.

ಬಜೆಟ್ ನಿಯಂತ್ರಣ (Budget Control)

ಟೋಕನ್ ಸಂಖ್ಯೆಗಳು ನೇರವಾಗಿ ಹಣ ಅಥವಾ GPU ಗಂಟೆಗಳಿಗೆ ಪರಿವರ್ತನೆಯಾಗುತ್ತವೆ. ಪ್ರತಿ ವಿನಂತಿಗೂ ಪ್ರಾಂಪ್ಟ್ (prompt) ಮತ್ತು ಕಂಪ್ಲೀಷನ್ (completion) ಟೋಕನ್‌ಗಳನ್ನು ಲಾಗ್ ಮಾಡಿ. ಅವುಗಳನ್ನು ಪ್ರತಿ ಬಳಕೆದಾರರು, ಪ್ರತಿ ಫೀಚರ್ ಮತ್ತು ಪ್ರತಿ ಮಾಡೆಲ್ ವರ್ಷನ್ ಪ್ರಕಾರ ಟ್ರ್ಯಾಕ್ ಮಾಡಿ. ಓಪನ್-ವೇಟ್ ಮಾಡೆಲ್‌ಗಳು (Open-weight models) ನಿಮಗೆ ಚೆಕ್‌ಪಾಯಿಂಟ್‌ಗಳನ್ನು ಬದಲಾಯಿಸಲು ಅವಕಾಶ ನೀಡುತ್ತವೆ, ಆದರೆ ಪ್ರತಿ ಚೆಕ್‌ಪಾಯಿಂಟ್‌ಗೂ ತನ್ನದೇ ಆದ ವೆಚ್ಚದ ಪ್ರೊಫೈಲ್ ಮತ್ತು ಕಾಂಟೆಕ್ಸ್ಟ್-ವಿಂಡೋ (context-window) ಗಾತ್ರವಿರುತ್ತದೆ. ಲಾಗ್‌ಗಳಿಲ್ಲದೆ, ನಿಮ್ಮ ಉತ್ಪನ್ನದ ಯಾವ ಭಾಗವು ಹೆಚ್ಚು ಕಂಪ್ಯೂಟ್ ಬಳಸುತ್ತಿದೆ ಎಂಬುದು ನಿಮಗೆ ತಿಳಿಯುವುದಿಲ್ಲ.

ಸಿಸ್ಟಮ್ ಮೆಸೇಜ್‌ಗಳ ಮೂಲಕ ವರ್ತನೆಯ ರೂಪಾಂತರ (Behavior Shaping with System Messages)

ಸಿಸ್ಟಮ್ ಮೆಸೇಜ್ ನಿಮ್ಮ ಮೊದಲ ನಿಯಂತ್ರಣದ ಸಾಲು. ಟೋನ್ ಸೆಟ್ ಮಾಡಲು, ನಿರ್ಬಂಧಗಳನ್ನು ಜಾರಿಗೆ ತರಲು ಮತ್ತು ಪ್ರತಿ ಬಳಕೆದಾರರ ಸಂಭಾಷಣೆಯು ಗೌರವಿಸಬೇಕಾದ ಸ್ಟ್ಯಾಟಿಕ್ ಕಾಂಟೆಕ್ಸ್ಟ್ ಅನ್ನು ಸೇರಿಸಲು ಇದನ್ನು ಬಳಸಿ. ಓಪನ್-ವೇಟ್ ಮಾಡೆಲ್‌ಗಳು ಅವುಗಳ ಫೈನ್-ಟ್ಯೂನಿಂಗ್ ಮತ್ತು ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್‌ಗಳ ಆಧಾರದ ಮೇಲೆ ವಿಭಿನ್ನವಾಗಿ ವರ್ತಿಸುವುದರಿಂದ, ಈ ಫೀಲ್ಡ್ ಅನ್ನು ನೀವು A/B ಟೆಸ್ಟ್ ಮಾಡುವ ವೇರಿಯಬಲ್ ಆಗಿ ಪರಿಗಣಿಸಿ. ಅಸ್ಪಷ್ಟ ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್ ಅಸ್ಪಷ್ಟ ಉತ್ತರಗಳನ್ನು ನೀಡುತ್ತದೆ. ನಿಖರವಾದ ಪ್ರಾಂಪ್ಟ್ ಮಾಡೆಲ್ ಅನ್ನು ಸರಿಯಾದ ಹಾದಿಯಲ್ಲಿಡುತ್ತದೆ—ಉದಾಹರಣೆಗೆ, ಅಸಿಸ್ಟೆಂಟ್ ಕೇವಲ ಬಿಲ್ಲಿಂಗ್ ಮತ್ತು ರಿಟರ್ನ್ಸ್ ಅನ್ನು ಮಾತ್ರ ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಉಳಿದೆಲ್ಲವನ್ನೂ ವಿನಯಪೂರ್ವಕವಾಗಿ ನಿರಾಕರಿಸಬೇಕು ಎಂದು ತಿಳಿಸುವುದು.

ಮೂಲಸೌಕರ್ಯ ಸ್ವಾತಂತ್ರ್ಯ ಮತ್ತು ಡೇಟಾ ಸಾರ್ವಭೌಮತ್ವ (Infrastructure Freedom and Data Sovereignty)

ಓಪನ್-ವೇಟ್ ಮಾಡೆಲ್‌ಗಳ ಅತ್ಯಂತ ದೊಡ್ಡ ಪ್ರಯೋಜನಗಳಲ್ಲಿ ಒಂದೆಂದರೆ ಅದರ ಮೇಲಿನ ಅಧಿಕಾರ (custody). ನಿಮ್ಮ ಪ್ರಾಂಪ್ಟ್‌ಗಳು ಮತ್ತು ಕಂಪ್ಲೀಷನ್‌ಗಳು ನಿಮ್ಮ ಪರಿಸರದಿಂದ ಹೊರಗೆ ಹೋಗುವ ಅಗತ್ಯವಿಲ್ಲ. ನೀವು ಮಾಡೆಲ್ ಅನ್ನು ಆನ್-ಪ್ರೆಮಿಸಿಸ್ ಅಥವಾ ವರ್ಚುವಲ್ ಪ್ರೈವೇಟ್ ಕ್ಲೌಡ್‌ನಲ್ಲಿ ರನ್ ಮಾಡಿದರೆ, ನೀವು ಥರ್ಡ್-ಪಾರ್ಟಿ ಡೇಟಾ ಪ್ರೊಸೆಸಿಂಗ್ ಒಪ್ಪಂದಗಳನ್ನು ತಪ್ಪಿಸಬಹುದು ಮತ್ತು ಟ್ರೈನಿಂಗ್-ಡೇಟಾ ವಿವಾದಗಳಿಗೆ ಒಳಗಾಗುವ ಸಾಧ್ಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು. ಆರೋಗ್ಯ ರಕ್ಷಣೆ, ಹಣಕಾಸು ಮತ್ತು ಡೇಟಾ ಸೋರಿಕೆ ಸಂಭವಿಸಿದರೆ ಅನುಸರಣೆ (compliance) ಸಮಸ್ಯೆ ಉಂಟಾಗುವ ಯಾವುದೇ ಡೊಮೇನ್‌ಗಳಿಗೆ ಇದು ಬಹಳ ಮುಖ್ಯವಾಗಿದೆ.

ನೀವು ಬಾಹ್ಯ ಇನ್ಫರೆನ್ಸ್ ಹೋಸ್ಟ್ ಅನ್ನು ಬಳಸಿದರೂ ಸಹ, ಓಪನ್ ವೇಟ್ಸ್ ನಿಮಗೆ ಪೋರ್ಟಬಿಲಿಟಿ (portability) ನೀಡುತ್ತದೆ. ಹೋಸ್ಟ್ ಬೆಲೆ ಅಥವಾ ನಿಯಮಗಳನ್ನು ಬದಲಾಯಿಸಿದರೆ, ನೀವು ಅದೇ ಮಾಡೆಲ್ ಫೈಲ್‌ಗಳನ್ನು ಇನ್ನೊಂದು ಪ್ರೊವೈಡರ್‌ಗೆ ವರ್ಗಾಯಿಸಬಹುದು ಅಥವಾ ನಿಮ್ಮ ಸ್ವಂತ ವ್ಯವಸ್ಥೆಗೆ ತರಬಹುದು. ವೇಟ್ಸ್‌ಗಳನ್ನು ಹೊಂದಿರುವ ಕಂಪನಿ ಒಂದೇ ಆಗಿರುವುದರಿಂದ, ನೀವು ಒಂದೇ API ಗೆ ಕಟ್ಟುಬಿದ್ದಿರುವುದಿಲ್ಲ.

ಒಂದು ಪ್ರಾಯೋಗಿಕ ಆರಂಭಿಕ ಬಿಂದು (A Practical Starting Point)

ನೀವು ಇಂದು ಇಂಟಿಗ್ರೇಟ್ ಮಾಡುತ್ತಿದ್ದರೆ, ಒಂದೇ ಮಾಡೆಲ್ ಮತ್ತು ಒಂದೇ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ನೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿ. ಅಥೆಂಟಿಕೇಶನ್ (authentication), ಮರುಪ್ರಯತ್ನಗಳು (retries) ಮತ್ತು ಟೋಕನ್ ಲಾಗಿಂಗ್ ಅನ್ನು ನಿರ್ವಹಿಸುವ ಸಣ್ಣ ಅಬ್‌ಸ್ಟ್ರಾಕ್ಷನ್ ಲೇಯರ್‌ನಲ್ಲಿ (abstraction layer) ನಿಮ್ಮ HTTP ಕ್ಲೈಂಟ್ ಅನ್ನು ಸುತ್ತುವರಿಯಿರಿ. ನಂತರ ಸ್ಟ್ರೀಮಿಂಗ್ ಅನ್ನು ಸೇರಿಸಿ, ಏಕೆಂದರೆ ಬಳಕೆದಾರರ ಅನುಭವದಲ್ಲಿ ಅದರ ಪ್ರಯೋಜನ ತಕ್ಷಣವೇ ತಿಳಿಯುತ್ತದೆ. ನಂತರ ಹೆಚ್ಚಿನ ಮೌಲ್ಯದ ವರ್ಕ್‌ಫ್ಲೋಗಾಗಿ—ಸ್ಟೇಟಸ್ ಲುಕ್‌ಅಪ್‌ಗಳು, ಕಂಟೆಂಟ್ ಮಾಡರೇಶನ್ ಅಥವಾ ಫಾರ್ಮ್ ಫಿಲ್ಲಿಂಗ್—ಒಂದು ಫಂಕ್ಷನ್ ಕಾಲ್ ಅನ್ನು ಪರಿಚಯಿಸಿ. ವ್ಯಾಪಕವಾಗಿ ಅಳವಡಿಸುವ ಮೊದಲು ಒಂದು ವಾರದವರೆಗೆ ಲೇಟೆನ್ಸಿ (latency), ಎರ್‌ರರ್ ರೇಟ್‌ಗಳು ಮತ್ತು ಟೋಕನ್ ವೆಚ್ಚವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ.

ಸಂಪೂರ್ಣವಾಗಿ ಮ್ಯಾನೇಜ್ ಮಾಡಲಾದ API ಗಿಂತ ಓಪನ್-ವೇಟ್ ಮಾಡೆಲ್‌ಗಳಿಗೆ ಹೆಚ್ಚಿನ ಸೆಟಪ್ ಅಗತ್ಯವಿರುತ್ತದೆ, ಆದರೆ ಅವು ಪಾರದರ್ಶಕತೆ, ನಮ್ಯತೆ ಮತ್ತು ನಿಯಂತ್ರಣದೊಂದಿಗೆ ಆ ಶ್ರಮಕ್ಕೆ ತಕ್ಕ ಪ್ರತಿಫಲ ನೀಡುತ್ತವೆ. ಇಂಟಿಗ್ರೇಶನ್ ಅನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ನಿರ್ಮಿಸಿ, ಎಲ್ಲವನ್ನೂ ಇನ್ಸ್ಟ್ರುಮೆಂಟ್ ಮಾಡಿ, ಆಗ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಅಗತ್ಯವಿರುವ ರೀತಿಯಲ್ಲೇ ವರ್ತಿಸುವ AI ಲೇಯರ್ ಅನ್ನು ನೀವು ಹೊಂದಿರುತ್ತೀರಿ.

ಮೂಲಗಳು ಮತ್ತು ಹೆಚ್ಚಿನ ಓದು