Microsoft ತನ್ನ Foundry Toolbox ಮತ್ತು ಅದರ ಸಹವರ್ತಿ ವೈಶಿಷ್ಟ್ಯವಾದ Tool Search ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದೆ. ಇದು ಏಕೈಕ ಎಂಡ್‌ಪಾಯಿಂಟ್ (single-endpoint) ಸೇವೆಯಾಗಿದ್ದು, ಅಭಿವೃದ್ಧಿಪಡಿಸುವವರು (developers) ಪ್ರತಿಯೊಂದು ಏಜೆಂಟ್ ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಜೋಡಿಸುವ ಅಗತ್ಯವಿಲ್ಲದೆ, ನೂರಾರು ಪರಿಕರಗಳನ್ನು (tools) AI ಏಜೆಂಟ್‌ಗಳಿಗೆ ಜೋಡಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಕ್ಯಾಟಲಾಗ್‌ನಲ್ಲಿ 600 ಕ್ಕೂ ಹೆಚ್ಚು ಪರಿಕರಗಳಿದ್ದಾಗ, Tool Search ಇನ್‌ಪುಟ್ ಟೋಕನ್‌ಗಳನ್ನು (input tokens) 94% ರಷ್ಟು ಕಡಿಮೆ ಮಾಡಿದೆ.

ಕೇಂದ್ರಿತ ಟೂಲ್‌ಬಾಕ್ಸ್ ಏಕೆ ಮುಖ್ಯ

ಬಳಕೆದಾರರ ವಿನಂತಿಗಳನ್ನು ಪೂರೈಸಲು AI ಏಜೆಂಟ್‌ಗಳಿಗೆ ಬಾಹ್ಯ ಸಾಮರ್ಥ್ಯಗಳು—ಡೇಟಾಬೇಸ್‌ಗಳು, CRMs, ಅನಾಲಿಟಿಕ್ಸ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳು—ಅಗತ್ಯವಿವೆ. ಇದುವರೆಗೆ ಅನೇಕ ಸಂಸ್ಥೆಗಳು ಪ್ರತಿಯೊಂದು ಏಜೆಂಟ್ ಅನ್ನು ಅಗತ್ಯವಿರುವ APIಗಳಿಗೆ ನೇರವಾಗಿ ಸಂಪರ್ಕಿಸುತ್ತಿದ್ದವು. ಎಂಜಿನಿಯರ್‌ಗಳು ಪ್ರತಿಯೊಂದು ಹೊಸ ಏಜೆಂಟ್‌ಗಾಗಿ ಕ್ರೆಡೆನ್ಶಿಯಲ್ ಕಾನ್ಫಿಗರೇಶನ್ (credential configuration), ಪಾಲಿಸಿ ಎನ್‌ಫೋರ್ಸ್‌ಮೆಂಟ್ (policy enforcement) ಮತ್ತು ಎರರ್-ಹ್ಯಾಂಡ್ಲಿಂಗ್ ಕೋಡ್ ಅನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತಿದ್ದರು. ಇದರ ಪರಿಣಾಮವಾಗಿ, ನಕಲಾದ ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಗೋಜಲಾಗಿ, ಅದನ್ನು ಆಡಿಟ್ ಮಾಡುವುದು ಕಷ್ಟವಾಗುತ್ತಿತ್ತು ಮತ್ತು ಭದ್ರತಾ ಲೋಪಗಳಿಗೆ (security gaps) ದಾರಿಯಾಗುತ್ತಿತ್ತು.

