ಇಂಟರ್ನೆಟ್ ಈ ವರ್ಷವನ್ನು ಏಜೆಂಟ್ಗಳ ವರ್ಷ ಎಂದು ನಿರ್ಧರಿಸಿದೆ. ಪ್ರತಿಯೊಂದು ಎಂಜಿನಿಯರಿಂಗ್ ರೋಡ್ಮ್ಯಾಪ್ನಲ್ಲೂ LangGraph, CrewAI, ಮತ್ತು AutoGen ಎಂಬ ಹೆಸರುಗಳು ಕೇಳಿಬರುತ್ತಿವೆ. ತಂಡಗಳು ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಲೇಯರ್ಗಳನ್ನು (orchestration layers) ಸ್ಟ್ರೆಸ್-ಟೆಸ್ಟ್ ಮಾಡುತ್ತಿವೆ, ಸ್ಟೇಟ್ ಮೆಷಿನ್ಗಳು (state machines) ಮತ್ತು ರೋಲ್-ಪ್ಲೇ (role-play) ನಡುವೆ ಚರ್ಚಿಸುತ್ತಿವೆ, ಮತ್ತು ಯಾವ ಲೈಬ್ರರಿಯು ಅಂತಿಮವಾಗಿ ಲಾರ್ಜ್ ಲ್ಯಾಂಗ್ವೇಜ್ ಮಾಡೆಲ್ಗಳನ್ನು (LLMs) ಸ್ವಾಯತ್ತಗೊಳಿಸುತ್ತದೆ (autonomous) ಎಂದು ಯೋಚಿಸುತ್ತಿವೆ.
ಇಲ್ಲಿ ಒಂದು ಅಹಿತಕರ ಸತ್ಯವಿದೆ: ಆ ಹೋಲಿಕೆಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವು ಅವಧಿಗೂ ಮುನ್ನವೇ ಮಾಡಲಾದವು. ಫ್ರೇಮ್ವರ್ಕ್ಗಳು ಕಷ್ಟದ ಭಾಗವಲ್ಲ. ಕಷ್ಟದ ಭಾಗವೆಂದರೆ ನಾವು ನಮ್ಮ ಪದಗಳನ್ನು ಸರಿಯಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿರುವುದು. ಈಗ ಜನರು ಎಲ್ಲವನ್ನೂ ಏಜೆಂಟ್ ಎಂದು ಕರೆಯುತ್ತಿದ್ದಾರೆ. ಒಂದು ಟೂಲ್ ಕಾಲ್ (tool call) ಏಜೆಂಟ್ ಅಲ್ಲ. ಒಂದು ಚಾಟ್ಬಾಟ್ ಏಜೆಂಟ್ ಅಲ್ಲ. ಅಸ್ಪಷ್ಟವಾದ ಅಂತಹ ವ್ಯಾಖ್ಯಾನವು ನೇರವಾಗಿ ಕೆಟ್ಟ ಎಂಜಿನಿಯರಿಂಗ್, ಅತಿಯಾದ ಸಿಸ್ಟಮ್ ನಿರ್ಮಾಣ (overbuilt systems) ಮತ್ತು ಉತ್ಪಾದನಾ ವಿಘ್ನಗಳಿಗೆ (production outages) ಕಾರಣವಾಗುತ್ತದೆ, ಇವುಗಳನ್ನು ಒಂದು ಸರಳ ಸ್ಕ್ರಿಪ್ಟ್ ಮೂಲಕ ತಪ್ಪಿಸಬಹುದಾಗಿತ್ತು.
ನೀವು ಫ್ರೇಮ್ವರ್ಕ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಮೊದಲು, ನೀವು ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದೀರಿ ಎಂಬುದನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿ.
ಏಜೆಂಟ್ ಎಂದರೆ ವಾಸ್ತವವಾಗಿ ಏನು
ಏಜೆಂಟ್ ಅನ್ನು ಅದು ಚಲಾಯಿಸುವ ಮಾಡೆಲ್ ಅಥವಾ ಅದು ಮಾಡುವ API ಕಾಲ್ಗಳ ಸಂಖ್ಯೆಯಿಂದ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗುವುದಿಲ್ಲ. ಏಜೆಂಟ್ ಅನ್ನು ಅದರ ನಡವಳಿಕೆಯಿಂದ (behavior) ವ್ಯಾಖ್ಯಾನಿಸಲಾಗುತ್ತದೆ. ಅದಕ್ಕೆ ಸ್ಪಷ್ಟವಾದ ಉದ್ದೇಶವಿರಬೇಕು. ಮನುಷ್ಯ ಮೊದಲೇ ಹಾದಿಯನ್ನು ನಿರ್ಧರಿಸುವ ಬದಲು, ಮುಂದಿನ ಹಂತ ಯಾವುದು ಎಂಬುದನ್ನು ಅದು ತಾನೇ ನಿರ್ಧರಿಸಬೇಕು. ಆ ಹಂತವು ವಿಫಲವಾದಾಗ ಅದು ವೈಫಲ್ಯವನ್ನು ನಿಭಾಯಿಸಬೇಕು. ಮತ್ತು ಯಾವಾಗ ನಿಲ್ಲಿಸಬೇಕು ಎಂಬುದು ಅದಕ್ಕೆ ತಿಳಿದಿರಬೇಕು.
ಒಂದು ಸಪೋರ್ಟ್ ಸಿಸ್ಟಮ್ ಬಗ್ಗೆ ಯೋಚಿಸಿ; ಅದು ಬರುವ ಇಮೇಲ್ ಅನ್ನು ಓದುತ್ತದೆ, ಅದನ್ನು ರಿಫಂಡ್ ವಿನಂತಿಯೆಂದು ವರ್ಗೀಕರಿಸುತ್ತದೆ, ಆರ್ಡರ್ ಸಂಖ್ಯೆಯನ್ನು ಹೊರತೆಗೆಯುತ್ತದೆ, ಶಿಪ್ಪಿಂಗ್ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಪ್ರಶ್ನಿಸುತ್ತದೆ, ರಿಟರ್ನ್ ಪಾಲಿಸಿ ಅವಧಿಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ, ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸಿದ್ಧಪಡಿಸುತ್ತದೆ ಮತ್ತು ಟಿಕೆಟ್ ಪರಿresolved ಎಂದು ಗುರುತಿಸುತ್ತದೆ. ಡೇಟಾಬೇಸ್ ಟೈಮ್ ಔಟ್ ಆದರೆ, ಅದು ಕಾಯುತ್ತದೆ ಮತ್ತು ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಪಾಲಿಸಿ ವಿಂಡೋ ಅಸ್ಪಷ್ಟವಾಗಿದ್ದರೆ, ಅದು ಮನುಷ್ಯನ ಗಮನಕ್ಕೆ ತರುತ್ತದೆ. ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಕಳುಹಿಸಿದಾಗ, ಅದು ನಿಲ್ಲುತ್ತದೆ. ಅದುವೇ ಏಜೆಂಟ್. JSON ಅನ್ನು ಹಿಂತಿರುಗಿಸುವ ಕೇವಲ ಒಂದು LLM ಕಾಲ್ ಸುತ್ತಲಿನ ವ್ರ್ಯಾಪರ್ (wrapper) ಏಜೆಂಟ್ ಅಲ್ಲ, ಮಾರ್ಕೆಟಿಂಗ್ ತಂಡವು ಅದರ ಮೇಲೆ ಎಷ್ಟೇ "ಏಜೆಂಟ್" ಸ್ಟಿಕ್ಕರ್ಗಳನ್ನು ಹಾಕಿದರೂ ಸಹ.
ಈ ವ್ಯತ್ಯಾಸವು ಮುಖ್ಯವಾಗಿದೆ ಏಕೆಂದರೆ ಸಂಕೀರ್ಣತೆಗೆ ಒಂದು ಬೆಲೆ ಇರುತ್ತದೆ. ಸ್ವಾಯತ್ತತೆಯ ಅಗತ್ಯವಿಲ್ಲದ ಸಿಸ್ಟಮ್ ಅದಕ್ಕಾಗಿ ಬೆಲೆ ತೆರಬಾರದು.
ಪ್ರೊಡಕ್ಷನ್ AI ನ ನೈಜ ರೂಪ
ಪ್ರಸ್ತುತ ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ಚಲಿಸುತ್ತಿರುವ ಹೆಚ್ಚಿನ AI ಸಿಸ್ಟಮ್ಗಳು ನಿರ್ದಿಷ್ಟ ವ್ಯಾಪ್ತಿಯಲ್ಲಿವೆ (narrow). ಅವು ಒಂದು ಕೆಲಸವನ್ನು ಚೆನ್ನಾಗಿ ಮಾಡುತ್ತವೆ. ಅವು ಸಪೋರ್ಟ್ ಟಿಕೆಟ್ಗಳನ್ನು ಕ್ಯೂಗಳಿಗೆ ವರ್ಗೀಕರಿಸುತ್ತವೆ. ಸ್ಕ್ಯಾನ್ ಮಾಡಿದ ದಾಖಲೆಗಳಿಂದ ಎಕ್ಸ್ಪೈರಿ ದಿನಾಂಕಗಳನ್ನು ಹೊರತೆಗೆಯುತ್ತವೆ. ಗ್ರಾಹಕರ ಪ್ರಶ್ನೆಗಳನ್ನು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ನಾಲೇಜ್ ಬೇಸ್ ಲೇಖನಗಳೊಂದಿಗೆ ಹೊಂದಿಸುತ್ತವೆ. ಅವು ಸಾಮಾನ್ಯ ತರ್ಕದ ಇಂಜಿನ್ಗಳಲ್ಲ (general reasoning engines), ಮತ್ತು ಅವುಗಳಂತೆ ನಟಿಸುವುದು ಅತಿಯಾದ ಓವರ್-ಎಂಜಿನಿಯರಿಂಗ್ಗೆ (overengineering) ಕಾರಣವಾಗುತ್ತದೆ.
ಇದು ಮಾಡೆಲ್ ಬಿಡುಗಡೆಗಳ ಬಗ್ಗೆ ವಿನಾಶಕಾರಿ ವ್ಯಾಮೋಹಕ್ಕೂ ಕಾರಣವಾಗುತ್ತದೆ. ಅಸಮರ್ಪಕ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಹೊಸ ಫೌಂಡೇಶನ್ ಮಾಡೆಲ್ ಸರಿಪಡಿಸುತ್ತದೆ ಎಂದು ಭಾವಿಸಿ ತಂಡಗಳು ಹೊಸ ಮಾಡೆಲ್ಗಳ ಹಿಂದೆ ಬೀಳುತ್ತವೆ. ಅದು ಸಾಧ್ಯವಿಲ್ಲ. ದೋಷ ನಿರ್ವಹಣೆ ಇಲ್ಲದ (no error handling) ದುರ್ಬಲ ಲೂಪ್ನಲ್ಲಿ ಚಲಿಸುವ ಹೆಚ್ಚು ಸಾಮರ್ಥ್ಯವುಳ್ಳ ಮಾಡೆಲ್, ಕೇವಲ ಹೆಚ್ಚಿನ ಆತ್ಮವಿಶ್ವಾಸದೊಂದಿಗೆ ಮತ್ತು ಹೆಚ್ಚು ಸೃಜನಾತ್ಮಕ ಭ್ರಮೆಗಳೊಂದಿಗೆ (hallucinations) ವಿಫಲವಾಗುತ್ತದೆ. ಬೆಂಚ್ಮಾರ್ಕ್ಗಳ ಹಿಂದೆ ಬೀಳುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ರಚನೆಯನ್ನು (structure) ಹುಡುಕಲು ಪ್ರಾರಂಭಿಸಿ.
ಫ್ರೇಮ್ವರ್ಕ್ ಎಂಬುದು ಉತ್ಪನ್ನವಲ್ಲ
LangGraph ನಿಮಗೆ ಸ್ಪಷ್ಟವಾದ ಸ್ಟೇಟ್ ಮೆಷಿನ್ಗಳು ಮತ್ತು ಸೈಕಲ್ಗಳನ್ನು ನೀಡುತ್ತದೆ. CrewAI ಏಜೆಂಟ್ಗಳು ಪರ್ಸೋನಾಗಳನ್ನು (personas) ಅಳವಡಿಸಿಕೊಳ್ಳುವ ರೋಲ್-ಬೇಸ್ಡ್ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಅನ್ನು ಬಳಸುತ್ತದೆ. AutoGen ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಪರಸ್ಪರ ಚಾಟ್ ಮಾಡುವ ಕನ್ವರ್ಸೇಷನಲ್ ಏಜೆಂಟ್ಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತದೆ. ಇವೆಲ್ಲವೂ ಸಾಮರ್ಥ್ಯವುಳ್ಳ ಪರಿಕರಗಳಾಗಿವೆ. ಅವು ಕಂಟ್ರೋಲ್ ಫ್ಲೋಗೆ (control flow) ಮೂಲಭೂತವಾಗಿ ವಿಭಿನ್ನವಾದ ವಿಧಾನಗಳಾಗಿವೆ.
ಆದರೆ ನೀವು ಆಯ್ಕೆ ಮಾಡುವ ಫ್ರೇಮ್ವರ್ಕ್ ಗಿಂತ ಅದರೊಳಗೆ ನೀವು ಅನುಸರಿಸುವ ಮಾದರಿಗಳು (patterns) ಹೆಚ್ಚು ಮುಖ್ಯವಾಗಿವೆ. ಗಡಿಗಳನ್ನು (boundaries) ಗೌರವಿಸುವುದರಿಂದ ಕೇವಲ Python ಮತ್ತು Redis ಬಳಸಿ ಅತ್ಯಂತ ಭದ್ರವಾದ ಆಟೊಮೇಷನ್ ಅನ್ನು ವಿತರಿಸುವ ತಂಡಗಳನ್ನು ನಾನು ನೋಡಿದ್ದೇನೆ. ಫ್ರೇಮ್ವರ್ಕ್ ಅನ್ನು ಡಿಸೈನ್ನ ಪರ್ಯಾಯವಾಗಿ ಪರಿಗಣಿಸಿದ್ದರಿಂದ, ಅದ್ದೂರಿ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ನ ಭಾರಕ್ಕೆ ಕುಸಿದುಹೋದ ಇತರ ತಂಡಗಳನ್ನು ನಾನು ನೋಡಿದ್ದೇನೆ.
ನಿಮ್ಮ ಹ್ಯಾಂಡ್ಆಫ್ಗಳು (handoffs) ಅಸ್ಪಷ್ಟವಾಗಿದ್ದರೆ, ನಿಮ್ಮ ಟೂಲ್ಗಳು ದುರ್ಬಲವಾಗಿದ್ದರೆ ಮತ್ತು ನಿಮ್ಮ ರಿಟ್ರೈ ಲಾಜಿಕ್ (retry logic) ಇಲ್ಲದಿದ್ದರೆ, ನಿಮ್ಮ requirements.txt ನಲ್ಲಿರುವ ಲೋಗೋ ನಿಮ್ಮನ್ನು ಉಳಿಸಲಾರದು.
ವಾಸ್ತವವಾಗಿ ನಿಮ್ಮ ಸಮಯಕ್ಕೆ ಅರ್ಹವಾದ ಮೂರು ವಿಷಯಗಳು
ನೀವು ಏಜೆಂಟಿಕ್ ಸಿಸ್ಟಮ್ಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದರೆ, ನಿಮ್ಮ ಪ್ರಯತ್ನವನ್ನು ಈ ಮೂರು ಕ್ಷೇತ್ರಗಳಲ್ಲಿ ವಿನಿಯೋಗಿಸಿ.
ಟೂಲ್ ಡಿಸೈನ್ (Tool design). ನಿಮ್ಮ ಏಜೆಂಟ್ ಕರೆಯಬಹುದಾದ ಪ್ರತಿಯೊಂದು ಫಂಕ್ಷನ್ ಕೂಡ ಒಂದು ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಸುತ್ತುವರಿದ ಹೊಣೆಗಾರಿಕೆಯಾಗಿದೆ (liability). ಅವುಗಳನ್ನು ಬಿಗುವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಿ. ಇನ್ಪುಟ್ಗಳನ್ನು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ವ್ಯಾಲಿಡೇಟ್ ಮಾಡಿ. 500 ಎರರ್ ಡಂಪ್ಗಳ ಬದಲಿಗೆ, ಓದಲು ಸುಲಭವಾಗುವಂತಹ ಎರರ್ಗಳನ್ನು ಹಿಂತಿರುಗಿಸಿ. ಏನಾದರೂ ತಪ್ಪಾದಾಗ ಏಜೆಂಟ್ ತರ್ಕಬದ್ಧವಾಗಿ ಯೋಚಿಸಬಲ್ಲ ಒಂದು ಉತ್ತಮ ಟೂಲ್ ಎಂದರೆ ಅದುವೇ.
ಫೈಲ್ಯೂರ್ ಹ್ಯಾಂಡ್ಲಿಂಗ್ (Failure handling). ಪ್ರತಿಯೊಂದು LLM