AI ಏಜೆಂಟ್ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್‌ನ ಅತ್ಯುತ್ತಮ ಅಭ್ಯಾಸಗಳು: ವೈಫಲ್ಯಗಳು, ಅನುಮೋದನೆಗಳು ಮತ್ತು ಮರುಪ್ರಯತ್ನಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು

AI ಏಜೆಂಟ್ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಈ ಮಾರ್ಗದರ್ಶಿ ವಿವರಿಸುತ್ತದೆ, ಕೇಂದ್ರೀಕೃತ, ವಿಕೇಂದ್ರೀಕೃತ ಮತ್ತು ಶ್ರೇಣೀಕೃತ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳನ್ನು ಹೋಲಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರೊಡಕ್ಷನ್‌ನಲ್ಲಿ ವೈಫಲ್ಯಗಳು, ಅನುಮೋದನೆಗಳು ಮತ್ತು ಮರುಪ್ರಯತ್ನಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಏಳು ಅತ್ಯುತ್ತಮ ಅಭ್ಯಾಸಗಳನ್ನು ಒಳಗೊಂಡಿದೆ.

Diagram of AI agent orchestration: a user's multi-step goal goes to an orchestrator, which routes work to agents, models, and tools to produce a final output, while breaking down tasks, tracking dependencies, delegating execution, managing shared context, and combining outputs.

ಒಂದೇ ಪ್ರಾಜೆಕ್ಟ್‌ನಲ್ಲಿ ಹಲವು ಏಜೆಂಟ್‌ಗಳು ಕೆಲಸ ಮಾಡುವುದು ಅತ್ಯಂತ ದಕ್ಷವೆಂದು ತೋರುತ್ತದೆ. ಒಂದು ಕೆಲಸವನ್ನು ಯೋಜಿಸುತ್ತದೆ, ಇನ್ನೊಂದು ವಿನ್ಯಾಸವನ್ನು ನಿಭಾಯಿಸುತ್ತದೆ ಮತ್ತು ಮೂರನೆಯದು ಕೋಡ್ ಬರೆಯುತ್ತದೆ. ಅದು ವಿಫಲವಾಗುವವರೆಗೂ ಸರಿಯಾಗಿಯೇ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಮತ್ತು ವೈಫಲ್ಯಗಳು ನೀವು ಬಯಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ ಸಂಭವಿಸುತ್ತವೆ.

ಈ ವೈಫಲ್ಯಗಳನ್ನು ತಡೆಯಲು ಎಚ್ಚರಿಕೆಯ ಕಾರ್ಯಪ್ರವಾಹ ಎಂಜಿನಿಯರಿಂಗ್ ಅಗತ್ಯ. ಹಾಗಾಗಿ, ಆರ್ಕೆಸ್ಟ್ರೇಟೆಡ್ ಕಾರ್ಯಪ್ರವಾಹಗಳನ್ನು ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲದಂತೆ ಮಾಡುವುದು ಏನು ಎಂಬುದನ್ನು ವಿಶ್ಲೇಷಿಸೋಣ ಮತ್ತು ಪ್ರೊಡಕ್ಷನ್ ವಿಶ್ವಾಸಾರ್ಹತೆಗಾಗಿ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್‌ನ ಉತ್ತಮ ಅಭ್ಯಾಸಗಳನ್ನು ಅನ್ವೇಷಿಸೋಣ.

AI ಏಜೆಂಟ್ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಎಂದರೇನು?

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

ಸರಳವಾಗಿ ಹೇಳುವುದಾದರೆ, ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಲೇಯರ್ ಒಂದು ಗುರಿಯನ್ನು ಸಣ್ಣ ಕಾರ್ಯಗಳಾಗಿ ವಿಭಜಿಸುತ್ತದೆ, ಅವಲಂಬನೆಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತದೆ, ಎಕ್ಸಿಕ್ಯೂಶನ್ ಅನ್ನು ಸೂಕ್ತ ಏಜೆಂಟ್‌ಗಳಿಗೆ ವಹಿಸುತ್ತದೆ, ಹಂಚಿಕೊಂಡ ಸಂದರ್ಭವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಔಟ್‌ಪುಟ್‌ಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸುತ್ತದೆ.

AI ಏಜೆಂಟ್ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ: ಎಕ್ಸಿಕ್ಯೂಶನ್ ಎಂಜಿನ್‌ನ ಒಳನೋಟ

ನೀವು ಆರ್ಕೆಸ್ಟ್ರೇಟರ್‌ಗೆ ಕಾರ್ಯವನ್ನು ನೀಡಿದ ನಂತರ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡೋಣ.

Perplexity ನ Computer ಕಾರ್ಯಾಗಾರದ ಒಂದು ಉದಾಹರಣೆಯನ್ನು ಪರಿಗಣಿಸಿ: Salesforce, Snowflake, ಇಮೇಲ್, ಕ್ಯಾಲೆಂಡರ್ ಮತ್ತು ಇತ್ತೀಚಿನ ಸುದ್ದಿಗಳ ಮಾಹಿತಿಯನ್ನು ಬಳಸಿ ಖಾತೆ ಇಂಟೆಲಿಜೆನ್ಸ್ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ನಿರ್ಮಿಸುವುದು.

  1. ಗುರಿಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಂಡು ಕೆಲಸವನ್ನು ಯೋಜಿಸಿ. ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ವಿನಂತಿಸಿದ ಫಲಿತಾಂಶದಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಅದನ್ನು ಸ್ಪಷ್ಟ ಅವಲಂಬನೆಗಳಿರುವ ಕಾರ್ಯಗಳಾಗಿ ವಿಭಜಿಸುತ್ತದೆ. ನಮ್ಮ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಉದಾಹರಣೆಯಲ್ಲಿ, ಇದು ವಿವಿಧ ಮೂಲಗಳಿಂದ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಿ ಅದನ್ನು ಸಿದ್ಧವಾದ ಅಂತಿಮ ಉತ್ಪನ್ನವಾಗಿ ಪರಿವರ್ತಿಸುವುದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಯಾವ ಹಂತಗಳು ಇತರ ಹಂತಗಳನ್ನು ಅವಲಂಬಿಸಿವೆ ಮತ್ತು ಯಾವುವು ಸ್ವತಂತ್ರವಾಗಿ ನಡೆಯಬಹುದು ಎಂಬುದನ್ನು ಪ್ಲಾನರ್ ನಿರ್ಧರಿಸುತ್ತದೆ.
  2. ಕಾರ್ಯಗಳನ್ನು ಸೂಕ್ತ ಏಜೆಂಟ್‌ಗಳಿಗೆ ರವಾನಿಸಿ. ಅವಲಂಬನೆಗಳು ಪೂರೈಸಲ್ಪಟ್ಟಿರುವ ಕಾರ್ಯಗಳನ್ನು ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಗುರುತಿಸಿ, ಕೆಲಸವನ್ನು ವಿಶೇಷ ಏಜೆಂಟ್‌ಗಳು ಅಥವಾ ಮಾಡೆಲ್‌ಗಳಿಗೆ ವಹಿಸುತ್ತದೆ. ಅವಲಂಬಿತ ಕಾರ್ಯಗಳು ತಮ್ಮ ಪೂರ್ವಾಪೇಕ್ಷಿತಗಳಿಗಾಗಿ ಕಾಯುತ್ತವೆ. Perplexity Computer ಹಲವು ಫ್ರಾಂಟಿಯರ್ ಮಾಡೆಲ್‌ಗಳನ್ನು ಬಳಸುತ್ತದೆ ಮತ್ತು ಕಾರ್ಯಪ್ರವಾಹದ ವಿವಿಧ ಭಾಗಗಳನ್ನು ಆ ಕಾರ್ಯಗಳಿಗೆ ಸೂಕ್ತವಾದ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ರವಾನಿಸುತ್ತದೆ. ಇದು ಸ್ವತಂತ್ರ ಕೆಲಸವನ್ನು ಸಮಾನಾಂತರವಾಗಿ ನಡೆಸಲು ಸಹ ಅವಕಾಶ ನೀಡುತ್ತದೆ.
  3. ನಿಯಂತ್ರಿತ ಪರಿಸರಗಳಲ್ಲಿ ಟೂಲ್ ಕರೆಗಳನ್ನು ಎಕ್ಸಿಕ್ಯೂಟ್ ಮಾಡಿ. ಏಜೆಂಟ್‌ಗಳು ವೆಬ್ ಹುಡುಕಾಟ, API ಗಳು, ಸಂಪರ್ಕಿತ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು, ಫೈಲ್ ಕಾರ್ಯಾಚರಣೆಗಳು ಅಥವಾ ಕೋಡ್ ಎಕ್ಸಿಕ್ಯೂಶನ್‌ನಂತಹ ಟೂಲ್‌ಗಳ ಮೂಲಕ ತಮ್ಮ ಪರಿಸರದೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತವೆ. ಎಕ್ಸಿಕ್ಯೂಶನ್ ಲೇಯರ್ ಈ ಕ್ರಿಯೆಗಳನ್ನು ಚಲಾಯಿಸಿ ಫಲಿತಾಂಶಗಳನ್ನು ಏಜೆಂಟ್‌ಗಳಿಗೆ ಹಿಂತಿರುಗಿಸುತ್ತದೆ.
  4. ಏಜೆಂಟ್‌ಗಳ ನಡುವೆ ಫಲಿತಾಂಶಗಳು ಮತ್ತು ಸಂದರ್ಭವನ್ನು ರವಾನಿಸಿ. ಏಜೆಂಟ್ ತನ್ನ ಕಾರ್ಯವನ್ನು ಮುಗಿಸಿದ ನಂತರ, ಮುಂದುವರಿಯಲು ಮುಂದಿನ ಡೌನ್‌ಸ್ಟ್ರೀಮ್ ಏಜೆಂಟ್‌ಗೆ ಸಂಬಂಧಿತ ಔಟ್‌ಪುಟ್ ಅಗತ್ಯವಿರುತ್ತದೆ. ಹ್ಯಾಂಡ್‌ಆಫ್ ದಾಖಲೆಯು ಕಾರ್ಯ ID, ಔಟ್‌ಪುಟ್ ಉಲ್ಲೇಖ, ಸ್ಕೀಮಾ ಆವೃತ್ತಿ ಮತ್ತು ಮೂಲ ಮೆಟಾಡೇಟಾವನ್ನು ಒಳಗೊಂಡಿರಬಹುದು. ಮುಂದಿನ ಹಂತಗಳಿಗೆ ಅಗತ್ಯವಿರುವ ಸಂದರ್ಭವನ್ನು ಕಾಯ್ದುಕೊಳ್ಳುತ್ತಾ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಈ ಹ್ಯಾಂಡ್‌ಆಫ್‌ಗಳನ್ನು ಸಮನ್ವಯಗೊಳಿಸುತ್ತದೆ. ಮುಖ್ಯವಾಗಿ, ಏಜೆಂಟ್‌ಗಳು ಇತರ ಪ್ರತಿಯೊಂದು ಏಜೆಂಟ್‌ನ ಕೆಲಸದ ಸಂಪೂರ್ಣ ಇತಿಹಾಸವನ್ನು ತಮ್ಮದೇ ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋಗಳಲ್ಲಿ ಹೊತ್ತೊಯ್ಯಬೇಕಾಗಿಲ್ಲ.
  5. ಏಜೆಂಟ್ ಸಂದರ್ಭದಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಎಕ್ಸಿಕ್ಯೂಶನ್ ಸ್ಥಿತಿಯನ್ನು ದಾಖಲಿಸಿ. ಏಜೆಂಟ್‌ಗಳು ಕಾರ್ಯಗಳನ್ನು ಪ್ರಾರಂಭಿಸಿದಂತೆ, ಪೂರ್ಣಗೊಳಿಸಿದಂತೆ ಅಥವಾ ಅವುಗಳಲ್ಲಿ ವಿಫಲವಾದಂತೆ, ಎಕ್ಸಿಕ್ಯೂಶನ್ ಎಂಜಿನ್ ಕಾರ್ಯ ಸ್ಥಿತಿಗಳು, ಎಕ್ಸಿಕ್ಯೂಶನ್ ಪ್ರಯತ್ನಗಳು, ಔಟ್‌ಪುಟ್ ಉಲ್ಲೇಖಗಳು ಮತ್ತು ಉಳಿದ ಕೆಲಸದೊಂದಿಗೆ ಶಾಶ್ವತ ಕಾರ್ಯಪ್ರವಾಹ ದಾಖಲೆಯನ್ನು ಅಪ್‌ಡೇಟ್ ಮಾಡುತ್ತದೆ. ಸಂಭಾಷಣೆಯ ಇತಿಹಾಸದಿಂದ ಕಾರ್ಯಪ್ರವಾಹವನ್ನು ಪುನರ್ನಿರ್ಮಿಸಲು LLM ಅನ್ನು ಅವಲಂಬಿಸದೆಯೇ ಪ್ರಗತಿಯನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಮತ್ತು ಅಡಚಣೆಗಳ ನಂತರ ಪುನರಾರಂಭಿಸಲು ಈ ದಾಖಲೆಯು ಆರ್ಕೆಸ್ಟ್ರೇಟರ್‌ಗೆ ಅವಕಾಶ ನೀಡುತ್ತದೆ.
  6. ಫಲಿತಾಂಶಗಳನ್ನು ಮೌಲ್ಯೀಕರಿಸಿ ಮತ್ತು ಮುಂದೆ ಏನಾಗಬೇಕು ಎಂದು ನಿರ್ಧರಿಸಿ. ಕಾರ್ಯವೊಂದು ಹಿಂತಿರುಗಿದಾಗ, ಅದರ ಔಟ್‌ಪುಟ್ ನಿರೀಕ್ಷಿತ ಒಪ್ಪಂದವನ್ನು ಪೂರೈಸುತ್ತದೆಯೇ ಮತ್ತು ಮುಂದಿನ ಕಾರ್ಯದ ಅವಲಂಬನೆಗಳು ಪೂರೈಸಲ್ಪಟ್ಟಿವೆಯೇ ಎಂಬುದನ್ನು ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಲೇಯರ್ ಪರಿಶೀಲಿಸುತ್ತದೆ. ಸಮಸ್ಯೆ ಕಂಡುಬಂದರೆ, ಕಾರ್ಯಪ್ರವಾಹವು ಸರಿಪಡಿಸುವಿಕೆಗಾಗಿ ಹಿಂದಿನ ಹಂತಕ್ಕೆ ಹಿಂತಿರುಗಬಹುದು ಅಥವಾ ವಿರಾಮಗೊಳ್ಳಬಹುದು. ಇಲ್ಲದಿದ್ದರೆ, ಅದು ಪೂರ್ಣಗೊಳ್ಳುವತ್ತ ಮುಂದುವರಿಯುತ್ತದೆ.