Foundry Toolbox ಆ ಅಸ್ತವ್ಯಸ್ತತೆಯನ್ನು ಒಂದು ಏಕೀಕೃತ ಸೇವಾ ಪದರದಿಂದ (unified service layer) ಬದಲಾಯಿಸುತ್ತದೆ. ಡಜನ್ಗಟ್ಟಲೆ ಏಜೆಂಟ್‌ಗಳು ಪ್ರತ್ಯೇಕ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳನ್ನು ಬಳಸುವ ಬದಲು, ಎಲ್ಲಾ ಏಜೆಂಟ್‌ಗಳು ಒಂದೇ “toolbox” ಎಂಡ್‌ಪಾಯಿಂಟ್ ಮೂಲಕ ಸಂವಹನ ನಡೆಸುತ್ತವೆ. ಟೂಲ್‌ಬಾಕ್ಸ್ ವರ್ಷನಿಂಗ್ (versioning), ಕನೆಕ್ಷನ್ ಸ್ಟ್ರಿಂಗ್‌ಗಳು ಮತ್ತು ಭದ್ರತಾ ನೀತಿಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ, ಇದರಿಂದ ತಂಡಗಳು ಇಡೀ ಟೂಲ್ ಪರಿಸರ ವ್ಯವಸ್ಥೆಯನ್ನು (ecosystem) ಒಂದೇ ಸ್ಥಳದಿಂದ ನಿರ್ವಹಿಸಬಹುದು. ಹಲವಾರು ವ್ಯವಹಾರ ಘಟಕಗಳಲ್ಲಿ ಡಜನ್ಗಟ್ಟಲೆ ಏಜೆಂಟ್‌ಗಳನ್ನು ನಡೆಸುವ ಉದ್ಯಮಗಳು ತಕ್ಷಣವೇ ಕಾರ್ಯಾಚರಣೆಯ ಹೊರೆಯು (operational overhead) ಕಡಿಮೆಯಾಗುವುದನ್ನು ಕಾಣುತ್ತಾರೆ.

ದೊಡ್ಡ ಪರಿಕರ ಕ್ಯಾಟಲಾಗ್‌ಗಳು ಒಂದು ಗುಪ್ತ ವೆಚ್ಚವನ್ನು ಸೃಷ್ಟಿಸುತ್ತವೆ: ಅದುವೇ ಟೋಕನ್ ಬಳಕೆ. ಲೇಂಗ್ವೇಜ್ ಮಾಡೆಲ್ (language model) ಎಲ್ಲಾ ಲಭ್ಯವಿರುವ ಪರಿಕರಗಳ ಪಟ್ಟಿಯನ್ನು ಒಳಗೊಂಡಿರುವ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ, ಅದರ ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋ (context window) ದೊಡ್ಡದಾಗುತ್ತದೆ, ಇದರಿಂದ ತಾರ್ಕಿಕ ವಿಶ್ಲೇಷಣೆ ಅಥವಾ ಬಳಕೆದಾರರಿಗೆ ಕಾಣುವ ಪಠ್ಯಕ್ಕಾಗಿ ಬಳಸಬಹುದಾದ ಟೋಕನ್‌ಗಳು ವ್ಯರ್ಥವಾಗುತ್ತವೆ. Tool Search ಈ ಸಮಸ್ಯೆಯನ್ನು ಮೂಲದಿಂದಲೇ ಎದುರಿಸುತ್ತದೆ.

ಏಜೆಂಟ್ Tool Search ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದಾಗ, ಮಾಡೆಲ್ ಮೊದಲು tool_search ಎಂಬ ಮೆಟಾ-ಟೂಲ್ ಅನ್ನು ಕರೆಯುತ್ತದೆ ಮತ್ತು ಅದಕ್ಕೆ ಏನು ಬೇಕೆಂದು ಸರಳ ಇಂಗ್ಲಿಷ್‌ನಲ್ಲಿ ವಿವರಿಸುತ್ತದೆ (ಉದಾಹರಣೆಗೆ, “find the latest sales forecast for region X”). ಈ ಸೇವೆ ಉದ್ದೇಶಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುವ ಅಭ್ಯರ್ಥಿ ಪರಿಕರಗಳ ಸಂಕ್ಷಿಪ್ತ ಮತ್ತು ಶ್ರೇಣೀಕೃತ ಪಟ್ಟಿಯನ್ನು ನೀಡುತ್ತದೆ. ನಂತರ ಮಾಡೆಲ್ ಆ ಪಟ್ಟಿಯಿಂದ ಅತ್ಯಂತ ಸೂಕ್ತವಾದ ಆಯ್ಕೆಯನ್ನು ಆರಿಸಿಕೊಂಡು call_tool ಅನ್ನು ಬಳಸುತ್ತದೆ. ಕೇವಲ ಸಂಬಂಧಿತ ಉಪಸಮೂಹವನ್ನು (subset) ಮಾತ್ರ ಪ್ರದರ್ಶಿಸುವ ಮೂಲಕ, ಪ್ರಾಂಪ್ಟ್ ಚಿಕ್ಕದಾಗಿರುತ್ತದೆ, ಇದು 600-ಟೂಲ್ ಬೆಂಚ್‌ಮಾರ್ಕ್‌ನಲ್ಲಿ ಇನ್‌ಪುಟ್ ಟೋಕನ್‌ಗಳನ್ನು 94% ರಷ್ಟು ಉಳಿಸುತ್ತದೆ.

