I used to think building an AI agent was basically the same as prompting a chatbot. You frame the question well, the mod

AI ಏಜೆಂಟ್ ನಿರ್ಮಿಸುವುದು ಎಂಬುದು ಚಾಟ್‌ಬಾಟ್‌ಗೆ ಪ್ರಾಂಪ್ಟ್ ನೀಡಿದಂತೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತಿದ್ದೆ. ನೀವು ಪ್ರಶ್ನೆಯನ್ನು ಸರಿಯಾಗಿ ರೂಪಿಸಿದರೆ, ಮಾಡೆಲ್ ಉತ್ತರಿಸುತ್ತದೆ, ಅಷ್ಟೇ ಎಂದು ಅಂದುಕೊಂಡಿದ್ದೆ. ನಂತರ ನಾನು ಕೆಲವು ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದೆ. ಆಗ ವಾಸ್ತವವು ಕಠಿಣವಾಗಿ ಎದುರಾಯಿತು. ಒಂದು LLM ಏಜೆಂಟ್ ಅಲ್ಲ. ಒಂದು LLM ಕೇವಲ ಮುಂದಿನ ಟೋಕನ್ ಅನ್ನು ಊಹಿಸುತ್ತದೆ. ಆ 'ಲೂಪ್' (loop) ಅಥವಾ ಚಕ್ರವೇ ಏಜೆಂಟ್ ಅನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.

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

ಏಜೆನ್ಸಿಯನ್ನು (Agency) ಸೃಷ್ಟಿಸುವ ಚಕ್ರ

ಈ ಲೂಪ್ ಎಂಬುದು ಕೇವಲ ಒಂದು ಅಮೂರ್ತ ಸಿದ್ಧಾಂತವಲ್ಲ. ಇದು ನಿಮ್ಮ ಪರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಯಾವುದೇ ವ್ಯವಸ್ಥೆಯ ಕಾರ್ಯಾಚರಣೆಯ ಹೃದಯಬಡಿತವಾಗಿದೆ. ಪ್ರಾಯೋಗಿಕವಾಗಿ ಇದು ಹೀಗೆಯೇ ಇರುತ್ತದೆ:

• Think (ಯೋಚಿಸಿ): ಮಾಡೆಲ್ ಗುರಿಯ ಬಗ್ಗೆ ಯೋಚಿಸುತ್ತದೆ ಮತ್ತು ಅದಕ್ಕೆ ಏನು ಬೇಕು ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. ಬಳಕೆದಾರರು, "ನಾಳೆ ಪೋರ್ಟ್ಲೆಂಡ್‌ಗೆ ನಾನು ಛತ್ರಿ ತರಬೇಕೇ?" ಎಂದು ಕೇಳಿದರೆ, ಅದಕ್ಕೆ ಹವಾಮಾನ ವರದಿ ಮತ್ತು ಸ್ಥಳದ ಮಾಹಿತಿ ಬೇಕೆಂದು ಮಾಡೆಲ್ ಗುರುತಿಸುತ್ತದೆ.
• Act (ಕಾರ್ಯಗತಗೊಳಿಸಿ): ಮಾಡೆಲ್ ಒಂದು ಟೂಲ್ ಅನ್ನು ಬಳಸುತ್ತದೆ. ಅದು "Portland" ಎಂಬ ಸ್ಥಳವನ್ನು ಗುರುತಿಸಲು geocoding API ಅನ್ನು ಬಳಸಬಹುದು, ನಂತರ ಆ ಅಕ್ಷಾಂಶ ಮತ್ತು ರೇಖಾಂಶಗಳೊಂದಿಗೆ (coordinates) ಹವಾಮಾನ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗೆ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಬಹುದು.
• Observe (ಗಮನಿಸಿ): ಮಾಡೆಲ್ ಟೂಲ್‌ನ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಓದುತ್ತದೆ. API ನಿಂದ JSON ಹವಾಮಾನ ವರದಿಯೇ ಬಂದಿದೆ, 403 ಎರರ್ ಬಂದಿದೆಯೇ ಅಥವಾ HTML ಮೇಂಟೆನೆನ್ಸ್ ಪೇಜ್ ಬಂದಿದೆಯೇ?
• Update (ನವೀಕರಿಸಿ): ಕಂಡದ್ದರ ಆಧಾರದ ಮೇಲೆ, ಮಾಡೆಲ್ ತನ್ನ ಯೋಜನೆಯನ್ನು ಪರಿಷ್ಕರಿಸುತ್ತದೆ. ಒಂದು ವೇಳೆ ಜಿಯೋಕೋಡರ್ ಪೋರ್ಟ್ಲೆಂಡ್, ಒರೆಗನ್ ಬದಲಿಗೆ ಪೋರ್ಟ್ಲೆಂಡ್, ಮೇನ್ ಅನ್ನು ನೀಡಿದರೆ, ಮಾಡೆಲ್ ಅದನ್ನು ಸ್ಪಷ್ಟಪಡಿಸಿಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ. ಒಂದು ವೇಳೆ API ಕೆಲಸ ಮಾಡುತ್ತಿಲ್ಲದಿದ್ದರೆ, ಅದು ಪರ್ಯಾಯ ಮೂಲವನ್ನು ಬಳಸಬಹುದು ಅಥವಾ ಬಳಕೆದಾರರನ್ನು ಕೇಳಬಹುದು.
• Think Again (ಮತ್ತೆ ಯೋಚಿಸಿ): ಹೊಸ ಸಂದರ್ಭದೊಂದಿಗೆ ಚಕ್ರವು ಮತ್ತೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.

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