ಸರಳವೆಂದು ತೋರುವ AI ಏಜೆಂಟ್ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್‌ನ ಹಿಂದೆ ಅನೇಕ ಚಲಿಸುವ ಭಾಗಗಳು ಕೆಲಸ ಮಾಡುತ್ತವೆ. ನೀವು ಏಜೆಂಟ್ ಸಮನ್ವಯವನ್ನು ಹೇಗೆ ಸಂಘಟಿಸುತ್ತೀರಿ ಎಂಬುದು ಎಕ್ಸಿಕ್ಯೂಶನ್ ಮೇಲೆ ನಿಮಗೆ ಎಷ್ಟು ನಿಯಂತ್ರಣವಿದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಮತ್ತು ಖಂಡಿತವಾಗಿ, ಆ ಎಲ್ಲಾ ಸಮನ್ವಯವು ಹೆಚ್ಚುವರಿ ಹೊರೆಯನ್ನು ಸೇರಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ ಅದು ಯಾವಾಗಲೂ ಸಾರ್ಥಕವಲ್ಲ.

AI ಏಜೆಂಟ್ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಅನ್ನು ಯಾವಾಗ ಬಳಸಬೇಕು?

ಕಾರ್ಯದ ವಿವಿಧ ಭಾಗಗಳಿಗೆ ಭಿನ್ನ ಪರಿಣತಿ ಅಗತ್ಯವಿದ್ದಾಗ, ಸ್ವತಂತ್ರ ಕೆಲಸವನ್ನು ಸಮಾನಾಂತರವಾಗಿ ನಡೆಸಬಹುದಾದಾಗ ಅಥವಾ ಮುಂದಿನ ಹಂತವನ್ನು ಮುಂಚಿತವಾಗಿ ನಿರ್ಧರಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದಾಗ ಬಹು-ಏಜೆಂಟ್ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಅನ್ನು ಪರಿಗಣಿಸಿ.

ಆದ್ದರಿಂದ, ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಮೂರು ಸನ್ನಿವೇಶಗಳಲ್ಲಿ ಸಹಾಯಕವಾಗಿದೆ:

  • ಕಾರ್ಯಗಳಿಗೆ ವಿಭಿನ್ನ ವಿಶೇಷತೆಗಳು ಬೇಕಾಗುತ್ತವೆ. ಉದಾಹರಣೆಗೆ, ಕೋಡಿಂಗ್ ಪ್ರಾಜೆಕ್ಟ್‌ಗೆ ಪ್ರತ್ಯೇಕ ಯೋಜನೆ, ವಿನ್ಯಾಸ, ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಪರಿಶೀಲನಾ ಏಜೆಂಟ್‌ಗಳಿಂದ ಪ್ರಯೋಜನವಾಗಬಹುದು.
  • ಸ್ವತಂತ್ರ ಕಾರ್ಯಗಳು ಸಮಾನಾಂತರವಾಗಿ ನಡೆಯಬಹುದು. ಒಂದೇ ಏಜೆಂಟ್ ಎಲ್ಲವನ್ನೂ ಅನುಕ್ರಮವಾಗಿ ಪೂರ್ಣಗೊಳಿಸುವ ಬದಲು, ಹಲವು ಏಜೆಂಟ್‌ಗಳು ಏಕಕಾಲದಲ್ಲಿ ಕೆಲಸ ಮಾಡಿ ತಮ್ಮ ಫಲಿತಾಂಶಗಳನ್ನು ಆರ್ಕೆಸ್ಟ್ರೇಟರ್‌ಗೆ ಹಿಂತಿರುಗಿಸಬಹುದು.
  • ಸಮಸ್ಯೆಯು ಮುಕ್ತ-ಅಂತ್ಯದ್ದಾಗಿದೆ. ಏಜೆಂಟ್‌ಗಳು ಪೂರ್ವನಿರ್ಧರಿತ ಅನುಕ್ರಮವನ್ನು ಅನುಸರಿಸುವ ಬದಲು ವಿಭಿನ್ನ ವಿಧಾನಗಳನ್ನು ಅನ್ವೇಷಿಸಬೇಕಾಗಬಹುದು, ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಕಾಗಬಹುದು ಮತ್ತು ಸಹಯೋಗದಿಂದ ಕೆಲಸ ಮಾಡಬೇಕಾಗಬಹುದು.

ಇವುಗಳನ್ನು ಹೊರತುಪಡಿಸಿ, ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಕೇವಲ ದುಬಾರಿ ಟ್ರೆಂಡ್ ಆಗಿದೆ. ಹೆಚ್ಚು ಏಜೆಂಟ್‌ಗಳು ಎಂದರೆ ಹೆಚ್ಚು ಸಮನ್ವಯ ಮತ್ತು ಸಂಭಾವ್ಯವಾಗಿ ಹೆಚ್ಚಿನ ಟೋಕನ್ ವೆಚ್ಚಗಳು ಕೂಡ.

“ನಾನು ಸಾಮಾನ್ಯವಾಗಿ ಅತ್ಯಂತ ಸರಳ ಆಯ್ಕೆಯಿಂದ ಪ್ರಾರಂಭಿಸಿ ಅಲ್ಲಿಂದ ಮುಂದೆ ನಿರ್ಮಿಸುತ್ತೇನೆ. ನಮಗೆ ಹಂತಗಳು ತಿಳಿದಿದ್ದರೆ ಮತ್ತು ಅವು ಪುನರಾವರ್ತಿಸಬಲ್ಲವಾಗಿದ್ದರೆ, ಅದು ಬಹುಶಃ ಕಾರ್ಯಪ್ರವಾಹ. ಏಜೆಂಟ್‌ಗಳಿಗೆ ವಿಭಿನ್ನ ಜವಾಬ್ದಾರಿಗಳು, ಅನುಮತಿಗಳು ಅಥವಾ ಬಳಕೆದಾರರು ಇದ್ದಾಗ ಮಾತ್ರ ಹಲವು ಏಜೆಂಟ್‌ಗಳನ್ನು ಪರಿಚಯಿಸಲು ಕಾರಣವಿದೆ ಎಂದು ನನಗೆ ಅನಿಸುತ್ತದೆ,” ಎನ್ನುತ್ತಾರೆ Josh Spilker, AirOps ನಲ್ಲಿ ಸರ್ಚ್ ಮಾರ್ಕೆಟಿಂಗ್ ಮುಖ್ಯಸ್ಥರು.

ಆಗಲೂ ಸಹ, ಹೆಚ್ಚುವರಿ ಮಾಡೆಲ್ ಕರೆಗಳು, ಹ್ಯಾಂಡ್‌ಆಫ್‌ಗಳು, ಲೇಟೆನ್ಸಿ ಮತ್ತು ವೈಫಲ್ಯದ ಬಿಂದುಗಳೊಂದಿಗೆ ಪ್ರಯೋಜನಗಳನ್ನು ತೂಗಿ ನೋಡಿ.

AI ಏಜೆಂಟ್ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳು ಮತ್ತು ಅವುಗಳ ಸಾಧಕ-ಬಾಧಕಗಳು

ಏಜೆಂಟ್ ಸಮನ್ವಯವನ್ನು ರಚಿಸಲು ಮೂರು ಸಾಮಾನ್ಯ ವಿಧಾನಗಳಿವೆ — ಕೇಂದ್ರೀಕೃತ, ವಿಕೇಂದ್ರೀಕೃತ ಮತ್ತು ಶ್ರೇಣೀಕೃತ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್. ಸರಿಯಾದ ಆರ್ಕಿಟೆಕ್ಚರ್ ಆಯ್ಕೆಮಾಡುವುದು ಒಂದೇ ಪ್ರಶ್ನೆಗೆ ಬಂದು ನಿಲ್ಲುತ್ತದೆ: ಕೆಲಸವನ್ನು ಯಾರು ನಿಯಂತ್ರಿಸುತ್ತಾರೆ, ಮತ್ತು ಏಜೆಂಟ್‌ಗಳು ಪರಸ್ಪರ ಹೇಗೆ ಸಮನ್ವಯಗೊಳ್ಳುತ್ತವೆ?

ಕೇಂದ್ರೀಕೃತ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್

ಕೇಂದ್ರೀಕೃತ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್‌ನಲ್ಲಿ, ಒಂದೇ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಅದು ಕಾರ್ಯವನ್ನು ವಿಭಜಿಸುತ್ತದೆ, ಕೆಲಸವನ್ನು ತಜ್ಞ ಏಜೆಂಟ್‌ಗಳಿಗೆ ವಹಿಸುತ್ತದೆ, ಅವುಗಳ ಪ್ರಗತಿಯನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅವುಗಳ ಫಲಿತಾಂಶಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸುತ್ತದೆ.

ಸಾಧಕ-ಬಾಧಕ: ಕೇಂದ್ರೀಕೃತ ಸಮನ್ವಯವು ಎಕ್ಸಿಕ್ಯೂಶನ್ ಅನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವುದನ್ನು ಮತ್ತು ಒಂದೇ ನಿಯಂತ್ರಣ ಬಿಂದುವಿನಲ್ಲಿ ಸಾಮಾನ್ಯ ನಿಯಮಗಳನ್ನು ಅನ್ವಯಿಸುವುದನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ. ಆದರೆ, ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಅಡಚಣೆಯ ಬಿಂದುವಾಗಬಹುದು, ಮತ್ತು ಸಿಸ್ಟಮ್ ಚೇತರಿಕೆಯನ್ನು ಬೆಂಬಲಿಸದ ಹೊರತು ಅದರ ವೈಫಲ್ಯವು ಸಂಪೂರ್ಣ ಕಾರ್ಯಪ್ರವಾಹವನ್ನು ಅಡ್ಡಿಪಡಿಸಬಹುದು.

ವಿಕೇಂದ್ರೀಕೃತ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್

ವಿಕೇಂದ್ರೀಕೃತ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್‌ನಲ್ಲಿ, ಪ್ರತಿಯೊಂದು ನಿರ್ಧಾರಕ್ಕೂ ಒಬ್ಬ ವ್ಯವಸ್ಥಾಪಕನನ್ನು ಅವಲಂಬಿಸುವ ಬದಲು ಏಜೆಂಟ್‌ಗಳು ಹೆಚ್ಚು ನೇರವಾಗಿ ಸಮನ್ವಯಗೊಳ್ಳುತ್ತವೆ. ಅವು ಸಂದೇಶಗಳನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳಬಹುದು, ಹಂಚಿಕೊಂಡ ಸ್ಥಿತಿಯನ್ನು ಓದಬಹುದು ಮತ್ತು ತಮ್ಮ ಮುಂದಿನ ಹಂತಗಳನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ನಿರ್ಧರಿಸಬಹುದು.

ಸಾಧಕ-ಬಾಧಕ: ಏಜೆಂಟ್‌ಗಳು ಕೇಂದ್ರ ಪ್ಲಾನರ್‌ಗಾಗಿ ಕಾಯದೆ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು, ಇದು ಈ ವಿಧಾನವನ್ನು ಅನ್ವೇಷಣಾತ್ಮಕ ಕೆಲಸ ಮತ್ತು ಸ್ವತಂತ್ರ ಕೊಡುಗೆಗಳಿಗೆ ಉಪಯುಕ್ತವಾಗಿಸುತ್ತದೆ. ಆದರೆ ಏಜೆಂಟ್‌ಗಳು ಭಿನ್ನಾಭಿಪ್ರಾಯ ಹೊಂದಿದಾಗ, ಹಂಚಿಕೊಂಡ ಮಾಹಿತಿಯನ್ನು ಅಪ್‌ಡೇಟ್ ಮಾಡಿದಾಗ ಅಥವಾ ಸ್ಥಿರವಾದ ಫಲಿತಾಂಶವನ್ನು ತಲುಪಬೇಕಾದಾಗ ಸಮನ್ವಯ ಕಠಿಣವಾಗುತ್ತದೆ.

