Google ನ AI architecture guide ಮತ್ತು Anthropic ನ engineering blog ಸ್ವಾಯತ್ತ ಏಜೆಂಟ್ಗಳಿಗಾಗಿ (autonomous agents) "ReAct" loop ಅನ್ನು ಒಂದು ಮಾದರಿಯಾಗಿ ವಿವರಿಸುತ್ತವೆ. ಮಾದರಿಗೆ (model) ನಿಯಂತ್ರಣವನ್ನು ನೀಡುವ ಮೊದಲು ಡೆವಲಪರ್ಗಳು ವೆಚ್ಚ (cost), ವಿಳಂಬ (latency) ಮತ್ತು ದೋಷದ ಅಪಾಯವನ್ನು (error risk) ಪರಿಗಣಿಸಬೇಕು ಎಂದು ಅವು ಸೂಚಿಸುತ್ತವೆ. ಈ ಸಲಹೆಯು ಬಹಳ ಮುಖ್ಯ, ಏಕೆಂದರೆ ತಪ್ಪಾಗಿ ಆಯ್ಕೆ ಮಾಡಿದ ಏಜೆಂಟ್ ಕ್ಲೌಡ್ ಬಜೆಟ್ಗಳನ್ನು ಖಾಲಿ ಮಾಡಬಹುದು ಮತ್ತು ಪ್ರೊಡಕ್ಷನ್ ಸಿಸ್ಟಮ್ಗಳಲ್ಲಿ ಪತ್ತೆಹಚ್ಚಲು ಕಷ್ಟವಾಗುವ ದೋಷಗಳನ್ನು ಉಂಟುಮಾಡಬಹುದು.
ಪ್ರಾಯೋಗಿಕವಾಗಿ ReAct loop ಹೇಗಿರುತ್ತದೆ
ಈ ಲೂಪ್ ಮೂರು ಹಂತಗಳನ್ನು ಒಳಗೊಂಡಿದೆ:
- Thought (ಆಲೋಚನೆ) – ಮಾದರಿಯು ಪ್ರಸ್ತುತ ಕಾರ್ಯದ ಬಗ್ಗೆ ಯೋಚಿಸುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ಹಂತವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ.
- Action (ಕ್ರಮ) – ಇದು ಬಾಹ್ಯ ಪರಿಕರವನ್ನು (ಉದಾಹರಣೆಗೆ, ಒಂದು code-search API) ಬಳಸುತ್ತದೆ ಅಥವಾ ಅಂತಿಮ ಉತ್ತರವನ್ನು ನೀಡುತ್ತದೆ.
- Observation (ವೀಕ್ಷಣೆ) – ಇದು ಪರಿಕರದ ಔಟ್ಪುಟ್ ಅನ್ನು ಓದುತ್ತದೆ, ಫಲಿತಾಂಶವನ್ನು ತನ್ನ ನೆನಪಿನಲ್ಲಿ (memory) ಸಂಗ್ರಹಿಸುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ Thought ಗೆ ಬಳಸುತ್ತದೆ.
Anthropic ಈ ಇಡೀ ರಚನೆಯನ್ನು "autonomous agent" ಎಂದು ಕರೆಯುತ್ತದೆ; Google ಈ ಮೂಲ ಚಕ್ರವನ್ನು "ReAct" ಎಂದು ಹೆಸರಿಸುತ್ತದೆ. ಈ ವ್ಯತ್ಯಾಸವು ಸೂಕ್ಷ್ಮವಾಗಿದ್ದರೂ ನಿರ್ಣಾಯಕವಾಗಿದೆ: ಸಾಂಪ್ರದಾಯಿಕ ವರ್ಕ್ಫ್ಲೋನಲ್ಲಿ (workflow) ಡೆವಲಪರ್ನ ಕೋಡ್ ಕ್ರಮವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ಆದರೆ ಏಜೆಂಟ್ನಲ್ಲಿ ಮಾದರಿಯು (model) ನಿರ್ಧರಿಸುತ್ತದೆ.
ಮಾದರಿಯು ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಡೆಸಲು ಯಾವಾಗ ಬಿಡಬೇಕು
ಮುಕ್ತವಾದ ಸಮಸ್ಯೆಗಳು (Open-ended problems) ReAct ಶೈಲಿಯ ಏಜೆಂಟ್ಗಳಿಗೆ ಅತ್ಯುತ್ತಮವಾಗಿವೆ. ನೀವು ಮೊದಲೇ ಪ್ರತಿಯೊಂದು ಸಂಭವನೀಯ ಹಂತವನ್ನು ಪಟ್ಟಿ ಮಾಡಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಏಜೆಂಟ್ ಕ್ರಿಯಾಶೀಲವಾಗಿ (dynamically) ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು. ಸಾಮಾನ್ಯ ಬಳಕೆಯ ಸಂದರ್ಭಗಳು ಹೀಗಿವೆ:
- Code-fix bots – ಇವು ರೆಪೊಸಿಟರಿಯನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡಿ, ವಿಫಲವಾದ ಪರೀಕ್ಷೆಯನ್ನು ಪತ್ತೆಹಚ್ಚುತ್ತವೆ ಮತ್ತು ಬಿಲ್ಡ್ ಪಾಸಾಗುವವರೆಗೆ ಪದೇ ಪದೇ ಪ್ಯಾಚ್ಗಳನ್ನು ಅನ್ವಯಿಸುತ್ತವೆ.
- Robotic navigation – ವಾಹನವು ಅನಿರೀಕ್ಷಿತ ಅಡೆತಡೆಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಬೇಕಾದ ಮತ್ತು ತಕ್ಷಣವೇ ಮಾರ್ಗಗಳನ್ನು ಮರು-ಯೋಜಿಸಬೇಕಾದ ಸಂದರ್ಭಗಳು.
ಈ ಸನ್ನಿವೇಶಗಳಲ್ಲಿ ಪುನರಾವರ್ತನೆಗಳ (iterations) ಸಂಖ್ಯೆಯು ತಿಳಿದಿರುವುದಿಲ್ಲ, ಮತ್ತು ಹಂತಗಳನ್ನು ಮೊದಲೇ ಕೋಡ್ ಮಾಡುವುದು (hard-coding) ಅಸ್ಥಿರವಾಗಬಹುದು.
ವರ್ಕ್ಫ್ಲೋ ಯಾವಾಗ ಉತ್ತಮವಾಗಿರುತ್ತದೆ
ಹಂತಗಳು ಮುನ್ಸೂಚನೆ ನೀಡಬಹುದಾದಂತಿದ್ದರೆ (predictable), ಸಾಂಪ್ರದಾಯಿಕ ಪೈಪ್ಲೈನ್ ಉತ್ತಮವಾಗಿರುತ್ತದೆ. ಸ್ಥಿರವಾದ ಕ್ರಮಗಳು ಹೀಗಿವೆ:
- ಕಡಿಮೆ ವೆಚ್ಚ (Cheaper) – ಡಜನ್ಗಟ್ಟಲೆ ಬಾರಿ ನಡೆಯಬಹುದಾದ ಮಲ್ಟಿ-ಟರ್ನ್ ಲೂಪ್ಗಿಂತ ಒಂದೇ API ಕರೆಯು ಕಡಿಮೆ ವೆಚ್ಚದಾಯಕವಾಗಿರುತ್ತದೆ.
- ವೇಗ hơn (Faster) – ಪ್ರತಿ ಪುನರಾವರ್ತನೆಯೊಂದಿಗೆ ವಿಳಂಬ (latency) ಹೆಚ್ಚಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಒಮ್ಮೆಲೇ ಕೇಳುವ (one-shot query) ಪ್ರಶ್ನೆಯು ಬೇಗ ಮುಕ್ತಾಯವಾಗುತ್ತದೆ.
- ಪರಿಶೀಲಿಸಲು ಸುಲಭ (Easier to audit) – ನಿರ್ಧಾರಿತ ಕೋಡ್ ಹಾದಿಗಳು (deterministic code paths) ಪರೀಕ್ಷೆ ಮತ್ತು ಅನುಸರಣೆಯನ್ನು (compliance) ಸುಲಭಗೊಳಿಸುತ್ತವೆ.
ಬಲ್ಕ್ ಡೇಟಾ ವ್ಯಾಲಿಡೇಶನ್ ಅಥವಾ ದಿನನಿತ್ಯದ ವರದಿ ತಯಾರಿಕೆಯಂತಹ ಹೆಚ್ಚಿನ ಫ್ರೀಕ್ವೆನ್ಸಿ ಇರುವ ಸರಳ ಕಾರ್ಯಗಳಿಗೆ ಸ್ವಾಯತ್ತ ಏಜೆಂಟ್ಗಿಂತ ವರ್ಕ್ಫ್ಲೋವೇ ಸೂಕ್ತವಾಗಿದೆ.
ಸ್ವಾಯತ್ತತೆಯ ಅಡಗಿರುವ ವೆಚ್ಚಗಳು
ಸಮಸ್ಯೆ ಸೂಕ್ತವಾಗಿ ಕಂಡರೂ ಸಹ, ಡೆವಲಪರ್ಗಳು ಮೂರು ಪ್ರಾಯೋಗಿಕ ಅನಾನುಕೂಲಗಳಿಗಾಗಿ ಬಜೆಟ್ ಸಿದ್ಧಪಡಿಸಿಕೊಳ್ಳಬೇಕು:
- ಹೆಚ್ಚಿನ ಕಂಪ್ಯೂಟ್ ವೆಚ್ಚ (High compute expense) – ಪ್ರತಿ Thought-Action-Observation ಚಕ್ರವು ಮತ್ತೊಂದು ಮಾದರಿ ಇನ್ಫರೆನ್ಸ್ ಅನ್ನು ಬಳಸುತ್ತದೆ, ಇದು ಕ್ಲೌಡ್ ವೆಚ್ಚವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ.
- ಹೆಚ್ಚುವರಿ ವಿಳಂಬ (Added latency) – ಒಟ್ಟು ಪ್ರತಿಕ್ರಿಯೆಯ ಸಮಯವು ಮಾದರಿ ಮತ್ತು ಯಾವುದೇ ಬಾಹ್ಯ ಪರಿಕರಗಳಿಗೆ ಮಾಡುವ ಎಲ್ಲಾ ರೌಂಡ್-ಟ್ರಿಪ್ಗಳ ಮೊತ್ತವಾಗಿರುತ್ತದೆ.
- ದೋಷಗಳ ವೃದ್ಧಿ (Error amplification) – ಒಂದು ತಪ್ಪಾದ ವೀಕ್ಷಣೆ (observation) ಸರಣಿ ದೋಷಗಳನ್ನು ಉಂಟುಮಾಡಬಹುದು ಮತ್ತು ಸಂಪೂರ್ಣವಾಗಿ ತಪ್ಪು ಅಂತಿಮ ಉತ್ತರವನ್ನು ನೀಡಬಹುದು.
ಈ ಅಂಶಗಳು ಏಜೆಂಟ್ಗಳು ನೀಡುವ ಸೈದ್ಧಾಂತಿಕ ನಮ್ಯತೆಯನ್ನು (theoretical flexibility) ಕುಂದಿಸಬಹುದು.
ಡೆವಲಪರ್ಗಳಿಗಾಗಿ ಸುರಕ್ಷತಾ ಮಾರ್ಗಸೂಚಿ (Safety playbook)
ಸ್ವಾಯತ್ತ ಏಜೆಂಟ್ಗಳು ನಿಯಂತ್ರಣ ತಪ್ಪದಂತೆ ನೋಡಿಕೊಳ್ಳಲು, ಮೂರು ಸುರಕ್ಷತಾ ಕ್ರಮಗಳನ್ನು ಶಿಫಾರಸು ಮಾಡಲಾಗಿದೆ:
- ಪುನರಾವರ್ತನೆಗಳಿಗೆ ಮಿತಿ ಹಾಕಿ (Cap iterations) – ಏಜೆಂಟ್ ಅನಿಯಮಿತವಾಗಿ ಚಲಿಸದಂತೆ ಲೂಪ್ಗಳ ಗರಿಷ್ಠ ಸಂಖ್ಯೆಯನ್ನು ನಿರ್ಧರಿಸಿ.
- ದೃಢವಾದ ಟೂಲ್ ಇಂಟರ್ಫೇಸ್ಗಳಲ್ಲಿ ಹೂಡಿಕೆ ಮಾಡಿ – ಇಡೀ ವ್ಯವಸ್ಥೆಯ ವಿಶ್ವಾಸಾರ್ಹತೆಯು ಚತುರ ಪ್ರಾಂಪ್ಟಿಂಗ್ ಟ್ರಿಕ್ಸ್ (prompting tricks) ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರದೆ, ಸ್ಪಷ್ಟವಾದ ಮತ್ತು ಸರಿಯಾಗಿ ವಿವರಿಸಲಾದ API ಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ.
- ನಿಯೋಜನೆಗೆ ಮೊದಲು ಸ್ಯಾಂಡ್ಬಾಕ್ಸ್ ಮಾಡಿ (Sandbox before deployment) – ಕಟ್ಟುನಿಟ್ಟಾದ ಗಾರ್ಡ್ರೈಲ್ಗಳೊಂದಿಗೆ ಪ್ರತ್ಯೇಕ ಪರಿಸರದಲ್ಲಿ ಏಜೆಂಟ್ಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ, ಅನಿರೀಕ್ಷಿತ ಟೂಲ್ ಕರೆಗಳು ಅಥವಾ ನಿಯಂತ್ರಣ ತಪ್ಪಿದ ಲೂಪ್ಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ.
ಈ ಮಾರ್ಗಸೂಚಿಯನ್ನು ಅನುಸರಿಸುವುದರಿಂದ ಸಂಕೀರ್ಣವಾಗುತ್ತಿರುವ ದೋಷಗಳನ್ನು ಮೊದಲೇ ಪತ್ತೆಹಚ್ಚಲು ಮತ್ತು ವೆಚ್ಚದ ಮಿತಿಗಳನ್ನು ಜಾರಿಗೆ ತರಲು ಸುಲಭವಾಗುತ್ತದೆ.
ಪ್ರಾಯೋಗಿಕವಾಗಿ ಆಗುವ ಹೊಂದಾಣಿಕೆ (The trade-off)
ReAct ಶೈಲಿಯ ಏಜೆಂಟ್ ಮತ್ತು ಸ್ಕ್ರಿಪ್ಟ್ ಮಾಡಲಾದ ವರ್ಕ್ಫ್ಲೋ ನಡುವೆ ಆಯ್ಕೆ ಮಾಡುವುದು ಸಮಸ್ಯೆ ಮುಕ್ತವಾಗಿದೆಯೇ ಅಥವಾ ಮುನ್ಸೂಚನೆ ನೀಡಬಹುದಾದಂತಿದೆಯೇ ಎಂಬ ಅಂಶದ ಮೇಲೆ ಮತ್ತು ವೆಚ್ಚ, ವಿಳಂಬ ಮತ್ತು ದೋಷದ ಅಪಾಯದ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ.
ಸಾರಾಂಶ (Bottom line): ನಿಮಗೆ ಅಡಾಪ್ಟಿವ್ ರೀಸನಿಂಗ್ (adaptive reasoning) ಅಗತ್ಯವಿದ್ದಾಗ ಮತ್ತು ಪ್ರತಿಯೊಂದು ಕ್ರಮವನ್ನು ಮೊದಲೇ ನಿರ್ಧರಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದಾಗ ReAct ಏಜೆಂಟ್ಗಳು ಅತ್ಯುತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ, ಆದರೆ ಅವು ಹೆಚ್ಚಿನ ವೆಚ್ಚ, ನಿಧಾನಗತಿಯ ಪ್ರತಿಕ್ರಿಯೆ ಮತ್ತು ಸೂಕ್ಷ್ಮ ದೋಷಗಳ ಹೆಚ್ಚಿನ ಸಾಧ್ಯತೆಯನ್ನು ತರುತ್ತವೆ. ಶಿಸ್ತುಬದ್ಧವಾದ ವಿಧಾನ—ಸ್ಪಷ್ಟವಾದ ನಿಲುಗಡೆ ನಿಯಮಗಳು, ದೃಢವಾದ ಟೂಲ್ ಕಾಂಟ್ರಾಕ್ಟ್ಗಳು ಮತ್ತು ಸ್ಯಾಂಡ್ಬಾಕ್ಸ್ ಪರೀಕ್ಷೆ—ಆ ಶಕ್ತಿಯನ್ನು ಬಜೆಟ್ ಸೋರಿಕೆಯ ಬದಲಿಗೆ ನಿಯಂತ್ರಿತ ಆಸ್ತಿಯನ್ನಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.