ಎಲ್ಲಾ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳು ಒಂದೇ ರೀತಿ ಏಕೆ ಕಾಣಿಸುತ್ತವೆ?

ನೀವು LangGraph, CrewAI, ಅಥವಾ AutoGen ಬಳಸಿದ್ದರೆ, ಅವುಗಳು ಒಂದೇ ರೀತಿ ಕಾಣಿಸುತ್ತವೆ ಎಂದು ನೀವು ಗಮನಿಸಿರಬಹುದು. LangGraph ಹರಿವನ್ನು (flow) ನೋಡ್‌ಗಳು ಮತ್ತು ಎಡ್ಜ್‌ಗಳ ನಿರಂತರ ಗ್ರಾಫ್ ಆಗಿ ಮಾಡೆಲ್ ಮಾಡುತ್ತದೆ. CrewAI ಏಜೆಂಟ್‌ಗಳನ್ನು ಪಾತ್ರಗಳು ಮತ್ತು ಕ್ರೂಗಳಾಗಿ (crews) ಸಂಘಟಿಸುತ್ತದೆ. AutoGen ಮಲ್ಟಿ-ಏಜೆಂಟ್ ಸಂಭಾಷಣೆಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಪ್ಯಾಕೇಜಿಂಗ್ ವಿಭಿನ್ನವಾಗಿರಬಹುದು, ಆದರೆ ಅಸ್ಥಿಪಂಜರ (skeleton) ಒಂದೇ.

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

ಈ ಫ್ರವೇರ್‌ಕಗಳು ಲೂಪ್ ಮೇಲೆ ಗಮನ ಕೇಂದ್ರೀಕರಿಸುತ್ತವೆ ಏಕೆಂದರೆ ಏಜೆನ್ಸಿ ಎಂಬುದು ಅಲ್ಲಿಯೇ ಇರುತ್ತದೆ. ಅಡಿಪಾಯದ ಮಾಡೆಲ್ GPT-4, Claude ಅಥವಾ ಫೈನ್-ಟ್ಯೂನ್ ಮಾಡಿದ ಓಪನ್-ವೇಟ್ ಮಾಡೆಲ್ ಆಗಿರಬಹುದು. ಲೂಪ್ ಇಲ್ಲದಿದ್ದರೆ, ನಿಮ್ಮ ಬಳಿ ಕೇವಲ ಒಂದು ದುಬಾರಿ ವಾಕ್ಯ ಪೂರ್ಣಗೊಳಿಸುವ ಸಾಧನವಿರುತ್ತದೆ. ಲೂಪ್ ಇದ್ದರೆ, ನಿಮ್ಮ ಬಳಿ ಅನೇಕ ಪ್ರಯತ್ನಗಳ ಮೂಲಕ ಒಂದು ಗುರಿಯನ್ನು ತಲುಪಬಲ್ಲ ವ್ಯವಸ್ಥೆ ಇರುತ್ತದೆ.

