AI ಏಜೆಂಟ್ಗಳು ಪ್ರಯೋಗಾತ್ಮಕ ಪ್ರೋಟೋಟೈಪ್ಗಳಿಂದ ನಿಜ ಜೀವನದ ಅಪ್ಲಿಕೇಶನ್ಗಳಿಗೆ ಸಾಗುತ್ತಿದ್ದಂತೆ, ಅವರ ವರ್ತನೆ ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು, ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು ಮತ್ತು kelu输出ಗಳನ್ನು ವ್ಯವಸ್ಥಿತವಾಗಿ ಮೌಲ್ಯಮಾಪನ ಮಾಡುವ ಸಾಮರ್ಥ್ಯ маңыздыವಾಗುತ್ತದೆ.
ಈ ಪಾಠವನ್ನು ಪೂರ್ಣಗೊಳಿಸಿದ ನಂತರ, ನೀವು ಈ ಕೆಳಗಿನ ವಿಷಯಗಳನ್ನು ತಿಳಿದಿರುತ್ತೀರಿ/ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೀರಿ:
ಉದ್ದೇಶವು ನಿಮ್ಮ “ಕಪ್ಪು ಪೆಟ್ಟಿಗೆ” ಏಜೆಂಟ್ಗಳನ್ನು ಪಾರದರ್ಶಕ, ನಿರ್ವಹಣಾ ಮತ್ತು ನಂಬಬಹುದಾದ ವ್ಯವಸ್ಥೆಗಳಾಗಿ ಪರಿವರ್ತಿಸಲು ಅಗತ್ಯವಾದ ಜ್ಞಾನವನ್ನು ಒದಗಿಸುವುದು.
ಗಮನಿಸಿ: AI ಏಜೆಂಟ್ಗಳು ಸುರಕ್ಷಿತ ಮತ್ತು ನಂಬಿಕೊಳ್ಳಬಹುದಾಗಿರಲಿ ಎಂದು ನಿಯೋಜಿಸುವುದು ಮುಖ್ಯವಾಗಿದೆ. ದಯವಿಟ್ಟು ನಂಬಿಸಬಹುದಾದ AI ಏಜೆಂಟ್ಗಳನ್ನು ನಿರ್ಮಿಸಲಾಗುವುದು ಪಾಠವನ್ನು ಕೂಡ ಪರಿಗಣಿಸಿ.
Langfuse ಅಥವಾ Microsoft Foundry ಮುಂತಾದ ನಿರೀಕ್ಷಣಾ ಸಾಧನಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಏಜೆಂಟ್ ರನ್ಗಳನ್ನು ಟ್ರೇಸ್ಗಳು ಮತ್ತು ಸ್ಪಾನ್ಗಳಾಗಿ ಪ್ರತಿನಿಧಿಸುತ್ತವೆ.
ನಿರೀಕ್ಷಣಾ ಸಾಮರ್ಥ್ಯವಿಲ್ಲದೆ, AI ಏಜೆಂಟ್ ಒಂದು “ಕಪ್ಪು ಪೆಟ್ಟಿಗೆ” ಎನ್ನಿಸಬಹುದು — ಅದರ ಆಂತರಿಕ ಸ್ಥಿತಿ ಮತ್ತು ತર્ક ಮೋಹಕವಾಗಿರುತ್ತದೆ, ದೋಷಗಳನ್ನು ನಿರ್ಣಯಿಸುವುದು ಅಥವಾ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸುವುದು ಕಠಿಣವಾಗುತ್ತದೆ. ನಿರೀಕ್ಷಣಾ ಸಾಮರ್ಥ್ಯದಿಂದ, ಏಜೆಂಟ್ಗಳು “ಗಾಜಿನ ಪೆಟ್ಟಿಗೆಗಳು” ಆಗಿ ಪರಿಗಣಿಸಲ್ಪಡುತ್ತವೆ, ಇದು ಪಾರದರ್ಶಕತೆ ನೀಡುತ್ತದೆ ಮತ್ತು ನಂಬಿಕೆಯನ್ನು ನಿರ್ಮಿಸಲು ಮತ್ತು ಅವುಗಳನ್ನು ನಿರ್ಣಯಿಸಿದಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಅಗತ್ಯವಿದೆ.
AI ಏಜೆಂಟ್ಗಳನ್ನು ಉತ್ಪಾದನಾ ಪರಿಸರಗಳಿಗೆ ವರ್ಗಾಯಿಸುವುದು ಹೊಸ ಸವಾಲುಗಳು ಮತ್ತು ಅಗತ್ಯಗಳನ್ನು ಪರಿಚಯಿಸುತ್ತದೆ. ನಿರೀಕ್ಷಣಾ ಸಾಮರ್ಥ್ಯವು ಈಗ “ಉಪಯುಕ್ತತೆಯಂಥ” ಅಲ್ಲ, ಬದಲಾಗಿ ಅತ್ಯವಶ್ಯಕ ಸಾಮರ್ಥ್ಯವಾಗಿದೆ:
ಏಜೆಂಟ್ ವರ್ತನೆಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮತ್ತು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ವಿವಿಧ ಮೆಟ್ರಿಕ್ಗಳು ಮತ್ತು ಸಂಕೇತಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಬೇಕು. ನಿರ್ದಿಷ್ಟ ಮೆಟ್ರಿಕ್ಗಳು ಏಜೆಂಟ್ ಉದ್ದೇಶದ ಆಧಾರದಲ್ಲಿ ಬದಲಾಗಬಹುದು, ಆದರೆ ಕೆಲವು ಸಾಮಾನ್ಯವಾಗಿ ಮಹತ್ವದವಾಗಿವೆ.
ಇದು ಕೆಲವು ಸಾಮಾನ್ಯ ಮೆಟ್ರಿಕ್ಗಳು:
ವಿಲಂಬ (Latency): ಏಜೆಂಟ್ 얼마나 ಶೀಘ್ರವಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ? ದೀರ್ಘ ನಿರೀಕ್ಷಾ ಸಮಯಗಳು ಬಳಕೆದಾರ ಅನುಭವವನ್ನು ನೆಗೆಟಿವಾಗಿ ಪ್ರಭಾವಿಸುತ್ತವೆ. ನೀವು ಏಜೆಂಟ್ ರನ್ಗಳ ಟ್ರೇಸಿಂಗ್ ಮೂಲಕ ಕಾರ್ಯಗಳು ಮತ್ತು ವೈಯಕ್ತಿಕ ಹಂತಗಳ ವಿಲಂಬವನ್ನು ಅಳೆಯಬೇಕು. ಉದಾಹರಣೆಗೆ, ಎಲ್ಲಾ ಮಾದರಿ ಕರೆಗಳಿಗೆ ಏಜೆಂಟ್ 20 ಸೆಕೆಂಡ್ ತೆಗೆದುಕೊಂಡಿದ್ದರೆ, ಬೇಗನೆಯ ಮಾದರಿಯನ್ನು ಬಳಸಿಕೊಳ್ಳುವುದ거나 ಮಾದರಿ ಕರೆಗಳನ್ನು ಸಮಾಂತರವಾಗಿ ನಡೆಸುವುದರಿಂದ ವೇಗ ಹೆಚ್ಚಿಸಬಹುದು.
ವೆಚ್ಚಗಳು: ಪ್ರತಿ ಏಜೆಂಟ್ ರನ್ ಗೆ ಖರ್ಚು ಎಷ್ಟು? AI ಏಜೆಂಟ್ಗಳು ಟೋಕನ್ ಪ್ರತಿ ಅಥವಾ ಹೊರಗಿನ APIಗಳ ಪ್ರತಿ ಕಾಲ್ ಪ್ರಕಾರ ಬಿಲ್ ಆಗುವ LLM ಕರೆಗಳ ಮೇಲೆ ಅವಲಂಬಿಸುತ್ತವೆ. ಬಹಳಷ್ಟು ಉಪಕರಣ ಬಳಕೆ ಅಥವಾ ಅನೇಕ prompts ವೆಚ್ಚವನ್ನು ದ್ರುತವಾಗಿ ಹೆಚ್ಚಿಸಬಹುದು. ಉದಾಹರಣೆಗೆ, ಒಂದು ಏಜೆಂಟ್ ಗುಣಮಟ್ಟದಲ್ಲಿ ಸಣ್ಣ ಸುಧಾರಣೆಗೆ LLM ಅನ್ನು ಐದು ಬಾರಿ ಕರೆಮಾಡುತ್ತಿದ್ದರೆ, ನೀವು ವೆಚ್ಚ ನ್ಯಾಯವಾಗಿದೆಯೇ ಅಥವಾ ಕಾಲ್ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಬೇಕು. ರಿಯಲ್-ಟೈಮ್ ಮೇಲ್ವಿಚಾರಣೆ ಅಸಹಜ ಏರಿಕೆಗಳನ್ನು (ಉದಾ. ದೋಷಗಳಿಂದಾಗಿ ಅತಿರೇಕ API ಲೂಪ್ಗಳು) ಗುರುತಿಸಲು ಸಹಾಯ ಮಾಡಬಹುದು.
ಕೋರ್ನರ್ ದೋಷಗಳ ವಿನಂತಿಗಳು (Request Errors): ಏಜೆಂಟ್ ಎಷ್ಟು ವಿನಂತಿಗಳನ್ನು ವಿಫಲಗೊಳಿಸಿತು? ಇದರಲ್ಲಿ API ದೋಷಗಳು ಅಥವಾ ವಿಫಲವಾದ ಉಪಕರಣ ಕರೆಗಳು ಸೇರಬಹುದು. ಉತ್ಪಾದನೆಯಲ್ಲಿ ಈ ಮಾದರಿಯ ವಿರುದ್ದ ನಿಮ್ಮ ಏಜೆಂಟ್ ಅನ್ನು ಹೆಚ್ಚು ದೃಢಗೊಳಿಸಲು, ನೀವು fallback ಗಳು ಅಥವಾ retries ಅನ್ನು ಸ್ಥಾಪಿಸಬಹುದು. ಉದಾಹರಣೆ: LLM provider A ಡೌನ್ ಆಗಿದ್ದರೆ, ಬ್ಯಾಕ್ಅಪ್ ಆಗಿ LLM provider B ಗೆ ಬದಲಾಯಿಸುವುದು.
ಬಳಕೆದಾರ ಪ್ರತಿಕ್ರಿಯೆ: ನೇರ ಬಳಕೆದಾರ ಮೌಲ್ಯಮಾಪನಗಳನ್ನು ನೇರವಾಗಿ ಜಾರಿ ಮಾಡಿದರೆ ಅಮೂಲ್ಯ洞察 ಲಭ್ಯವಾಗುತ್ತವೆ. ಇದರಲ್ಲಿ ಸ್ಪಷ್ಟ ರೇಟಿಂಗ್ಗಳು (👍thumbs-up/👎down, ⭐1-5 ಸ್ಟಾರ್) ಅಥವಾ ಪಠ್ಯದ ಕಾಮೆಂಟ್ಗಳು ಸೇರಬಹುದು. ನಿರಂತರ ನೆಗೆಟಿವ್ ಪ್ರತಿಕ್ರಿಯೆ ನೀವು ನಿರೀಕ್ಷಿಸಿದಂತೆ ಏಜೆಂಟ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿಲ್ಲ ಎಂಬ ಸೂಚನೆ ನೀಡುತ್ತದೆ.
ಅಕ್ರಮಿಕ ಬಳಕೆದಾರ ಪ್ರತಿಕ್ರಿಯೆ (Implicit User Feedback): ಸ್ಪಷ್ಟ ರೇಟಿಂಗ್ ಇಲ್ಲದೆ ಸಹ ಬಳಕೆದಾರ ವರ್ತನೆಗಳು ಪರೋಕ್ಷ ಪ್ರತಿಕ್ರಿಯೆ ಒದಗಿಸುತ್ತವೆ. ಇದರಲ್ಲಿ ತಕ್ಷಣದ ಪ್ರಶ್ನೆ ಮರುರೂಪಣೆ, ಪುನರಾವರ್ತಿತ ಪ್ರಶ್ನೆಗಳು ಅಥವಾ retry ಬಟನ್ ಕ್ಲಿಕ್ ಮಾಡುವಂತಹವುಗಳಾಗಬಹುದು. ಉದಾಹರಣೆ: ಬಳಕೆದಾರರು ನಿರಂತರವಾಗಿ ಅದೇ ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳುತ್ತಿರುವುದನ್ನು ನೀವು ನೋಡಿದರೆ, ಅದು ಏಜೆಂಟ್ ನಿರೀಕ್ಷೆಯಂತೆ ಕಾರ್ಯನಿರತವಿಲ್ಲ ಎಂಬ ಸೂಚನೆ.
ನಿಖರತೆ (Accuracy): ಏಜೆಂಟ್ ಎಷ್ಟು ಪ್ರಮಾಣದಲ್ಲಿ ಸರಿಯಾದ ಅಥವಾ ಇಚ್ಛಿತ outputಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ? ನಿಖರತೆ ವ್ಯಾಖ್ಯಾನಗಳು ಬದಲಾಗಬಹುದು (ಉದಾ. ಸಮಸ್ಯೆ ಪರಿಹಾರ ಸಾಮರ್ಥ್ಯದ ಸರಿಯಾದತೆ, ಮಾಹಿತಿ ಪುನಃಪ್ರಾಪ್ತಿ ನಿಖರತೆ, ಬಳಕೆದಾರ ತೃಪ್ತಿ). ಯಶಸ್ಸು ಹೇಗಿರಬೇಕು ಎಂಬುದನ್ನು ಮೊದಲಿಗೆ ವ್ಯಾಖ್ಯಾನಿಸಬೇಕು. ನೀವು ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳು, ಮೌಲ್ಯಮಾಪನಸ್ಕೋರ್ಗಳು ಅಥವಾ ಕಾರ್ಯ ಪೂರ್ಣಗೊಂಡೆಂಬ ಲೇಬಲ್ಗಳ ಮೂಲಕ ನಿಖರತೆ ಟ್ರ್ಯಾಕ್ ಮಾಡಬಹುದು. ಉದಾಹರಣೆಗೆ, ಟ್ರೇಸ್ಗಳನ್ನು “succeeded” ಅಥವಾ “failed” ಎಂದು ಗುರುತಿಸುವುದು.
ಸ್ವಯಂಚಾಲಿತ ಮೌಲ್ಯಮಾಪನ ಮೆಟ್ರಿಕ್ಗಳು: ನೀವು ಸ್ವಯಂಚಾಲಿತ ಮೌಲ್ಯಮಾಪನಗಳನ್ನು ಕೂಡ ಸ್ಥಾಪಿಸಬಹುದು. ಉದಾಹರಣೆಗೆ, ನೀವು ಏಜೆಂಟ್_OUTPUT ಅನ್ನು LLM ಬಳಸಿ ಸ್ಕೋರ್ ಮಾಡಲು ಬಳಸಬಹುದು, ಉದಾ. ಅದು ಸಹಾಯಕವಾಗಿದೆ, ನಿಖರವಾಗಿರುವುದೆ ಅಥವಾ ಇಲ್ಲವೆ ಎಂಬುದನ್ನು. ಹಲವು ಓಪನ್ ಸೋರ್ಸ್ ಲೈಬ್ರರಿಗಳು ವಿಭಿನ್ನ ಆಯಾಮಗಳನ್ನು ಸ್ಕೋರ್ ಮಾಡಲು ಸಹಾಯ ಮಾಡುತ್ತವೆ. ಉದಾಹರಣೆ: RAG ಏಜೆಂಟ್ ಗಾಗಿ RAGAS ಅಥವಾ ಹಾನಿಕಾರಕ ಭಾಷೆ ಅಥವಾ prompt injection ಅನ್ನು ಪತ್ತೆಹಚ್ಚಲು LLM Guard ಉಳಿತಾಯವಾಗಿದೆ.
ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಈ ಮೆಟ್ರಿಕ್ಗಳ ಸಂಯೋಜನೆಯೇ AI ಏಜೆಂಟ್ ಆರೋಗ್ಯದ ಅತ್ಯುತ್ತಮ ಕವರ್ ನೀಡುತ್ತದೆ. ಈ ಅಧ್ಯಾಯದ ಉದಾಹರಣಾ ನೋಟ್ಬುಕ್ ನಲ್ಲಿ ಈ ಮೆಟ್ರಿಕ್ಗಳು ನಿಜ ಉದಾಹರಣೆಯಲ್ಲೀ ಹೇಗೆ ಕಾಣಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ನಾವು ತೋರಿಸುತ್ತೇವೆ ಆದರೆ ಮೊದಲು ಸಾಮಾನ್ಯ ಮೌಲ್ಯಮಾಪನ ಕಾರ್ಯಪದ್ಧತಿ ಹೇಗಿರುತ್ತದೆ ಎಂದು ತಿಳಿದುಕೊಳ್ಳೋಣ.
ಟ್ರೇಸಿಂಗ್ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು, ನೀವು ನಿಮ್ಮ ಕೋಡ್ ಅನ್ನು ಇನ್ಸ್ಟ್ರುಮೆಂಟ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಉದೇಶ್ಯವು ಏಜೆಂಟ್ ಕೋಡ್ ಅನ್ನು ಇನ್ಸ್ಟ್ರುಮೆಂಟ್ ಮಾಡಿ ಟ್ರೇಸ್ಗಳು ಮತ್ತು ಮೆಟ್ರಿಕ್ಗಳನ್ನು ಹೊರಡಿಸುವುದಾಗಿದೆ, ಅವುಗಳನ್ನು ನಿರೀಕ್ಷಣಾ ವೇದಿಕೆಗಳಿಂದ ಹಿಡಿಯಬಹುದಾದ, ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬಹುದಾದ ಮತ್ತು ದೃಶ್ಯೀಕರಿಸಬಹುದಾದಂತೆ.
OpenTelemetry (OTel): OpenTelemetry LLM ನಿರೀಕ್ಷಣಾ ಸಾಮರ್ಥ್ಯದ ಬೆಳವಣಿಗೆಯಲ್ಲಿ ಕೈಗಾರಿಕಾ ಮಾನದಂಡವಾಗಿ ಹೊರಬಂದಿದೆ. ಇದು ಟೆಲಿಮೆಟ್ರಿ ಡೇಟಾವನ್ನು ರಚಿಸಲು, ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ರಫ್ತು ಮಾಡಲು APIಗಳು, SDKಗಳು ಮತ್ತು ಸಾಧನಗಳ ಸಂಕಲನವನ್ನು ಒದಗಿಸುತ್ತದೆ.
ಈಗಿರುವ ಏಜೆಂಟ್ ಫ್ರೆಮರ್ಕ್ಗಳನ್ನು vòngುವ ಇದಕ್ಕೆ ಉಚಿತವಾಗಿರುವ ಅನೇಕ ಇನ್ಸ್ಟ್ರುಮೆಂಟೇಶನ್ ಲೈಬ್ರರಿಗಳು ಇವೆ ಮತ್ತು ಅವು OpenTelemetry ಸ್ಪಾನ್ಗಳನ್ನು ನಿರೀಕ್ಷಣಾ ಸಾಧನಕ್ಕೆ ಬಹಿರ್ಗತಿಪಡಿಸಲು ಸುಲಭಗೊಳಿಸುತ್ತವೆ. Microsoft Agent Framework OpenTelemetryನ್ನು ಸ್ವಭಾವಿಕವಾಗಿ ಸಮಾವೇಶಿಸುತ್ತದೆ. ಕೆಳಗಿನದೊಂದು MAF ಏಜೆಂಟ್ ಅನ್ನು ಇನ್ಸ್ಟ್ರುಮೆಂಟ್ ಮಾಡುವ ಉದಾಹರಣೆ:
from agent_framework.observability import get_tracer, get_meter
tracer = get_tracer()
meter = get_meter()
with tracer.start_as_current_span("agent_run"):
# ಏಜೆಂಟ್ ಕಾರ್ಯನಿರ್ವಹಣೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಟ್ರೇಸ್ ಮಾಡಲಾಗುತ್ತದೆ
pass
ಈ ಅಧ್ಯಾಯದ ಉದಾಹರಣಾ ನೋಟ್ಬುಕ್ ನಿಮ್ಮ MAF ಏಜೆಂಟ್ ಅನ್ನು ಹೇಗೆ ಇನ್ಸ್ಟ್ರುಮೆಂಟ್ ಮಾಡುವುದು ಎಂದು ಪ್ರದರ್ಶಿಸುತ್ತದೆ.
ಮ್ಯಾನುಯಲ್ ಸ್ಪಾನ್ ಸೃಷ್ಟಿ: ಇನ್ಸ್ಟ್ರುಮೆಂಟೇಶನ್ ಲೈಬ್ರರಿಗಳು ಉತ್ತಮ ಮೂಲಭೂತ ರೇಖೆಯನ್ನು ಒದಗಿಸಿದರೂ, ಹೆಚ್ಚಿನ ವಿವರವಾದ ಅಥವಾ ಕಸ್ಟಮ್ ಮಾಹಿತಿ ಬೇಕಾಗುವ ಸಂದರ್ಭಗಳು 많ಿರುತ್ತವೆ. ನೀವು ಕಸ್ಟಮ್ ಪ್ರಯೋಜನಕ್ಕಾಗಿ ಕೈಯಿಂದ ಸ್ಪಾನ್ಸ್ ಸೃಷ್ಟಿಸಬಹುದು. ಮುಖ್ಯವಾಗಿ, ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಅಥವಾ ಕೈಯಿಂದ ಸೃಷ್ಟಿಸಲಾದ ಸ್ಪಾನ್ಗಳನ್ನು ಕಸ್ಟಮ್ ಅಟ್ರಿಬ್ಯೂಟ್ಗಳು (ಟ್ಯಾಗ್ಗಳು ಅಥವಾ ಮೆಟಾಡೇಟಾ ಎಂದು ಸಹ ಕರೆಯಲಾಗುತ್ತದೆ) ಮೂಲಕ ಸಮ್ಮೃದ್ಧಗೊಳಿಸಬಹುದು. ಈ ಅಟ್ರಿಬ್ಯೂಟ್ಗಳಲ್ಲಿ ವ್ಯವಹಾರ ಸ್ಪೆಸಿಫಿಕ್ ಡೇಟಾ, ಮಧ್ಯಂತರ ಗಣನೆಗಳು ಅಥವಾ ಡೀಬಗ್ಗಿಂಗ್ ಅಥವಾ ವಿಶ್ಲೇಷಣೆಗೆ ಉಪಯುಕ್ತವಾಗಬಹುದಾದ ಯಾವುದೇ ಸ.context ಸೇರಬಹುದು, ಉದಾಹರಣೆಗೆ user_id, session_id, ಅಥವಾ model_version.
Langfuse Python SDK ಬಳಸಿ ಟ್ರೇಸ್ಗಳು ಮತ್ತು ಸ್ಪಾನ್ಗಳನ್ನು ಕೈಯಿಂದ ಸೃಷ್ಟಿಸುವ ಉದಾಹರಣೆ:
from langfuse import get_client
langfuse = get_client()
span = langfuse.start_span(name="my-span")
span.end()
ನಿರೀಕ್ಷಣಾ ಸಾಮರ್ಥ್ಯವು ನಮಗೆ ಮೆಟ್ರಿಕ್ಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ, ಆದರೆ ಮೌಲ್ಯಮಾಪನವು ಆ ಡೇಟಾವನ್ನು ವಿಶ್ಲೇಷಿಸುವ (ಮತ್ತು ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸುವ) ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ, ಏಜೆಂಟ್ ಹೇಗೆ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಮತ್ತು ಅದನ್ನು ಹೇಗೆ ಸುಧಾರಿಸಬಹುದು ಎಂದು ನಿರ್ಧಾರಮಾಡಲು. ಬೇರೇನಂದ್ರೆ, ನೀವು ಆ ಟ್ರೇಸ್ಗಳು ಮತ್ತು ಮೆಟ್ರಿಕ್ಗಳನ್ನು ಪಡೆದ ಮೇಲೆ, ಏಜೆಂಟ್ ಅನ್ನು ನ್ಯಾಯ ಸುವರ್ಣಿಸಲು ಮತ್ತು ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ನೀವು ಅವುಗಳನ್ನು ಹೇಗೆ ಬಳಸುತ್ತೀರಿ?
ನಿಯಮಿತ ಮೌಲ್ಯಮಾಪನವು ಮುಖ್ಯವಾಗಿರುವುದೆಂದರೆ AI ಏಜೆಂಟ್ಗಳು ಅಸ್ಪಷ್ಟವಾಗಿರಬಹುದು ಮತ್ತು ಇವುವು (ಅಪ್ಡೇಟ್ಗಳು ಅಥವಾ ಮಾದರಿ ವರ್ತನೆದ ಡ್ರಿಫ್ಟ್ ಮುಖೇನ) ಪರಿಣಮಿಸಬಹುದು – ಮೌಲ್ಯಮಾಪನವಿಲ್ಲದೆ, ನಿಮ್ಮ “ಸ್ಮಾರ್ಟ್ ಏಜೆಂಟ್” ನಿಜವಾಗಿಯೂ ತನ್ನ ಕೆಲಸವನ್ನು טובವಾಗಿ ಮಾಡುತ್ತಿದೆಯೇ ಅಥವಾ ಅವನು ಹಾನಿಗೊಂಡಿದ್ದಾನೇ ಎಂಬುದನ್ನು ನೀವು ತಿಳಿದುಕೊಳ್ಳುವುದಿಲ್ಲ.
AI ಏಜೆಂಟ್ಗಳಿಗಾಗಿ ಎರಡು ವರ್ಗಗಳ ಮೌಲ್ಯಮಾಪನಗಳಿವೆ: ಆನ್ಲೈನ್ ಮೌಲ್ಯಮಾಪನ ಮತ್ತು ಆಫ್ಲೈನ್ ಮೌಲ್ಯಮಾಪನ. ಎರಡೂ মূল্যಯುತವಾಗಿವೆ ಮತ್ತು ಪರಸ್ಪರ ಪೂರಕವಾಗಿವೆ. ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಆಫ್ಲೈನ್ ಮೌಲ್ಯಮಾಪನದಿಂದ ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ, ಏಕೆಂದರೆ ಯಾವುದೇ ಏಜೆಂಟ್ ಅನ್ನು ನಿಯೋಜಿಸುವ ಮೊದಲು ಇದು ಕನಿಷ್ಠ ಅಗತ್ಯ ಹಂತವಾಗಿದೆ.

