AI ಏಜೆಂಟ್ ಡೆಮೋಗಳ ಹಿಂದಿರುವ ಕರಾಳ ಸತ್ಯ

ಲಿಂಕ್ಡ್‌ಇನ್‌ನಲ್ಲಿ (LinkedIn) ತುಂಬಿರುವ ಹೆಚ್ಚಿನ AI-ಏಜೆಂಟ್ ಡೆಮೋಗಳು ನೈಜ ಏಜೆಂಟ್‌ಗಳಲ್ಲ. ನಾನು ದಿನವಿಡೀ ಸಂಶೋಧನಾ ಪ್ರಬಂಧಗಳನ್ನು ಓದುತ್ತಾ ಮತ್ತು ಉತ್ಪನ್ನಗಳನ್ನು ತಯಾರಿಸುವ ಎಂಜಿನಿಯರ್‌ಗಳೊಂದಿಗೆ ಮಾತನಾಡುತ್ತಾ ಇರುತ್ತೇನೆ, ಮತ್ತು ಆಕರ್ಷಕ ಡೆಮೋಗಳು ಹಾಗೂ ಉತ್ಪಾದನಾ-ಸಿದ್ಧ ವ್ಯವಸ್ಥೆಗಳ (production-ready systems) ನಡುವಿನ ಅಂತರವು ಹೆಚ್ಚಾಗುತ್ತಿರುವುದನ್ನು ನಾನು ಗಮನಿಸುತ್ತಿದ್ದೇನೆ. ಕೇವಲ ಪ್ರಚಾರದ (hype) ಹಿಂದೆ ಬರುವ ಡೆವಲಪರ್‌ಗಳು ಅಂತಿಮವಾಗಿ ಅಸ್ಥಿರವಾದ ಮತ್ತು ಅತಿಯಾದ ಎಂಜಿನಿಯರಿಂಗ್ ಮಾಡಿದ ಪರಿಕರಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತಾರೆ.

ಈ ಪ್ರಚಾರ (hype) ಏಕೆ ಮುಖ್ಯ

"ಏಜೆಂಟ್" ಎಂಬುದು ಈಗ ಯಾವುದೇ ಸ್ಕ್ರಿಪ್ಟ್, ಚಾಟ್‌ಬಾಟ್ ಅಥವಾ ಬಾಹ್ಯ ಪರಿಕರವನ್ನು ಕರೆಯುವ ಸರಳ ಫಂಕ್ಷನ್‌ಗೆ ಅಂಟಿಸಬಹುದಾದ ಒಂದು ಪ್ರಚಲಿತ ಪದವಾಗಿದೆ (buzzword). ಇದರ ಪರಿಣಾಮ: ಸ್ಕ್ರೀನ್ ಮೇಲೆ ಆಕರ್ಷಕವಾಗಿ ಕಾಣುವ ಆದರೆ ಸ್ವಾಯತ್ತ ವ್ಯವಸ್ಥೆಯ (autonomous system) ಮೂಲ ಗುಣಲಕ್ಷಣಗಳಾದ—ಸ್ಪಷ್ಟ ಉದ್ದೇಶ, ಮುಂದಿನ ಹಂತವನ್ನು ನಿರ್ಧರಿಸುವ ಸಾಮರ್ಥ್ಯ ಮತ್ತು ಅಂತರ್ಗತ ವಿಫಲತೆ ನಿರ್ವಹಣೆ (failure handling)—ಅನುಸರಿಸದ ಡೆಮೋಗಳು. ತಂಡಗಳು ಒಂದು ಪೋಲಿಶ್ ಮಾಡಿದ ಡೆಮೋವನ್ನು ಸಿದ್ಧ ಪರಿಹಾರ ಎಂದು ತಪ್ಪಾಗಿ ಭಾವಿಸಿದಾಗ, ಅವರು ಸರಳ ಕಾರ್ಯಗಳಿಗಾಗಿ ಅನಗತ್ಯ ರಚನೆಗಳನ್ನು ನಿರ್ಮಿಸಲು ಶ್ರಮ ವ್ಯರ್ಥ ಮಾಡುತ್ತಾರೆ ಅಥವಾ ಸಂಕೀರ್ಣ ಕಾರ್ಯಪ್ರವೃತ್ತಿಗಳಿಗಾಗಿ (workflows) ಅಸ್ಥಿರವಾದ ಪೈಪ್‌ಲೈನ್‌ಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡುತ್ತಾರೆ.

ನೈಜ ಮತ್ತು ಆಕರ್ಷಕದ ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ಗುರುತಿಸುವ ಪರಿಶೀಲನಾ ಪಟ್ಟಿ