ಶ್ರೇಣೀಕೃತ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್

ಶ್ರೇಣೀಕೃತ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ವ್ಯವಸ್ಥಾಪಕ ವಿಧಾನವನ್ನು ಹಲವು ಹಂತಗಳಿಗೆ ವಿಸ್ತರಿಸುತ್ತದೆ. ಉನ್ನತ ಮಟ್ಟದ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಜವಾಬ್ದಾರಿಯನ್ನು ಅಧೀನ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್‌ಗಳಿಗೆ ವಹಿಸುತ್ತದೆ, ಅವು ತಮ್ಮದೇ ತಜ್ಞ ಏಜೆಂಟ್‌ಗಳ ಗುಂಪುಗಳನ್ನು ಸಮನ್ವಯಗೊಳಿಸುತ್ತವೆ.

ಮಾರಾಟ, ಹಣಕಾಸು ಮತ್ತು ಕಾನೂನು ತಂಡಗಳನ್ನು ಒಳಗೊಂಡ ಎಂಟರ್‌ಪ್ರೈಸ್ ಕಾರ್ಯಪ್ರವಾಹವನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ಉನ್ನತ ಮಟ್ಟದ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಪ್ರತಿಯೊಂದು ಕೆಲಸದ ಹೊಳೆಯನ್ನು ಕ್ಷೇತ್ರ-ನಿರ್ದಿಷ್ಟ ಸಂಯೋಜಕಕ್ಕೆ ವಹಿಸಬಹುದು. ನಂತರ ಆ ಸಂಯೋಜಕಗಳು ತಮ್ಮದೇ ಆದ ತಜ್ಞ ಏಜೆಂಟ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸಿ, ಕ್ರೋಢೀಕೃತ ಫಲಿತಾಂಶಗಳನ್ನು ವರದಿ ಮಾಡುತ್ತವೆ.

ಒಂದೇ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಾಗದಷ್ಟು ಕಾರ್ಯಪ್ರವಾಹಗಳು ವಿಸ್ತಾರವಾಗಿದ್ದಾಗ ಈ ರಚನೆ ಸಹಾಯ ಮಾಡಬಹುದು.

ಸಾಧಕ-ಬಾಧಕ: ಶ್ರೇಣಿಗಳು ತಂಡಗಳಿಗೆ ಸಮನ್ವಯ ಜವಾಬ್ದಾರಿಗಳನ್ನು ವಿಭಜಿಸಲು ಮತ್ತು ಪ್ರತ್ಯೇಕ ಶಾಖೆಗಳೊಳಗೆ ವೈಫಲ್ಯಗಳನ್ನು ಸಂಭಾವ್ಯವಾಗಿ ನಿಭಾಯಿಸಲು ಅವಕಾಶ ನೀಡುತ್ತವೆ. ಆದರೆ, ಅವು ಹೆಚ್ಚುವರಿ ಹ್ಯಾಂಡ್‌ಆಫ್‌ಗಳು, ಹೆಚ್ಚು ಸಂಕೀರ್ಣ ಸ್ಥಿತಿ ನಿರ್ವಹಣೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಕಾರ್ಯಾಚರಣಾ ಹೊರೆಯನ್ನು ತರುತ್ತವೆ. ಸ್ಥಳೀಯ ಚೇತರಿಕೆಯು ಚೆಕ್‌ಪಾಯಿಂಟ್‌ಗಳು ಮತ್ತು ಎಕ್ಸಿಕ್ಯೂಶನ್ ಸ್ಥಿತಿಯನ್ನು ಹೇಗೆ ಅಳವಡಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನೂ ಅವಲಂಬಿಸಿರುತ್ತದೆ.

ಈ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳ ಹೋಲಿಕೆ:

ಮಾನದಂಡ

ಕೇಂದ್ರೀಕೃತ

ವಿಕೇಂದ್ರೀಕೃತ

ಶ್ರೇಣೀಕೃತ

ಎಕ್ಸಿಕ್ಯೂಶನ್ ಮಾಲೀಕತ್ವ

ಒಂದೇ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಕೆಲಸ ವಹಿಸುವಿಕೆಯನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ

ಏಜೆಂಟ್‌ಗಳು ಸಹವರ್ತಿ ಏಜೆಂಟ್‌ಗಳು ಅಥವಾ ಹಂಚಿಕೊಂಡ ಸ್ಥಿತಿಯ ಮೂಲಕ ಸಮನ್ವಯಗೊಳ್ಳುತ್ತವೆ

ಜವಾಬ್ದಾರಿಯನ್ನು ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಹಂತಗಳಾದ್ಯಂತ ಹಂಚಲಾಗುತ್ತದೆ

ಸ್ಥಿತಿಯ ಸ್ಥಿರತೆ

ಒಂದೇ ನಿಯಂತ್ರಣ ಬಿಂದುವಿನ ಮೂಲಕ ಸಮನ್ವಯಗೊಳಿಸುವುದು ಸುಲಭ

ಸ್ಪಷ್ಟ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಮತ್ತು ಸಂಘರ್ಷ ನಿರ್ವಹಣೆ ಅಗತ್ಯ

ಶಾಖೆಗಳ ಒಳಗೆ ಮತ್ತು ಶಾಖೆಗಳಾದ್ಯಂತ ಸಮನ್ವಯ ಅಗತ್ಯ

ವೈಫಲ್ಯ ಪ್ರತ್ಯೇಕತೆ

ಕೇಂದ್ರ ನಿಯಂತ್ರಕವು ನಿರ್ಣಾಯಕ ಅವಲಂಬನೆಯಾಗಬಹುದು

ಪ್ರತ್ಯೇಕ ಏಜೆಂಟ್‌ಗಳು ಸ್ವತಂತ್ರವಾಗಿ ವಿಫಲವಾಗಬಹುದು, ಆದರೆ ಹಂಚಿಕೊಂಡ ಮೂಲಸೌಕರ್ಯವು ನಿರ್ಣಾಯಕವಾಗಿಯೇ ಉಳಿಯುತ್ತದೆ

ಚೇತರಿಕೆಗಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಿದ್ದರೆ ವೈಫಲ್ಯಗಳನ್ನು ಶಾಖೆಗಳೊಳಗೆ ಸೀಮಿತಗೊಳಿಸಬಹುದು

ನೀತಿ ಜಾರಿ

ಸಾಮಾನ್ಯ ನಿಯಂತ್ರಣಗಳನ್ನು ಕೇಂದ್ರೀಯವಾಗಿ ಜಾರಿಗೊಳಿಸಬಹುದು

ಎಲ್ಲಾ ಭಾಗವಹಿಸುವವರಲ್ಲಿ ನೀತಿಗಳನ್ನು ಸ್ಥಿರವಾಗಿ ಜಾರಿಗೊಳಿಸಬೇಕು

ನಿಯಂತ್ರಣಗಳನ್ನು ಜಾಗತಿಕ ಮತ್ತು ಡೊಮೇನ್ ಮಟ್ಟಗಳಲ್ಲಿ ಅನ್ವಯಿಸಬಹುದು

ಕಾರ್ಯಾಚರಣೆಯ ಸಂಕೀರ್ಣತೆ

ಸಾಮಾನ್ಯವಾಗಿ ಕಡಿಮೆ

ಹೆಚ್ಚಿನ ಸಮನ್ವಯ ಸಂಕೀರ್ಣತೆ

ಬಹು ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಪದರಗಳಿಂದಾಗಿ ಹೆಚ್ಚಿನ ಸಂಕೀರ್ಣತೆ

ಅನುಕ್ರಮ, ಸಮಾನಾಂತರ ಮತ್ತು ಹಸ್ತಾಂತರ-ಆಧಾರಿತ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ

ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕಾದ ಇನ್ನೊಂದು ವ್ಯತ್ಯಾಸವಿದೆ. ಏಜೆಂಟ್‌ಗಳನ್ನು ಯಾರು ಸಮನ್ವಯಗೊಳಿಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ಆರ್ಕಿಟೆಕ್ಚರ್ ನಿರ್ಧರಿಸುತ್ತದೆ. ಅವುಗಳ ಕಾರ್ಯಗಳು ಹೇಗೆ ಮುಂದುವರಿಯುತ್ತವೆ ಎಂಬುದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯ ಮಾದರಿ ನಿರ್ಧರಿಸುತ್ತದೆ.

ಇವು ಮೂರು ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯ ಮಾದರಿಗಳು:

  • ಅನುಕ್ರಮ ಕಾರ್ಯಪ್ರವಾಹಗಳು: ಏಜೆಂಟ್‌ಗಳು ಪೂರ್ವನಿರ್ಧರಿತ ಕ್ರಮದಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತವೆ, ಒಂದು ಏಜೆಂಟ್‌ನ ಫಲಿತಾಂಶವು ಮತ್ತೊಂದು ಏಜೆಂಟ್‌ನ ಇನ್‌ಪುಟ್ ಆಗುತ್ತದೆ.
  • ಸಮಾನಾಂತರ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ: ಸ್ವತಂತ್ರ ಏಜೆಂಟ್‌ಗಳು ಏಕಕಾಲದಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತವೆ.
  • ಹಸ್ತಾಂತರ-ಆಧಾರಿತ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ: ಕಾರ್ಯ ಮುಂದುವರಿದಂತೆ ನಿಯಂತ್ರಣವು ವಿಶೇಷಜ್ಞ ಏಜೆಂಟ್‌ಗಳ ನಡುವೆ ಚಲಿಸುತ್ತದೆ. ಮುಂದಿನ ಹಂತವನ್ನು ನಿರ್ವಹಿಸಲು ಮತ್ತೊಂದು ಏಜೆಂಟ್ ಹೆಚ್ಚು ಸಮರ್ಥವಾಗಿದ್ದಾಗ ಇದು ಉಪಯುಕ್ತವಾಗಿದೆ, ಆದರೂ ಪ್ರತಿಯೊಂದು ಹಸ್ತಾಂತರವು ಮುಂದುವರಿಯಲು ಅಗತ್ಯವಿರುವ ಮಾಹಿತಿಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳಬೇಕು.

ಈ ಮಾದರಿಗಳು ಪರಸ್ಪರ ಹೊರತಾದವುಗಳಲ್ಲ, ಮತ್ತು ಅವು ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳಿಗೆ ಒಂದಕ್ಕೊಂದು ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ. ನಿಮ್ಮ ಕಾರ್ಯಪ್ರವಾಹದ ಅವಲಂಬನೆಗಳು, ಸಮನ್ವಯದ ಅವಶ್ಯಕತೆಗಳು ಮತ್ತು ಸ್ವೀಕಾರಾರ್ಹ ಕಾರ್ಯಾಚರಣೆಯ ಹೊರೆಯನ್ನು ಬೆಂಬಲಿಸುವ ಅತ್ಯಂತ ಸರಳ ರಚನೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದೇ ಗುರಿಯಾಗಿದೆ.

ಸಾಮಾನ್ಯ AI ಏಜೆಂಟ್ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ವೈಫಲ್ಯಗಳು