ನಿಜವಾದ ಕೆಲಸ ಯಾವಾಗ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ

ಲೋಕಲ್ ಡೆಮೋಗಳು ಅದ್ಭುತವಾಗಿ ಕಾಣಿಸಬಹುದು. ಆದರೆ ಪ್ರೊಡಕ್ಷನ್ ಎಂದರೆ ಮ್ಯಾಜಿಕ್ ಮತ್ತು ಗೊಂದಲಗಳು ಎದುರಾಗುವ ಸ್ಥಳ. ನೀವು ಪ್ರೊಟೊಟೈಪಿಂಗ್ ಹಂತವನ್ನು ದಾಟಿದ ನಂತರ, ನೀವು AI ಸಮಸ್ಯೆಗಳನ್ನು ಬಿಟ್ಟು ಸಿಸ್ಟಮ್ಸ್ ಇಂಜಿನಿಯರಿಂಗ್ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತೀರಿ.

ಟೂಲ್ ವೈಫಲ್ಯಗಳು ಅನಿವಾರ್ಯ. APIs ಟೈಮ್ ಔಟ್ ಆಗಬಹುದು. ಅವು ತಪ್ಪಾದ JSON ಅನ್ನು ನೀಡಬಹುದು ಅಥವಾ HTML ಒಳಗೊಂಡಿರುವ 500 ಎರರ್‌ಗಳನ್ನು ನೀಡಬಹುದು. ನಿಮ್ಮ ಲೂಪ್ ಪ್ರತಿಯೊಂದು ಟೂಲ್ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಕುರುಡಾಗಿ ನಂಬಿದರೆ, ನಿಮ್ಮ ಏಜೆಂಟ್ ಯಶಸ್ಸನ್ನು ಹ್ಯಾಲ್ಯುಸಿನೇಟ್ ಮಾಡಬಹುದು ಅಥವಾ ಗೊಂದಲದಲ್ಲಿ ಸಿಲುಕಬಹುದು. ನಿಮಗೆ ಪ್ರತಿ ರಿಟರ್ನ್ ಪೇಲೋಡ್ ಮೇಲೆ ರಿಟ್ರೈ ಲಾಜಿಕ್ (retry logic), ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕರ್‌ಗಳು (circuit breakers) ಮತ್ತು ಸ್ಕೀಮಾ ವ್ಯಾಲಿಡೇಶನ್ (schema validation) ಅಗತ್ಯವಿದೆ.

ಮೆಮೊರಿ ಹಳೆಯದಾಗುತ್ತದೆ (Memory goes stale). ಬಳಕೆದಾರರ ನೆಚ್ಚಿನ ಡೇಟಾಬೇಸ್ PostgreSQL ಎಂದು ನಿಮ್ಮ ಏಜೆಂಟ್‌ಗೆ ನೆನಪಿರುತ್ತದೆ, ಆದರೆ ಇನ್ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್ ತಂಡವು ನಿನ್ನೆ ರಾತ್ರಿ ಹೊಸ ಕ್ಲಸ್ಟರ್‌ಗೆ ಸ್ಥಳಾಂತರ ಮಾಡಿರಬಹುದು. ಸಂದರ್ಭವನ್ನು ನವೀಕರಿಸಲು ಅಥವಾ ಅಪ್ರಸ್ತುತಗೊಳಿಸಲು ಯಾವುದೇ ವ್ಯವಸ್ಥೆ ಇಲ್ಲದಿದ್ದರೆ, ಏಜೆಂಟ್ ತಪ್ಪು ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳ ವಿರುದ್ಧ ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ಕಮಾಂಡ್‌ಗಳನ್ನು ನೀಡುತ್ತದೆ. ಮೆಮೊರಿ ಇರಲಿ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ಗಳು, ಕಾನ್ಫಿಡೆನ್ಸ್ ಸ್ಕೋರ್‌ಗಳು ಮತ್ತು ತನ್ನ ಮಾಹಿತಿಯನ್ನು ತಾನೇ ಅಸಿಂಧುಗೊಳಿಸುವ ಸಾಮರ್ಥ್ಯ.