ಇದು ನಿಯಂತ್ರಿತ ಪರಿಸರದಲ್ಲಿ, ಸಾಮಾನ್ಯವಾಗಿ ಪರೀಕ್ಷಾ ಡೇಟಾಸೆಟ್ಗಳನ್ನು ಬಳಸಿ, ಲೈವ್ ಬಳಕೆದಾರ ಪ್ರಶ್ನೆಗಳನ್ನು ಬಳಸದೆ ಏಜೆಂಟ್ ಅನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುವುದು. ನೀವು ನಿರೀಕ್ಷಿತ output ಅಥವಾ ಸರಿಯಾದ ವರ್ತನೆ ಏನೆಂದು ತಿಳಿದಿರುವ ಕ್ಯೂರೇಟೆಡ್ ಡೇಟಾಸೆಟ್ಗಳನ್ನು ಬಳಸುತ್ತೀರಿ ಮತ್ತು ಅದರಲ್ಲಿ ನಿಮ್ಮ ಏಜೆಂಟ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತೀರಿ.
ಉದಾಹರಣೆಗೆ, ನೀವು ಗಣಿತ ಪದ-ಪ್ರಶ್ನೆ ಏಜೆಂಟ್ ನಿರ್ಮಿಸಿದ್ದರೆ, ನಿಮಗೆ ತಿಳಿದ ಉತ್ತರಗಳೊಂದಿಗೆ 100 ಸಮಸ್ಯೆಗಳ test dataset ಇರಬಹುದು. ಆಫ್ಲೈನ್ ಮೌಲ್ಯಮಾಪನವನ್ನು ಅಭಿವೃದ್ಧಿ ವೇಳೆ (ಮತ್ತು CI/CD ಪೈಪ್ಲೈನ್ಗಳ ಭಾಗವಾಗಿರಬಹುದು) ಸುಧಾರಣೆಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ಅಥವಾ ರಿಗ್ರೆಶನ್ಗಳ ವಿರುದ್ಧ ರಕ್ಷಿಸಲು ಮಾಡಲಾಗುತ್ತದೆ. ಲಾಭವೆಂದರೆ ಇದು ಪುನರಾವರ್ತನೀಯ ಮತ್ತು ನಿಮಗೆ ಗ್ರೌಂಡ್ ಟ್ರೂತ್ ಇದ್ದಾಗ ಸ್ಪಷ್ಟ ನಿಖರತೆ ಮೆಟ್ರಿಕ್ಗಳನ್ನು ಕೊಡುವುದು. ನೀವು ಬಳಕೆದಾರ ಪ್ರಶ್ನೆಗಳನ್ನು ಅನುಕರಿಸಬಹುದು ಮತ್ತು ಏಜೆಂಟ್ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಆદર્શ ಉತ್ತರಗಳ ವಿರುದ್ಧ ಅಳೆಯಬಹುದು ಅಥವಾ ಮೇಲ್ಕಂಡ ಸ್ವಯಂಚಾಲಿತ ಮೆಟ್ರಿಕ್ಗಳನ್ನು ಬಳಸಬಹುದು.
ಆಫ್ಲೈನ್ ಮೌಲ್ಯಮಾಪನದ ಪ್ರಮುಖ ಸವಾಲು ನಿಮ್ಮ ಟೆಸ್ಟ್ ಡೇಟಾಸೆಟ್ ಸಮಗ್ರವಾಗಿರಬೇಕು ಮತ್ತು ಪ್ರಾಸಂಗಿಕತೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳಬೇಕು — ಏಜೆಂಟ್ ಸ್ಥಿರ ಪರೀಕ್ಷಾ ಸೆಟ್ನಲ್ಲಿ ಚೆನ್ನಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು ಆದರೆ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಬಹುಮಟ್ಟಿಗೆ ವಿಭಿನ್ನ ಪ್ರಶ್ನೆಗಳನ್ನು ಎದುರಿಸಬಹುದು. ಆದ್ದರಿಂದ, ನೀವು ಟೆಸ್ಟ್ ಸೆಟ್ಗಳನ್ನು ನವೀನ ಎಡ್ಜ್ ಪ್ರಕರಣಗಳು ಮತ್ತು ನಿಜ ಜಗತ್ತಿನ ದೃಶ್ಯಗಳನ್ನು ಪ್ರತಿಬಿಂಬಿಸುವ ಉದಾಹರಣೆಗಳೊಂದಿಗೆ تازهಮಾಡಬೇಕು. ಸಣ್ಣ “ಸ್ಮೋಕ್ ಟೆಸ್ಟ್” ಪ್ರಕರಣಗಳ ಮತ್ತು ದೊಡ್ಡ ಮೌಲ್ಯಮಾಪನ ಸೆಟ್ಗಳ ಮಿಶ್ರಣವು ಉಪಯುಕ್ತ: ತ್ವರಿತ ಪರಿಶೀಲನೆಗಳಿಗೆ ಸಣ್ಣ ಸೆಟ್ಗಳು ಮತ್ತು ವಿಶಾಲ ಕಾರ್ಯಕ್ಷಮತೆ ಮೆಟ್ರಿಕ್ಗಳಿಗಾಗಿ ದೊಡ್ಡ ಸೆಟ್ಗಳು.