ಸರಳ ಕಡೆಗಣನೆಗಳಿಂದ ಹಿಡಿದು ಜಟಿಲ ಅಡಚಣೆಗಳವರೆಗೆ, ಆರ್ಕೆಸ್ಟ್ರೇಶನ್‌ನಲ್ಲಿ ಏನು ಬೇಕಾದರೂ ತಪ್ಪಾಗಬಹುದು. ಕೆಲವೊಮ್ಮೆ, ಒಟ್ಟಾರೆ ಕಾರ್ಯಪ್ರವಾಹ ವಿಫಲವಾಗುತ್ತಿದ್ದರೂ ಏಜೆಂಟ್ ತನ್ನ ಕೆಲಸವನ್ನು ಸರಿಯಾಗಿ ಮಾಡುತ್ತಿರುವಂತೆ ಕಾಣಿಸಬಹುದು. ಕ್ಷೇತ್ರದ ವೃತ್ತಿಪರರ ಅನುಭವಗಳ ಆಧಾರದ ಮೇಲೆ, ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲದ ಆರ್ಕೆಸ್ಟ್ರೇಟೆಡ್ ಕಾರ್ಯಪ್ರವಾಹಗಳ ಹಿಂದಿನ ಕೆಲವು ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳನ್ನು ನಾವು ಸಂಗ್ರಹಿಸಿದ್ದೇವೆ — ಅವುಗಳ ಬಗ್ಗೆ ಎಚ್ಚರದಿಂದಿರಿ:

  • ಮಾಹಿತಿ ಕಳೆದುಕೊಳ್ಳುವ ಏಜೆಂಟ್ ಹಸ್ತಾಂತರಗಳು. ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಸಾರಾಂಶಗೊಳಿಸಿದ ಯೋಜನೆಯನ್ನು ವಿಶೇಷಜ್ಞ ಏಜೆಂಟ್‌ಗೆ ರವಾನಿಸುತ್ತದೆ, ಆದರೆ ಆ ಸಾರಾಂಶದಲ್ಲಿ ನಿರ್ಬಂಧಗಳು, ಅವಲಂಬನೆಗಳು ಅಥವಾ ಅನುಷ್ಠಾನದ ವಿವರಗಳು ಬಿಟ್ಟುಹೋಗುತ್ತವೆ.
  • ಅಕಾಲಿಕ ಫ್ಯಾನ್-ಇನ್ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ. ಎಲ್ಲಾ ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಕಾರ್ಯಗಳು ಮುಗಿಯುವ ಮೊದಲೇ ಡೌನ್‌ಸ್ಟ್ರೀಮ್ ಏಜೆಂಟ್ ಫಲಿತಾಂಶಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.
  • ಅನಿಶ್ಚಿತ ಹಂಚಿಕೆಯ-ಸ್ಥಿತಿ ನವೀಕರಣಗಳು. ಸಮಾನಾಂತರ ಏಜೆಂಟ್‌ಗಳು ಸ್ಪಷ್ಟವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ವಿಲೀನ ಶಬ್ದಾರ್ಥವಿಲ್ಲದೆ ಒಂದೇ ಸ್ಥಿತಿ ಕೀಗಳಿಗೆ ಬರೆಯುತ್ತವೆ. ಫ್ರೇಮ್‌ವರ್ಕ್ ನವೀಕರಣಗಳನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿ, ಇದು ಕಳೆದುಹೋದ ಬರಹಗಳು, ನಕಲಾದ ಡೇಟಾ, ಕ್ರಮ-ಅವಲಂಬಿತ ಔಟ್‌ಪುಟ್ ಅಥವಾ ಸಂಘರ್ಷದ ಬದಲಾವಣೆಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು.
  • ಚೆಕ್‌ಪಾಯಿಂಟ್ ಮತ್ತು ಅಡ್ಡಪರಿಣಾಮದ ಭಿನ್ನತೆ. ಒಂದು ಕಾರ್ಯವು ಬಾಹ್ಯ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ ವರ್ಕರ್ ವಿಫಲವಾಗುವ ಮೊದಲು ಅದರ ಯಶಸ್ವಿ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ಶಾಶ್ವತವಾಗಿ ದಾಖಲಿಸಲಾಗುವುದಿಲ್ಲ. ಚೇತರಿಕೆಯ ಸಮಯದಲ್ಲಿ, ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಪೂರ್ಣಗೊಳ್ಳದ ಕಾರ್ಯವನ್ನು ನೋಡಿ ಅದನ್ನು ಮತ್ತೆ ರನ್ ಮಾಡುತ್ತದೆ.
  • ಮಾನವ-ಅನುಮೋದನೆ ಪುನರಾರಂಭದ ರೇಸ್‌ಗಳು. ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ವಿರಾಮಗೊಳಿಸುವುದು ಮತ್ತು ಪುನರಾರಂಭಿಸುವುದು ತನ್ನದೇ ಆದ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.
  • ನಿಯೋಜನೆಯ ಲೂಪ್‌ಗಳು ಮತ್ತು ಮರುಪ್ರಯತ್ನಗಳ ಹೆಚ್ಚಳ. ಏಜೆಂಟ್‌ಗಳ ಜವಾಬ್ದಾರಿಗಳು ಅತಿಕ್ರಮಿಸುವುದರಿಂದ, ಅವಲಂಬನೆಗಳು ವೃತ್ತಾಕಾರವಾಗಿರುವುದರಿಂದ ಅಥವಾ ಪೂರ್ಣಗೊಳಿಸುವ ಷರತ್ತುಗಳು ಅಸ್ಪಷ್ಟವಾಗಿರುವುದರಿಂದ, ಅವು ಪದೇ ಪದೇ ಕೆಲಸವನ್ನು ಒಂದಕ್ಕೊಂದು ಹಸ್ತಾಂತರಿಸುತ್ತವೆ.
  • ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯ ಭದ್ರತೆ ಎಂದು ತಪ್ಪಾಗಿ ಭಾವಿಸಲಾದ ಸೂಚನಾ-ಮಟ್ಟದ ನಿಯಂತ್ರಣಗಳು. ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಕೆಲವು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಪ್ರವೇಶಿಸದಂತೆ ಅಥವಾ ಸೂಕ್ಷ್ಮ ಕ್ರಿಯೆಗಳನ್ನು ನಿರ್ವಹಿಸದಂತೆ ಏಜೆಂಟ್‌ಗಳಿಗೆ ಹೇಳಬಹುದು, ಆದರೆ ಮಾಡೆಲ್ ಸೂಚನೆಗಳು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಅನುಮತಿಗಳು, ನೆಟ್‌ವರ್ಕ್ ನಿರ್ಬಂಧಗಳು ಅಥವಾ ಅಧಿಕಾರದ ಗಡಿಗಳನ್ನು ಜಾರಿಗೊಳಿಸುವುದಿಲ್ಲ. ದುರುದ್ದೇಶಪೂರಿತ ಸೂಚನೆಗಳಿಲ್ಲದಿದ್ದರೂ ಸಹ, ನ್ಯಾಯಸಮ್ಮತ ಗುರಿಗಳನ್ನು ಅನುಸರಿಸುವಾಗ ಏಜೆಂಟ್‌ಗಳು ಭದ್ರತಾ ಗಡಿಗಳನ್ನು ಏಕೆ ದಾಟಬಹುದು ಎಂಬುದನ್ನು Perplexity ಯ ಭದ್ರತಾ ಎಂಜಿನಿಯರಿಂಗ್ ಸಂಶೋಧನೆ ಎತ್ತಿ ತೋರಿಸುತ್ತದೆ

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

ಪ್ರೊಡಕ್ಷನ್ ವಿಶ್ವಾಸಾರ್ಹತೆಗಾಗಿ 7 AI ಏಜೆಂಟ್ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಉತ್ತಮ ಅಭ್ಯಾಸಗಳು

1. ಸ್ಪಷ್ಟ ಕಾರ್ಯ ಒಪ್ಪಂದಗಳು, ಸ್ವೀಕಾರ ಮಾನದಂಡಗಳು ಮತ್ತು ನಿಲುಗಡೆ ಷರತ್ತುಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿ

ಅಸ್ಪಷ್ಟ ಗುರಿಗಳು ಮತ್ತು ಸ್ಪಷ್ಟವಲ್ಲದ ಕೆಲಸ ಮುಗಿದಿದೆ ಎಂಬುದರ ವ್ಯಾಖ್ಯಾನ ಸಾಮಾನ್ಯವಾಗಿ ನಿರಾಶಾದಾಯಕ ಏಜೆಂಟ್-ರಚಿತ ಫಲಿತಾಂಶಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತವೆ. ಇದಕ್ಕೆ ಪರಿಹಾರವೆಂದರೆ ಪ್ರಾಂಪ್ಟ್ ಒಪ್ಪಂದ (ಏಜೆಂಟ್‌ಗಾಗಿ ಕೆಲಸದ ವ್ಯಾಪ್ತಿ): ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು ಗುರಿ, ನಿರ್ಬಂಧಗಳು, ಔಟ್‌ಪುಟ್ ಸ್ವರೂಪ ಮತ್ತು ವೈಫಲ್ಯದ ಷರತ್ತುಗಳನ್ನು ಒಪ್ಪಿಕೊಳ್ಳಿ.

ಉದಾಹರಣೆಗೆ, ಅನಿಯಮಿತವಾಗಿ ವಿಫಲವಾಗುವ ಇಂಟಿಗ್ರೇಶನ್ ಪರೀಕ್ಷೆಯನ್ನು ಸರಿಪಡಿಸುವ ಜವಾಬ್ದಾರಿ ಹೊಂದಿರುವ ಏಜೆಂಟ್‌ಗಾಗಿ ನೀವು ಒಪ್ಪಂದವನ್ನು ಹೇಗೆ ವ್ಯಾಖ್ಯಾನಿಸಬಹುದು ಎಂಬುದು ಇಲ್ಲಿದೆ:

  • ಗುರಿ: ಅಸ್ಥಿರವಾಗಿ ವಿಫಲವಾಗುವ ಚೆಕ್‌ಔಟ್ API ಇಂಟಿಗ್ರೇಶನ್ ಪರೀಕ್ಷೆಯ ಕಾರಣವನ್ನು ಗುರುತಿಸಿ ಸರಿಪಡಿಸಿ.
  • ಇನ್‌ಪುಟ್‌ಗಳು: ಪರೀಕ್ಷಾ ಮೂಲ ಕೋಡ್, CI ವೈಫಲ್ಯ ಲಾಗ್‌ಗಳು, ಇತ್ತೀಚಿನ ಕಮಿಟ್‌ಗಳು ಮತ್ತು ಸಂಬಂಧಿತ ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್.
  • ನಿರ್ಬಂಧಗಳು: ಪರೀಕ್ಷೆಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬೇಡಿ, ಅಸರ್ಶನ್‌ಗಳನ್ನು ಸಡಿಲಗೊಳಿಸಬೇಡಿ ಅಥವಾ ಸಂಬಂಧವಿಲ್ಲದ ಅಪ್ಲಿಕೇಶನ್ ವರ್ತನೆಯನ್ನು ಮಾರ್ಪಡಿಸಬೇಡಿ.
  • ನಿರೀಕ್ಷಿತ ಔಟ್‌ಪುಟ್: ಕೋಡ್ ಪ್ಯಾಚ್, ಮೂಲ ಕಾರಣದ ವಿವರಣೆ ಮತ್ತು ಪರೀಕ್ಷಾ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯ ಫಲಿತಾಂಶಗಳು.
  • ಸ್ವೀಕಾರ ಮಾನದಂಡಗಳು: ಹಿಂದೆ ವಿಫಲವಾಗುತ್ತಿದ್ದ ಪರೀಕ್ಷೆಯು ಸತತ 10 ರನ್‌ಗಳಲ್ಲಿ ಉತ್ತೀರ್ಣವಾಗುತ್ತದೆ ಮತ್ತು ಸಂಬಂಧಿತ ರಿಗ್ರೆಶನ್ ಸೂಟ್ ಉತ್ತೀರ್ಣವಾಗುತ್ತದೆ.
  • ವೈಫಲ್ಯದ ಷರತ್ತುಗಳು: ಮೂಲ ಕಾರಣವನ್ನು ಸ್ಥಾಪಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ, ಸರಿಪಡಿಸುವಿಕೆಯು ರಿಗ್ರೆಶನ್‌ಗಳನ್ನು ಪರಿಚಯಿಸುತ್ತದೆ, ಅಥವಾ ಅಗತ್ಯವಿರುವ ಪರೀಕ್ಷಾ ಪರಿಸರ ಲಭ್ಯವಿಲ್ಲ.

ಆದರೆ ಇನ್ನೊಂದು ಪ್ರಮುಖ ಭಾಗವಿದೆ: ಏಜೆಂಟ್ ಯಾವಾಗ ನಿಲ್ಲಬೇಕು?

ತೃಪ್ತಿಕರ ಫಲಿತಾಂಶವನ್ನು ನೀಡಿಲ್ಲ ಎಂಬ ಕಾರಣಕ್ಕೆ ಏಜೆಂಟ್ ಅನಿರ್ದಿಷ್ಟವಾಗಿ ಪುನರಾವರ್ತಿಸುತ್ತಲೇ ಇರಬಾರದು. ಯಶಸ್ವಿ ಪೂರ್ಣಗೊಳಿಸುವಿಕೆ ಎಂದರೇನು, ಭಾಗಶಃ ಪೂರ್ಣಗೊಂಡ ಕಾರ್ಯವನ್ನು ಯಾವಾಗ ಹಿಂದಿರುಗಿಸಬೇಕು ಮತ್ತು ಅವಶ್ಯಕತೆಯನ್ನು ಪೂರೈಸಲು ಸಾಧ್ಯವಾಗದ ಕಾರಣ ಯಾವಾಗ ನಿಲ್ಲಿಸಬೇಕು ಎಂಬುದನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿ. ಬಗೆಹರಿಯದ ಕಾರ್ಯಗಳು ಅಂತ್ಯವಿಲ್ಲದ ಲೂಪ್‌ಗಳಾಗದಂತೆ ಗರಿಷ್ಠ ನಿಯೋಜನೆಯ ಆಳ ಮತ್ತು ಪುನರಾವರ್ತನೆಯ ಮಿತಿಗಳು ಅಥವಾ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯ ಬಜೆಟ್‌ಗಳನ್ನು ಹೊಂದಿಸಿ.