ಅನಂತ ಲೂಪ್‌ಗಳು (Infinite loops) ಮೌನ ಕೊಲೆಗಾರರು. ಏಜೆಂಟ್ ವೆಬ್‌ನಲ್ಲಿ ಹುಡುಕುತ್ತದೆ, ಯಾವುದೂ ಉಪಯುಕ್ತವಾಗಿ ಸಿಗುವುದಿಲ್ಲ, ಕ್ವೆರಿಯನ್ನು ಸ್ವಲ್ಪ ಬದಲಾಯಿಸಿ ಮತ್ತೆ ಹುಡುಕುತ್ತದೆ, ಮತ್ತೆ ಏನೂ ಸಿಗುವುದಿಲ್ಲ ಮತ್ತು ಇದೇ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತದೆ. ಗರಿಷ್ಠ ಇಟರೇಶನ್ ಮಿತಿ ಅಥವಾ ಸೆಮ್ಯಾಂಟಿಕ್ ಡೂಪ್ಲಿಕೇಟ್ ಡಿಟೆಕ್ಷನ್ ಇಲ್ಲದಿದ್ದರೆ, ಬಳಕೆದಾರರು ಕಾಯುತ್ತಿರುವಾಗ ಅದು ಟೋಕನ್‌ಗಳನ್ನು ಮತ್ತು ಹಣವನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ. ನೀವು ಗಾರ್ಡ್‌ರೈಲ್‌ಗಳನ್ನು (guardrails) ನಿರ್ಮಿಸಬೇಕು: ರಿಟ್ರೈಗಳಿಗೆ ಕಟ್ಟುನಿಟ್ಟಾದ ಮಿತಿ, ಡೈವರ್ಜೆನ್ಸ್ ಚೆಕ್‌ಗಳು ಮತ್ತು ಮಾನವ ಹಸ್ತಕ್ಷೇಪದ ಮಾರ್ಗಗಳು (human escalation paths).

ಅಪ್ರಸ್ತುತ ಮಾಹಿತಿಯು ತರ್ಕವನ್ನು ಕುಗ್ಗಿಸುತ್ತದೆ. Retrieval-Augmented Generation ಪೈಪ್‌ಲೈನ್‌ಗಳು ಹೆಚ್ಚಾಗಿ ಐವತ್ತು ಪ್ಯಾರಾಗ್ರಾಫ್‌ಗಳ ಅಸ್ಪಷ್ಟವಾಗಿ ಸಂಬಂಧಿಸಿದ ದಾಖಲೆಗಳನ್ನು context window ಗೆ ಹಾಕುತ್ತವೆ. ಇದರಿಂದಾಗಿ ಏಜೆಂಟ್ ಗೊಂದಲಕ್ಕೀಡಾಗಿ ತಪ್ಪು ಸಾಧನವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ ಅಥವಾ ತಪ್ಪು ಪ್ಯಾರಾಮೀಟರ್ ಅನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ (hallucinates). ಮಾದರಿಯು (model) ಹುಡುಕಿದ ಪಠ್ಯವನ್ನು ನೋಡುವ ಮೊದಲೇ ನಿಮಗೆ ಫಿಲ್ಟರಿಂಗ್, ಶ್ರೇಣಿೀಕರಣ ಮತ್ತು ಸಂಕ್ಷಿಪ್ತ ಸಾರಾಂಶದ ಅಗತ್ಯವಿದೆ.

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

ಕೆಲಸವನ್ನು ಪೂರ್ಣಗೊಳಿಸುವುದು

