ಧ್ವನಿ (Voice) ಎಂಬುದು ಪ್ರತಿಯೊಂದು AI ಏಜೆಂಟ್ ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಕೂಡ ತೀವ್ರವಾಗಿ ಬಿಡುಗಡೆ ಮಾಡಲು ಬಯಸುವ ವೈಶಿಷ್ಟ್ಯವಾಗಿದೆ. ಇದನ್ನು ನಿಮ್ಮ ವೆಬ್ ಆಪ್, CLI ಟೂಲ್ ಅಥವಾ ಟೆಲಿಗ್ರಾಮ್ ಬಾಟ್ ಪಕ್ಕದಲ್ಲಿರುವ ಒಂದು ಸ್ವತಂತ್ರ ಚಾನಲ್ (standalone channel) ಆಗಿ ನಿರ್ಮಿಸುವುದು ಸಾಮಾನ್ಯ ಕ್ರಮವಾಗಿದೆ. ಇದು ಸಹಜವೆಂದು ಅನಿಸುತ್ತದೆ. ಧ್ವನಿ ಎಂದರೆ ಧ್ವನಿ ಸಂವಾದದ ಇಂಟರ್ಫೇಸ್ ಸೃಷ್ಟಿಸುವುದು ಎಂದೇ ಅರ್ಥೈಸಿಕೊಳ್ಳುತ್ತೇವೆ. ಆದರೆ ಈ ಸಹಜ ಪ್ರವೃತ್ತಿಯು ಒಂದು ದುರ್ಬಲ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಇದು ಕೆಲಸವನ್ನು ದ್ವಿಗುಣಗೊಳಿಸುತ್ತದೆ, ನಿಮ್ಮ ಲಾಗ್ಗಳನ್ನು (logs) ಹಾಳುಮಾಡುತ್ತದೆ ಮತ್ತು ನಿಧಾನವಾಗಿ ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ ಸಂದರ್ಭವನ್ನು (project context) ಅಸ್ತವ್ಯಸ್ತಗೊಳಿಸುತ್ತದೆ.
APC ಮತ್ತು APX ನಲ್ಲಿ, ನಾವು ವಿಭಿನ್ನ ಮಾರ್ಗವನ್ನು ಆರಿಸಿಕೊಂಡಿದ್ದೇವೆ. ಧ್ವನಿ ಎಂಬುದು ಒಂದು ಚಾನಲ್ ಅಲ್ಲ. ಅದು ಒಂದು 'ಮೋಡ್' (mode). ಅದು ಯಾವುದನ್ನೋ ಬದಲಾಯಿಸುವ ಬದಲು, ಒಂದು ಸರ್ಫೇಸ್ನ (surface) ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಈ ವ್ಯತ್ಯಾಸವನ್ನು ಸರಿಯಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ವ್ಯವಸ್ಥೆಯು ಚದುರಿಹೋಗದಂತೆ ತಡೆಯುತ್ತದೆ.
ತಪ್ಪು ಅಬ್ಸ್ಟ್ರಾಕ್ಷನ್ (The Wrong Abstraction)
ನೀವು ಧ್ವನಿಯನ್ನು ತನ್ನದೇ ಆದ ಚಾನಲ್ ಎಂದು ಪರಿಗಣಿಸಿದಾಗ, ಏಜೆಂಟ್ಗೆ ಮಾತನಾಡುವುದು ಟೈಪ್ ಮಾಡುವುದಕ್ಕಿಂತ ಮೂಲಭೂತವಾಗಿ ಭಿನ್ನವಾದ ಸಂಭಾಷಣೆ ಎಂದು ನೀವು ಅಲಿಖಿತವಾಗಿ ಭಾವಿಸುತ್ತೀರಿ. ಇಂಜಿನಿಯರಿಂಗ್ ತಂಡಗಳು ಕೋಡ್ಬೇಸ್ ಅನ್ನು ವಿಭಜಿಸುವ ಮೂಲಕ ಇದಕ್ಕೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತವೆ. ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಅಲ್ಲಿ ಒಂದು CLI ಚಾನಲ್ ಮತ್ತು ಪ್ರತ್ಯೇಕವಾದ voice-CLI ಚಾನಲ್ ಉಂಟಾಗುತ್ತದೆ. ಒಂದು ವೆಬ್ ಚಾನಲ್ ಮತ್ತು ಅದರ ಸಮಾನಾಂತರವಾಗಿ ಒಂದು voice-web ಚಾನಲ್ ಉಂಟಾಗುತ್ತದೆ. ಪ್ರತಿಯೊಂದೂ ತನ್ನದೇ ಆದ ಪ್ರಾಂಪ್ಟ್ ವೈವಿಧ್ಯತೆಗಳು (prompt variations), ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ನಿಯಮಗಳು ಮತ್ತು ಸಂದರ್ಭ ನಿರ್ವಹಣಾ ತರ್ಕವನ್ನು (context handling logic) ಬಯಸುತ್ತದೆ.
ಇಲ್ಲಿಯೇ ಗೊಂದಲ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಏಜೆಂಟ್ನ ನಡವಳಿಕೆಯಲ್ಲಿ ಮಾಡುವ ಸಣ್ಣ ಬದಲಾವಣೆಯನ್ನು ಈಗ ಹಲವಾರು ಪ್ರಾಂಪ್ಟ್ ಟ್ರೀಗಳಲ್ಲಿ (prompt trees) ಕಾಪಿ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಒಂದು ವೇಳೆ ತಂಡವು ಯಾವುದಾದರೂ ಒಂದು ಸರ್ಫೇಸ್ ಅನ್ನು ಮರೆತರೆ, ಬಳಕೆದಾರರ ಅನುಭವವು ಚದುರಿಹೋಗುತ್ತದೆ. ಬಳಕೆದಾರರು ಪಠ್ಯದ ಮೂಲಕ ಒಂದು ರೀತಿಯ ಧ್ವನಿ ಮತ್ತು ಮಾತಿನ ಮೂಲಕ ಸ್ವಲ್ಪ ವಿಭಿನ್ನವಾದ ವ್ಯಕ್ತಿತ್ವವನ್ನು ಪಡೆಯುತ್ತಾರೆ. ಕಾಲಾನಂತರದಲ್ಲಿ, ಈ ಸಣ್ಣ ಅಸಂಗತತೆಗಳು ವ್ಯವಸ್ಥೆಯ ಅಸ್ಥಿರತೆಗೆ ಕಾರಣವಾಗುತ್ತವೆ. ಪೋರ್ಟಬಲ್ ಸಂದರ್ಭದ ಪದರವು (portable context layer) ತನ್ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ, ಏಕೆಂದರೆ ಅದು ಒಂದು ಬ್ರಾಂಚ್ನಲ್ಲಿ ಧ್ವನಿ ಮತ್ತು ಇನ್ನೊಂದರಲ್ಲಿ ಮೌನ ಪಠ್ಯವನ್ನು ಪರಿಗಣಿಸಬೇಕಾಗುತ್ತದೆ. ಅಬ್ಸ್ಟ್ರಾಕ್ಷನ್ ಸೋರಿಕೆಯಾಗುತ್ತದೆ (abstraction leaks), ಮತ್ತು ನಿಮ್ಮ ಒಮ್ಮಿತವಾಗಿದ್ದ ಪ್ರಾಜೆಕ್ಟ್ ವ್ಯಾಖ್ಯಾನವು ಚಾನಲ್-ನಿರ್ದಿಷ್ಟ ಹ್ಯಾಕ್ಗಳ ಸಂಗ್ರಹವಾಗಿ ಚದುರಿಹೋಗುತ್ತದೆ.
ಸಂದರ್ಭವನ್ನು (Context) ರನ್ಟೈಮ್ನಿಂದ (Runtime) ಪ್ರತ್ಯೇಕಿಸುವುದು
ಇದನ್ನು ತಡೆಯಲು, ನಾವು ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರತ್ಯೇಕವಾಗಿರುವ ಎರಡು ಪದರಗಳ ನಡುವೆ ಜವಾಬ್ದಾರಿಗಳನ್ನು ವಿಭಜಿಸುತ್ತೇವೆ.
APC ಪ್ರಾಜೆಕ್ಟ್ ಸಂದರ್ಭವನ್ನು (project context) ಹೊಂದಿರುತ್ತದೆ. ಇದು ಏಜೆಂಟ್ಗಳು, ನಿಯಮಗಳು ಮತ್ತು ಒಂದು ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು ರೂಪಿಸುವ ಕೌಶಲ್ಯಗಳನ್ನು (skills) ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ. ಇದನ್ನು ವ್ಯವಸ್ಥೆಯ ಸ್ಥಿರವಾದ ಅರ್ಥ ಎಂದು ಭಾವಿಸಿ. ಇದು ರಚನಾತ್ಮಕ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತದೆ. ಈ ಏಜೆಂಟ್ಗೆ ಏನು ತಿಳಿದಿದೆ? ಅದಕ್ಕೆ ಏನು ಮಾಡಲು ಅನುಮತಿಯಿದೆ? ಅದು ಯಾವ ಪರಿಕರಗಳನ್ನು (tools) ಬಳಸಬಹುದು? ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪರದೆಯ ಮೇಲೆ ಪ್ರದರ್ಶಿಸಲಾಗುತ್ತಿದೆಯೇ, ಚಾಟ್ API ಮೂಲಕ ಕಳುಹಿಸಲಾಗುತ್ತಿದೆಯೇ ಅಥವಾ ಸ್ಪೀಕರ್ ಮೂಲಕ ಹೊರಬರುತ್ತಿದೆಯೇ ಎಂಬುದರ ಬಗ್ಗೆ APC ಸಂಪೂರ್ಣವಾಗಿ ತಟಸ್ಥವಾಗಿರಬೇಕು.
APX ರನ್ಟೈಮ್ ಪದರವನ್ನು (runtime layer) ನಿರ್ವಹಿಸುತ್ತದೆ. ನೀವು ವಾಸ್ತವವಾಗಿ ಬಳಸುವ ಸರ್ಫೇಸ್ಗಳನ್ನು ಇದು ನಿರ್ವಹಿಸುತ್ತದೆ: CLI, ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್, ಡೆಸ್ಕ್ಟಾಪ್ ಇಂಟರ್ಫೇಸ್, ಟೆಲಿಗ್ರಾಮ್ ಬಾಟ್ ಇತ್ಯಾದಿ. ಬಳಕೆದಾರರು ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಿದಾಗ, APX ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಎಲ್ಲಿ ಮತ್ತು ಹೇಗೆ ಪ್ರಸ್ತುತಪಡಿಸಬೇಕೆಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. ಉತ್ತರವನ್ನು ಓದುವಿಕೆಗೆ ಅನುಗುಣವಾಗಿ ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡಬೇಕೆ ಅಥವಾ ಮಾತನಾಡುವುದಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಉತ್ತಮಗೊಳಿಸಬೇಕೆ ಎಂಬ ನಿರ್ಧಾರವು ರನ್ಟೈಮ್ ವಿಷಯವಾಗಿದೆ. ಇದು APC ಯಲ್ಲಲ್ಲದೆ APX ನಲ್ಲಿ ಇರಬೇಕು.
ಈ ಪ್ರತ್ಯೇಕತೆಯು, APX ಎಷ್ಟು ಸರ್ಫೇಸ್ಗಳನ್ನು ಪ್ರದರ್ಶಿಸಿದರೂ ಸಹ APC ಯಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ಪ್ರಾಜೆಕ್ಟ್ ಅಖಂಡವಾಗಿ ಉಳಿಯುತ್ತದೆ ಎಂದರ್ಥ. ಒಪ್ಪಂದವು (contract) ಬದಲಾಗುವುದಿಲ್ಲ, ಕೇವಲ ಪ್ರಸ್ತುತಿ ಪದರವು (presentation layer) ಮಾತ್ರ ಬದಲಾಗುತ್ತದೆ.
ಮೋಡ್ಗಳು (Modes) ವಾಸ್ತವವಾಗಿ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ
ನಮ್ಮ ಅನುಷ್ಠಾನದಲ್ಲಿ (implementation), ಟೆಲಿಗ್ರಾಮ್, CLI ಮತ್ತು ವೆಬ್ ಆಪ್ನಂತಹವುಗಳು ಚಾನಲ್ಗಳಾಗಿವೆ. ಚಾನಲ್ ಎಂಬುದು ಸಂವಹನ ಎಲ್ಲಿ ನಡೆಯಿತು ಎಂದು ತಿಳಿಸುತ್ತದೆ. ಧ್ವನಿಯು ಚಾನಲ್ ಮೆಟಾಡೇಟಾದ (metadata) ಮೂಲಕ ಒಂದು 'ಮೋಡ್' ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಮೋಡ್ ಎಂಬುದು ಪ್ರತಿಕ್ರಿಯೆಯು ಹೇಗೆ ವರ್ತಿಸಬೇಕು ಎಂದು ತಿಳಿಸುತ್ತದೆ.
ಪ್ರಾಂಪ್ಟ್ ಬಿಲ್ಡರ್ (prompt builder) ಈ ಗಡಿಯನ್ನು ಗೌರವಿಸುತ್ತದೆ. ಇದು APC ಯಲ್ಲಿನ ಪ್ರಾಜೆಕ್ಟ್ ಸಂದರ್ಭವನ್ನು ಪಡೆಯುತ್ತದೆ, ನಂತರ ಚಾನಲ್ ಮೆಟಾಡೇಟಾವನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಒಂದು ವೇಳೆ ಡೆಸ್ಕ್ಟಾಪ್ ಸರ್ಫೇಸ್ ಧ್ವನಿ ಮೋಡ್ನಲ್ಲಿ (voice mode) ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದರೆ, ಬಿಲ್ಡರ್ ಆ ಕ್ಷಣದಲ್ಲಿ ಮಾತ್ರ ನಿರ್ದಿಷ್ಟ ಸೂಚನೆಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ. ಬಹುಶಃ ಇದು ಮಾಡೆಲ್ಗೆ ಚಿಕ್ಕ ವಾಕ್ಯಗಳು, ಸಂಶ್ಲೇಷಣೆಗಾಗಿ (synthesis) ಸ್ಪಷ್ಟವಾದ ವಿರಾಮ ಚಿಹ್ನೆಗಳು ಅಥವಾ ಮಾತನಾಡುವ ಸಂಖ್ಯೆಗಳ ನಿಯಮಗಳ ಕಡೆಗೆ ಗಮನಹರಿಸಲು ಸೂಚಿಸಬಹುದು. ಅದೇ ಡೆಸ್ಕ್ಟಾಪ್ ಸರ್ಫೇಸ್ ಪಠ್ಯ ಮೋಡ್ನಲ್ಲಿ (text mode) ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದರೆ, ಆ ಧ್ವನಿ ಸೂಚನೆಗಳು ಪ್ರಾಂಪ್ಟ್ಗೆ ಎಂದಿಗೂ ಪ್ರವೇಶಿಸುವುದಿಲ್ಲ.
ಇದರ ಫಲಿತಾಂಶವು ಪ್ರತಿ ಸರ್ಫೇಸ್ಗೆ ಒಂದೇ ಪ್ರಾಂಪ್ಟ್ ಟ್ರೀ (prompt tree) ಆಗಿರುತ್ತದೆ. ಪ್ರತ್ಯೇಕವಾದ voice-desktop ಬ್ರಾಂಚ್ ಇರುವುದಿಲ್ಲ. whisper-web ಎಂಬ ವೈವಿಧ್ಯತೆಯೂ ಇರುವುದಿಲ್ಲ. ರನ್ಟೈಮ್ ಕೇಳಿದಾಗ ಮಾತ್ರ ಮತ್ತು ಅಂತಿಮ ಕ್ಷಣದಲ್ಲಿ ಮಾತ್ರ ಮಾರ್ಪಾಡು (modifier) ಅನ್ವಯಿಸುತ್ತದೆ. ಮೂಲ ಪ್ರಾಂಪ್ಟ್ ಸ್ಥಿರವಾಗಿರುತ್ತದೆ.
ನೀವು ಪಡೆಯುವ ಪ್ರಯೋಜನಗಳು
ಈ ಆರ್ಕಿಟೆಕ್ಚರ್ ಮೂರು ಪ್ರಾಯೋಗಿಕ ರೀತಿಯಲ್ಲಿ ಪ್ರಯೋಜನಕಾರಿಯಾಗಿದೆ.
ಕಡಿಮೆ ನಿರ್ವಹಣಾ ವೆಚ್ಚಗಳು (Lower maintenance costs). ಧ್ವನಿಯು ತನ್ನದೇ ಆದ ಚಾನಲ್ ಆಗಿದ್ದರೆ, ಪ್ರತಿಯೊಂದು ಸರ್ಫೇಸ್ಗೂ ಒಂದು ಅವಳಿ (twin) ಅಗತ್ಯವಿರುತ್ತಿತ್ತು. ನೀವು ಒಂದು CLI ಚಾನಲ್ ಮತ್ತು ಒಂದು voice-CLI ಚಾನಲ್, ಒಂದು ಟೆಲಿಗ್ರಾಮ್ ಚಾನಲ್ ಮತ್ತು ಒಂದು voice-Telegram ಚಾನಲ್ ಹೀಗೆ ನಿರ್ವಹಿಸಬೇಕಾಗುತ್ತಿತ್ತು. ನೀವು ಪ್ರತಿ ಬಾರಿ ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಹೊಂದಾಣಿಕೆ ಮಾಡಿದಾಗ, ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ಬಗ್ ಅನ್ನು ಸರಿಪಡಿಸಿದಾಗ ಅಥವಾ ಕೌಶಲ್ಯದ ವಿವರಣೆಯನ್ನು ಸುಧಾರಿಸಿದಾಗ, ಆ ಬದಲಾವಣೆಯನ್ನು ಎರಡೂ ಟ್ರೀಗಳಲ್ಲಿ ಪ್ರಸಾರ ಮಾಡಬೇಕಾಗುತ್ತಿತ್ತು. ಒಂದು ವೇಳೆ ಮರೆತರೆ, ಬಳಕೆದಾರರು ಆ ವ್ಯತ್ಯಾಸವನ್ನು ಗಮನಿಸುತ್ತಾರೆ. 'ಮೋಡ್' ಅನ್ನು ಬಳಸುವ ಮೂಲಕ, ನೀವು ಪ್ರತಿ ಸರ್ಫೇಸ್ಗೆ ಒಂದೇ ಪ್ರಾಂಪ್ಟ್ ಟ್ರೀ ಅನ್ನು ಹೊಂದಿರುತ್ತೀರಿ. ಧ್ವನಿಯು ಹಾದಿಯ ವಿಭಜನೆಯ ಬದಲು ಒಂದು 'ಕಂಡೀಷನಲ್ ಓವರ್ಲೇ' (conditional overlay) ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನೀವು ಸಂವಹನ ನಡೆಸಲು ಹೊಸ ವಿಧಾನಗಳನ್ನು ಸೇರಿಸಿದಾಗಲೂ ನಿಮ್ಮ ಕೆಲಸದ ಹೊರೆ ಸ್ಥಿರವಾಗಿರುತ್ತದೆ.
ನಿಖರವಾದ ಲಾಗಿಂಗ್. ಚಾನಲ್ಗಳು ಸಂವಹನ ಎಲ್ಲಿ ನಡೆಯಿತು ಎಂಬುದನ್ನು ದಾಖಲಿಸುತ್ತವೆ. ಮೋಡ್ಗಳು ಪ್ರತಿಕ್ರಿಯೆಯು ಹೇಗೆ ತಲುಪಿತು ಎಂಬುದನ್ನು ದಾಖಲಿಸುತ್ತವೆ. ಬಳಕೆದಾರನು ಅದನ್ನು ಓದಿದರೂ ಅಥವಾ ಕೇಳಿದರೂ, ಡೆಸ್ಕ್ಟಾಪ್ ಸಂವಹನವು ಡೆಸ್ಕ್ಟಾಪ್ ಸಂವಹನವಾಗಿಯೇ ಉಳಿಯುತ್ತದೆ. ನಿಮ್ಮ ತಂಡವು ಬಗ್ ಅನ್ನು ಪತ್ತೆಹಚ್ಚುವಾಗ ಅಥವಾ ಅನಾಲಿಟಿಕ್ಸ್ ಅನ್ನು ಪರಿಶೀಲಿಸುವಾಗ, 'desktop-voice' ಮತ್ತು 'desktop-text' ಅನ್ನು ವಿಭಿನ್ನ ಉತ್ಪನ್ನಗಳಂತೆ ಪರಿಗಣಿಸಿ ಹೊಂದಾಣಿಕೆ ಮಾಡಬೇಕಾಗಿಲ್ಲ. ಚಾನಲ್ ಐಡೆಂಟಿಫೈಯರ್ ಸ್ವಚ್ಛವಾಗಿರುತ್ತದೆ ಮತ್ತು ಮೋಡ್ ಫ್ಲಾಗ್ ಮೆಟಾಡಾಟಾದಲ್ಲಿ ಅದರ ಪಕ್ಕದಲ್ಲೇ ಇರುತ್ತದೆ. ಸ್ಥಳ ಮತ್ತು ವರ್ತನೆಯು ಒಂದಕ್ಕೊಂದು ಬೆರೆತಿರದ ಕಾರಣ, ನಿಮ್ಮ ಲಾಗ್ಗಳು ನಿಖರವಾಗಿರುತ್ತವೆ ಮತ್ತು ડીಬಗ್ ಮಾಡುವುದು ಸರಳವಾಗಿರುತ್ತದೆ.
ಸ್ವಚ್ಛವಾದ ಪ್ರಾಜೆಕ್ಟ್ ಸಂದರ್ಭ. APC ಒಪ್ಪಂದವನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ. ಪ್ರತಿಕ್ರಿಯೆಯು ಮಾತನಾಡಲಾಗಿದೆಯೇ, ಪಿಸುಗುಟ್ಟಲಾಗಿದೆಯೇ ಅಥವಾ ಮೊನೊಸ್ಪೇಸ್ ಫಾಂಟ್ನಲ್ಲಿ ಪ್ರದರ್ಶಿಸಲಾಗಿದೆಯೇ ಎಂಬುದು ಅದಕ್ಕೆ ಮುಖ್ಯವಾಗಬಾರದು. ಅವು ರನ್ಟೈಮ್ ವಿಷಯಗಳಾಗಿವೆ. ವಾಯ್ಸ್ ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ಅನ್ನು APX ಒಳಗೆ ಇರಿಸುವ ಮೂಲಕ, ನಾವು APC ನ ಪೋರ್ಟಬಿಲಿಟಿಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತೇವೆ. ನೀವು ವಾಯ್ಸ್-ನಿರ್ದಿಷ್ಟ ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ಕಲ್ಪನೆಗಳು ಅಥವಾ ಸ್ಪೀಚ್-ಆಪ್ಟಿಮೈಸೇಶನ್ನಂತಹ ಅಗತ್ಯವಿಲ್ಲದ ಅಂಶಗಳನ್ನು ಎಳೆದುಕೊಂಡು ಹೋಗದೆ, ಒಂದು APC ಪ್ರಾಜೆಕ್ಟ್ ವ್ಯಾಖ್ಯಾನವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಹೊಸ ರನ್ಟೈಮ್ ಪರಿಸರಕ್ಕೆ ವರ್ಗಾಯಿಸಬಹುದು. ಗಡಿ ಸ್ಥಿರವಾಗಿರುತ್ತದೆ ಮತ್ತು ಪ್ರಾಜೆಕ್ಟ್ನ ಅರ್ಥವು ಸ್ಥಿರವಾಗಿ ಉಳಿಯುತ್ತದೆ.
ಡೆಸ್ಕ್ಟಾಪ್ನಲ್ಲಿ ಸಾಕ್ಷ್ಯ
ನಮ್ಮದೇ ಆದ ಡೆಸ್ಕ್ಟಾಪ್ ಮಾರ್ಗವು ದೈನಂದಿನ ಬಳಕೆಯಲ್ಲಿ ಇದನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತದೆ. ಡೆಸ್ಕ್ಟಾಪ್ ಎಂಬುದು ಸರ್ಫೇಸ್. ಬಳಕೆದಾರನು ಸ್ಪೀಚ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದಾಗ, ಸಿಸ್ಟಮ್ ಅದೇ ಡೆಸ್ಕ್ಟಾಪ್ ಸರ್ಫೇಸ್ ಅನ್ನು ವಾಯ್ಸ್ ಮೋಡ್ನಲ್ಲಿ ಚಲಾಯಿಸುತ್ತದೆ. ವಾಯ್ಸ್ ಮೋಡ್ ಲೇಯರ್ನಲ್ಲಿ ಇರುವುದರಿಂದ, ಡೆಸ್ಕ್ಟಾಪ್ ಚಾನಲ್ ತನ್ನ ಸಂಪೂರ್ಣ ಸಂದರ್ಭ ಮತ್ತು ವರ್ತನೆಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಇದು ವಿಭಿನ್ನ ನಿಯಮಗಳಿರುವ ಬೇರೆ ಉತ್ಪನ್ನವಾಗುವುದಿಲ್ಲ. ಪ್ರಾಂಪ್ಟ್ ಬಿಲ್ಡರ್ ಕೇವಲ ಫ್ಲಾಗ್ ಅನ್ನು ಗಮನಿಸುತ್ತದೆ ಮತ್ತು ಅಗತ್ಯವಿದ್ದಾಗ ಮಾತ್ರ ವಾಯ್ಸ್ ಸೂಚನೆಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ. ಬಳಕೆದಾರನು ಮತ್ತೆ ಪಠ್ಯಕ್ಕೆ ಬದಲಾಯಿಸಿದಾಗ, ಆ ಸೂಚನೆಗಳು ಸಂಪೂರ್ಣವಾಗಿ ಮಾಯವಾಗುತ್ತವೆ. ಮೂಲ ಪ್ರಾಜೆಕ್ಟ್ ಸಂದರ್ಭವು ಎಂದಿಗೂ ಬದಲಾಗಲಿಲ್ಲ. ಡೆಸ್ಕ್ಟಾಪ್ ಯಾವಾಗಲೂ ಡೆಸ್ಕ್ಟಾಪ್ ಆಗಿಯೇ ಇತ್ತು.
ನಿಜವಾದ ಸಾರಾಂಶ
ಮೂಲ ಕಲ್ಪನೆಯು ಸರಳವಾಗಿದೆ. APC ಸ್ಥಿರವಾದ ಪ್ರಾಜೆಕ್ಟ್ ಅರ್ಥವನ್ನು ವಿವರಿಸುತ್ತದೆ. APX ರನ್ಟೈಮ್ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ. ವಾಯ್ಸ್ ಎಂಬುದು ಒಂದು ಸರ್ಫೇಸ್ನ ಮಾರ್ಪಡಕವೇ ಹೊರತು, ಅದಕ್ಕೆ ಬದಲಾವಣೆಯಲ್ಲ. ಅದನ್ನು ಹಾಗೆಯೇ ಪರಿಗಣಿಸಿ, ಆಗ ನಿಮ್ಮ ಪ್ರಾಂಪ್ಟ್ಗಳು ಚಿಕ್ಕದಾಗಿರುತ್ತವೆ. ನಿಮ್ಮ ಲಾಗ್ಗಳು ಸ್ಪಷ್ಟವಾಗಿರುತ್ತವೆ. ನಿಮ್ಮ