ಈ ಎರಡು ಹಂತದ ಕಾರ್ಯವಿಧಾನವು ಆಯ್ಕೆಯ ನಿಖರತೆಯನ್ನು ಕೂಡ ಸುಧಾರಿಸುತ್ತದೆ. ಇದೇ ಬೆಂಚ್‌ಮಾರ್ಕ್‌ನಲ್ಲಿ, ಮಾಡೆಲ್ ಪೂರ್ಣ ಕ್ಯಾಟಲಾಗ್ ಅನ್ನು ಹುಡುಕಬೇಕಾದ ಸಂದರ್ಭಕ್ಕಿಂತ, ಈ ವಿಧಾನದಲ್ಲಿ ಸರಿಯಾದ ಪರಿಕರವನ್ನು ಹೆಚ್ಚು ಬಾರಿ ಆರಿಸಿದೆ, ಇದರಿಂದ ತಪ್ಪು ಕರೆಯುವಿಕೆಗಳು (false calls) ಮತ್ತು ಅನಗತ್ಯ ಮರುಪ್ರಯತ್ನಗಳು ಕಡಿಮೆಯಾದವು.

ಟೂಲ್‌ಬಾಕ್ಸ್‌ನಿಂದ ಗರಿಷ್ಠ ಪ್ರಯೋಜನ ಪಡೆಯುವುದು ಹೇಗೆ

  • ಉತ್ತಮ ಮೆಟಾಡೇಟಾವನ್ನು ಬರೆಯಿರಿ – Tool Search ಪ್ರತಿಯೊಂದು ಪರಿಕರದ ಹೆಸರು ಮತ್ತು ವಿವರಣೆಯನ್ನು ಅವಲಂಬಿಸಿದೆ. “Get data” ನಂತಹ ಅಸ್ಪಷ್ಟ ಲೇಬಲ್‌ಗಳು ಮಾಡೆಲ್‌ಗೆ ಕೆಲಸ ಮಾಡಲು ಅಲ್ಪ ಮಾಹಿತಿಯನ್ನು ನೀಡುತ್ತವೆ. “Retrieve customer renewal risks and contacts” ನಂತಹ ವಿವರವಾದ ಶೀರ್ಷಿಕೆಗಳು ಸರ್ಚ್ ಇಂಜಿನ್ ಅನ್ನು ಸರಿಯಾದ ಹೊಂದಾಣಿಕೆಗೆ ಮಾರ್ಗದರ್ಶನ ಮಾಡುತ್ತವೆ.
  • ಪದೇ ಪದೇ ಬಳಸುವ ಪರಿಕರಗಳನ್ನು ಪಿನ್ ಮಾಡಿ – ಒಂದು ಏಜೆಂಟ್‌ಗೆ ಪ್ರತಿ ಬಾರಿಯೂ ನಿರ್ದಿಷ್ಟ ಉಪಯುಕ್ತತೆಯ ಅಗತ್ಯವಿದ್ದರೆ, ಆ ಪರಿಕರವನ್ನು ಏಜೆಂಟ್‌ನ ಕಾನ್ಫಿಗರೇಶನ್‌ಗೆ ಪಿನ್ ಮಾಡಿ. ಪಿನ್ ಮಾಡುವುದರಿಂದ ಸರ್ಚ್ ಹಂತವನ್ನು ಬಿಡಬಹುದು, ಇದರಿಂದ ವಿಳಂಬ (latency) ಮತ್ತು ಟೋಕನ್ ಬಳಕೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು.
  • ಸಾಮರ್ಥ್ಯದ ಆಧಾರದ ಮೇಲೆ ಸಂಘಟಿಸಿ – ಇಡೀ ಉದ್ಯಮವನ್ನು ಒಳಗೊಳ್ಳುವ ಒಂದು ಬೃಹತ್ ಟೂಲ್‌ಬಾಸ್ ಅನ್ನು ಹೊಂದುವ ಬದಲು, ಪರಿಕರಗಳನ್ನು ತಾರ್ಕಿಕ ಗುಂಪುಗಳಾಗಿ (ಉದಾಹರಣೆಗೆ, sales-tools, CRM-tools) ವಿಂಗಡಿಸಿ. ಸಣ್ಣ ಗುಂಪುಗಳು ತಪ್ಪು ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳಿಂದ ಉಂಟಾಗುವ ಪರಿಣಾಮವನ್ನು (blast radius) ಸೀಮಿತಗೊಳಿಸುತ್ತವೆ ಮತ್ತು ಸರ್ಚ್ ಫಲಿತಾಂಶಗಳನ್ನು ಕೇಂದ್ರೀಕೃತವಾಗಿಡುತ್ತವೆ.
  • ನಿಯೋಜಿಸುವ (deploy) ಮೊದಲು ಪರೀಕ್ಷಿಸಿ – ಟೂಲ್‌ಬಾಕ್ಸ್ ಆವೃತ್ತಿಗಳು ಬದಲಾಯಿಸಲಾಗದವು (immutable); ಒಂದು ಆವೃತ್ತಿಯನ್ನು ಡಿಫಾಲ್ಟ್ ಎಂದು ನಿಗದಿಪಡಿಸಿದ ನಂತರ, ಎಲ್ಲಾ ಏಜೆಂಟ್‌ಗಳು ಅದನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸುತ್ತವೆ. ಕಂಪನಿಯಾದ್ಯಂತ ಜಾರಿಗೆ ತರುವ ಮೊದಲು, ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಲು ડેವಲಪರ್ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಬಳಸಿ.