ನಮ್ಮ CI ಉದಾಹರಣೆಗೆ ಹಿಂತಿರುಗೋಣ. ನೀವು ಈ ಕೆಳಗಿನ ನಿಲುಗಡೆ ಷರತ್ತುಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಬಹುದು:

  • ಯಶಸ್ಸು: ಸರಿಪಡಿಸುವಿಕೆಯು ಸತತ 10 ಪರೀಕ್ಷಾ ರನ್‌ಗಳಲ್ಲಿ ಮತ್ತು ಸಂಬಂಧಿತ ರಿಗ್ರೆಶನ್ ಸೂಟ್‌ನಲ್ಲಿ ಉತ್ತೀರ್ಣವಾಗುತ್ತದೆ.
  • ಪುನರಾವರ್ತನೆಯ ಮಿತಿ: ಏಜೆಂಟ್ ಎರಡಕ್ಕಿಂತ ಹೆಚ್ಚು ಸಂಭಾವ್ಯ ಸರಿಪಡಿಸುವಿಕೆಗಳನ್ನು ಪ್ರಯತ್ನಿಸುವಂತಿಲ್ಲ.
  • ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯ ಬಜೆಟ್: ಸಮಸ್ಯೆ ಬಗೆಹರಿಯದೆ ಉಳಿದಿದ್ದರೂ ಸಹ, 60 ನಿಮಿಷಗಳ ನಂತರ ಏಜೆಂಟ್ ನಿಲ್ಲಿಸಬೇಕು.
  • ನಿಯೋಜನೆಯ ಮಿತಿ: ಏಜೆಂಟ್ ಒಂದು ವಿಶೇಷಜ್ಞ ಏಜೆಂಟ್‌ಗೆ ಕೆಲಸವನ್ನು ನಿಯೋಜಿಸಬಹುದು, ಅದರ ನಂತರ ಯಾವುದೇ ಸಬ್‌ಏಜೆಂಟ್ ನಿಯೋಜನೆ ಇರುವುದಿಲ್ಲ.
  • ಭಾಗಶಃ ಪೂರ್ಣಗೊಳಿಸುವಿಕೆ: ಎರಡೂ ಪ್ರಯತ್ನಗಳು ವಿಫಲವಾದರೆ ಅಥವಾ ಸಮಯದ ಮಿತಿ ಮುಗಿದರೆ, ಏಜೆಂಟ್ ತಾನು ಕಂಡುಕೊಂಡ ಅಂಶಗಳು, ಪ್ರಯತ್ನಿಸಿದ ಬದಲಾವಣೆಗಳು ಮತ್ತು ಪರೀಕ್ಷಾ ಫಲಿತಾಂಶಗಳನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ.
  • ತಡೆಹಿಡಿಯಲಾದ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ: ಪರೀಕ್ಷಾ ಪರಿಸರ ಲಭ್ಯವಿಲ್ಲದಿದ್ದರೆ, ಏಜೆಂಟ್ ಯಶಸ್ಸನ್ನು ಘೋಷಿಸುವ ಬದಲು ನಿಲ್ಲಿಸಿ ಅಡಚಣೆಯನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ.

2. ಆರ್ಕೆಸ್ಟ್ರೇಟರ್‌ಗಳನ್ನು ಹಗುರವಾಗಿರಿಸಿ ಮತ್ತು ರಚನಾತ್ಮಕ ಹಸ್ತಾಂತರಗಳನ್ನು ಜಾರಿಗೊಳಿಸಿ

ಕೆಲವೊಮ್ಮೆ ಡೆವಲಪರ್‌ಗಳು ಆರ್ಕೆಸ್ಟ್ರೇಟರ್‌ಗೆ ಹಲವಾರು ಜವಾಬ್ದಾರಿಗಳನ್ನು ನೀಡುತ್ತಾರೆ, ಮತ್ತು ಅದು ವಿಶೇಷಜ್ಞ ಏಜೆಂಟ್‌ಗಳನ್ನು ಸಮನ್ವಯಗೊಳಿಸುವ ಬದಲು ತಾನೇ ಕೋಡ್ ಬರೆಯಲು, ಡೀಬಗ್ ಮಾಡಲು ಅಥವಾ ವಿವರವಾದ ವಿಮರ್ಶೆಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಇದು ಅಡಚಣೆಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ: ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ತನ್ನ ಕಾಂಟೆಕ್ಸ್ಟ್ ಬಜೆಟ್ ಅನ್ನು ಅನುಷ್ಠಾನದ ವಿವರಗಳಿಗೆ ಖರ್ಚು ಮಾಡುತ್ತದೆ, ನಿಯೋಜನೆಯನ್ನು ವಿಳಂಬಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಫಲಿತಾಂಶಗಳ ಜವಾಬ್ದಾರಿಯನ್ನು ಅಸ್ಪಷ್ಟಗೊಳಿಸುತ್ತದೆ.

ಆದ್ದರಿಂದ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್‌ಗಳು ತಮ್ಮ ಕೆಲಸವನ್ನು ಮಾಡಲು ಬಿಡಿ ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಆರ್ಟಿಫ್ಯಾಕ್ಟ್‌ಗಳನ್ನು ಉಲ್ಲೇಖಿಸುವ ಮೂಲಕ ಹಸ್ತಾಂತರಗಳನ್ನು ಜಾರಿಗೊಳಿಸಿ: ಮೂಲ ಕಾರ್ಯ, ಸಂಬಂಧಿತ ಇನ್‌ಪುಟ್‌ಗಳು, ಔಟ್‌ಪುಟ್ ಆರ್ಟಿಫ್ಯಾಕ್ಟ್‌ಗಳು, ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯ ಸ್ಥಿತಿ ಮತ್ತು ಯಾವುದೇ ಬಗೆಹರಿಯದ ಸಮಸ್ಯೆಗಳು.

ಈ ಉದಾಹರಣೆಯನ್ನು ಪರಿಗಣಿಸಿ: status: completed ಎಂಬುದು ಸಂಪೂರ್ಣ ಕಾರ್ಯಪ್ರವಾಹವನ್ನಲ್ಲ, ಏಜೆಂಟ್‌ಗೆ ನಿಯೋಜಿಸಲಾದ ಕೆಲಸವನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಪರೀಕ್ಷೆಗಳು ಇನ್ನೂ pending ಆಗಿರುವುದರಿಂದ, ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಅಂತಿಮ ಫಲಿತಾಂಶವನ್ನು ಅನುಮೋದಿಸಬಾರದು.

json
{ "task_id": "fix-42", "status": "completed", "artifact_ref": "patch-17", "test_status": "pending", "blockers": [] }

3. ಕಾರ್ಯಪ್ರವಾಹದ ಸ್ಥಿತಿಯನ್ನು ಶಾಶ್ವತವಾಗಿ ಉಳಿಸಿ ಮತ್ತು ಕಾಂಟೆಕ್ಸ್ಟ್ ಬೆಳವಣಿಗೆಯನ್ನು ನಿಯಂತ್ರಿಸಿ

ಏಜೆಂಟ್‌ನ ಸಂಭಾಷಣೆಯ ಇತಿಹಾಸವು ಕಾರ್ಯಪ್ರವಾಹದ ಪ್ರಗತಿಯ ವಿಶ್ವಾಸಾರ್ಹ ದಾಖಲೆಯಲ್ಲ. ಅದರ ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋ ತುಂಬಿದಾಗ, ಸ್ವಯಂಚಾಲಿತ ಕಾಂಪ್ಯಾಕ್ಷನ್ ಮುಖ್ಯ ವಿವರಗಳನ್ನು ಕೈಬಿಡಬಹುದು. ಮತ್ತು ವರ್ಕರ್ ಕ್ರ್ಯಾಶ್ ಆದರೆ, ಯಾವ ಹಂತಗಳು ನಿಜವಾಗಿಯೂ ಪೂರ್ಣಗೊಂಡಿವೆ ಎಂಬುದನ್ನು ಮುಂದಿನ ಏಜೆಂಟ್ ತಿಳಿದುಕೊಳ್ಳಬೇಕು.

ಉದಾಹರಣೆಗೆ, ಕೋಡಿಂಗ್ ಏಜೆಂಟ್ ಪ್ಯಾಚ್ ಅನ್ನು ರಚಿಸಿ ನಂತರ ಕ್ರ್ಯಾಶ್ ಆದರೆ, ಮುಂದಿನ ವರ್ಕರ್ ಉಳಿಸಲಾದ ಆರ್ಟಿಫ್ಯಾಕ್ಟ್ ಅನ್ನು ಹಿಂಪಡೆದು ದಾಖಲಾದ ಕಾರ್ಯಪ್ರವಾಹದ ಸ್ಥಿತಿಯಿಂದ ಮುಂದುವರಿಯಬೇಕು. ಆದರೆ ಏಜೆಂಟ್ ಬಾಹ್ಯ CI ರನ್ ಅನ್ನು ಸಹ ಪ್ರಚೋದಿಸಿದ್ದರೆ, ಕ್ರಿಯೆಯನ್ನು ಪುನರಾವರ್ತಿಸುವ ಮೊದಲು ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಆ ರನ್ ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಹೊಂದಾಣಿಕೆ ಮಾಡಬೇಕು

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

4. ವೈಫಲ್ಯ-ಅರಿವಿನ ಮರುಪ್ರಯತ್ನಗಳು ಮತ್ತು ಚೇತರಿಸಿಕೊಳ್ಳಬಹುದಾದ ಟೂಲ್ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಿ

ನಿಮ್ಮ CI ಏಜೆಂಟ್ ಪರೀಕ್ಷಾ ರನ್ ಅನ್ನು ಪ್ರಚೋದಿಸುತ್ತದೆ ಎಂದುಕೊಳ್ಳಿ, ಆದರೆ API ವಿನಂತಿಯ ಸಮಯ ಮೀರುತ್ತದೆ. ಪರೀಕ್ಷಾ ರನ್ ಪ್ರಾರಂಭವಾಗಲು ವಿಫಲವಾಯಿತೇ, ಅಥವಾ CI ಸೇವೆ ಅದನ್ನು ಸರದಿಯಲ್ಲಿರಿಸಿ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಕಳೆದುಕೊಂಡಿತೇ?

ಸಮಯ ಮೀರುವಿಕೆ ಎಂದರೆ ಕಾರ್ಯಾಚರಣೆ ವಿಫಲವಾಗಿದೆ ಎಂದು ಅಗತ್ಯವಾಗಿ ಅರ್ಥವಲ್ಲ. ಅದಕ್ಕಾಗಿಯೇ ಮುಂದೆ ಏನಾಗಬೇಕು ಎಂದು ನಿರ್ಧರಿಸುವ ಮೊದಲು ನೀವು ದೋಷಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ಗುರುತಿಸಬೇಕು:

  • ತಾತ್ಕಾಲಿಕ ದೋಷಗಳು (429, 503): ಮಿತಿಗೊಳಿಸಿದ ಎಕ್ಸ್‌ಪೊನೆನ್ಶಿಯಲ್ ಬ್ಯಾಕ್‌ಆಫ್ ಮತ್ತು ಜಿಟರ್‌ನೊಂದಿಗೆ ಮರುಪ್ರಯತ್ನಿಸಿ, ಒದಗಿಸಿದಾಗ Retry-After ಅನ್ನು ಗೌರವಿಸಿ.
  • ಮೌಲ್ಯೀಕರಣ ಅಥವಾ ಅನುಮತಿ ದೋಷಗಳು (400, 403): ಅದೇ ವಿನಂತಿಯನ್ನು ಪುನರಾವರ್ತಿಸುವ ಬದಲು ನಿಲ್ಲಿಸಿ ಅಥವಾ ಮೂಲ ಸಮಸ್ಯೆಯನ್ನು ಸರಿಪಡಿಸಿ.
  • ಅಸ್ಪಷ್ಟ ಫಲಿತಾಂಶಗಳು (ಸಂಭವನೀಯ ಬರಹದ ನಂತರ ಸಮಯ ಮೀರುವಿಕೆ): ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುವ ಮೊದಲು ಕಾರ್ಯಾಚರಣೆ ಯಶಸ್ವಿಯಾಯಿತೇ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಿ.

ಗಮನಿಸಿ: ಮರುಪ್ರಯತ್ನಿಸಬಹುದಾದ ದೋಷಗಳಿಗೂ ಮಿತಿಗಳು ಬೇಕು. ಪ್ರತಿ ಟೂಲ್ ಕರೆಗೆ ಸಮಯ ಮಿತಿಯನ್ನು ಹೊಂದಿಸಿ, ಮರುಪ್ರಯತ್ನಗಳ ಸಂಖ್ಯೆ ಮತ್ತು ಒಟ್ಟು ಮರುಪ್ರಯತ್ನದ ಸಮಯವನ್ನು ಮಿತಿಗೊಳಿಸಿ, ಮತ್ತು ನೆಸ್ಟೆಡ್ ಏಜೆಂಟ್‌ಗಳು ಅದೇ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಮತ್ತೆ ಮತ್ತೆ ಮರುಪ್ರಾರಂಭಿಸದಂತೆ ಒಟ್ಟಾರೆ ಕಾರ್ಯಪ್ರವಾಹದ ಗಡುವನ್ನು ಜಾರಿಗೊಳಿಸಿ. ಅವಲಂಬನೆಯೊಂದು ಪದೇ ಪದೇ ವಿಫಲವಾದರೆ, ವಿನಂತಿಗಳನ್ನು ತಾತ್ಕಾಲಿಕವಾಗಿ ನಿಲ್ಲಿಸಲು ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕರ್ ಬಳಸಿ.