ಇದು ಲೈವ್, ನಿಜ ಜೀವನದ ಪರಿಸರದಲ್ಲಿ — ಅಂದರೆ ಉತ್ಪಾದನಿಯಲ್ಲಿ ನಿಜವಾದ ಬಳಕೆಗಾಗಿ ಏಜೆಂಟ್ ಅನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುವುದಕ್ಕೆ ಸಂಬಂಧಿಸಿದೆ. ಆನ್ಲೈನ್ ಮೌಲ್ಯಮಾಪನವು ನಿಜ ಬಳಕೆದಾರ ಸಂವಹನಗಳ ಮೇಲೆ ಏಜೆಂಟ್ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು ಮತ್ತು ಫಲಿತಾಂಶಗಳನ್ನು ನಿರಂತರವಾಗಿ ವಿಶ್ಲೇಷಿಸುವುದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ.
ಉದಾಹರಣೆಗೆ, ನೀವು ಲೈವ್ ಟ್ರಾಫಿಕ್ನಲ್ಲಿ ಯಶಸ್ಸಿನ ದರಗಳು, ಬಳಕೆದಾರ ತೃಪ್ತಿ ಸ್ಕೋರ್ಗಳು ಅಥವಾ ಇತರ ಮೆಟ್ರಿಕ್ಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಬಹುದು. ಆನ್ಲೈನ್ ಮೌಲ್ಯಮಾಪನದ ಲಾಭವೆಂದರೆ ಅದರಿಂದ ನೀವು ಲ್ಯಾಬ್ ಸೆಟ್ಟಿಂಗ್ನಲ್ಲಿ ಊಹಿಸದದ್ದನ್ನೇ ಹಿಡಿಯಬಹುದು — ಮಾದರಿ ಡ್ರಿಫ್ಟ್ ಅನ್ನು ಸಮಯದೊಂದಿಗೆ ಗಮನಿಸಬಹುದು (ಉದಾ. ಇನ್ಪುಟ್ ಮಾದರಿಗಳ ಬದಲಾವಣೆಯಿಂದ ಏಜೆಂಟ್ ಪರಿಣಾಮಕಾರಿತ್ವ ಕುಗ್ಗುತ್ತದೆ) ಮತ್ತು ನಿಮ್ಮ ಟೆಸ್ಟ್ ಡೇಟಾದಲ್ಲಿ ಇರದ ಅನಿರೀಕ್ಷಿತ ಪ್ರಶ್ನೆಗಳು ಅಥವಾ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಬಹುದು. ಇದು ಏಜೆಂಟ್ ನಲ್ಲಿನ ನಿಜ ನಡತೆಯನ್ನು ಚಿತ್ರಿಸುತ್ತದೆ.
ಆನ್ಲೈನ್ ಮೌಲ್ಯಮಾಪನವು ಪರೋಕ್ಷ ಮತ್ತು ಸ್ಪಷ್ಟ ಬಳಕೆದಾರ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದನ್ನು ಒಳಗೊಂಡಿರಬಹುದು ಮತ್ತು ನೆರವಾಗುವಂತೆ ಛಾಯಾಚಾಲಕ ಪರೀಕ್ಷೆಗಳನ್ನು (shadow tests) ಅಥವಾ A/B ಟೆಸ್ಟ್ಗಳನ್ನು ನಡೆಸಬಹುದು (ಇಲ್ಲಿ ಹೊಸ ಏಜೆಂಟ್ ಆವೃತ್ತಿ ಹಳೆಯದಕ್ಕೆ ಹೋಲಿಸಲು ಪ್ಯಾರಲೆಲ್ನಲ್ಲಿ ಓಡುತ್ತದೆ). ಸವಾಲು ಏನೆಂದರೆ ಲೈವ್ ಸಂವಹನಗಳಿಗೆ ವಿಶ್ವಸನೀಯ ಲೇಬಲ್ಗಳು ಅಥವಾ ಸ್ಕೋರ್ಗಳನ್ನು ಪಡೆಯುವುದು ಕಷ್ಟವಾಗಬಹುದು — ನೀವು ಬಳಕೆದಾರ ಪ್ರತಿಕ್ರಿಯೆ ಅಥವಾ ಡೌನ್ಸ್ಟ್ರೀಮ್ ಮೆಟ್ರಿಕ್ಗಳ(ಉದಾ. ಬಳಕೆದಾರ ಫಲಿತಾಂಶವನ್ನು ಕ್ಲಿಕ್ ಮಾಡಿದರೆ) ಮೇಲೆ ಅವಲಂಬಿಸಬಹುದು.
ಆನ್ಲೈನ್ ಮತ್ತು ಆಫ್ಲೈನ್ ಮೌಲ್ಯಮಾಪನಗಳು ಪರಸ್ಪರ ವಿರುದ್ಧವಲ್ಲ; ಅವು ಬಹುಮಟ್ಟಿಗೆ ಪೂರಕವಾಗಿವೆ. ಆನ್ಲೈನ್ ಮೇಲ್ವಿಚಾರಣೆಯಿಂದ (ಉದಾ. ಹೊಸ ರೀತಿಯ ಬಳಕೆದಾರ ಪ್ರಶ್ನೆಗಳು) ದೊರಕುವ洞察ಗಳನ್ನು ಆಫ್ಲೈನ್ ಪರೀಕ್ಷಾ ಡೇಟಾಸೆಟ್ಗಳನ್ನು ವಿಸ್ತರಿಸಲು ಬಳಸಬಹುದು. ಬದಲಾಗಿ, ಆಫ್ಲೈನ್ ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ಚೆನ್ನಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಏಜೆಂಟ್ಗಳನ್ನು ಆನ್ಲೈನ್ನಲ್ಲಿ ಹೆಚ್ಚು ವಿಶ್ವಾಸದಿಂದ ನಿಯೋಜಿಸಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬಹುದು.
ಅತಂತ್ರವಾಗಿ, ಅನೇಕ ತಂಡಗಳು ಕೆಳಗಿನ ಚಕ್ರವನ್ನು ಅನುಸರಿಸುತ್ತವೆ:
ಆಫ್ಲೈನ್ನಲ್ಲಿ ಮೌಲ್ಯಮಾಪನ -> ನಿಯೋಜಿಸಿ -> ಆನ್ಲೈನ್ನಲ್ಲಿ ಮೇಲ್ವಿಚಾರಣೆ -> ಹೊಸ ವೈಫಲ್ಯ ಪ್ರಕರಣಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ -> ಆಫ್ಲೈನ್ ಡೇಟಾಸೆಟ್ಗೆ ಸೇರಿಸಿ -> ಏಜೆಂಟ್ ಅನ್ನು ತಿದ್ದಿ -> ಪುನರಾವರ್ತನೆ.
AI ಏಜೆಂಟ್ಗಳನ್ನು ಉತ್ಪಾದನೆಯಲ್ಲಿ ನಿಯೋಜಿಸಿದಾಗ, ನೀವು ವಿವಿಧ ಸವಾಲುಗಳನ್ನು ಎದುರಿಸಬಹುದಾಗಿದೆ. ಇಲ್ಲಿದೆ ಕೆಲವು ಸಾಮಾನ್ಯ ಸಮಸ್ಯೆಗಳು ಮತ್ತು ಅವುಗಳ ಸಾಧ್ಯ ಪರಿಹಾರಗಳು:
| ಸಮಸ್ಯೆ | ಸಾಧ್ಯ ಪರಿಹಾರ |
|---|---|
| AI ಏಜೆಂಟ್ ನಿರಂತರವಾಗಿ ಕಾರ್ಯಗಳನ್ನು ಸुसಂಸ್ಕೃತವಾಗಿ ನಿರ್ವಹಿಸುತ್ತಿಲ್ಲ | - AI ಏಜೆಂಟ್ಗೆ ನೀಡಲಾಗುತ್ತಿರುವ prompt ಅನ್ನು ತಿದ್ದಿ; ಉದ್ದೇಶಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿರಲಿ. - ಕಾರ್ಯಗಳನ್ನು ಉಪಕಾರ್ಯಗಳಲ್ಲಿ ವಿಭಜಿಸುವುದು ಮತ್ತು ಅವುಗಳನ್ನು ಅನೇಕ ಏಜೆಂಟ್ಗಳು ನಿರ್ವಹಿಸುವಂತೆ ಮಾಡುವುದು ಸಹ ಸಹಾಯಕಾರಿಯಾಗಬಹುದು. |
| AI ಏಜೆಂಟ್ ನಿರಂತರ ಲೂಪ್ಗಳಲ್ಲಿ ಸಿಡಿಯುತ್ತಿರುವುದು | - ಏಜೆಂಟ್ ಯಾವಾಗ ಪ್ರಕ್ರಿಯೆ ನಿಲ್ಲಿಸಬೇಕು ಎಂಬ ಸ್ಪಷ್ಟ ತೀರ್ಮಾನಗಳು ಮತ್ತು ನಿಬಂಧನೆಗಳನ್ನು ಹೊಂದಿರುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. - ತರ್ಕ ಮತ್ತು ಯೋಜನೆಗೆ ಅಗತ್ಯವಾಗುವ ಸಂಕೀರ್ಣ ಕಾರ್ಯಗಳಿಗೆ, ತರ್ಕಾತ್ಮಕ ಕಾರ್ಯಗಳಿಗೆ ವಿಶೇಷೀಕೃತ ದೊಡ್ಡ ಮಾದರಿಯನ್ನು ಬಳಸಿ. |
| AI ಏಜೆಂಟ್ ಉಪಕರಣ ಕರೆಗಳು ಚೆನ್ನಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿಲ್ಲ | - ಏಜೆಂಟ್ ವ್ಯವಸ್ಥೆಯ ಹೊರಗೆ ಉಪಕರಣದ output ಅನ್ನು ಪರೀಕ್ಷಿಸಿ ಮತ್ತು ಮಾನ್ಯಗೊಳಿಸಿ. - ವ್ಯಾಖ್ಯಾನಿಸಿದ ಪರಿಮೆರ್ಷೆಗಳು, prompts ಮತ್ತು ಉಪಕರಣಗಳ ನಾಮಕರಣವನ್ನು ತಿದ್ದಿ. |
| ಬಹು-ಏಜೆಂಟ್ ವ್ಯವಸ್ಥೆ ಸತತವಾಗಿ ಕಾರ್ಯನಿರತವಿಲ್ಲ | - ಪ್ರತಿ ಏಜೆಂಟ್ಗೆ ನೀಡಲಾಗುತ್ತಿರುವ promptಗಳನ್ನು ಸ್ಪೆಸಿಫಿಕ್ ಮತ್ತು ಪರस्पರ ವಿಭಿನ್ನವಾಗಿರುವಂತೆ ತಿದ್ದಿ. - ಯಾವ ಏಜೆಂಟ್ ಸರಿಯೆಂದು ನಿರ್ಧರಿಸಲು “routing” ಅಥವಾ ಕಂಟ್ರೋಲರ್ ಏಜೆಂಟ್ ಬಳಸಿ ಹೈರಾರ್ಕಿಕ ವ್ಯವಸ್ಥೆಯನ್ನು ರಚಿಸಿ. |
ಈ ಸಮಸ್ಯೆಗಳ ಬಹುತೇಕವನ್ನು ನಿರೀಕ್ಷಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ಜಾರಿಗೆ ತಂದರೆ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿ ರೀತಿಯಲ್ಲಿ ಗುರುತಿಸಬಹುದು. ಮೇಲ್ಕಂಡ ಟ್ರೇಸ್ಗಳು ಮತ್ತು ಮೆಟ್ರಿಕ್ಗಳು ಏಜೆಂಟ್ ಕಾರ್ಯಪ್ರವಾಹದಲ್ಲಿ ಅಲ್ಲಿ ತುಣುಕು ತಪ್ಪುಗಳು ನಡೆದಿವೆ ಎಂಬುದನ್ನು ಖಚಿತವಾಗಿ ನಿರ್ದಿಷ್ಠಪಡಿಸುವುದಕ್ಕೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಇದರಿಂದ ಡೀಬಗ್ಗಿಂಗ್ ಮತ್ತು ಅನುಕೂಲವರ್ಧನೆ ಬಹಳ ಪರಿಣಾಮಕಾರಿಯಾಗುತ್ತದೆ.
ಉತ್ಪಾದನಿಗೆ AI ಏಜೆಂಟ್ಗಳನ್ನು ಅನ್ವಯಿಸುವ ವೆಚ್ಚಗಳನ್ನು ನಿಯಂತ್ರಿಸಲು ಕೆಲವು ತಂತ್ರಗಳು ಇಲ್ಲಿವೆ:
Using Smaller Models: ಸಣ್ಣ ಭಾಷಾ ಮಾದರಿಗಳು (SLMs) ಕೆಲವು ಏಜೆಂಟಿಕ್ ಬಳಕೆ ಪ್ರಕರಣಗಳಲ್ಲಿ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು ಮತ್ತು ವೆಚ್ಚವನ್ನು ಗಣನೀಯವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತವೆ. ಮೇಲಾಗಿ ಉಲ್ಲೇಖಿಸಿದಂತೆ, ದೊಡ್ಡ ಮಾದರಿಗಳೊಂದಿಗೆ ಪ್ರದರ್ಶನವನ್ನು ನಿರ್ಧರಿಸಿ ಹೋಲಿಕೆ ಮಾಡುವ ಮೌಲ್ಯಮಾಪನ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ಮಿಸುವುದು ನಿಮ್ಮ ಬಳಕೆ ಪ್ರಕರಣದಲ್ಲಿ SLM ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸಲಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಅತ್ಯುತ್ತಮ ಮಾರ್ಗವಾಗಿದೆ. ಉದ್ದೇಶ ವರ್ಗೀಕರಣ ಅಥವಾ ಪ್ಯಾರಾಮೀಟರ್ ಹೊರತೆಗೆಯುವಿಕೆ 같은 ಸರಳ ಕಾರ್ಯಗಳಿಗೆ SLMಗಳನ್ನು ಬಳಸುವುದನ್ನು ಪರಿಗಣಿಸಿ, ಮತ್ತು ಸಂಕೀರ್ಣ ತಾರ್ಕಿಕತೆಗೆ ದೊಡ್ಡ ಮಾದರಿಗಳನ್ನು ಮೀಸಲಿಡಿ.
Using a Router Model: ಸಮಾನವಾದ ತಂತ್ರವೆಂದರೆ ವಿವಿಧ ಮಾದರಿಗಳ ಮತ್ತು ಗಾತ್ರಗಳ ವೈವಿಧ್ಯವನ್ನು ಬಳಸುವುದು. ನೀವು ಜಟಿಲತೆಯ ಆಧಾರದ ಮೇಲೆ ವಿನಂತಿಗಳನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿ ಹೊಂದಿಕೊಳ್ಳುವ ಮಾದರಿಗಳ ಕಡೆಗೆ ಮಾರ್ಗದರ್ಶಿಸಲು LLM/SLM ಅಥವಾ ಸರ್ವರ್ಲೆಸ್ ಫಂಕ್ಷನ್ ಅನ್ನು ಬಳಸಬಹುದು. ಇದು ಸರಿಯಾದ ಕಾರ್ಯಗಳಿಗೆ ಪ್ರದರ್ಶನವನ್ನು ಖಚಿತಪಡಿಸುವುದರ ಜೊತೆಗೆ ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಸರಳ ಪ್ರಶ್ನೆಗಳನ್ನು ಸಣ್ಣ ಮತ್ತು ವೇಗದ ಮಾದರಿಗಳ ಕಡೆಗೆ ಮಾರ್ಗದರ್ಶಿಸಿ, ಮತ್ತು ಸಂಕೀರ್ಣ ತಾರ್ಕಿಕ ಕಾರ್ಯಗಳಿಗಾಗಿ ಮಾತ್ರ ದುಬಾರಿಯಾದ ದೊಡ್ಡ ಮಾದರಿಗಳನ್ನು ಬಳಸಿ.
Caching Responses: ಸಾಮಾನ್ಯ ವಿನಂತಿಗಳು ಮತ್ತು ಕಾರ್ಯಗಳನ್ನು ಗುರುತಿಸಿ ಅವುಗಳ ಉತ್ತರಗಳನ್ನು ನಿಮ್ಮ ಏಜೆಂಟಿಕ್ ವ್ಯವಸ್ಥೆಯ ಮೂಲಕ ಹೋಗುವ ಮುನ್ನ ಒದಗಿಸುವುದು ಸಮಾನ ವಿನಂತಿಗಳ ಪ್ರಮಾಣವನ್ನು ಕಡಿಮೆ ಮಾಡುವ ಉತ್ತಮ ವಿಧಾನವಾಗಿದೆ. ನೀವು ಹಗುರವಾದ AI ಮಾದರಿಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಒಂದು ಹರಿವನ್ನು (flow) ಅನುಷ್ಠಾನಗೊಳಿಸಬಹುದು, ಅದು ಒಂದು ವಿನಂತಿ ನಿಮ್ಮ ಕ್ಯಾಶ್ ಮಾಡಿದ ವಿನಂತಿಗಳಿಗಿಂತ ಎಷ್ಟು ಸಾಮ್ಯವಿದೆ ಎಂದು ಗುರುತಿಸುತ್ತದೆ. ಆವೃತ್ತಿಯು ಹೆಚ್ಚಾಗುವ ಪ್ರಶ್ನೆಗಳು ಅಥವಾ ಸಾಮಾನ್ಯ ಕಾರ್ಯಪ್ರವಾಹಗಳಿಗಾಗಿ ಈ ತಂತ್ರವು ವೆಚ್ಚವನ್ನು ಗಣನೀಯವಾಗಿ ಕಡಿಮೆ ಮಾಡಬಹುದು.
In the ಉದಾಹರಣೆ ನೋಟ್ಬುಕ್, we’ll see examples of how we can use observability tools to monitor and evaluate our agent.
ಇತರ ಕಲಿಯುತ್ತಿರುವವರನ್ನು ಭೇಟಿಯಾಗಲು, ಆಫೀಸ್ ಅವರ್ಸ್ಗೆ ಹಾಜರಾಗಲು ಮತ್ತು ನಿಮ್ಮ AI ಏಜೆಂಟ್ಗಳ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಗಳನ್ನು ಪಡೆಯಲು Microsoft Foundry Discord ಸೇರಿಕೊಳ್ಳಿ.
ನಿರಾಕರಣೆ: ಈ ದಸ್ತಾವೇಜನ್ನು AI ಅನುವಾದ ಸೇವೆ Co-op Translator ಬಳಸಿ ಅನುವಾದಿಸಲಾಗಿದೆ. ನಾವು ಶುದ್ಧತೆಯತ್ತ ಪ್ರಯತ್ನಿಸುವುದರೊಂದಿಗೆ ಸಹ, ಸ್ವಯಂಚಾಲಿತ ಅನುವಾದಗಳಲ್ಲಿ ದೋಷಗಳು ಅಥವಾ ಅಸ್ಪಷ್ಟತೆಗಳು ಇರುವುದು ಸಾಧ್ಯವೆಂದು ದಯವಿಟ್ಟು ಗಮನಿಸಿರಿ. ಮೂಲ ಭಾಷೆಯಲ್ಲಿರುವ ಮೂಲ ದಸ್ತಾವೇಜನ್ನು ಅಧಿಕೃತ ಉದ್ರೇಕವಾಗಿ ಪರಿಗಣಿಸಬೇಕು. ಗಂಭೀರ/ನಿರ್ಣಾಯಕ ಮಾಹಿತಿಗಾಗಿ ವೃತ್ತಿಪರ ಮಾನವ ಅನುವಾದವನ್ನು ಶಿಫಾರಸು ಮಾಡಲಾಗಿದೆ. ಈ ಅನುವಾದದ ಬಳಕೆಯಿಂದ ಉಂಟಾಗುವ ಯಾವುದೇ ಅಸಮಂಜಸ್ಯತೆಗಳು ಅಥವಾ ತಪ್ಪು ವ್ಯಾಖ್ಯಾನಗಳಿಗೆ ನಾವು ಜವಾಬ್ದಾರರಲ್ಲ.