ಒಬ್ಬ ಡೆವಲಪರ್ ನಿಜವಾದ ಏಜೆಂಟ್ ಅನ್ನು ಗುರುತಿಸಲು ಈ ವಿಶ್ಲೇಷಣೆಯು ಮೂರು速 ಪ್ರಶ್ನೆಗಳನ್ನು ಸೂಚಿಸುತ್ತದೆ:

  • ಪ್ರತಿಯೊಂದು ಹಂತಕ್ಕೂ ವ್ಯವಸ್ಥೆಗೆ ಮನುಷ್ಯನ ಮಾರ್ಗದರ್ಶನದ ಅಗತ್ಯವಿದೆಯೇ? ಹೌದು ಎಂದಾದರೆ, ಅದು ಕೇವಲ ಚಾಟ್ ಇಂಟರ್ಫೇಸ್ ಆಗಿದೆಯೇ ಹೊರತು, ಸ್ವಾಯತ್ತ ಏಜೆಂಟ್ ಅಲ್ಲ.

  • ವಿಫಲವಾದ ಟೂಲ್ ಕಾಲ್‌ನಿಂದ (tool call) ವ್ಯವಸ್ಥೆಯು ಚೇತರಿಸಿಕೊಳ್ಳಬಲ್ಲದೇ? ಒಬ್ಬ ಏಜೆಂಟ್ ವಿಫಲತೆಯನ್ನು ಪತ್ತೆಹಚ್ಚಬೇಕು, ಮರುಪ್ರಯತ್ನ ಮಾಡಬೇಕೆ ಅಥವಾ ಪರ್ಯಾಯ ಮಾರ್ಗವನ್ನು ಅನುಸರಿಸಬೇಕೆ ಅಥವಾ ಕಾರ್ಯವನ್ನು ಗೌರವಯುತವಾಗಿ ಸ್ಥಗಿತಗೊಳಿಸಬೇಕೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಬೇಕು.

  • ವ್ಯವಸ್ಥೆಯು ಉನ್ನತ ಮಟ್ಟದ ಗುರಿಯನ್ನು ಉಪ-ಕಾರ್ಯಗಳಾಗಿ (subtasks) ವಿಭಜಿಸುತ್ತದೆಯೇ? ನೈಜ ಏಜೆಂಟ್‌ಗಳು ಕೇವಲ ನಿಗದಿತ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಅನುಸರಿಸುವ ಬದಲು, ಉದ್ದೇಶಗಳನ್ನು ವಿಭಜಿಸಿ ಕೆಲಸವನ್ನು ಯೋಜಿಸುತ್ತವೆ.

ಯಶಸ್ವಿ ತಂಡಗಳು ವಾಸ್ತವವಾಗಿ ಯಾವುದರ ಮೇಲೆ ಗಮನ ಹರಿಸುತ್ತವೆ

ಉನ್ನತ ಕಾರ್ಯಕ್ಷಮತೆ ಹೊಂದಿರುವ ಎಂಜಿನಿಯರಿಂಗ್ ಗುಂಪುಗಳು ಹೊಸ ಮಾಡೆಲ್ ಬಿಡುಗಡೆಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸಿ, ಈ ಮೂರು ವಿನ್ಯಾಸದ ಸ್ತಂಭಗಳ ಮೇಲೆ ಹೆಚ್ಚಿನ ಗಮನ ಹರಿಸುತ್ತವೆ ಎಂದು ನಾನು ಗಮನಿಸಿದ್ದೇನೆ:

ಟೂಲ್ ವಿನ್ಯಾಸ (Tool design)

ಏಜೆಂಟ್‌ಗಳು ಸುಗಮವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ಇಂಟರ್ಫೇಸ್‌ಗಳ ಮೂಲಕ ಬಾಹ್ಯ ಸೇವೆಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತವೆ. ಸ್ವಚ್ಛವಾದ API ಮೇಲ್ಮೈಯು (surface) ಇನ್‌ಪುಟ್‌ಗಳು, ಔಟ್‌ಪುಟ್‌ಗಳು ಮತ್ತು ಎರರ್ ಕೋಡ್‌ಗಳ ಬಗ್ಗೆ ಏಜೆಂಟ್ ತರ್ಕಿಸಲು ಸುಲಭವಾಗಿಸುತ್ತದೆ. ಫ್ರೇಮ್‌ವರ್ಕ್‌ನ ಆಯ್ಕೆ—LangChain, CrewAI ಅಥವಾ ಸ್ವಂತ ಲೈಬ್ರರಿ—ಎಂಬುದು ನಿರ್ಧಾರಿತ (deterministic), ವರ್ಷನ್ ಮಾಡಲಾದ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳನ್ನು ಪ್ರದರ್ಶಿಸುವ ಶಿಸ್ತಿಗಿಂತ ಕಡಿಮೆ ಮುಖ್ಯವಾಗುತ್ತದೆ.