ಬಾಹ್ಯ ಅಡ್ಡಪರಿಣಾಮಗಳಿರುವ ಕಾರ್ಯಾಚರಣೆಗಳಿಗಾಗಿ, ಪ್ರತಿ ತಾರ್ಕಿಕ ಕ್ರಿಯೆಗೆ ಸ್ಥಿರವಾದ ಐಡೆಂಪೊಟೆನ್ಸಿ ಕೀ ಅನ್ನು ನಿಗದಿಪಡಿಸಿ ಮತ್ತು ಮರುಪ್ರಯತ್ನಗಳಾದ್ಯಂತ ಅದನ್ನು ಮರುಬಳಸಿ. API ಸರ್ವರ್-ಸೈಡ್ ಡಿಡ್ಯೂಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಬೆಂಬಲಿಸಿದರೆ, ಅದು ಕ್ರಿಯೆಯನ್ನು ಎರಡು ಬಾರಿ ನಿರ್ವಹಿಸದೆ ಪುನರಾವರ್ತಿತ ವಿನಂತಿಗಳನ್ನು ಗುರುತಿಸಬಹುದು. ಬೆಂಬಲಿಸದಿದ್ದರೆ, ಕೋರಿಲೇಶನ್ ID ಅಥವಾ ಇತರ ಅಧಿಕೃತ ಉಲ್ಲೇಖವನ್ನು ಬಳಸಿ ಬಾಹ್ಯ ಸಿಸ್ಟಮ್ ಅನ್ನು ಪ್ರಶ್ನಿಸಿ.

ಏನಾಯಿತು ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದಾಗ, ನಿಲ್ಲಿಸಿ ಮತ್ತು ಎಸ್ಕಲೇಟ್ ಮಾಡಿ.

ನಮ್ಮ CI ಏಜೆಂಟ್‌ಗಾಗಿ ಮರುಪ್ರಯತ್ನದ ತರ್ಕದ ಒಂದು ಉದಾಹರಣೆ, ಸೂಡೋಕೋಡ್ ರೂಪದಲ್ಲಿ:

python
op_id = get_or_create_operation_id( task_id=task_id, patch_id=patch_id, action="start_ci_run" ) try: return ci.start_run(commit, request_id=op_id) except TimeoutError: run = ci.find_by_request_id(op_id) if run: return run if ci.supports_idempotency: return bounded_retry( lambda: ci.start_run(commit, request_id=op_id) ) raise NeedsReconciliation(op_id)

ಕೋಡ್ ಟಿಪ್ಪಣಿ: ಈ ಉದಾಹರಣೆಯು CI API ವಿನಂತಿ ID ಮೂಲಕ ರನ್‌ಗಳನ್ನು ಹುಡುಕುವುದನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ ಎಂದು ಭಾವಿಸುತ್ತದೆ. request_id ಪೂರೈಕೆದಾರರು ಐಡೆಂಪೊಟೆನ್ಸಿಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಖಾತರಿಪಡಿಸಿದರೆ ಮಾತ್ರ ನಕಲುಗಳನ್ನು ತಡೆಯುತ್ತದೆ. bounded_retry() ವಿವರಣೆಗಾಗಿ ನೀಡಲಾದ ಸೂಡೋಕೋಡ್ ಆಗಿದೆ. ಪ್ರೊಡಕ್ಷನ್‌ನಲ್ಲಿ, ಮರುಪ್ರಯತ್ನಗಳನ್ನು ಪ್ರತಿ-ಕಾರ್ಯಾಚರಣೆಯ ಮರುಪ್ರಯತ್ನ ಬಜೆಟ್ (ಗರಿಷ್ಠ ಪ್ರಯತ್ನಗಳು ಅಥವಾ ಕಳೆದ ಸಮಯ) ಮತ್ತು ಒಟ್ಟಾರೆ ಕಾರ್ಯಪ್ರವಾಹದ ಗಡುವು ಎರಡರಿಂದಲೂ ಮಿತಿಗೊಳಿಸಬೇಕು.

ಬಹು ಸೇವೆಗಳನ್ನು ವ್ಯಾಪಿಸುವ ದೀರ್ಘ ಕಾರ್ಯಪ್ರವಾಹಗಳಿಗಾಗಿ, ನಂತರದ ಹಂತಗಳು ವಿಫಲವಾದಾಗ ಸರಿದೂಗಿಸುವ ಕ್ರಿಯೆಗಳನ್ನು ಸಮನ್ವಯಗೊಳಿಸಲು Saga ಪ್ಯಾಟರ್ನ್ ಅನ್ನು ಪರಿಗಣಿಸಿ. ಸರಿದೂಗಿಸುವಿಕೆ ಯಾವಾಗಲೂ ಸಂಪೂರ್ಣ ರೋಲ್‌ಬ್ಯಾಕ್ ಅಲ್ಲ ಎಂಬುದನ್ನು ನೆನಪಿಡಿ. ನೀವು ಡೇಟಾಬೇಸ್ ನವೀಕರಣವನ್ನು ಹಿಮ್ಮುಖಗೊಳಿಸಬಹುದು, ಆದರೆ ಕಳುಹಿಸಿದ ಇಮೇಲ್ ಅನ್ನು ಹಿಂಪಡೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ.

5. ಸ್ಪಷ್ಟ ಸಂಪನ್ಮೂಲ ಬಜೆಟ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸವನ್ನು ರೂಟ್ ಮಾಡಿ ಮತ್ತು ಸಮಾನಾಂತರಗೊಳಿಸಿ

ಇಲ್ಲಿ ಸಮತೋಲನಗೊಳಿಸಬೇಕಾದ ಎರಡು ವಿಷಯಗಳಿವೆ: ಪ್ರತಿ ಕಾರ್ಯಕ್ಕೆ ಎಷ್ಟು ಮಾಡೆಲ್ ಸಾಮರ್ಥ್ಯ ಬೇಕು ಮತ್ತು ನೀವು ಏಕಕಾಲದಲ್ಲಿ ಎಷ್ಟು ಕಾರ್ಯಗಳನ್ನು ರನ್ ಮಾಡಬಹುದು. ಇವುಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ತಪ್ಪಾದರೆ, ಏಜೆಂಟ್‌ಗಳು ಹಂಚಿಕೆಯ API ಕೋಟಾಗಳಿಗಾಗಿ ಸ್ಪರ್ಧಿಸುವ ಅಥವಾ ದುಬಾರಿ ರೀಜನಿಂಗ್ ಮಾಡೆಲ್‌ಗಳನ್ನು ಮಾತ್ರ ಅವಲಂಬಿಸುವ ಅಪಾಯವಿದೆ.

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

ಉದಾಹರಣೆಗೆ, Perplexity Computer ನ Effort Mode ಮಾಡೆಲ್ ಅನ್ನು ಕೈಯಾರೆ ಆಯ್ಕೆ ಮಾಡದೆಯೇ ಒಂದು ಕಾರ್ಯಕ್ಕೆ ಎಷ್ಟು ಪ್ರಯತ್ನ ಬೇಕು ಎಂಬುದನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. Light, Standard, High ಅಥವಾ Ultra ಆಯ್ಕೆಮಾಡಿ, ಮತ್ತು Perplexity ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಆರ್ಕೆಸ್ಟ್ರೇಟಿಂಗ್ ಮಾಡೆಲ್ ಮತ್ತು ಅದರ ರೀಜನಿಂಗ್ ಮಟ್ಟವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ಆ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ನಂತರ ಉಪಕಾರ್ಯಗಳನ್ನು ಬೆಂಬಲಿಸುವ ಏಜೆಂಟ್‌ಗಳಿಗೆ ನಿಯೋಜಿಸುತ್ತದೆ, ಅವು ವಿಭಿನ್ನ ಪೂರೈಕೆದಾರರ ಮಾಡೆಲ್‌ಗಳನ್ನು ಬಳಸಬಹುದು.

Perplexity ಗುಣಮಟ್ಟ ಮತ್ತು ವೆಚ್ಚಕ್ಕಾಗಿ ಮಾಡೆಲ್ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತದೆ, ಹೋಲಿಸಬಹುದಾದ ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡುವ ಕಡಿಮೆ ವೆಚ್ಚದ ಆಯ್ಕೆಗಳಿಗೆ ಆದ್ಯತೆ ನೀಡುತ್ತದೆ. ಮಾಡೆಲ್ ಮತ್ತು ರೀಜನಿಂಗ್ ಮಟ್ಟವನ್ನು ನೀವೇ ಆಯ್ಕೆ ಮಾಡಲು ಬಯಸಿದರೆ, ನೀವು Custom ನಿಯಂತ್ರಣಗಳನ್ನು ಸಹ ಬಳಸಬಹುದು.

ಸಮಾನಾಂತರತೆಗೆ ಬಂದರೆ, ಮಿತಿಯು ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯ ಮತ್ತು ಬಾಹ್ಯ ಅವಲಂಬನೆಗಳಿಂದ ಬರಬೇಕು. ಹಂಚಿಕೆಯ API ಗಳ ವಿನಂತಿ ಮತ್ತು ಟೋಕನ್ ದರ ಮಿತಿಗಳನ್ನು ಪರಿಶೀಲಿಸಿ, ನಂತರ ಹೆಚ್ಚುತ್ತಿರುವ ಏಕಕಾಲಿಕತೆಯೊಂದಿಗೆ ನಿಮ್ಮ ಕಾರ್ಯಪ್ರವಾಹವನ್ನು ಲೋಡ್-ಟೆಸ್ಟ್ ಮಾಡಿ. ಥ್ರೂಪುಟ್ ಸುಧಾರಿಸುತ್ತದೆಯೇ ಅಥವಾ ವಿನಂತಿಗಳು ಸರದಿಯಲ್ಲಿ ನಿಲ್ಲಲು, ನಿಧಾನವಾಗಲು ಅಥವಾ 429 ದೋಷಗಳನ್ನು ಹಿಂದಿರುಗಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತವೆಯೇ ಎಂಬುದನ್ನು ಗಮನಿಸಿ.

ಸಂಪನ್ಮೂಲ ಬಳಕೆಯನ್ನು ನಿರೀಕ್ಷಿತವಾಗಿರಿಸಲು, ಸಂಪನ್ಮೂಲ ಮಿತಿಗಳು ಮತ್ತು ಶೆಡ್ಯೂಲಿಂಗ್ ನಿಯಂತ್ರಣಗಳನ್ನು ಜಾರಿಗೊಳಿಸಿ:

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

6. ಅನುಮೋದನೆಗಳನ್ನು ಜಾರಿಗೊಳಿಸಿ ಮತ್ತು ಏಜೆಂಟ್ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ

ತನ್ನದೇ ಕ್ರಿಯೆಗಳು ಸುರಕ್ಷಿತವೇ ಎಂದು ನಿರ್ಧರಿಸಲು ಎಂದಿಗೂ ಮಾಡೆಲ್‌ಗೆ ಕೇಳಬೇಡಿ. ಬದಲಿಗೆ, ಏಜೆಂಟ್‌ಗಳಿಗೆ ಕನಿಷ್ಠ-ಸವಲತ್ತು ಅನುಮತಿಗಳನ್ನು ನೀಡಿ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್‌ನಲ್ಲಿ ಅಪಾಯ-ಆಧಾರಿತ ಅನುಮೋದನೆ ನಿಯಮಗಳನ್ನು ಜಾರಿಗೊಳಿಸಿ. ಏಜೆಂಟ್‌ಗಳು ಕೋಡ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದರೆ, ಆ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ನಿಮ್ಮ ಹೋಸ್ಟ್ ಪರಿಸರದಿಂದ ಪ್ರತ್ಯೇಕಿಸಿ ಮತ್ತು ಫೈಲ್‌ಗಳು, ನೆಟ್‌ವರ್ಕ್‌ಗಳು ಮತ್ತು ಕ್ರೆಡೆನ್ಶಿಯಲ್‌ಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ನಿರ್ಬಂಧಿಸಿ. ಏಜೆಂಟ್ ತಪ್ಪು ಮಾಡಿದರೆ ಅಥವಾ ಅಸುರಕ್ಷಿತ ಕೋಡ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದರೆ ಆಗುವ ಹಾನಿಯನ್ನು ಇದು ಮಿತಿಗೊಳಿಸುತ್ತದೆ.

“ಅತಿಯಾಗಿ ಸಂಕೀರ್ಣವಾದ ಮಲ್ಟಿ-ಏಜೆಂಟ್ ಸಿಸ್ಟಮ್‌ಗಳ ಬಗ್ಗೆ, ವಿಶೇಷವಾಗಿ ಏಜೆಂಟ್‌ಗಳು ಪರಸ್ಪರರ ಕೆಲಸವನ್ನು ವಿಮರ್ಶಿಸಿ ಅನುಮೋದಿಸುವಾಗ, ನನಗೆ ಸಂದೇಹವಿದೆ. ಯಾರೂ ನಿಜವಾಗಿ ಅದನ್ನು ಹಿಡಿಯದೆ, ಹಲವಾರು ಏಜೆಂಟ್‌ಗಳು ಅದೇ ತಪ್ಪನ್ನು ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ಮುಂದಕ್ಕೆ ರವಾನಿಸುವ ಪರಿಸ್ಥಿತಿ ಉಂಟಾಗಬಹುದು,” ಎಂದು ಸ್ಪಿಲ್ಕರ್ ಎಚ್ಚರಿಸುತ್ತಾರೆ.