ಪರಿಕರಗಳ ಸಂಖ್ಯೆ ನೂರಾರು ತಲುಪಿದಾಗ ಈ ಅಭ್ಯಾಸಗಳು ಹೆಚ್ಚು ಮುಖ್ಯವಾಗುತ್ತವೆ. ಕೆಲವೇ ಉಪಯುಕ್ತತೆಗಳನ್ನು ಹೊಂದಿರುವ ಏಕೈಕ ಏಜೆಂಟ್‌ಗೆ, ನೇರ ಸಂಪರ್ಕಗಳು ಇನ್ನೂ ಸರಳ ಮಾರ್ಗವಾಗಿರಬಹುದು. ಆದರೆ ತಂಡಗಳು ಹೆಚ್ಚಾದಂತೆ ಮತ್ತು ಟೂಲ್‌ಬಾಕ್ಸ್ ವಿಸ್ತರಿಸಿದಂತೆ, ನಕಲಾತಿಯನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು, ಕಟ್ಟುನಿಟ್ಟಾದ ಭದ್ರತೆ ಮತ್ತು ಅಳೆಯಬಹುದಾದ ಟೋಕನ್ ಉಳಿತಾಯದ ಮೂಲಕ ಕೇಂದ್ರೀಕೃತ ಮಾದರಿಯು ತನ್ನ ಲಾಭವನ್ನು ತಂದುಕೊಡುತ್ತದೆ.

ಸಾರಾಂಶ: Foundry Toolbox ಮತ್ತು Tool Search ದೊಡ್ಡ ಮಟ್ಟದ AI ನಿಯೋಜನೆಗಳಿಗೆ ಪರಿಕರಗಳ ಅತಿಯಾದ ವಿಸ್ತರಣೆಯನ್ನು ನಿಯಂತ್ರಿಸಲು, ಟೋಕನ್ ವ್ಯರ್ಥವನ್ನು 94% ರಷ್ಟು ಕಡಿಮೆ ಮಾಡಲು ಮತ್ತು ಸ್ಥಿರವಾದ ಭದ್ರತಾ ನೀತಿಗಳನ್ನು ಜಾರಿಗೆ ತರಲು ಒಂದು ಮಾರ್ಗವನ್ನು ನೀಡುತ್ತವೆ—ಇವೆಲ್ಲವೂ ಕೇವಲ ಒಂದು ಸುಸಜ್ಜಿತ ಸೇವಾ ಪದರವನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಆರಂಭಿಕ ಸೆಟಪ್ ಮತ್ತು ಮೆಟಾಡೇಟಾ ಶಿಸ್ತನ್ನು ಪಾಲಿಸಬಲ್ಲ ತಂಡಗಳು ಹೆಚ್ಚು ಚುರುಕಾದ ಮತ್ತು ನಿಯಂತ್ರಿಸಬಹುದಾದ ಏಜೆಂಟ್ ಪರಿಸರ ವ್ಯವಸ್ಥೆಯನ್ನು ಪಡೆಯಬಹುದು.