ಏಜೆಂಟ್ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸಲು ಪ್ರಯತ್ನಿಸುವ ಹೆಚ್ಚಿನ AI ತಂಡಗಳು ಒಂದೇ ಸಾಧನಗಳನ್ನು ಆಶ್ರಯಿಸುತ್ತವೆ: ದೊಡ್ಡ ಕಾನ್ಟೆಕ್ಸ್ಟ್ ವಿಂಡೋಗಳು, ಹೆಚ್ಚಿನ ದಾಖಲೆಗಳು ಮತ್ತು ಹೆಚ್ಚು ಚುರುಕಾದ ಪ್ರಾಂಪ್ಟ್ಗಳು. ಅದು ಸಂಪೂರ್ಣವಾಗಿ ತಪ್ಪಾದ ಪ್ರವೃತ್ತಿ ಎಂಬುದು ಈ ಲೇಖನದ ವಾದ. ಕೊರತೆಯಿರುವ ಅಂಶ ಹೆಚ್ಚಿನ ಮಾಹಿತಿಯಲ್ಲ. ಅದು ನಿಯಂತ್ರಣ. ಪ್ರಾತ್ಯಕ್ಷಿಕೆಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಏಜೆಂಟ್ ಮತ್ತು ಉತ್ಪಾದನಾ ಪರಿಸರದಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಏಜೆಂಟ್ ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ಉತ್ತಮವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಿದ ನಿಯಂತ್ರಣ ಪದರವೇ ರೂಪಿಸುತ್ತದೆ.
AI ಏಜೆಂಟ್ಗೆ ದೊಡ್ಡ ಮೆಮೊರಿ, ಹೆಚ್ಚಿನ ದಾಖಲೆಗಳು ಅಥವಾ ದೀರ್ಘ ಕಾನ್ಟೆಕ್ಸ್ಟ್ ವಿಂಡೋ ನೀಡುವುದರಿಂದ ಅದು ಚುರುಕಾಗುವುದಿಲ್ಲ. ಬದಲಿಗೆ ನಿಧಾನವಾಗುತ್ತದೆ ಮತ್ತು ಹೆಚ್ಚು ವೆಚ್ಚವಾಗುತ್ತದೆ. ಎಲ್ಲವನ್ನೂ ಒಮ್ಮೆಯೇ ಬಳಸುವ ಬದಲು, ತನಗೆ ಏನು ಮತ್ತು ಯಾವಾಗ ಬೇಕು ಎಂಬುದನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಏಜೆಂಟ್ಗೆ ಕಲಿಸುವುದರಿಂದ ನಿಜವಾದ ಸುಧಾರಣೆ ದೊರೆಯುತ್ತದೆ.
ವಿಶ್ವಾಸಾರ್ಹತೆ ಆವರ್ತನದಿಂದ ಬರುತ್ತದೆ, ಮಾಡೆಲ್ನಿಂದಲ್ಲ. ಪ್ರಾತ್ಯಕ್ಷಿಕೆಯಲ್ಲಿ ಮೆಚ್ಚಿಸುವ ಏಜೆಂಟ್ ಮತ್ತು ಉತ್ಪಾದನಾ ಪರಿಸರದಲ್ಲಿ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಏಜೆಂಟ್ ನಡುವಿನ ವ್ಯತ್ಯಾಸವು AI ಗುಣಮಟ್ಟದಲ್ಲಿಲ್ಲ. ವ್ಯವಸ್ಥೆಯು ತನ್ನ ಕೆಲಸವನ್ನು ತಾನೇ ಪರಿಶೀಲಿಸುತ್ತದೆಯೇ ಎಂಬುದರಲ್ಲಿದೆ. ಪ್ರತಿ ಹಂತದಲ್ಲೂ ಯೋಜಿಸಿ, ಕಾರ್ಯನಿರ್ವಹಿಸಿ, ಗಮನಿಸಿ ಮತ್ತು ಪರಿಶೀಲಿಸುವ ಏಜೆಂಟ್ಗಳು ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ತಪ್ಪು ಮಾಡುವ ಬದಲು ತಮ್ಮ ತಪ್ಪುಗಳನ್ನು ತಾವೇ ಪತ್ತೆಹಚ್ಚುತ್ತವೆ.
ಇಂದಿನ ಹೆಚ್ಚಿನ AI ಏಜೆಂಟ್ಗಳು ಮೂಲತಃ ಹೆಚ್ಚುವರಿ ಹಂತಗಳನ್ನು ಹೊಂದಿರುವ ಚಾಟ್ಬಾಟ್ಗಳು. ತಾವು ಸರಿಯಾದ ದಾರಿಯಲ್ಲಿದ್ದೇವೆಯೇ, ಯಾವಾಗ ನಿಲ್ಲಿಸಬೇಕು ಅಥವಾ ಯಾವಾಗ ಬೇರೆ ವಿಧಾನ ಪ್ರಯತ್ನಿಸಬೇಕು ಎಂದು ತಿಳಿಯುವ ಯಾವುದೇ ಕಾರ್ಯವಿಧಾನ ಅವುಗಳಿಗಿಲ್ಲ. ಸ್ಪಷ್ಟ ಯಶಸ್ಸಿನ ಮಾನದಂಡಗಳು, ರಚನಾತ್ಮಕ ಸ್ಥಿತಿ ಮತ್ತು ಮೌಲ್ಯೀಕರಣ ಪರಿಶೀಲನೆಗಳಂತಹ ಸೂಕ್ತ ನಿಯಂತ್ರಣ ಪದರವನ್ನು ಸೇರಿಸುವುದರಿಂದಲೇ ಏಜೆಂಟ್ನಂತೆ ಕಾಣುವ ವಸ್ತು ನಿಜವಾಗಿಯೂ ನಂಬಬಹುದಾದ ವ್ಯವಸ್ಥೆಯಾಗುತ್ತದೆ.
ನಿನ್ನೆ ಮಧ್ಯಾಹ್ನದ ಊಟಕ್ಕೆ ನೀವು ಏನು ತಿಂದಿರಿ?
“ನಿನ್ನೆ + ಮಧ್ಯಾಹ್ನದ ಊಟ” ಸಿಗುವವರೆಗೆ ನಿಮ್ಮ ಪ್ರತಿಯೊಂದು ನೆನಪನ್ನೂ ಬಹುಶಃ ಮರುಪ್ರಸಾರ ಮಾಡಿರಲಿಲ್ಲ. ಆ ಪರಿಕಲ್ಪನೆಗಳು ಇರುವ ನಿಮ್ಮ ಅನುಭವದ ಭಾಗಕ್ಕೆ ನೇರವಾಗಿ ಹೋದಿರಿ. ಏಜೆಂಟ್ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಇದು ಉಪಯುಕ್ತವಾದ ಮಾನಸಿಕ ಮಾದರಿ:
ಬೃಹತ್ ಕಾನ್ಟೆಕ್ಸ್ಟ್ ವಿಂಡೋ ಮೆಮೊರಿಯಲ್ಲ.
ಹಿಂಪಡೆದ ದಾಖಲೆಗಳ ರಾಶಿ ಅರ್ಥಗ್ರಹಿಕೆಯಲ್ಲ.
ದೀರ್ಘ ಚೈನ್-ಆಫ್-ಥಾಟ್ ವಿಶ್ವಾಸಾರ್ಹತೆಯಲ್ಲ.
ಅವು ಕೇವಲ ಪದಾರ್ಥಗಳು. ಆದರೆ ಏಜೆಂಟ್ ಅನ್ನು ನಿಜವಾದ ಏಜೆಂಟ್ನಂತೆ ಭಾಸವಾಗುವಂತೆ ಮಾಡುವ ಅಂಶವೇ ನಿಮ್ಮ ಮೆದುಳು ಇಡೀ ಜೀವನದ ಇತಿಹಾಸವನ್ನು ಕಠಿಣವಾಗಿ ಹುಡುಕದಂತೆ ಮಾಡುತ್ತದೆ: ನಿಯಂತ್ರಣ.
ಇತ್ತೀಚಿನ ಬೃಹತ್ ಭಾಷಾ ಮಾಡೆಲ್ಗಳಿಗಾಗಿ ಏಜೆಂಟೀಯ ರೀಜನಿಂಗ್ ಸಮೀಕ್ಷೆಯು ನಿರ್ಮಾಣದ ವೇಳೆ ನಮ್ಮಲ್ಲಿ ಹಲವರು ಅನುಭವಿಸುತ್ತಿದ್ದ ಬದಲಾವಣೆಯನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿ ಸಾರಾಂಶಗೊಳಿಸಿ ಹೆಸರಿಸಿದೆ: ಮಾಡೆಲ್ನ ಒಳಗಿನ ರೀಜನಿಂಗ್ನಿಂದ ಸಂವಹನದ ಮೂಲಕ ರೀಜನಿಂಗ್ಗೆ ಬದಲಾವಣೆ. ಈ ಲೇಖನವು ಆ ಸಂಶೋಧನಾ ಪ್ರಬಂಧದ ಸಾರಾಂಶವಲ್ಲ. ಆ ಬದಲಾವಣೆಯನ್ನು ಪ್ರಾಯೋಗಿಕ ವ್ಯವಸ್ಥೆ ವಿನ್ಯಾಸವಾಗಿ ರೂಪಿಸುವ ಪ್ರಯತ್ನವಿದು:
ಏಜೆಂಟ್ಗಳನ್ನು ಸಾಧನಗಳನ್ನು ಹೊಂದಿರುವ ಚಾಟ್ಬಾಟ್ಗಳಂತೆ ನಿರ್ಮಿಸಿದರೆ, ಚಾಟ್ಬಾಟ್ ವೈಫಲ್ಯಗಳೇ ಮುಂದುವರಿಯುತ್ತವೆ. ಆದರೆ ತಪ್ಪುಗಳು ಹೆಚ್ಚು ದುಬಾರಿಯಾಗಿರುತ್ತವೆ.
ಕೆಲಕಾಲ “ಮಾಡೆಲ್ ಅನ್ನು ಹೆಚ್ಚು ಚುರುಕಾಗಿಸುವ” ನಮ್ಮ ಪೂರ್ವನಿಯೋಜಿತ ಕಾರ್ಯತಂತ್ರವು ಮೂಲತಃ ಉತ್ತಮ ಪ್ರಾಂಪ್ಟ್ಗಳು, ಚೈನ್-ಆಫ್-ಥಾಟ್, ಸ್ವಯಂ-ಸ್ಥಿರತೆ / ಮಾದರಿ ಆಯ್ಕೆ ಆಧಾರಿತ ಸುಧಾರಣೆಗಳು ಮತ್ತು ಬಹುಶಃ ಸ್ವಲ್ಪ ಹುಡುಕಾಟವಾಗಿತ್ತು.
ReAct ಒಂದು ಮಹತ್ವದ ತಿರುವಾಗಿತ್ತು, ಏಕೆಂದರೆ ಅದು “ಆಲೋಚನೆ → ಕ್ರಿಯೆ → ಅವಲೋಕನ”ವನ್ನು ಸಹಜವಾಗಿ ಕಾಣುವಂತೆ ಮಾಡಿತು. ಆದರೆ ಅಡಗಿರುವ ನಿರ್ಬಂಧವನ್ನು ಗಮನಿಸಿ: ಇದರಲ್ಲಿ ಬಹಳಷ್ಟು ಇನ್ನೂ “ಹೆಚ್ಚಿನ ಟೋಕನ್ಗಳನ್ನು ಬಳಸುವ ವನ್-ಶಾಟ್ ನಿರ್ಣಯ”ವಾಗಿಯೇ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ. ಸಮೀಕ್ಷೆಯ ನಿರೂಪಣೆ ಹೆಚ್ಚು ನಿಖರವಾಗಿದೆ: ಏಜೆಂಟೀಯ ರೀಜನಿಂಗ್ ಪರೀಕ್ಷಾ-ಸಮಯದ ಸಂವಹನವನ್ನು ವಿಸ್ತರಿಸುವುದಕ್ಕೆ ಒತ್ತು ನೀಡುತ್ತದೆ. ಅಂದರೆ ಮಾಡೆಲ್, ಮೆಮೊರಿ ಮತ್ತು ಪರಿಸರ ಎಲ್ಲವೂ ಆವರ್ತನದಲ್ಲೇ ಉಳಿಯುವ ಪುನರಾವರ್ತಿತ ಪ್ರಕ್ರಿಯೆಯಾಗಿ ನಿರ್ಣಯವನ್ನು ಪರಿವರ್ತಿಸುತ್ತದೆ.
ಪ್ರಾತ್ಯಕ್ಷಿಕೆಯಲ್ಲಿ ಪ್ರಭಾವಶಾಲಿಯಾಗಿ ಕಂಡರೂ ನೈಜ ಕಾರ್ಯಪ್ರವಾಹಗಳಲ್ಲಿ ದುರ್ಬಲವಾಗಿರುವ ಏಜೆಂಟ್ಗಳನ್ನು ನೀವು ನಿರ್ಮಿಸಿದ್ದರೆ ಅಥವಾ ಬಳಸಿದ್ದರೆ, ಇದು ನಿಮಗಾಗಿ.
ನಾನು ಹೆಚ್ಚಾಗಿ ನೋಡಿರುವ ಮತ್ತು ಸ್ವತಃ ಹಲವು ಆವೃತ್ತಿಗಳನ್ನು ನಿರ್ಮಿಸಿರುವ ಒಂದು ಮಾದರಿಯನ್ನು ವಿವರಿಸುತ್ತೇನೆ:
ಉತ್ತಮ ಚಾಟ್ ಮಾಡೆಲ್ ತೆಗೆದುಕೊಳ್ಳಿ
ಕೆಲವು ಸಾಧನಗಳನ್ನು ಸೇರಿಸಿ. ಉದಾಹರಣೆಗೆ ಹುಡುಕಾಟ, DB ಪ್ರಶ್ನೆ ಮತ್ತು ಬಹುಶಃ ಸಂಕೇತ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ
RAG ಸೇರಿಸಿ
“ನೀವು ಸ್ವಾಯತ್ತ ಏಜೆಂಟ್” ಎಂಬ ವ್ಯವಸ್ಥೆಯ ಪ್ರಾಂಪ್ಟ್ ಸೇರಿಸಿ
ಅದು ನಿಲ್ಲುವವರೆಗೆ ಅಥವಾ ಸಮಯ ಮೀರುವವರೆಗೆ ಎಲ್ಲವನ್ನೂ ಪುನರಾವರ್ತನಾ ಆವರ್ತನದಲ್ಲಿ ಸುತ್ತಿ
ಅಭಿನಂದನೆಗಳು, ಈಗ ನಿಮ್ಮ ಬಳಿ ಏಜೆಂಟ್ನಂತೆ ಕಾಣುವ ವಸ್ತುವಿದೆ. ಆದರೆ ಅದು ಸಾಮಾನ್ಯವಾಗಿ ಊಹಿಸಬಹುದಾದ ರೀತಿಗಳಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ:
ಸಂದರ್ಭದ ಉಬ್ಬರ: ಪ್ರತಿಯೊಂದು ಅವಲೋಕನವನ್ನೂ ಸೇರಿಸಲಾಗುತ್ತದೆ. ಪ್ರಾಂಪ್ಟ್ಗಳು ಪುರಾತತ್ವದ ಪದರಗಳಂತಾಗುತ್ತವೆ.
ಸಾಧನಗಳ ಅಸಮರ್ಪಕ ಬಳಕೆ: “ತಪ್ಪು ಸಾಧನವನ್ನು ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ಬಳಸುವುದು” ಪೂರ್ವನಿಯೋಜಿತ ವೈಫಲ್ಯವಾಗುತ್ತದೆ.
ನಿಲ್ಲಿಸುವ ಷರತ್ತುಗಳಿಲ್ಲ: ನಿಲ್ಲಿಸಬೇಕಾದ ಅಗತ್ಯವಿಲ್ಲವೆಂಬ ಕಾರಣಕ್ಕಲ್ಲ, ಮುಂದುವರಿಯಲು ಸಾಧ್ಯವೆಂಬ ಕಾರಣಕ್ಕೆ ಅದು ಮುಂದುವರಿಯುತ್ತದೆ.
ಗ್ರೌಂಡಿಂಗ್ ಶಿಸ್ತು ಇಲ್ಲ: ನೀವು ಒತ್ತಾಯಿಸದ ಹೊರತು ತಾನು ತಪ್ಪು ಮಾಡಿರುವುದನ್ನು ಅದು ಗುರುತಿಸುವುದಿಲ್ಲ.
ಮೆಮೊರಿ = ಚಾಟ್ ಇತಿಹಾಸ: ಇದು ಮೂಲತಃ ದಾಖಲೆಗಳನ್ನು ಬರೆದು ಅದನ್ನು ಕಲಿಕೆ ಎಂದು ಕರೆಯುವುದಷ್ಟೇ.
ಆದ್ದರಿಂದಲೇ “ಏಜೆಂಟ್ಗಳು” ಪ್ರಾತ್ಯಕ್ಷಿಕೆಯಲ್ಲಿ ಮಾಂತ್ರಿಕವಾಗಿ, ಉತ್ಪಾದನಾ ಪರಿಸರದಲ್ಲಿ ಅವ್ಯವಸ್ಥಿತವಾಗಿ ಕಾಣುತ್ತವೆ. ಏಜೆಂಟೀಯ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಉತ್ಪಾದನಾ ಪರಿಸರದಲ್ಲಿ ಅಳವಡಿಸಿದ ನಮ್ಮ ಅನುಭವವೂ ಇದನ್ನೇ ತೋರಿಸುತ್ತದೆ: ನೀವು ಮಾಡೆಲ್ ಬದಲು ವ್ಯವಸ್ಥೆಯನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ಆರಂಭಿಸಿದಾಗ, ವೈಫಲ್ಯದ ವಿಧಾನಗಳಲ್ಲಿ ಸಂಚರಣೆ, ಸಾಧನಗಳ ಶಿಸ್ತುಬದ್ಧ ಬಳಕೆ, ಸಂದರ್ಭದ ಕಡಿತ ಮತ್ತು ಮೌಲ್ಯಮಾಪನ ವಿನ್ಯಾಸವೂ ಸೇರಿರುತ್ತವೆ. ಕೇವಲ “ಮಾಡೆಲ್ ಸರಿಯಾಗಿ ಉತ್ತರಿಸಿತೇ” ಎಂಬುದಲ್ಲ.
ಹಾಗಾದರೆ ಪ್ರಶ್ನೆ ಹೀಗಿದೆ: ಉದ್ದೇಶಿತ ಏಜೆಂಟ್ ಎಂದರೇನು?
ಇದನ್ನು ಹೆಚ್ಚು ಸ್ಪಷ್ಟಗೊಳಿಸಲು, ಬಹುತೇಕರು ಊಹಿಸಬಹುದಾದ ಸರಳ ಕಾರ್ಯಪ್ರವಾಹ ಇಲ್ಲಿದೆ: “ಮುಂದಿನ ಮಂಗಳವಾರ ಲಂಡನ್ನಿಂದ ನ್ಯೂಯಾರ್ಕ್ಗೆ ನನಗಾಗಿ ವಿಮಾನ ಟಿಕೆಟ್ ಕಾಯ್ದಿರಿಸಿ. ಸಂಜೆ 6 ಗಂಟೆಯೊಳಗೆ ತಲುಪಬೇಕು. ವೆಚ್ಚ £900ಕ್ಕಿಂತ ಕಡಿಮೆ ಇರಲಿ. ನಡುಹಾದಿಯ ಪಕ್ಕದ ಆಸನ ಬೇಕು.”
ಸಾಮಾನ್ಯವಾಗಿ “ಏಜೆಂಟ್ನಂತೆ ಕಾಣುವ” ಅನುಷ್ಠಾನ ಹೀಗಿರುತ್ತದೆ:
ಇನ್ನೂ ಯಾವುದೂ ಅಗತ್ಯವಿಲ್ಲದಿದ್ದರೂ, ವಿಮಾನಯಾನ / ಪ್ರಯಾಣ ನೀತಿಯ ಹಲವಾರು ದಾಖಲೆಗಳನ್ನು ತಕ್ಷಣವೇ ಹಿಂಪಡೆಯುತ್ತದೆ.
ಹುಡುಕಾಟ ಸಾಧನಕ್ಕೆ ಕರೆ ಮಾಡಿ, ಫಲಿತಾಂಶಗಳ ದೊಡ್ಡ ಪಟ್ಟಿಯನ್ನು ಪ್ರಾಂಪ್ಟ್ಗೆ ಅಂಟಿಸಿ, “ಒಂದನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ.”
ನಿರ್ಬಂಧಗಳನ್ನು ಪರಿಶೀಲಿಸದೆ ಅವಸರವಾಗಿ ಕಾಯ್ದಿರಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ ಆಗಮನದ ಸಮಯ / ಸರಕು / ಆಸನ / ನೀತಿ.
ಅದು ವಿಫಲವಾದರೆ, ಸ್ವಲ್ಪ ವಿಭಿನ್ನವಾಗಿ ಮರುಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಆದರೆ ಏನು ಬದಲಾಯಿತು ಅಥವಾ ಏನು ಕಲಿಯಿತು ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿರುವುದಿಲ್ಲ.
ವೈಫಲ್ಯಕ್ಕೆ ಮಾಡೆಲ್ ರೀಜನಿಂಗ್ ಮಾಡಲು ಅಸಮರ್ಥವಾಗಿರುವುದು ಕಾರಣವಲ್ಲ. ಕಾರ್ಯಪ್ರವಾಹವನ್ನು ವ್ಯವಸ್ಥೆಯು ನಿಯಂತ್ರಿಸದಿರುವುದೇ ಕಾರಣ.
ಹೆಚ್ಚು ಏಜೆಂಟೀಯ ಆವೃತ್ತಿಯು ಕಾರ್ಯವನ್ನು ಸ್ಪಷ್ಟ ಸ್ಥಿತಿ ಮತ್ತು ಪರಿಶೀಲನೆಗಳನ್ನು ಹೊಂದಿರುವ ಸಂವಾದಾತ್ಮಕ ಪ್ರಕ್ರಿಯೆಯಾಗಿ ಪರಿಗಣಿಸುತ್ತದೆ:
ಯೋಜಿಸಿ: ನಿರ್ಬಂಧಗಳನ್ನು ಪುನರುಚ್ಚರಿಸಿ + ಕಾಣೆಯಾದ ಮಾಹಿತಿಯನ್ನು ಪಟ್ಟಿ ಮಾಡಿ. ಉದಾಹರಣೆಗೆ, “ಯಾವ ವಿಮಾನ ನಿಲ್ದಾಣಕ್ಕೆ ಆದ್ಯತೆ?” / “1 ಬಾರಿ ವಿಮಾನ ಬದಲಿಸುವುದು ಒಪ್ಪಿಗೆಯೇ?”.
ಕಾರ್ಯನಿರ್ವಹಿಸಿ: ರಚನಾತ್ಮಕ ಪ್ರಶ್ನೆಯೊಂದಿಗೆ ವಿಮಾನ ಹುಡುಕಾಟಕ್ಕೆ ಕರೆ ಮಾಡಿ. ಉದಾಹರಣೆಗೆ ದಿನಾಂಕದ ವ್ಯಾಪ್ತಿ, ಆಗಮನದ ನಿರ್ಬಂಧ ಮತ್ತು ಬಜೆಟ್.
ಗಮನಿಸಿ: ಫಲಿತಾಂಶಗಳನ್ನು ದೊಡ್ಡದಾಗಿ ಅಂಟಿಸಿದ ಪಠ್ಯದ ಬದಲು, ಸಂಕ್ಷಿಪ್ತ ಸ್ಥಿತಿ ವಸ್ತುವಿನಲ್ಲಿ ಸಂಗ್ರಹಿಸಿ. ಉದಾಹರಣೆಗೆ ಬೆಲೆ / ಆಗಮನ / ಮಧ್ಯಂತರ ನಿಲುಗಡೆಗಳೊಂದಿಗೆ ಅಗ್ರ 5 ಆಯ್ಕೆಗಳು.
ನವೀಕರಿಸಿ: ನಿರ್ಬಂಧಗಳು ಈಡೇರದಿದ್ದರೆ ಪ್ರಶ್ನೆಯನ್ನು ಪರಿಷ್ಕರಿಸಿ. ಉದಾಹರಣೆಗೆ, “ಸಂಜೆ 6 ಗಂಟೆಯೊಳಗಿನ ಆಗಮನ ತೀರಾ ಕಟ್ಟುನಿಟ್ಟಾಗಿದೆ. ಸಮಯದ ವ್ಯಾಪ್ತಿಯನ್ನು ವಿಸ್ತರಿಸಬೇಕೇ ಅಥವಾ ಬಜೆಟ್ ಹೆಚ್ಚಿಸಬೇಕೇ?”.
ಪರಿಶೀಲಿಸಿ: ಮೌಲ್ಯಮಾಪಕಗಳನ್ನು ಚಲಾಯಿಸಿ. “ಆಗಮನ < 18:00,” “ಬೆಲೆ ≤ £900,” “ನೀತಿಗೆ ಅನುಗುಣವಾಗಿದೆ,” “ಆಸನ ಆಯ್ಕೆ ಲಭ್ಯವಿದೆ.”
ನಿಲ್ಲಿಸಿ: ಕಾಯ್ದಿರಿಸುವಿಕೆ API ದೃಢೀಕರಣ ನೀಡಿದ ಮತ್ತು ಎಲ್ಲ ಮೌಲ್ಯಮಾಪಕಗಳು ಅಂಗೀಕರಿಸಿದ ನಂತರವಷ್ಟೇ ನಿಲ್ಲಿಸಿ.
ಬದಲಾವಣೆ ಸೂಕ್ಷ್ಮವಾದರೂ ನಿರ್ಣಾಯಕವಾಗಿದೆ. ಹಿಂಪಡೆಯುವಿಕೆ ಷರತ್ತುಬದ್ಧವಾಗಿದೆ, ಸಹಜ ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲ. ಸಂದರ್ಭವನ್ನು ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ, ಅಂದರೆ ಸ್ಥಿತಿ ರಚನಾತ್ಮಕವಾಗಿದ್ದು ಸಂಗ್ರಹವಾಗುತ್ತಲೇ ಇರುವುದಿಲ್ಲ. ಪರಿಶೀಲನೆಯು ಆವರ್ತನದಲ್ಲೇ ಇರುತ್ತದೆ, ಬಳಕೆದಾರರಿಗೆ ಬಿಟ್ಟಿರುವುದಿಲ್ಲ. “ವಿಮಾನ ಟಿಕೆಟ್ ಕಾಯ್ದಿರಿಸುವಿಕೆ” ಬದಲು “ಖರೀದಿ ಆದೇಶ ರಚಿಸುವುದು,” “ಮರುಪಾವತಿ ನೀಡುವುದು,” “ಉತ್ಪಾದನಾ ಸಂರಚನೆ ಬದಲಿಸುವುದು” ಅಥವಾ “PR ಬಿಡುಗಡೆ ಮಾಡುವುದು” ಎಂದುಕೊಂಡರೂ ಕಥೆ ಒಂದೇ: ಏಜೆಂಟ್ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಾದ ನಂತರ, ಪ್ರಾಂಪ್ಟ್ಗಿಂತ ಆವರ್ತನವೇ ಮುಖ್ಯವಾಗುತ್ತದೆ.
ಮೇಲೆ ಉಲ್ಲೇಖಿಸಿದ ಸಮೀಕ್ಷೆಯು ಏಜೆಂಟೀಯ ರೀಜನಿಂಗ್ ಅನ್ನು ಮೂರು ಪದರಗಳಾಗಿ ವಿಂಗಡಿಸುತ್ತದೆ: ಮೂಲಭೂತ (ಯೋಜನೆ / ಸಾಧನ ಬಳಕೆ / ಹುಡುಕಾಟ), ಸ್ವಯಂ-ವಿಕಸನ (ಪ್ರತಿಕ್ರಿಯೆ + ಮೆಮೊರಿ), ಮತ್ತು ಸಾಮೂಹಿಕ (ಬಹು-ಏಜೆಂಟ್ ಸಮನ್ವಯ).
ಆದರೆ ಇದರ ಆಳವಾದ ವಿಚಾರವೇನೆಂದರೆ, ರೀಜನಿಂಗ್ ಕೇವಲ ಸಂಭಾವ್ಯವಾದ ಚೈನ್-ಆಫ್-ಥಾಟ್ ರಚಿಸುವುದಕ್ಕೆ ಸೀಮಿತವಾಗದೆ ಯೋಜನೆ, ನಿರ್ಧಾರ ಕೈಗೊಳ್ಳುವಿಕೆ ಮತ್ತು ಪರಿಶೀಲನೆಯನ್ನು ಸಂಘಟಿಸುವ ತತ್ವವಾಗುತ್ತದೆ. ನಿಮ್ಮ ವಾಸ್ತುಶಿಲ್ಪದಲ್ಲಿ ಬದಲಾಗುವ ಅಂಶಗಳಿಗೆ ಇದನ್ನು ಅನ್ವಯಿಸುವವರೆಗೆ ಇದು ಅಮೂರ್ತವಾಗಿ ತೋರುತ್ತದೆ. ನೆನಪಿಡಬೇಕಾದ ಮೂರು ಪ್ರಮುಖ ಅಂಶಗಳಿವೆ:
ಉತ್ತಮ ಏಜೆಂಟ್ ಹಿಂಪಡೆಯುವಿಕೆಯನ್ನು “ಯಾವಾಗಲೂ ಮಾಡಬೇಕಾದ ಕೆಲಸ”ವೆಂದು ಪರಿಗಣಿಸಬಾರದು. ಹಿಂಪಡೆಯುವಿಕೆಯು ಒಂದು ನಿರ್ಧಾರ, ಸಹಜ ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲ.
ಪ್ರಾಯೋಗಿಕ ಅಂದಾಜು ನಿಯಮ ಇಲ್ಲಿದೆ:
ನಿಮ್ಮ ವ್ಯವಸ್ಥೆ ಪ್ರತಿ ಸರದಿಯಲ್ಲೂ ಮಾಹಿತಿಯನ್ನು ಹಿಂಪಡೆಯುತ್ತಿದ್ದರೆ, ನೀವು ಹಿಂಪಡೆಯುವಿಕೆಯನ್ನು ನಿರ್ಮಿಸಿಲ್ಲ. ಸಂದರ್ಭ ತೆರಿಗೆಯನ್ನು ನಿರ್ಮಿಸಿದ್ದೀರಿ.
ನೈಜ ಕೆಲಸದಲ್ಲಿ ಇದು ಯಾವಾಗಲೂ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಉತ್ಪಾದನಾ ಪರಿಸರದ ಘಟನೆಯನ್ನು ದೋಷನಿವಾರಣೆ ಮಾಡುವಾಗ, ಎಲ್ಲ ದಾಖಲೆಗಳನ್ನೂ ಸಂದರ್ಭಕ್ಕೆ ಸುರಿಯುವುದಿಲ್ಲ. ನಿಮ್ಮ ಪ್ರಸ್ತುತ ಊಹೆಯ ಆಧಾರದಲ್ಲಿ ಮುಂದೆ ಯಾವ ಮಾಪಕಗಳು / ದಾಖಲೆಗಳನ್ನು ಪಡೆಯಬೇಕೆಂದು ನಿರ್ಧರಿಸುತ್ತೀರಿ. ಅದೇ “ಏಜೆಂಟೀಯ ಹಿಂಪಡೆಯುವಿಕೆ.” ಇನ್ನಷ್ಟು ನಿರ್ದಿಷ್ಟವಾದ ಮಾದರಿ ಇಲ್ಲಿದೆ:
ಹಿಂಪಡೆಯುವಿಕೆ ಅಗತ್ಯವೇ ಎಂದು ನಿರ್ಧರಿಸಿ
ಹೌದಾದರೆ: ಪ್ರಶ್ನೆ ರೂಪಿಸಿ, ಪಡೆದುಕೊಳ್ಳಿ, ಮೇಲ್ನೋಟಕ್ಕೆ ಓದಿ, ಅಗತ್ಯಾಂಶ ಹೊರತೆಗೆಯಿರಿ
ಪುರಾವೆಗಳು ಪರಸ್ಪರ ವಿರುದ್ಧವಾಗಿದ್ದರೆ: ಮತ್ತೆ ಪಡೆದುಕೊಳ್ಳಿ
ಆನಂತರವಷ್ಟೇ ಸಂಶ್ಲೇಷಿಸಿ
ಇಲ್ಲಿಯೇ “ಏಜೆಂಟೀಯ RAG” ಸಾಂಪ್ರದಾಯಿಕ RAGಗಿಂತ ಭಿನ್ನವಾಗಲು ಆರಂಭಿಸುತ್ತದೆ: ಹಿಂಪಡೆಯುವಿಕೆಯು ಪೂರ್ವನಿಯೋಜಿತ ಕಾರ್ಯಸರಣಿಯ ಹಂತವಾಗಿರದೆ, ಉದ್ದೇಶಪೂರ್ವಕ ರೀಜನಿಂಗ್ ಹಂತವಾಗುತ್ತದೆ.
ನೀವು “ಮಾಡೆಲ್” ಅನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುವುದನ್ನು ಬಿಟ್ಟು “ವ್ಯವಸ್ಥೆ”ಯನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ಆರಂಭಿಸಿದ ಕ್ಷಣದಿಂದಲೇ, ಸ್ಥಿತಿಯ ಮೇಲ್ವಿಚಾರಣೆ ಮತ್ತು ಜಾಡುಹಿಡಿಯುವಿಕೆ ಮುಖ್ಯವಾಗುತ್ತವೆ.
ಏಜೆಂಟ್ ಕಾರ್ಯಪ್ರವಾಹಗಳ ವೀಕ್ಷಣೀಯತೆಯ ಬಗ್ಗೆ ಉದ್ಯಮ ಈಗ ಹೆಚ್ಚು ಸ್ಪಷ್ಟ ನಿಲುವು ತಳೆದಿದೆ. ಉದಾಹರಣೆಗೆ, OpenAIಯ ಏಜೆಂಟ್ಗಳ SDK ಅಂತರ್ನಿರ್ಮಿತ ಜಾಡುಹಿಡಿಯುವಿಕೆ ಮತ್ತು ಏಜೆಂಟ್ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ದಾಖಲಿಸುವ ಟ್ರೇಸಸ್ ಡ್ಯಾಶ್ಬೋರ್ಡ್ನೊಂದಿಗೆ ಬರುತ್ತದೆ. ಇದು ರಚನೆಗಳು, ಸಾಧನ ಕರೆಗಳು, ಹಸ್ತಾಂತರಗಳು, ಸುರಕ್ಷತಾ ನಿಯಮಗಳು ಮತ್ತು ಕಸ್ಟಮ್ ಘಟನೆಗಳನ್ನು ದಾಖಲಿಸುವುದರಿಂದ, ಏನಾಯಿತು ಎಂಬುದನ್ನು ಹಂತ ಹಂತವಾಗಿ ದೋಷನಿವಾರಣೆ ಮಾಡಿ ಲೆಕ್ಕಪರಿಶೋಧಿಸಬಹುದು.
ಅದು “ಇದ್ದರೆ ಚೆನ್ನಾಗಿರುತ್ತದೆ” ಎನ್ನುವ ಸೌಲಭ್ಯವಲ್ಲ. ದೋಷನಿವಾರಣೆ ಮಾಡಬಹುದಾದ ವ್ಯವಸ್ಥೆಗೂ, ಕೇವಲ ಮೇಲ್ನೋಟಕ್ಕೆ ಸರಿಯಿದೆಯೇ ಎಂದು ನೋಡಬಹುದಾದ ವ್ಯವಸ್ಥೆಗೂ ಇರುವ ವ್ಯತ್ಯಾಸವೇ ಅದು.
ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಪ್ರತಿಕ್ರಿಯೆಯ ಕುರಿತು ಸಮೀಕ್ಷೆ ನೇರವಾಗಿ ಹೇಳಿರುವ ವಿಷಯವೇ ಅದರ ಅತ್ಯಂತ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಭಾಗವಾಗಿದೆ. ಅದು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಮೂರು ವಿಧಾನಗಳಾಗಿ ವಿಂಗಡಿಸುತ್ತದೆ: ಆತ್ಮಾವಲೋಕನದ ಪ್ರತಿಕ್ರಿಯೆ (ರಚಿಸಿ → ವಿಮರ್ಶಿಸಿ → ಪರಿಷ್ಕರಿಸಿ), ನಿಯತಾಂಕ ಹೊಂದಾಣಿಕೆ (ಸೂಕ್ಷ್ಮ ಹೊಂದಾಣಿಕೆ / RL ಮೂಲಕ ಕಲಿಕೆ), ಮತ್ತು ಮೌಲ್ಯಮಾಪಕ-ಚಾಲಿತ ಪ್ರತಿಕ್ರಿಯೆ (ಮೌಲ್ಯಮಾಪಕವು ಅಂಗೀಕರಿಸುವವರೆಗೆ ಮರುಪ್ರಯತ್ನ).
ಹೆಚ್ಚಿನ ತಂಡಗಳು ಮೌಲ್ಯಮಾಪಕ-ಚಾಲಿತ ಪ್ರತಿಕ್ರಿಯೆಯಿಂದ ಆರಂಭಿಸಬೇಕು, ಏಕೆಂದರೆ ಅದು ರೋಚಕವಲ್ಲದಿದ್ದರೂ ಪರಿಣಾಮಕಾರಿ. ಘಟಕ ಪರೀಕ್ಷೆ ನಡೆಸುವ, ಸ್ಕೀಮಾ ಪರಿಶೀಲಿಸುವ, ವ್ಯವಹಾರ ನಿಯಮಗಳು / ನಿರ್ಬಂಧಗಳನ್ನು ವಿಧಿಸುವ (“ಮೇಲಧಿಕಾರಿಗೆ ಕಳುಹಿಸದೆ Xಗಿಂತ ಹೆಚ್ಚಿನ ಮರುಪಾವತಿ ಬೇಡ”) ಅಥವಾ ವಾಸ್ತವಿಕತೆಯನ್ನು ಖಚಿತಪಡಿಸುವ (“ಉಲ್ಲೇಖಗಳು ಕಡ್ಡಾಯ”) ಯಾವುದೇ ಮೌಲ್ಯಮಾಪಕವನ್ನು ಬರೆಯಲು ಸಾಧ್ಯವಾದರೆ, ಅನಿರ್ಧಾರಿತ ಮಾಡೆಲ್ ಫಲಿತಾಂಶವನ್ನು ನಿಜವಾಗಿಯೂ ನಂಬಬಹುದಾದ ರೂಪಕ್ಕೆ ಪರಿವರ್ತಿಸಬಹುದು.
ಇಲ್ಲಿನ “ತಿಳಿದಿಲ್ಲವೆಂಬುದೂ ತಿಳಿಯದ” ಬದಲಾವಣೆಗಳಲ್ಲಿ ಒಂದು ಸರಳವಾಗಿದೆ: ಏಜೆಂಟ್ಗಳ ಜಗತ್ತಿನಲ್ಲಿ ವಿಶ್ವಾಸಾರ್ಹತೆ ಸಾಮಾನ್ಯವಾಗಿ ಮಾಡೆಲ್ಗಿಂತಲೂ ಹೆಚ್ಚು ಆವರ್ತನದಿಂದ ಬರುತ್ತದೆ.
ತರಬೇತಿಯಿಲ್ಲದೆಯೇ ನಡವಳಿಕೆಯನ್ನು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಸುಧಾರಿಸುವ, ನಾನು ಕಂಡುಕೊಂಡ ಅತ್ಯಂತ ಸರಳ ಆವರ್ತನ ಶಿಸ್ತು ಹೀಗಿದೆ:
ಹಂತಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸಿ: ಯೋಜಿಸಿ → ಕಾರ್ಯನಿರ್ವಹಿಸಿ → ಗಮನಿಸಿ → ನವೀಕರಿಸಿ.
ಪ್ರತಿ ಕ್ರಿಯೆಯ ನಂತರ, ಗಮನಿಸಿದ್ದನ್ನು 1–3 ಅಂಶಗಳಲ್ಲಿ ಸಾರಾಂಶಗೊಳಿಸಿ.
ಯಶಸ್ಸಿನ ಮಾನದಂಡಗಳು ಈಡೇರಿದಾಗ ಅಥವಾ ಬಜೆಟ್ ಮಿತಿ ತಲುಪಿದಾಗ ನಿಲ್ಲಿಸಿ. ಲಭ್ಯವಿರುವ ಅತ್ಯುತ್ತಮ ಫಲಿತಾಂಶ ಮತ್ತು ಉಳಿದ ಅನಿಶ್ಚಿತತೆಗಳನ್ನು ನೀಡಿ.
ಇದು ಮಾಡೆಲ್ ಹೆಚ್ಚು ವಿವರವಾಗಿ ಮಾತನಾಡುವಂತೆ ಮಾಡುವುದರ ಬಗ್ಗೆ ಅಲ್ಲ. ಇದು ವ್ಯವಸ್ಥೆಯನ್ನು ಸುಲಭವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವಂತೆ ಮಾಡುವುದು ಮತ್ತು ಪ್ರತಿ ಹಂತದಲ್ಲೂ “ವಾಸ್ತವದ ಸಂಪರ್ಕ”ವನ್ನು ಕಡ್ಡಾಯಗೊಳಿಸುವುದರ ಬಗ್ಗೆ. ಎಂಜಿನಿಯರ್ಗಳಿಗೆ ಸುಲಭವಾಗಿ ಸಂಬಂಧಿಸಬಹುದಾದ ಉದಾಹರಣೆಯೆಂದರೆ CI ಶೈಲಿಯ ಮುಚ್ಚಿದ-ಆವರ್ತನ ಗ್ರೌಂಡಿಂಗ್:
ಯೋಜಿಸಿ: ಬದಲಾವಣೆಗಳ ಪಟ್ಟಿಯನ್ನು ಪ್ರಸ್ತಾಪಿಸಿ
ಕಾರ್ಯನಿರ್ವಹಿಸಿ: ಪರೀಕ್ಷೆಗಳು / ಲಿಂಟ್ ಚಲಾಯಿಸಿ
ಗಮನಿಸಿ: ವೈಫಲ್ಯಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಿ
ನವೀಕರಿಸಿ: ತಿದ್ದುಪಡಿ ಮಾಡಿ ಮರುಪ್ರಯತ್ನಿಸಿ
ಅಚಾತುರ್ಯದಿಂದ ರೂಪುಗೊಂಡ ಏಜೆಂಟ್ ವಿನ್ಯಾಸಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸುವ ಕೆಲವು ಪ್ರಶ್ನೆಗಳು:
“ಏನನ್ನು ಹಿಂಪಡೆಯಬೇಕೆಂದು ನನ್ನ ಏಜೆಂಟ್ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆಯೇ ಅಥವಾ ನಾನೇ ಯಾವಾಗಲೂ ಹಿಂಪಡೆಯುತ್ತೇನೆಯೇ?”
ಹಿಂಪಡೆಯುವಿಕೆ ಷರತ್ತುರಹಿತವಾಗಿದ್ದರೆ, ವಿಳಂಬ, ವೆಚ್ಚ, ಸಂದರ್ಭದ ದುರ್ಬಲತೆ ಮತ್ತು ಕಳಪೆ ಒಳಸೇರಿಕೆ / ಕಳಪೆ ಹೊರಸೇರಿಕೆಯ ಹೆಚ್ಚಿನ ಅಪಾಯವನ್ನು ಎದುರಿಸಬೇಕಾಗುತ್ತದೆ.
“ತಾನು ತಪ್ಪು ಮಾಡಿರುವುದನ್ನು ನನ್ನ ಏಜೆಂಟ್ ಗುರುತಿಸಬಹುದೇ?”
“ಬಳಕೆದಾರರು ಬೇಸರಗೊಳ್ಳುತ್ತಾರೆ” ಎಂಬುದೊಂದೇ ನಿಮ್ಮ ಏಜೆಂಟ್ನ ಪ್ರತಿಕ್ರಿಯಾ ಸಂಕೇತವಾಗಿದ್ದರೆ, ಮಾನವರ ನೋವನ್ನು ಬಳಸಿಕೊಂಡು ನೀವು RL ಮಾಡುತ್ತಿದ್ದೀರಿ. ವಾಸ್ತವದ ಪರಿಶೀಲನೆ ನೀಡಲು ಮೌಲ್ಯಮಾಪಕ-ಚಾಲಿತ ಮರುಪ್ರಯತ್ನ ಆವರ್ತನವೇ ಅತ್ಯಂತ ಅಚ್ಚುಕಟ್ಟಾದ ವಿಧಾನ.
“ಮೆಮೊರಿಗೆ ಬರೆಯಬಹುದೇ ಮತ್ತು ಅದು ಕಾಲಕ್ರಮೇಣ ಸುಧಾರಿಸುತ್ತದೆಯೇ?”
ನಿಮ್ಮ “ಮೆಮೊರಿ” ಕೇವಲ ಚಾಟ್ ಇತಿಹಾಸವನ್ನು ಸೇರಿಸುತ್ತಿದ್ದರೆ, ನೀವು ಮೂಲತಃ ದಾಖಲೆಗಳನ್ನಷ್ಟೇ ಬರೆಯುತ್ತಿದ್ದೀರಿ. ಸಮೀಕ್ಷೆಯ ಮೆಮೊರಿ ನಿರೂಪಣೆ ಮುಖ್ಯವಾಗಿದೆ: ಮೆಮೊರಿ ಕೇವಲ ಸಂಭಾಷಣೆಯ ಪ್ರತಿಲಿಪಿಯಾಗಿರದೆ, ಏಜೆಂಟ್ಗಳು ಕಾಲಕ್ರಮೇಣ ಪರಿಷ್ಕರಿಸುವ ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಬೆಳೆಯುವ ಸಂದರ್ಭವಾಗುತ್ತದೆ.
ಏನಾಯಿತು ಎಂಬುದನ್ನು ದಾಖಲೆಗಳು ತಿಳಿಸಿದರೆ, ಮುಂದಿನ ಬಾರಿ ಏನು ಮಾಡಬೇಕೆಂದು ಮೆಮೊರಿ ತಿಳಿಸುತ್ತದೆ. ಚಾಟ್ ಇತಿಹಾಸವು ಸಂಭಾಷಣೆಯ ಪ್ರತಿಲಿಪಿ. ಮುಂದಕ್ಕೆ ಕೊಂಡೊಯ್ಯಲು ಯೋಗ್ಯವಾದುದೇನು ಎಂಬುದರ ಕುರಿತು ಮೆಮೊರಿ ನಿರಂತರವಾಗಿ ವಿಕಸಿಸುವ ನೀತಿಯಾಗಿದೆ.
ಕಾರ್ಯ ಪ್ರಕಾರ, ಸಾಧನ ಮತ್ತು ವೈಫಲ್ಯದ ವಿಧಾನವನ್ನು ಕೀಲಿಯಾಗಿ ಹಾಗೂ ಯಾವುದು ಕೆಲಸ ಮಾಡಿತು ಮತ್ತು ಯಾವುದನ್ನು ತಪ್ಪಿಸಬೇಕು ಎಂಬುದನ್ನು ಮೌಲ್ಯವಾಗಿ ಹೊಂದಿರುವ ಪುಟ್ಟ “ಕಲಿತ ಪಾಠಗಳು” ಕೋಷ್ಟಕವು ಉತ್ತಮ ಪ್ರಾಯೋಗಿಕ ಆರಂಭ. ಪರಿಪೂರ್ಣ ಜ್ಞಾನ ನಕ್ಷೆಯನ್ನು ನಿರ್ಮಿಸುವುದು ಇದರ ಉದ್ದೇಶವಲ್ಲ. ಸಂಚಿತವಾಗಿ ಸುಧಾರಿಸುವ ನಡವಳಿಕೆಯನ್ನು ರೂಪಿಸುವುದೇ ಉದ್ದೇಶ: ಮೆಮೊರಿ + ಪ್ರತಿಕ್ರಿಯೆಯು ಏಜೆಂಟ್ಗಳನ್ನು “ಸ್ಥಿತಿರಹಿತ ಸಹಾಯಕರು” ಎಂಬ ಹಂತದಿಂದ ಕಾಲಕ್ರಮೇಣ ಸುಧಾರಿಸುವ ವ್ಯವಸ್ಥೆಗಳನ್ನಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.
ಸಮಸ್ಯೆಗೆ ಇನ್ನಷ್ಟು ಏಜೆಂಟ್ಗಳನ್ನು ಬಳಸಬೇಕೆಂಬ ಪ್ರಲೋಭನೆ ಇರುತ್ತದೆ. ಆದರೆ ಇದು ಹೆಚ್ಚಾಗಿ ಸಮನ್ವಯದ ಹೆಚ್ಚುವರಿ ಹೊರೆಯನ್ನು ಹಲವು ಪಟ್ಟು ಹೆಚ್ಚಿಸುತ್ತದೆ. ಉತ್ತಮ “ಕನಿಷ್ಠ ಕಾರ್ಯಸಾಧ್ಯ ತಂಡ”ದ ಮಾದರಿ:
ಸಂಯೋಜಕ: ವಿಭಜಿಸುತ್ತದೆ + ನಿಯೋಜಿಸುತ್ತದೆ
ಕಾರ್ಯನಿರ್ವಾಹಕ: ಸಾಧನ ಕರೆಗಳು / ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡುತ್ತದೆ
ವಿಮರ್ಶಕ / ಮೌಲ್ಯಮಾಪಕ: ಸರಿಯಾದುದೇ / ಅಪಾಯವಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತದೆ
ಮೆಮೊರಿ ಪಾಲಕ: ಪಾಠಗಳನ್ನು ಬರೆಯುತ್ತದೆ / ಪರಿಷ್ಕರಿಸುತ್ತದೆ
ಪ್ರತಿ ಏಜೆಂಟ್ನ ಹೊಣೆಗಾರಿಕೆ ಏನೆಂದು ವಿವರಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ನಿಮಗೆ ಬಹು ಏಜೆಂಟ್ಗಳು ಇನ್ನೂ ಅಗತ್ಯವಿಲ್ಲ.
ಈ ಮಾದರಿ ಬದಲಾವಣೆಯನ್ನು ನಾವು ನಿಜವಾಗಿಯೂ ಒಪ್ಪಿಕೊಂಡರೆ, ಎಲ್ಲವನ್ನೂ ಪ್ರಾಂಪ್ಟ್ಗಳಲ್ಲಿ ತುಂಬುವುದು, ವೈಫಲ್ಯಗಳನ್ನು ಅಂತಿಮ ಫಲಿತಾಂಶಗಳೆಂದು ಪರಿಗಣಿಸುವುದು ಮತ್ತು ಏಜೆಂಟ್ಗಳನ್ನು ಚಾಟ್ಬಾಟ್ಗಳಂತೆ ಮೌಲ್ಯಮಾಪನ ಮಾಡುವುದನ್ನು ಬಹುಶಃ ನಿಲ್ಲಿಸುತ್ತೇವೆ. ಏಜೆಂಟ್ಗಳನ್ನು ಅವುಗಳ ನಿಜ ಸ್ವರೂಪದಲ್ಲೇ ಪರಿಗಣಿಸಲು ಆರಂಭಿಸುತ್ತೇವೆ: ಭಾಷೆಯೇ ನಿಯಂತ್ರಣ ಪದರವಾಗಿರುವ ತಂತ್ರಾಂಶ ವ್ಯವಸ್ಥೆಗಳು. ಅವುಗಳ ವಿಶ್ವಾಸಾರ್ಹತೆ ಆವರ್ತನದಿಂದ ಬರುತ್ತದೆ.
ಮತ್ತೊಂದು ಮಾಡೆಲ್ ಸೇರಿಸುವ ಮೊದಲು, ಮತ್ತೊಂದು ಮೌಲ್ಯಮಾಪನ ಆವರ್ತನವನ್ನು ಸೇರಿಸಿ. ಎಲ್ಲವನ್ನೂ ಹಿಂಪಡೆಯುವ ಮೊದಲು, ಅದನ್ನು ಷರತ್ತುಬದ್ಧಗೊಳಿಸಿ. ಹತ್ತನ್ನು ಬಿಡುಗಡೆ ಮಾಡುವ ಮೊದಲು ಒಂದು ಮೌಲ್ಯಮಾಪಕವನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿ. ಮೆಮೊರಿಯನ್ನು ದತ್ತಸಂಚಯದಂತೆ ಅಲ್ಲ, ನೀತಿ ನಿರ್ಧಾರಗಳಂತೆ ಪರಿಗಣಿಸಿ. ಬಹು-ಏಜೆಂಟ್ ವಿಧಾನಕ್ಕೆ ಹೋಗುವಾಗ, ಇಪ್ಪತ್ತು ಏಜೆಂಟ್ಗಳಿಂದಲ್ಲ, ಎರಡರಿಂದ ಆರಂಭಿಸಿ. ಇವು ನಿಯಮಗಳಲ್ಲ. ಉತ್ಪಾದನಾ ಪರಿಸರದ ಪರೀಕ್ಷೆಯನ್ನು ತಾಳಿಕೊಂಡ ಮಾದರಿಗಳು.