ಮಾನವ ಅನುಮೋದನೆಯ ಅಗತ್ಯವಿರುವ ಕ್ರಿಯೆಗಳಿಗಾಗಿ, ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ವಿರಾಮಗೊಳಿಸಿ ಮತ್ತು ಪ್ರಸ್ತಾಪಿತ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ನಿಖರವಾಗಿ ಉಳಿಸಿ:

  • ಅದರ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳು
  • ಅದರ ಗುರಿ ಸಂಪನ್ಮೂಲ
  • ಅದರ ಕಮಿಟ್ ಅಥವಾ ಸ್ಥಿತಿ ಆವೃತ್ತಿ
  • ವಿಮರ್ಶಕರ ನಿರ್ಧಾರ

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

ಆದ್ದರಿಂದ ಅನುಮೋದನೆ ತಿರಸ್ಕೃತವಾದರೆ ಅಥವಾ ಅವಧಿ ಮೀರಿದರೆ, ವಿನಂತಿ ಮುಚ್ಚಲ್ಪಡುತ್ತದೆ. ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮೊದಲು ಗುರಿ ಕಮಿಟ್, ಪ್ಯಾರಾಮೀಟರ್‌ಗಳು ಅಥವಾ ಅನುಮತಿಗಳು ಬದಲಾದರೆ, ಅನುಮೋದನೆಯನ್ನು ಅಮಾನ್ಯಗೊಳಿಸಿ ಹೊಸದನ್ನು ವಿನಂತಿಸಿ.

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

7. ಔಟ್‌ಪುಟ್‌ಗಳನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಪರಿಶೀಲಿಸಿ ಮತ್ತು ಚೇತರಿಕೆಯ ವರ್ತನೆಯನ್ನು ಪರೀಕ್ಷಿಸಿ

ಏಜೆಂಟ್ ನಿಜವಾಗಿ ವಿಫಲವಾದಾಗಲೂ Success ಎಂದು ವರದಿ ಮಾಡಿದ ಅನುಭವ ನಿಮಗಾಗಿದೆಯೇ? ಇದು ಕೋಪ ತರಿಸದಿದ್ದರೂ ಕಿರಿಕಿರಿ ಉಂಟುಮಾಡುತ್ತದೆ, ಮತ್ತು ಇದನ್ನು ಸರಿಪಡಿಸುವುದು ತ್ವರಿತವಲ್ಲ, ಏಕೆಂದರೆ ಎಲ್ಲಿ ತಪ್ಪಾಯಿತು ಎಂಬುದನ್ನು ಏಜೆಂಟ್‌ನ ಅಂತಿಮ ಸಂದೇಶವು ಅಗತ್ಯವಾಗಿ ತಿಳಿಸುವುದಿಲ್ಲ.

ತನಿಖೆ ಮಾಡಲು, ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯ ಸಮಯದಲ್ಲಿ ಏನಾಯಿತು ಎಂಬುದನ್ನು ಟ್ರೇಸ್ ಮಾಡಿ ಮತ್ತು ಫಲಿತಾಂಶಗಳನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಪರಿಶೀಲಿಸಿ. ಹಾಗಾಗಿ ಸಮಸ್ಯೆಯನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ ಬಗೆಹರಿಸಲು ಸ್ವಲ್ಪ ಸಮಯ ಮೀಸಲಿಡೋಣ.

ಏನು ತಪ್ಪಾಯಿತು ಎಂಬುದನ್ನು ಗುರುತಿಸಲು ಕಾರ್ಯಪ್ರವಾಹವನ್ನು ಟ್ರೇಸ್ ಮಾಡಿ

ಏಜೆಂಟ್‌ನ ಪ್ರಾಂಪ್ಟ್‌ಗಳನ್ನು ಡೀಬಗ್ ಮಾಡುವ ಮೊದಲು, ಸಂಪೂರ್ಣ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯ ಮಾರ್ಗವನ್ನು ಸೆರೆಹಿಡಿಯಿರಿ. ಒಂದೇ ಕಾರ್ಯಪ್ರವಾಹ ರನ್‌ನ ಅಡಿಯಲ್ಲಿ ಏಜೆಂಟ್ ಇನ್ವೊಕೇಶನ್‌ಗಳು, ಟೂಲ್ ಕರೆಗಳು, ದೋಷಗಳು ಮತ್ತು ಮರುಪ್ರಯತ್ನಗಳನ್ನು ಸಂಪರ್ಕಿಸುವ ಟ್ರೇಸ್ ನಿಮಗೆ ಬೇಕು.

OpenTelemetry ನ GenAI ಸೆಮ್ಯಾಂಟಿಕ್ ಕನ್ವೆನ್ಶನ್‌ಗಳು ಈ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ವಿವರಿಸಲು ಪ್ರಮಾಣೀಕೃತ ಮಾರ್ಗವನ್ನು ಒದಗಿಸುತ್ತವೆ. ಉದಾಹರಣೆಗೆ, invoke_workflow ಕಾರ್ಯಪ್ರವಾಹದ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು, invoke_agent ಏಜೆಂಟ್ ಇನ್ವೊಕೇಶನ್ ಅನ್ನು ಮತ್ತು execute_tool ಟೂಲ್ ಕರೆಯನ್ನು ಗುರುತಿಸುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಅದರ ಸಮಯ, ಸ್ಥಿತಿ ಮತ್ತು ಸಂಬಂಧಿತ ಮೆಟಾಡೇಟಾದೊಂದಿಗೆ span ಆಗಿ ದಾಖಲಿಸಬಹುದು.

ಈ ಹಂತವು ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯ ಮಾರ್ಗದ ಟ್ರೇಸ್ ಅನ್ನು ನೀಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಏಜೆಂಟ್ ಎಲ್ಲಿ ಎಡವಿತು ಎಂಬುದನ್ನು ನೀವು ಗುರುತಿಸಬಹುದು.

plaintext
invoke_agent generate_patch OK execute_tool start_ci_run OK run_id=9812 execute_tool get_ci_result TIMEOUT agent_response: "Success"

ವಿವರಣಾತ್ಮಕ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯ ಟ್ರೇಸ್.

ಔಟ್‌ಪುಟ್ ಅನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ವಿಮರ್ಶಿಸಿ

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

ವ್ಯಕ್ತಿನಿಷ್ಠ ತೀರ್ಮಾನದ ಅಗತ್ಯವಿರುವ — ಮತ್ತು ಆದ್ದರಿಂದ ಪ್ರೋಗ್ರಾಮ್ಯಾಟಿಕ್ ಪರಿಶೀಲನೆಗಳ ಮೂಲಕ ಮೌಲ್ಯಮಾಪನ ಮಾಡಲಾಗದ — ಔಟ್‌ಪುಟ್‌ಗಳಿಗಾಗಿ, ಸ್ವತಂತ್ರ ವಿಮರ್ಶಕ ಏಜೆಂಟ್ ಅನ್ನು ಪರಿಚಯಿಸಿ. ಒಂದು ವಿಧಾನವೆಂದರೆ ಇಂಪ್ಲಿಮೆಂಟರ್–ರಿವ್ಯೂವರ್–ರಿಸಾಲ್ವರ್ ಲೂಪ್, ಇದರಲ್ಲಿ ಒಂದು ಏಜೆಂಟ್ ಆರ್ಟಿಫ್ಯಾಕ್ಟ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ, ಹೊಸ ಕಾಂಟೆಕ್ಸ್ಟ್‌ನ ವಿಮರ್ಶಕ ಸಮಸ್ಯೆಗಳನ್ನು ಗುರುತಿಸುತ್ತದೆ, ಮತ್ತು ಮೌಲ್ಯೀಕರಣ ಮತ್ತೆ ರನ್ ಆಗುವ ಮೊದಲು ರಿಸಾಲ್ವರ್ ಅವುಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ.

ಸಾಧ್ಯವಿರುವಲ್ಲಿ ನೀವು ವಿಮರ್ಶಕರ ಕಂಡುಹಿಡಿತಗಳನ್ನು ಇನ್ನೂ ಮೌಲ್ಯೀಕರಿಸಬೇಕು, ಮತ್ತು ಪುನರಾವರ್ತಿತ ಮೌಲ್ಯಮಾಪನಗಳಿಗಾಗಿ LLM-ಆಧಾರಿತ ಗ್ರೇಡರ್‌ಗಳನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ, ಅವುಗಳ ತೀರ್ಮಾನಗಳನ್ನು ಮಾನವರು ವಿಮರ್ಶಿಸಿದ ಉದಾಹರಣೆಗಳ ಆಧಾರದಲ್ಲಿ ಮಾಪನಾಂಕ ನಿರ್ಣಯಿಸಿ.

ಚೇತರಿಕೆಯನ್ನು ಪರೀಕ್ಷಿಸಲು ವೈಫಲ್ಯಗಳನ್ನು ಸೇರಿಸಿ

ಇಲ್ಲಿಯವರೆಗೆ, ಏಜೆಂಟ್‌ಗಳು ಏನನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದವು ಎಂಬುದನ್ನು ನೀವು ಪತ್ತೆಹಚ್ಚಿದ್ದೀರಿ ಮತ್ತು ಅವುಗಳ ಔಟ್‌ಪುಟ್‌ಗಳು ಸರಿಯಾಗಿವೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿದ್ದೀರಿ. ಆದರೆ ಕಾರ್ಯದ ಅರ್ಧದಲ್ಲೇ ವರ್ಕರ್ ಕ್ರ್ಯಾಶ್ ಆದರೆ ಅಥವಾ ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸಿದ ನಂತರ API ಟೈಮ್ ಔಟ್ ಆದರೆ ಏನಾಗುತ್ತದೆ? ಆಶ್ಚರ್ಯಕರವಾಗಿ, ನಿಮ್ಮ ಕಾರ್ಯಪ್ರವಾಹವು ಸಾಮಾನ್ಯ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು, ಆದರೆ ಚೇತರಿಕೆಯ ಸಮಯದಲ್ಲಿ ವಿಫಲವಾಗಬಹುದು.

ಇದನ್ನು ಪರೀಕ್ಷಿಸಲು, ಪರೀಕ್ಷಾ ಪರಿಸರದಲ್ಲಿ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ದೋಷಗಳನ್ನು ಸೇರಿಸಿ:

  • API ಟೈಮ್‌ಔಟ್‌ಗಳನ್ನು ಅನುಕರಿಸಿ
  • ಬಾಹ್ಯ ರೈಟ್‌ಗಳು ಮತ್ತು ಚೆಕ್‌ಪಾಯಿಂಟ್‌ಗಳ ನಡುವೆ ವರ್ಕರ್‌ಗಳನ್ನು ಕ್ರ್ಯಾಶ್ ಮಾಡಿ
  • ದೋಷಪೂರಿತ ಟೂಲ್ ಔಟ್‌ಪುಟ್‌ಗಳನ್ನು ಹಿಂತಿರುಗಿಸಿ
  • ಅನುಮೋದನೆಗಳ ಅವಧಿ ಮುಗಿಯುವಂತೆ ಮಾಡಿ

ಪ್ರತಿ ಪರೀಕ್ಷೆಯ ನಂತರ, ಯಾವ ಹಂತಗಳು ರನ್ ಆದವು, ಕಾರ್ಯಪ್ರವಾಹ ಎಲ್ಲಿಂದ ಪುನರಾರಂಭವಾಯಿತು ಮತ್ತು ಯಾವುದೇ ಕ್ರಿಯೆಗಳು ಪುನರಾವರ್ತನೆಯಾದವೇ ಅಥವಾ ಬಿಟ್ಟುಹೋದವೇ ಎಂಬುದನ್ನು ನೋಡಲು ಎಕ್ಸಿಕ್ಯೂಶನ್ ಟ್ರೇಸ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ. ನಂತರ ನಿಜವಾದ ಫಲಿತಾಂಶಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.

ನಿಮ್ಮ CI ಏಜೆಂಟ್ ಪರೀಕ್ಷಾ ರನ್ ಪ್ರಾರಂಭಿಸಲು ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ ಎಂದುಕೊಳ್ಳಿ, ಆದರೆ API ಪ್ರತಿಕ್ರಿಯೆ ಟೈಮ್ ಔಟ್ ಆಗುತ್ತದೆ. ಏಜೆಂಟ್ ಮರುಪ್ರಯತ್ನಿಸುತ್ತದೆ, ಯಶಸ್ವಿ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪಡೆಯುತ್ತದೆ ಮತ್ತು ಯಶಸ್ವಿ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ. ನೀವು CI ಸೇವೆಯನ್ನು ಪರಿಶೀಲಿಸಿ, ಒಂದರ ಬದಲು ಎರಡು ಪರೀಕ್ಷಾ ರನ್‌ಗಳು ರಚನೆಯಾಗಿವೆ ಎಂದು ಕಂಡುಕೊಳ್ಳುವವರೆಗೂ ಎಲ್ಲವೂ ಸರಿಯಾಗಿರುವಂತೆ ಕಾಣುತ್ತದೆ.