ಏಜೆಂಟ್‌ಗಳಲ್ಲಿನ ನಿಜವಾದ ಬುದ್ಧಿವಂತಿಕೆಯು ಮೊದಲ ಉತ್ತರವನ್ನು ಸರಿಯಾಗಿ ನೀಡುವುದರಲ್ಲಿ ಇಲ್ಲ. ಬದಲಾಗಿ, ಏನೂ ಯೋಜನೆಯಂತೆ ನಡೆಯದಿದ್ದಾಗ, ಉದ್ದೇಶ ಮತ್ತು ಫಲಿತಾಂಶದ ನಡುವಿನ ಅಂತರವನ್ನು ಹೇಗೆ ನಿಭಾಯಿಸುತ್ತೇವೆ ಎಂಬುದರಲ್ಲಿದೆ. ಮೊದಲ ಪ್ರಯತ್ನ ಸುಲಭ. ಯಾರೇ ಆದರೂ ಒಂದು ಸರಳ ಹಾದಿಯನ್ನು (happy path) ಸ್ಕ್ರಿಪ್ಟ್ ಮಾಡಬಹುದು. ಕಷ್ಟದ ಭಾಗವೆಂದರೆ ನಾಲ್ಕನೇ ಪುನರಾವರ್ತನೆ (iteration); ಅಂದರೆ ಪ್ರೈಮರಿ API ಸ್ಥಗಿತಗೊಂಡಾಗ, context window ಕುಗ್ಗುತ್ತಿರುವಾಗ, ಬಳಕೆದಾರರು ತಾಳ್ಮೆ ಕಳೆದುಕೊಳ್ಳುತ್ತಿರುವಾಗ ಮತ್ತು ಏಜೆಂಟ್ ಆಗರೂ ಸಹ ಉಪಯುಕ್ತವಾದದ್ದನ್ನು ನೀಡಬೇಕಾದ ಸಂದರ್ಭದಲ್ಲಿ.

ಆ ಛಲವೇ ಒಂದು ಡೆಮೋ ಮತ್ತು ಉತ್ಪನ್ನದ ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ತಿಳಿಸುತ್ತದೆ. ಇದು ಪ್ರತಿ ಹಂತದಿಂದ ಕಲಿಯುವ ಸಾಮರ್ಥ್ಯವಾಗಿದೆ; ಇದನ್ನು ಮಾಡುವುದು model weights ಅನ್ನು ನೈಜ ಸಮಯದಲ್ಲಿ ಅಪ್‌ಡೇಟ್ ಮಾಡುವ ಮೂಲಕ ಅಲ್ಲ, ಬದಲಾಗಿ ಯೋಜನೆಯನ್ನು ಅಪ್‌ಡೇಟ್ ಮಾಡುವ ಮೂಲಕ. ತಂತ್ರಗಳು ಬದಲಾಗುತ್ತಿದ್ದರೂ ಏಜೆಂಟ್ ತನ್ನ ಗುರಿಯನ್ನು ಸ್ಥಿರವಾಗಿರಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಇದೇ ಲೂಪಿಂಗ್ ತತ್ವದ ಕಾರ್ಯವೈಖರಿ.

ಹಾಗಾದರೆ ಭವಿಷ್ಯವು ದೊಡ್ಡ ಮಾದರಿಗಳಿಗೆ ಸೇರಿದ್ದೇ ಅಥವಾ ಉತ್ತಮ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಲೂಪ್‌ಗಳಿಗೆ ಸೇರಿದ್ದೇ? ಸ್ಕೇಲ್ ಖಂಡಿತವಾಗಿಯೂ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಹೆಚ್ಚು ಸಾಮರ್ಥ್ಯವಿರುವ ಮಾದರಿಯು ಪ್ರತಿ ಚಕ್ರದಲ್ಲಿ ಉತ್ತಮವಾಗಿ ತರ್ಕ ಮಾಡುತ್ತದೆ. ಆದರೆ ಒಂದು ಬಿಗಿಯಾದ, ವೀಕ್ಷಿಸಬಹುದಾದ ಮತ್ತು ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವವಿರುವ (resilient) ಲೂಪ್‌ನೊಳಗೆ ಚಲಿಸುವ ಸಣ್ಣ ಮಾದರಿಯು, ಎಲ್ಲವನ್ನೂ ಒಂದೇ ಬಾರಿಗೆ ಪರಿಹರಿಸಲು ಕೇಳಲಾದ ಬೃಹತ್ ಮಾದರಿಗಿಂತ ಯಾವಾಗಲೂ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಊಹನೆಯನ್ನು ಕ್ರಿಯೆಯನ್ನಾಗಿ ಪರಿವರ್ತಿಸುವುದು ಈ ಲೂಪ್ ಆಗಿದೆ. ಅಲ್ಲಿ ಹೂಡಿಕೆ ಮಾಡಿ.

ಮೂಲ: The Looping Principle: A Simple Mental Model for Understanding AI Agents

ಇಂತಹ ಹೆಚ್ಚಿನ ಚರ್ಚೆಗಳಿಗಾಗಿ, GyaanSetu learning community on Telegram ಗೆ ಸೇರಿ.