ಪ್ರಸ್ತುತ GitHub ನಲ್ಲಿ ಮಲ್ಟಿ-ಏಜೆಂಟ್ ವರ್ಕ್ಫ್ಲೋಗಳು (Multi-agent workflows) ಪ್ರಾಬಲ್ಯ ಸಾಧಿಸುತ್ತಿವೆ. ಡೆವಲಪರ್ಗಳು ದೊಡ್ಡ ಭಾಷಾ ಮಾದರಿಗಳನ್ನು (large language models) ಒಂದಕ್ಕೊಂದು ಜೋಡಿಸುತ್ತಿದ್ದಾರೆ, ಪ್ರತಿಯೊಬ್ಬ ಏಜೆಂಟ್ಗೆ ಒಂದು ನಿರ್ದಿಷ್ಟ ಪರಿಣತಿಯನ್ನು ನೀಡುತ್ತಿದ್ದಾರೆ ಮತ್ತು ಒಬ್ಬನೇ ಮಾದರಿಯಿಂದ ಮಾಡಲು ಸಾಧ್ಯವಾಗದ ಕೆಲಸಗಳನ್ನು ನಿಭಾಯಿಸಲು ಅವುಗಳ ಔಟ್ಪುಟ್ಗಳನ್ನು ಸಂಘಟಿಸುತ್ತಿದ್ದಾರೆ (orchestrating). ಇದರ ಫಲಿತಾಂಶಗಳು ಪ್ರಭಾವಶಾಲಿಯಾಗಿರಬಹುದು. ಒಂದು ಏಜೆಂಟ್ ಸಂಶೋಧನೆ ಮಾಡುತ್ತದೆ, ಇನ್ನೊಂದು ಕರಡು ಸಿದ್ಧಪಡಿಸುತ್ತದೆ, ಮೂರನೆಯದು ಸತ್ಯಾಸತ್ಯತೆಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ ಮತ್ತು ನಾಲ್ಕನೆಯದು ಅಂತಿಮ ಔಟ್ಪುಟ್ ಅನ್ನು ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡುತ್ತದೆ. ಆದರೆ ಈ ಎಲ್ಲಾ ಸಮನ್ವಯದ ಅಡಿಯಲ್ಲಿ ಒಂದು ಅಸ್ಥಿರ ಅವಲಂಬನೆ (brittle dependency) ಅಡಗಿದೆ. ಮಾನವನ ಇನ್ಪುಟ್ ಅನ್ನು ಯಂತ್ರಕ್ಕೆ ಓದಬಲ್ಲ ಸೂಚನೆಗಳಾಗಿ ಪರಿವರ್ತಿಸುವ ಮೊದಲ ಹಂತವೇ ನಿಧಾನವಾಗಿದ್ದರೆ ಅಥವಾ ಅಸಮರ್ಪಕವಾಗಿದ್ದರೆ, ಇಡೀ ಸರಪಳಿ ಕುಸಿದು ಬೀಳುತ್ತದೆ. ಕೆಳಮಟ್ಟದ ಏಜೆಂಟ್ (downstream agent) ತಪ್ಪು ಮಾಹಿತಿಯನ್ನು (garbage) ಸರಿಪಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ; ಅದು ಕೇವಲ ಅದನ್ನು ಮುಂದಕ್ಕೆ ಹರಡುತ್ತದೆ ಅಷ್ಟೆ.
ಈ ಬಾಟಲ್ನೆಕ್ (bottleneck) ಪ್ರದೇಶದಲ್ಲಿ Iflytek/domux ಕಾರ್ಯಪ್ರವೃತ್ತವಾಗುತ್ತದೆ. ಇದು ಕೇವಲ ಒಂದು ಪ್ರಮುಖ ಕೆಲಸಕ್ಕಾಗಿ ನಿರ್ಮಿಸಲಾದ ಮುಕ್ತ ಮೂಲದ (open-source) ಮಾದರಿಯಾಗಿದೆ: ಅದುವೇ ವೇಗದ ಕಮಾಂಡ್ ಅರ್ಥೈಸುವಿಕೆ (fast command understanding). ಪ್ರಬಂಧಗಳನ್ನು ಬರೆಯುವ ಅಥವಾ ಮುಕ್ತ ಸಂಭಾಷಣೆಗಳನ್ನು ನಡೆಸುವ ಬದಲು, domux ನೈಸರ್ಗಿಕ ಭಾಷೆಯನ್ನು ವಿಶ್ಲೇಷಿಸುತ್ತದೆ ಮತ್ತು ಇತರ ಏಜೆಂಟ್ಗಳು ತಕ್ಷಣವೇ ಬಳಸಬಹುದಾದ ಕಟ್ಟುನಿಟ್ಟಾದ, ರಚನಾತ್ಮಕ ಡೇಟಾವನ್ನು (structured data) ನೀಡುತ್ತದೆ. ಸ್ಮಾರ್ಟ್ ಹೋಮ್ ಹಬ್ಗಳಿಂದ ಹಿಡಿದು ಕೈಗಾರಿಕಾ ನಿಯಂತ್ರಣ ಪ್ಯಾನೆಲ್ಗಳವರೆಗೆ, ನೈಜ-ಸಮಯದ ರಚನಾತ್ಮಕ ಇನ್ಪುಟ್ ಅಗತ್ಯವಿರುವ ಯಾವುದೇ ವ್ಯವಸ್ಥೆಯು ಇದನ್ನು ಪರ್ಸೆಪ್ಶನ್ ಲೇಯರ್ (perception layer) ಆಗಿ ಬಳಸಬಹುದು.
ಸರಪಳಿಯ ಅತ್ಯಂತ ದುರ್ಬಲ ಕೊಂಡಿ
ಒಬ್ಬ ಬಳಕೆದಾರರು "ಇಲ್ಲಿ ಸ್ವಲ್ಪ ಬೆಳಕನ್ನು ಹೆಚ್ಚಿಸು" (make it brighter in here) ಎಂಬ ಸರಳ ಕಮಾಂಡ್ ನೀಡಿದಾಗ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. ಮಲ್ಟಿ-ಏಜೆಂಟ್ ಸೆಟಪ್ನಲ್ಲಿ, ಆ ಹೇಳಿಕೆಯು ಲೈಟಿಂಗ್ ಕಂಟ್ರೋಲರ್, ಎನರ್ಜಿ ಮಾನಿಟರ್ ಮತ್ತು ಸೆಕ್ಯುರಿಟಿ ಲಾಗಿಂಗ್ ವ್ಯವಸ್ಥೆಯ ಮೂಲಕ ಹಾದುಹೋಗಬೇಕಾಗಬಹುದು. ಆರಂಭಿಕ ಪಾರ್ಸರ್ (parser) "ಬಳಕೆದಾರರಿಗೆ ಹೆಚ್ಚಿನ ಬೆಳಕು ಬೇಕು" ಎಂಬ ಅಸ್ಪಷ್ಟ ವಾಕ್ಯವನ್ನು ನೀಡಿದರೆ, ನಂತರದ ಪ್ರತಿಯೊಂದು ಏಜೆಂಟ್ ಕೂಡ ಅದರ ಅರ್ಥವನ್ನು ಮರು ವ್ಯಾಖ್ಯಾನಿಸಬೇಕಾಗುತ್ತದೆ. ಕೆಲವು ಏಜೆಂಟ್ಗಳು ನಿಖರವಾದ ಪ್ಯಾರಾಮೀಟರ್ಗಳಿಗಾಗಿ ಕಾಯುತ್ತಾ ನಿಂತುಹೋಗಬಹುದು. ಇತರೆಗಳು ಕೋಣೆಯನ್ನು ಅಥವಾ ಬೆಳಕಿನ ಮಟ್ಟವನ್ನು ಊಹಿಸಿ ತಪ್ಪು ಮಾಡಬಹುದು. ಇದರಿಂದಾಗಿ ಇಡೀ ವರ್ಕ್ಫ್ಲೋ ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತದೆ.
ವಿಳಂಬವು (Latency) ಸಮಸ್ಯೆಯನ್ನು ಮತ್ತಷ್ಟು ಉಲ್ಬಣಗೊಳಿಸುತ್ತದೆ. ಪ್ರವೇಶ ಹಂತದಲ್ಲಿ ಕೆಲವು ನೂರಾರು ಮಿಲಿಸೆಕೆಂಡ್ಗಳ ವಿಳಂಬವನ್ನು ಸೇರಿಸಿದರೆ, ಮಾಹಿತಿ ಮೂರನೇ ಏಜೆಂಟ್ಗೆ ತಲುಪುವ ಹೊತ್ತಿಗೆ, ವ್ಯವಸ್ಥೆಯು ಈಗಾಗಲೇ ಕೆಟ್ಟುಹೋದಂತೆ ಭಾಸವಾಗುತ್ತದೆ. ನೈಜ-ಸಮಯದ ಪರಿಸರಗಳು ನಿಧಾನಗತಿಯ ಆರಂಭವನ್ನು ಸಹಿಸುವುದಿಲ್ಲ. ಆರ್ಕಿಟೆಕ್ಚರ್ ಡೈಗ್ರಾಮ್ಗಳಲ್ಲಿ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಫ್ರೇಮ್ವರ್ಕ್ಗಳು ಸುಂದರವಾಗಿ ಕಂಡರೂ, ಅಸ್ಪಷ್ಟ ಅಥವಾ ನಿಧಾನಗತಿಯ ಇನ್ಪುಟ್ಗಳನ್ನು ನೀಡಿದಾಗ ಅವು ಕುಸಿದು ಬೀಳುತ್ತವೆ ಎಂಬುದು ಡೆವಲಪರ್ಗಳಿಗೆ ತಿಳಿಯುತ್ತಿದೆ. ಉಳಿದ ವರ್ಕ್ಫ್ಲೋ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲೇ ಕಮಾಂಡ್ಗಳನ್ನು ಪ್ರಮಾಣೀಕರಿಸಲು ನಿಮಗೆ ಒಂದು ಮೀಸಲಾದ ಲೇಯರ್ ಅಗತ್ಯವಿದೆ.
Domux ಅಂತಹ ಲೇಯರ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಇದು ಅಸ್ಪಷ್ಟ ಮಾನವ ಭಾಷೆಯನ್ನು ಸ್ವೀಕರಿಸಿ, ಅದನ್ನು ಕೆಳಮಟ್ಟದ ಏಜೆಂಟ್ಗಳು ಸತ್ಯಾಂಶವಾಗಿ (ground truth) ಪರಿಗಣಿಸಬಹುದಾದ ಸ್ವಚ್ಛವಾದ ಸ್ಕೀಮಾಗಿ (clean schema) ಪರಿವರ್ತಿಸುತ್ತದೆ.
ವೇಗ, ರಚನೆ ಮತ್ತು ನಿಖರತೆ
ಈ ಯೋಜನೆಯು ಉತ್ಪಾದನಾ ವರ್ತನೆಯ ಮೇಲೆ (production behavior) ನೇರವಾಗಿ ಪರಿಣಾಮ ಬೀರುವ ಮೂರು ಗುಣಲಕ್ಷಣಗಳನ್ನು ಪ್ರಚಾರ ಮಾಡುತ್ತದೆ.
ಮೊದಲನೆಯದಾಗಿ, ಇದು 150 ಮಿಲಿಸೆಕೆಂಡ್ಗಳಿಗಿಂತ ಕಡಿಮೆ ಸಮಯದಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ. ಈ ಮಿತಿಯು ಬಹಳ ಮುಖ್ಯವಾಗಿದೆ. ಸಂವಾದಾತ್ಮಕ ಸೆಟ್ಟಿಂಗ್ಗಳಲ್ಲಿ, ಕಾಲು ಸೆಕೆಂಡಿಗಿಂತ ಕಡಿಮೆ ಸಮಯದ ಪ್ರತಿಕ್ರಿಯೆಯು ತಕ್ಷಣವೇ ನಡೆದಂತೆ ಭಾಸವಾಗುತ್ತದೆ, ಆದರೆ ಒಂದು ಸೆಕೆಂಡ್ಗೆ ಹತ್ತಿರವಾಗುವ ಯಾವುದೇ ಪ್ರತಿಕ್ರಿಯೆಯು ಬಳಕೆದಾರರು ಪರಿಕರವನ್ನು ಬಳಸುವುದನ್ನು ಬಿಟ್ಟುಬಿಡುವಂತೆ ಮಾಡುತ್ತದೆ. ಇನ್ಪುಟ್ ಧ್ವನಿಯ ಮೂಲಕ ಇರಲಿ ಅಥವಾ ಚಾಟ್ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಇರಲಿ, domux ಪೈಪ್ಲೈನ್ ಅನ್ನು ನಿರಂತರವಾಗಿ ಚಲಿಸುವಂತೆ ಮಾಡುತ್ತದೆ.
ಎರಡನೆಯದಾಗಿ, ಇದು ಇನ್ಪುಟ್ಗಳನ್ನು ಕಟ್ಟುನಿಟ್ಟಾದ ಏಳು-ಫೀಲ್ಡ್ ಸ್ಕೀಮಾಗೆ (seven-field schema) ಮ್ಯಾಪ್ ಮಾಡುತ್ತದೆ. ಕೆಳಮಟ್ಟದ ವ್ಯವಸ್ಥೆಗಳು ಡಿಕೋಡ್ ಮಾಡಲು ಯಾವುದೇ ಮುಕ್ತ ಪಠ್ಯ (free-form text) ಇರುವುದಿಲ್ಲ. ಪ್ರತಿಯೊಂದು ಕಮಾಂಡ್ ಅನ್ನು ಮುನ್ಸೂಚಿಸಬಹುದಾದ ಕಾಲಂಟ್ಗಳಿಗೆ ವಿಂಗಡಿಸಲಾಗುತ್ತದೆ.
ಮೂರನೆಯದಾಗಿ, ಇದು 100 ಪ್ರತಿಶತ ಫಾರ್ಮ್ಯಾಟ್ ಅನುಸರಣೆಯೊಂದಿಗೆ (format compliance) 98.37 ಪ್ರತಿಶತ ನಿಖರತೆಯನ್ನು ಹೊಂದಿದೆ ಎಂದು ಪ್ರತಿಪಾದಿಸುತ್ತದೆ. ನಿಖರತೆ ಎಂದರೆ ಮಾದರಿಯು ಸಾಮಾನ್ಯವಾಗಿ ಬಳಕೆದಾರರನ್ನು ಸರಿಯಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ ಎಂದರ್ಥ. ಫಾರ್ಮ್ಯಾಟ್ ಅನುಸರಣೆ ಎಂದರೆ ಔಟ್ಪುಟ್ ಪ್ರತಿ ಬಾರಿಯೂ ರಚನಾತ್ಮಕವಾಗಿ ಸರಿಯಾಗಿರುತ್ತದೆ ಎಂದರ್ಥ. 99 ಪ್ರತಿಶತ ನಿಖರತೆ ಹೊಂದಿದ್ದರೂ, ಸಾಂದರ್ಭಿಕವಾಗಿ ಒಂದು ಫೀಲ್ಡ್ ಅನ್ನು ಬಿಟ್ಟುಬಿಡುವ ಅಥವಾ ಹೊಸದನ್ನು ಸೃಷ್ಟಿಸುವ ಪಾರ್ಸರ್ ಸ್ವಯಂಚಾಲಿತ ಸರಪಳಿಯಲ್ಲಿ ಹೊರೆಯಾಗುತ್ತದೆ. ಒಂದು ತಪ್ಪಾದ ಸಾಲು (malformed row) ಕನ್ಸ್ಯೂಮರ್ ಏಜೆಂಟ್ ಅನ್ನು ಕ್ರ್ಯಾಶ್ ಮಾಡಬಹುದು.
ಔಟ್ಪುಟ್ ವಾಸ್ತವವಾಗಿ ಹೇಗಿರುತ್ತದೆ ಎಂಬುದನ್ನು ಇಲ್ಲಿ ನೋಡಿ. ಮಾದರಿಯು ಕಮಾಂಡ್ ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದಾಗ, ಅದು ಪೈಪ್-ಡೆಲಿಮಿಟೆಡ್ (pipe-delimited) ರೆಕಾರ್ಡ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ:
action|device|attribute|value|unit|room|floor
turnOn|light|brightness|80|percent|living room|ground floor
ಈ ಫಾರ್ಮ್ಯಾಟ್ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿದೆ. ಪೈಪ್-ಡೆಲಿಮಿಟೆಡ್ ಪಠ್ಯವನ್ನು ಯಾವುದೇ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯಲ್ಲಿ ಭಾರೀ ಅವಲಂಬನೆಗಳಿಲ್ಲದೆ (heavy dependencies) ಸುಲಭವಾಗಿ ಪಾರ್ಸ್ ಮಾಡಬಹುದು. ಇದು JSON ಬ್ಲೋಟ್ (bloat) ಮತ್ತು ನೆಸ್ಟೆಡ್ ಸೀರಿಯಲೈಸೇಶನ್ನ (nested serialization) ವಿಳಂಬವನ್ನು ತಪ್ಪಿಸುತ್ತದೆ. ಲೈಟಿಂಗ್ ಏಜೆಂಟ್ ಕಮಾಂಡ್ ಮತ್ತು ಸಾಧನದ ಕಾಲಂಟ್ಗಳನ್ನು ಓದಿ ತಕ್ಷಣವೇ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು. ಲಾಗಿಂಗ್ ಏಜೆಂಟ್ ಮತ್ತೊಂದು ಇನ್ಫರೆನ್ಸ್ ಪಾಸ್ ನಡೆಸದೆ ಕೋಣೆ ಮತ್ತು ಮಹಡಿಯನ್ನು ಹೊರತೆಗೆಯಬಹುದು. ಈ ರಚನೆಯು ವಿನ್ಯಾಸದ ಮೂಲಕವೇ ಅಸ್ಪಷ್ಟತೆಯನ್ನು ನಿವಾರಿಸುತ್ತದೆ.
ಅಸ್ಪಷ್ಟ ಮಾನವ ಉದ್ದೇಶಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು
ನೈಜ ಜನರು API ಡಾಕ್ಯುಮೆಂಟೇಶನ್ನಂತೆ ಮಾತನಾಡುವುದಿಲ್ಲ. ಅವರು "ಸ್ವಲ್ಪ ಬೆಳಕನ್ನು ಹೆಚ್ಚಿಸು" ಅಥವಾ "ಇಲ್ಲಿನ ವಾತಾವರಣವನ್ನು ಸ್ವಲ್ಪ ಬೆಚ್ಚಗಾಗಿಸು" ಎಂಬಂತಹ ಮಾತುಗಳನ್ನು ಹೇಳುತ್ತಾರೆ. ಒಂದು ಅಸ್ಥಿರ ಪಾರ್ಸರ್ ಇಂತಹ ಸಂದರ್ಭಗಳಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ. Domux ಉದ್ದೇಶವನ್ನು ಒಂದು ಹೊಂದಾಣಿಕೆಯ ಕ್ರಿಯೆಗೆ (adjustment action) ಮ್ಯಾಪ್ ಮಾಡುವ ಮೂಲಕ ಮತ್ತು ಕೆಳಮಟ್ಟದ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ನಿಖರವಾದ ಮೌಲ್ಯವನ್ನು ನಿರ್ಧರಿಸಲು ಬಿಡುವ ಮೂಲಕ ಅಸ್ಪಷ್ಟತೆಯನ್ನು ನಿಭಾಯಿಸುತ್ತದೆ. ಯಾರಾದರೂ "ಸ್ವಲ್ಪ ಬೆಳಕನ್ನು ಹೆಚ್ಚಿಸು" ಎಂದು ಹೇಳಿದರೆ, ಮಾದರಿಯು ಆ ಕ್ರಿಯೆಯನ್ನು ಬ್ರೈಟ್ನೆಸ್ ಹೆಚ್ಚಿಸುವ ಕ್ರಿಯೆಯೆಂದು ಗುರುತಿಸುತ್ತದೆ. ನಿರ್ದಿಷ್ಟ ಸಂಖ್ಯೆಯ ಮಟ್ಟವನ್ನು ಪ್ರಸ್ತುತ ರೀಡಿಂಗ್ಗಳು, ಸಮಯ ಅಥವಾ