ಅದಕ್ಕಾಗಿಯೇ ನೀವು ಕಾರ್ಯಪ್ರವಾಹದ ದಾಖಲಾದ ಸ್ಥಿತಿ ಮತ್ತು ಬಾಹ್ಯ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿನ ನಿಜವಾದ ಬದಲಾವಣೆಗಳು ಎರಡನ್ನೂ ಪರಿಶೀಲಿಸಬೇಕು. ಕಾರ್ಯಪ್ರವಾಹವು ಉದ್ದೇಶಿಸದ ಅಡ್ಡಪರಿಣಾಮಗಳಿಲ್ಲದೆ ನಿರೀಕ್ಷಿತ ಸ್ಥಿತಿಯನ್ನು ತಲುಪಿದಾಗ ಮಾತ್ರ ಚೇತರಿಕೆ ಪರೀಕ್ಷೆಯು ಉತ್ತೀರ್ಣವಾಗಬೇಕು.

ಭವಿಷ್ಯದ ಬದಲಾವಣೆಗಳು ಅವುಗಳನ್ನು ಮತ್ತೆ ಪರಿಚಯಿಸದಂತೆ, ನೀವು ಪತ್ತೆಹಚ್ಚುವ ವೈಫಲ್ಯಗಳನ್ನು ನಿಮ್ಮ ರಿಗ್ರೆಶನ್ ಪರೀಕ್ಷೆಗಳಿಗೆ ಸೇರಿಸಿ.

ಅಂತಿಮವಾಗಿ, ಯಶಸ್ಸು ಎಂದರೆ ಕಾರ್ಯಪ್ರವಾಹವು ಅಗತ್ಯವಿರುವ ಪರಿಶೀಲನೆಗಳಲ್ಲಿ ಉತ್ತೀರ್ಣವಾಗಿದೆ ಮತ್ತು ಅದರ ಬಾಹ್ಯ ಫಲಿತಾಂಶಗಳನ್ನು ದೃಢೀಕರಿಸಲಾಗಿದೆ.

AI ಏಜೆಂಟ್ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಕುರಿತು ಪದೇ ಪದೇ ಕೇಳಲಾಗುವ ಪ್ರಶ್ನೆಗಳು

ಪ್ರತ್ಯೇಕವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ AI ಏಜೆಂಟ್‌ಗಳು ಎಂಟರ್‌ಪ್ರೈಸ್ ಮಟ್ಟದಲ್ಲಿ ಏಕೆ ವಿಫಲವಾಗುತ್ತವೆ?

ಪ್ರತ್ಯೇಕವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಏಜೆಂಟ್‌ಗಳು ತಮ್ಮ ವೈಯಕ್ತಿಕ ಕಾರ್ಯಗಳನ್ನು ಸರಿಯಾಗಿ ಪೂರ್ಣಗೊಳಿಸಬಹುದು, ಆದರೆ ಒಟ್ಟಾಗಿ ಅಸಂಗತ ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡಬಹುದು. 10:00 ಕ್ಕೆ ಮಾರಾಟ ಏಜೆಂಟ್ ಗ್ರಾಹಕರ ನಿಯಮಗಳನ್ನು ಪಡೆಯುತ್ತಿದೆ, 10:05 ಕ್ಕೆ ಬೆಲೆ ನಿಗದಿ ಏಜೆಂಟ್ ನವೀಕರಿಸಿದ ಬೆಲೆಗಳನ್ನು ಬಳಸಿ ಬೆಲೆ ಉಲ್ಲೇಖವನ್ನು ಲೆಕ್ಕಹಾಕುತ್ತಿದೆ ಮತ್ತು 10:07 ಕ್ಕೆ ಬದಲಾದ ಒಪ್ಪಂದವನ್ನು ಕಾನೂನು ಏಜೆಂಟ್ ಪರಿಶೀಲಿಸುತ್ತಿದೆ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ಪ್ರತಿಯೊಂದು ಏಜೆಂಟ್ ವ್ಯವಹಾರದ ವಿಭಿನ್ನ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಅವುಗಳ ಔಟ್‌ಪುಟ್‌ಗಳು ಪರಸ್ಪರ ವಿರೋಧಿಸಬಹುದು.

ಎಂಟರ್‌ಪ್ರೈಸ್ ಮಟ್ಟದಲ್ಲಿ ಈ ಸಮಸ್ಯೆ ಇನ್ನಷ್ಟು ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಏಜೆಂಟ್‌ಗಳು ಸ್ವತಂತ್ರವಾಗಿ ನವೀಕರಣಗೊಳ್ಳುವ ಅನೇಕ ವ್ಯವಸ್ಥೆಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತವೆ, ವಿಭಿನ್ನ ಅನುಮತಿಗಳೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಮತ್ತು ಸಂದರ್ಭ ಅಥವಾ ಎಕ್ಸಿಕ್ಯೂಶನ್ ಸ್ಥಿತಿಯನ್ನು ಅಗತ್ಯವಾಗಿ ಹಂಚಿಕೊಳ್ಳುವುದಿಲ್ಲ.

AI ಏಜೆಂಟ್‌ಗಳಲ್ಲಿ ಅನಂತ ಮರುಪ್ರಯತ್ನ ಲೂಪ್‌ಗಳನ್ನು ತಡೆಯುವುದು ಹೇಗೆ?

ಅನೇಕ ಹಂತಗಳಲ್ಲಿ ಮಿತಿಗಳನ್ನು ಹೊಂದಿಸಿ: ಗರಿಷ್ಠ ಟೂಲ್-ಕಾಲ್ ಮರುಪ್ರಯತ್ನಗಳು, ಗರಿಷ್ಠ ಏಜೆಂಟ್ ಪುನರಾವರ್ತನೆಗಳು, ಡೆಲಿಗೇಶನ್ ಆಳ ಮತ್ತು ಒಟ್ಟಾರೆ ಕಾರ್ಯಪ್ರವಾಹದ ಗಡುವು. ಮರುಪ್ರಯತ್ನಿಸುವ ಮೊದಲು ವೈಫಲ್ಯಗಳನ್ನು ವರ್ಗೀಕರಿಸಿ. ತಾತ್ಕಾಲಿಕ 429 ಪ್ರತಿಕ್ರಿಯೆಗಳಿಗೆ, Retry-After ಒದಗಿಸಿದ್ದರೆ ಅದನ್ನು ಪಾಲಿಸಿ. ಇಲ್ಲದಿದ್ದರೆ, ಜಿಟರ್‌ನೊಂದಿಗೆ ಸೀಮಿತ ಎಕ್ಸ್‌ಪೋನೆನ್ಶಿಯಲ್ ಬ್ಯಾಕ್‌ಆಫ್ ಬಳಸಿ.

ಮೌಲ್ಯೀಕರಣ ಅಥವಾ ಅನುಮತಿ ದೋಷಗಳ ನಂತರ ಬದಲಾಗದ ವಿನಂತಿಗಳನ್ನು ಮರುಪ್ರಯತ್ನಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ಡೌನ್‌ಸ್ಟ್ರೀಮ್ ಸೇವೆಯು ಪದೇ ಪದೇ ವಿಫಲವಾದರೆ, ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕರ್ ಏಜೆಂಟ್‌ಗಳು ಹೆಚ್ಚುವರಿ ಲೋಡ್ ಉಂಟುಮಾಡುವುದನ್ನು ತಡೆಯಬಹುದು.

ಕ್ರ್ಯಾಶ್ ಆದ ನಂತರ AI ಏಜೆಂಟ್ ಕಾರ್ಯಪ್ರವಾಹವನ್ನು ಪುನರಾರಂಭಿಸುವುದು ಹೇಗೆ?

ಚೇತರಿಕೆಯ ಕಾರ್ಯವಿಧಾನವು ನಿಮ್ಮ ರನ್‌ಟೈಮ್ ಅನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. LangGraph ನಲ್ಲಿ, PostgresSaver ನಂತಹ ಶಾಶ್ವತ ಚೆಕ್‌ಪಾಯಿಂಟರ್ ಗ್ರಾಫ್ ಸ್ಥಿತಿಯನ್ನು thread_id ಅಡಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತದೆ, ಇದರಿಂದ ಸಂಗ್ರಹಿತ ಸ್ಥಿತಿಯಿಂದ ಎಕ್ಸಿಕ್ಯೂಶನ್ ಮುಂದುವರಿಯಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. Temporal ನಲ್ಲಿ, ಮತ್ತೊಂದು ವರ್ಕರ್ ಕಾರ್ಯಪ್ರವಾಹದ ಈವೆಂಟ್ ಇತಿಹಾಸವನ್ನು ಮರುಪ್ಲೇ ಮಾಡುವ ಮೂಲಕ ಅದನ್ನು ಪುನರ್ನಿರ್ಮಿಸಬಹುದು. ಮರುಪ್ಲೇ ಸಮಯದಲ್ಲಿ, ಅದು ಹಿಂದೆ ದಾಖಲಾದ ಆಕ್ಟಿವಿಟಿ ಫಲಿತಾಂಶಗಳನ್ನು ಮರುಬಳಸುತ್ತದೆ.

ಕಾರ್ಯಪ್ರವಾಹಗಳು ಇನ್ನೂ ಚಾಲನೆಯಲ್ಲಿರುವಾಗ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಮರುನಿಯೋಜಿಸಿದರೆ, ಉಳಿಸಿದ ಸ್ಥಿತಿ ಮತ್ತು ಎಕ್ಸಿಕ್ಯೂಶನ್ ಇತಿಹಾಸಗಳು ಇನ್ನು ಮುಂದೆ ಹೊಂದಾಣಿಕೆಯಾಗದಿರಬಹುದು. Temporal ಇದನ್ನು Worker Versioning ಮತ್ತು ಕಾರ್ಯಪ್ರವಾಹ ಪ್ಯಾಚಿಂಗ್ ಮೂಲಕ ನಿಭಾಯಿಸುತ್ತದೆ. ಚೆಕ್‌ಪಾಯಿಂಟ್ ಆಧಾರಿತ ವ್ಯವಸ್ಥೆಗಳಿಗೆ, ಹೊಂದಾಣಿಕೆಯಾಗದ ಬದಲಾವಣೆಗಳನ್ನು ಜಾರಿಗೊಳಿಸುವ ಮೊದಲು ಸ್ಕೀಮಾ ಮೈಗ್ರೇಶನ್‌ಗಳನ್ನು ಯೋಜಿಸಿ ಮತ್ತು ಈಗಿರುವ ಉಳಿಸಿದ ಸ್ಥಿತಿಗಳ ವಿರುದ್ಧ ಚೇತರಿಕೆಯನ್ನು ಪರೀಕ್ಷಿಸಿ.

AI ಏಜೆಂಟ್ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್‌ನ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಪರೀಕ್ಷಿಸುವುದು ಹೇಗೆ?

ಒಂದೇ ಪ್ರಾತಿನಿಧಿಕ ಕಾರ್ಯಗಳನ್ನು ಅನೇಕ ಬಾರಿ ರನ್ ಮಾಡಿ ಮತ್ತು pass@k (k ಪ್ರಯತ್ನಗಳಲ್ಲಿ ಕನಿಷ್ಠ ಒಂದು ಯಶಸ್ವಿಯಾಗುತ್ತದೆಯೇ) ಮತ್ತು pass^k (ಎಲ್ಲಾ k ಪ್ರಯತ್ನಗಳು ಯಶಸ್ವಿಯಾಗುತ್ತವೆಯೇ) ನಡುವೆ ವ್ಯತ್ಯಾಸ ಮಾಡಿ

ಒಂದೇ ಒಟ್ಟು ಯಶಸ್ಸಿನ ದರವನ್ನು ಅವಲಂಬಿಸುವ ಬದಲು, ಕಾರ್ಯ ವರ್ಗ ಮತ್ತು ಕಾರ್ಯಪ್ರವಾಹ ಆವೃತ್ತಿಯ ಪ್ರಕಾರ ಫಲಿತಾಂಶಗಳನ್ನು ಅಳೆಯಿರಿ. ಮೊದಲ ಪ್ರಯತ್ನದ ಯಶಸ್ಸು, ಪುನರಾವರ್ತಿತ ರನ್‌ಗಳಾದ್ಯಂತ ಸ್ಥಿರತೆ, p95 ಲೇಟೆನ್ಸಿ, ಪ್ರತಿ ಪೂರ್ಣಗೊಂಡ ಕಾರ್ಯದ ವೆಚ್ಚ ಮತ್ತು ಮಾನವ ಹಸ್ತಕ್ಷೇಪದ ಅಗತ್ಯವಿರುವ ಪ್ರಮಾಣವನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಿ. ಯಶಸ್ಸಿನ ದರಗಳಿಗೆ ಮಾದರಿ ಗಾತ್ರಗಳು ಮತ್ತು ಅನಿಶ್ಚಿತತೆಯ ಮಧ್ಯಂತರಗಳನ್ನು ವರದಿ ಮಾಡಿ.