ವಿಫಲತೆ ನಿರ್ವಹಣೆ (Failure handling)

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

ವೀಕ್ಷಣೀಯತೆ (Observability)

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

ಯಾವುದೇ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಬಾಳಿಕೆ ಬರುವ ಮಾದರಿಗಳು

ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳು ವೇಗವಾಗಿ ವಿಕಸನಗೊಳ್ಳುತ್ತವೆ—LangChain ಮತ್ತು CrewAI ಬಹುತೇಕ ಪ್ರತಿ ತಿಂಗಳು ಹೊಸ ಬದಲಾವಣೆಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡುತ್ತವೆ. ಲೈಬ್ರರಿಗಳಿಗಿಂತ ಮಾದರಿಗಳೇ (patterns) ಮುಖ್ಯವಾಗಿರಬೇಕು ಎಂದು ಈ ವಿಶ್ಲೇಷಣೆಯು ವಾದಿಸುತ್ತದೆ. ವರ್ಷನ್ ಅಪ್‌ಗ್ರೇಡ್‌ಗಳ ನಂತರವೂ ಉಳಿಯುವ ಪುನರಾವರ್ತಿತ ರಚನೆಗಳು ಇಲ್ಲಿವೆ:

  • ಯೋಜಿಸಿ ನಂತರ ಕಾರ್ಯಗತಗೊಳಿಸಿ (Plan-then-execute) ತರ್ಕದ ಹಂತವನ್ನು (ಉದಾಹರಣೆಗೆ, "ನಾನು ಮುಂದೆ ಏನು ಮಾಡಬೇಕು?") ಮತ್ತು ಕ್ರಿಯೆಯ ಹಂತವನ್ನು (ಉದಾಹರಣೆಗೆ, "ಬಿಲ್ಲಿಂಗ್ API ಅನ್ನು ಕರೆಯಿರಿ") ಪ್ರತ್ಯೇಕಿಸಿ. ಇದು ಪ್ರಾಂಪ್ಟ್ ಉದ್ದವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಮಾಡೆಲ್‌ನ ಔಟ್‌ಪುಟ್ ಅನ್ನು ನಿರ್ಧಾರಿತವಾಗಿರಿಸುತ್ತದೆ.

  • ಮಾಹಿತಿಯ ಹುಡುಕಾಟವನ್ನು (retrieval) ತರ್ಕದಿಂದ (reasoning) ಪ್ರತ್ಯೇಕಿಸಿ ಸಂದರ್ಭವನ್ನು ಪಡೆಯುವುದು (ಜ್ಞಾನ ಕೋಶವನ್ನು ಹುಡುಕುವುದು, ದಾಖಲೆಯನ್ನು ಲೋಡ್ ಮಾಡುವುದು) ಎಂಬುದು ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸಲು ಆ ಸಂದರ್ಭವನ್ನು ಬಳಸುವುದಕ್ಕಿಂತ ಭಿನ್ನವಾದ ಕೆಲಸವಾಗಿದೆ. ಇವೆರಡನ್ನೂ ಬೆರೆಸುವುದರಿಂದ ಪ್ರಾಂಪ್ಟ್ ಗಾತ್ರವು ಹೆಚ್ಚಾಗುತ್ತದೆ ಮತ್ತು ವಿಫಲತೆಗಳನ್ನು ಪತ್ತೆಹಚ್ಚುವುದು ಕಷ್ಟವಾಗುತ್ತದೆ.

  • ಸ್ಪಷ್ಟ ಹಸ್ತಾಂತರಗಳು (Explicit handoffs) ಒಬ್ಬ ಏಜೆಂಟ್ ಮತ್ತೊಬ್ಬರಿಗೆ ಕೆಲಸವನ್ನು ವರ್ಗಾಯಿಸಿದಾಗ—ಉದಾಹರಣೆಗೆ, ಪ್ಲಾನರ್ ಒಂದು ಉಪ-ಕಾರ್ಯವನ್ನು ಡೇಟಾ-ಫೆಚರ್‌ಗೆ ನೀಡಿದಾಗ—ರಚನಾತ್ಮಕ ಹಸ್ತಾಂತರ ಫಾರ್ಮ್ಯಾಟ್ (JSON ಅಥವಾ ನಿರ್ದಿಷ್ಟ ಸ್ಕೀಮಾ) ಬಳಸಿ. ಸ್ವೀಕರಿಸುವ ಏಜೆಂಟ್ ಕಾರ್ಯवाही ಮಾಡುವ ಮೊದಲು ಪೇಲೋಡ್ ಅನ್ನು ವ್ಯಾಲಿಡೇಟ್ ಮಾಡಬಹುದು, ಇದು ದೃಢತೆಯನ್ನು ಸುಧಾರಿಸುತ್ತದೆ.

ಸಾಮಾನ್ಯ ತಪ್ಪು: RAG ಚಂಕಿಂಗ್

ಉತ್ತರಗಳು ವಿಷಯಕ್ಕೆ ಸಂಬಂಧಿಸದಿದ್ದಾಗ, ರಿಟ್ರಿವಲ್-ಆಗ್ಮೆಂಟೆಡ್ ಜನರೇಷನ್ (RAG) ವ್ಯವಸ್ಥೆಗಳು ಹೆಚ್ಚಾಗಿ ಭಾಷಾ ಮಾಡೆಲ್ ಅನ್ನು ದೂಷಿಸುತ್ತವೆ. ಆದರೆ ನಿಜವಾದ ಕಾರಣವು ಹೆಚ್ಚಾಗಿ ಚಂಕಿಂಗ್ ತಂತ್ರದಲ್ಲಿರುತ್ತದೆ ಎಂದು ವಿಶ್ಲೇಷಣೆಯು ಸೂಚಿಸುತ್ತದೆ. ವಾಕ್ಯಗಳನ್ನು ಕತ್ತರಿಸುವ ಅಥವಾ ಅರ್ಥಪೂರ್ಣ ಗಡಿಗಳನ್ನು (semantic boundaries) ಕಳೆದುಕೊಳ್ಳುವ ರೀತಿಯಲ್ಲಿ ದಾಖಲೆಯನ್ನು ತುಣುಕುಗಳಾಗಿ ವಿಭಜಿಸುವುದು ಮಾಡೆಲ್‌ಗೆ ಅಗತ್ಯವಿರುವ ಸಂದರ್ಭವನ್ನು (context) ಕಸಿದುಕೊಳ್ಳುತ್ತದೆ. ಮೆಟಾಡೇಟಾ ಟ್ಯಾಗ್‌ಗಳು, ಓವರ್‌ಲ್ಯಾಪ್ ವಿಂಡೋಗಳು ಮತ್ತು ಚಂಕ್ ಗಾತ್ರವನ್ನು ಸರಿಪಡಿಸುವುದರಿಂದ ಮಾಡೆಲ್ ಅನ್ನು ಬದಲಾಯಿಸದೆಯೇ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸಬಹುದು.

ಸಾರಾಂಶ

ನೀವು ತನ್ನಷ್ಟಕ್ಕೆ ತಾನೇ ಕಾರ್ಯನಿರ್ವಹಿಸುವ AI ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದರೆ, ಲಿಂಕ್ಡ್‌ಇನ್‌ನಲ್ಲಿ ಡೆಮೋ ಎಷ್ಟು ಆಕರ್ಷಕವಾಗಿ ಕಾಣುತ್ತದೆ ಎಂಬುದರ ಮೂಲಕ ಯಶಸ್ಸನ್ನು ಅಳೆಯುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ನಿಮ್ಮ ಕೋಡ್ ಗುರಿಗಳನ್ನು ವಿಭಜಿಸಬಲ್ಲದೇ, ಟೂಲ್ ವಿಫಲತೆಗಳನ್ನು ಎದುರಿಸಬಲ್ಲದೇ ಮತ್ತು ಡಿಬಗ್ ಮಾಡಲು ಸ್ಪಷ್ಟವಾದ ಸುಳಿವುಗಳನ್ನು (breadcrumb trail) ಬಿಡಬಲ್ಲದೇ ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ಆ ಮೂರು ಎಂಜಿನಿಯರಿಂಗ್ ಅಭ್ಯಾಸಗಳು—ಆಲೋಚನಾಪೂರ್ಣ ಟೂಲ್ ವಿನ್ಯಾಸ, ಶಿಸ್ತುಬದ್ಧ ವಿಫಲತೆ ನಿರ್ವಹಣೆ ಮತ್ತು ಫುಲ್-ಸ್ಟ್ಯಾಕ್ ವೀಕ್ಷಣೀಯತೆ—ಒಂದು ಆಕರ್ಷಕ ಪ್ರೊಟೊಟೈಪ್ ಅನ್ನು ವಿಶ್ವಾಸಾರ್ಹ ಏಜೆಂಟ್ ಆಗಿ ಪರಿವರ್ತಿಸುತ್ತವೆ.