LLMಗಳು ನಿಮ್ಮ ಕೋಡ್ಗೆ ತಲುಪುವುದಿಲ್ಲ – ಅವು ನಿಮಗೆ ಒಂದು ವಿನಂತಿಯನ್ನು (request) ನೀಡುತ್ತವೆ, ಮತ್ತು ನೀವು ಆ ಫಂಕ್ಷನ್ ಅನ್ನು ರನ್ ಮಾಡಬೇಕು. "ಮಾದರಿ (model) ನನ್ನ ಪೈಥಾನ್ ರೂಟೀನ್ ಅನ್ನು ಮಾಂತ್ರಿಕವಾಗಿ ಕರೆಯುತ್ತದೆ" ಎಂಬ ಮಿಥ್ಯೆಯನ್ನು ಈ ಸರಳ ಸತ್ಯವು ತಲೆಕೆಳಗು ಮಾಡುತ್ತದೆ ಮತ್ತು ಡೆವಲಪರ್ಗಳು ಡೆಬಗ್ಗಿಂಗ್ ಮತ್ತು ಸೆಕ್ಯೂರಿಟಿಯನ್ನು ಮರುಪರಿಶೀಲಿಸುವಂತೆ ಮಾಡುತ್ತದೆ.
ಡಿಸ್ಪ್ಯಾಚ್ ಲೂಪ್ (dispatch loop), ಹಂತ ಹಂತವಾಗಿ
ಒಂದು ಲ್ಯಾಂಗ್ವೇಜ್ ಮಾಡೆಲ್ (LLM) ಗೆ ಟೂಲ್ ಅಗತ್ಯವಿದ್ದಾಗ, ಅದು ಒಂದು ನಿರ್ದಿಷ್ಟ ಕ್ರಮವನ್ನು ಅನುಸರಿಸುತ್ತದೆ:
- ಯೋಜನೆ (Planning) – ಒಂದು ಕ್ರಮದ ಅಗತ್ಯವಿದೆ ಎಂದು ಮಾಡೆಲ್ ನಿರ್ಧರಿಸುತ್ತದೆ (ಉದಾಹರಣೆಗೆ, "ಪಾವತಿಯನ್ನು ಮರುಪಾವತಿಸಿ" - refund a payment).
- ವಿನಂತಿಯನ್ನು ತಯಾರಿಸುವುದು (Generating a request) – ಇದು ರಚನಾತ್ಮಕ ಪಠ್ಯವನ್ನು—ಸಾಮಾನ್ಯವಾಗಿ JSON—ನೀಡುತ್ತದೆ, ಇದು ಟೂಲ್ನ ಹೆಸರನ್ನು ಮತ್ತು ಆರ್ಗ್ಯುಮೆಂಟ್ಗಳನ್ನು (arguments) ಒಳಗೊಂಡಿರುತ್ತದೆ.
- ಪಾರ್ಸಿಂಗ್ (Parsing) – ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅಥವಾ ಬೆಂಬಲಿತ ಫ್ರೇಮ್ವರ್ಕ್ ಆ ಪಠ್ಯವನ್ನು ಓದುತ್ತದೆ.
- ಮ್ಯಾಚಿಂಗ್ (Matching) – ನೀವು ಎಕ್ಸ್ಪೋಸ್ ಮಾಡಿದ ನೈಜ ಫಂಕ್ಷನ್ಗಳ ರಿಜಿಸ್ಟ್ರಿಯಲ್ಲಿ ಫ್ರೇಮ್ವರ್ಕ್ ಆ ಹೆಸರನ್ನು ಹುಡುಕುತ್ತದೆ.
- ವ್ಯಾಲಿಡೇಟಿಂಗ್ (Validating) – ಆರ್ಗ್ಯುಮೆಂಟ್ಗಳು ಫಂಕ್ಷನ್ನ ಸ್ಕೀಮಾಗೆ (schema) ಹೊಂದಿಕೆಯಾಗುತ್ತವೆಯೇ ಮತ್ತು ಕರೆಯುವವರಿಗೆ ಅಧಿಕಾರವಿದೆಯೇ ಎಂದು ಇದು ಪರಿಶೀಲಿಸುತ್ತದೆ.
- ಎಕ್ಸಿಕ್ಯೂಟಿಂಗ್ (Executing) – ಹೊಂದಿಕೆಯಾದ ಫಂಕ್ಷನ್ ನಿಮ್ಮ ಎನ್ವಿರಾನ್ಮೆಂಟ್ನಲ್ಲಿ ರನ್ ಆಗಿ ಕೆಲಸವನ್ನು ಮಾಡುತ್ತದೆ.
- ರಿಟರ್ನಿಂಗ್ (Returning) – ಫಲಿತಾಂಶವನ್ನು ಪ್ಯಾಕೇಜ್ ಮಾಡಿ ಮುಂದಿನ ತರ್ಕಕ್ಕಾಗಿ (reasoning) ಮಾಡೆಲ್ಗೆ ಮರಳಿ ಕಳುಹಿಸಲಾಗುತ್ತದೆ.
LLM ಅನ್ನು ಒಬ್ಬ ಯೋಜಕ (planner), ಫ್ರೇಮ್ವರ್ಕ್ ಅನ್ನು ಡಿಸ್ಪ್ಯಾಚರ್ (dispatcher), ಮತ್ತು ಫಂಕ್ಷನ್ ಅನ್ನು ಡೇಟಾ ಅಥವಾ ಹಣವನ್ನು ಚಲಾಯಿಸುವ ಕೆಲಸಗಾರ (worker) ಎಂದು ಭಾವಿಸಿ.
"ಮಾಂತ್ರಿಕ" ಎಂಬ ಮಿಥ್ಯ ಏಕೆ ಮುಂದುವರಿಯುತ್ತದೆ?
ಹೆಚ್ಚಿನ ಡೆವಲಪರ್ಗಳು ಮಾಡೆಲ್ನ ಔಟ್ಪುಟ್ನಲ್ಲಿ ಫಂಕ್ಷನ್ ಕಾಲ್ನಂತೆ ಕಾಣುವ ಒಂದು ಸಾಲನ್ನು ನೋಡಿ, ಮಾಡೆಲ್ ಸ್ವತಃ ಆ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಮಾಡಿದೆ ಎಂದು ಭಾವಿಸುತ್ತಾರೆ. ಪ್ರೊವೈಡರ್ ಡಾಕ್ಯುಮೆಂಟ್ಗಳಲ್ಲಿನ "ಟೂಲ್ ಕಾಲಿಂಗ್" (tool calling) ಎಂಬ ಪದವು ಮಾಡೆಲ್ ನೇರವಾಗಿ ಕೋಡ್ ಅನ್ನು ಕರೆಯುತ್ತಿದೆ ಎಂಬಂತೆ ಕೇಳಿಸುತ್ತದೆ.
ವಾಸ್ತವದಲ್ಲಿ, ಮಾಡೆಲ್ ಕೇವಲ ಒಂದು ಕಾಲ್ ಅನ್ನು ವಿವರಿಸುವ ಪಠ್ಯವನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ. ಲೂಕಪ್, ಟೈಪ್ ಚೆಕಿಂಗ್, ಅನುಮತಿ ಜಾರಿ (permission enforcement), ಮತ್ತು ಎರರ್ ಹ್ಯಾಂಡ್ಲಿಂಗ್ನಂತಹ ಕಠಿಣ ಕೆಲಸಗಳನ್ನು ನಿಮ್ಮ ಪ್ರಕ್ರಿಯೆಯೇ ಮಾಡುತ್ತದೆ.
ಒಳಗಿನ ಕಾರ್ಯವಿಧಾನವನ್ನು ಮರೆಮಾಚುವ ಫ್ರೇಮ್ವರ್ಕ್ಗಳು
PydanticAI ಮತ್ತು LangChain ನಂತಹ ಲೈಬ್ರರಿಗಳು ನೀವು ಬಿಸಿನೆಸ್ ಲಾಜಿಕ್ ಮೇಲೆ ಗಮನ ಹರಿಸಲು ಲೂಪ್ ಅನ್ನು ಅಬ್ಸ್ಟ್ರಾಕ್ಟ್ (abstract) ಮಾಡುತ್ತವೆ. ಅವು ಸ್ವಯಂಚಾಲಿತವಾಗಿ:
- ಆರ್ಗ್ಯುಮೆಂಟ್ಗಳನ್ನು ಸ್ಕೀಮಾಗೆ (ಉದಾಹರಣೆಗೆ, Pydantic ಮಾಡೆಲ್) ವಿರುದ್ಧ ವ್ಯಾಲಿಡೇಟ್ ಮಾಡುತ್ತವೆ.
- ಅನುಮತಿಗಳನ್ನು ಜಾರಿಗೊಳಿಸುತ್ತವೆ, ಬಳಕೆದಾರರು ಟೂಲ್ ಅನ್ನು ಟ್ರಿಗ್ಗರ್ ಮಾಡಬಹುದೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುತ್ತವೆ.
- ಸೋಲಾದಾಗ ಮರುಪ್ರಯತ್ನಿಸುತ್ತವೆ (Retry), ಟೂಲ್ ಎರರ್ ನೀಡಿದಾಗ ಮಾಡೆಲ್ಗೆ ಮರಳಿ ಕಳುಹಿಸುತ್ತವೆ.
- ಅತಿಯಾದ ಲೂಪ್ಗಳಿಂದ ರಕ್ಷಣೆ ನೀಡುತ್ತವೆ, ಸತತ ಟೂಲ್ ಕಾಲ್ಗಳಿಗೆ ಮಿತಿ ಹೇರುತ್ತವೆ.
- ಸಂಭಾಷಣೆಯ ಸ್ಥಿತಿಯನ್ನು (conversation state) ಕಾಯ್ದುಕೊಳ್ಳುತ್ತವೆ, ಟೂಲ್ ಫಲಿತಾಂಶಗಳನ್ನು ಸಂಭಾಷಣೆಯೊಂದಿಗೆ ಜೋಡಿಸುತ್ತವೆ.
ಈ ಸಹಾಯಗಾರರಿದ್ದರೂ ಸಹ, ಮಾದರಿಯು (pattern) ಒಂದೇ ಆಗಿರುತ್ತದೆ: ಮಾಡೆಲ್ ಎಂದಿಗೂ ಕೋಡ್ ಅನ್ನು ಎಕ್ಸಿಕ್ಯೂಟ್ ಮಾಡುವುದಿಲ್ಲ.
ಪ್ರೊವೈಡರ್ಗಳಿಂದ ನೇರ (Native) ಟೂಲ್-ಕಾಲಿಂಗ್ ಬೆಂಬಲ
ಕೆಲವು ಪ್ರೊವೈಡರ್ಗಳು ಟೂಲ್ ವ್ಯಾಖ್ಯಾನಗಳು ಮತ್ತು ವಿನಂತಿ ಫಾರ್ಮ್ಯಾಟ್ಗಳನ್ನು ಪ್ರಮಾಣೀಕರಿಸುವ "ನೇರ" (native) ಟೂಲ್-ಕಾಲಿಂಗ್ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ನೀಡುತ್ತಾರೆ. ಇದು ಇಂಟಿಗ್ರೇಷನ್ ಅನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ ಆದರೆ ಡಿಸ್ಪ್ಯಾಚ್ ಹಂತವನ್ನು ತೆಗೆದುಹಾಕುವುದಿಲ್ಲ. ವಿನಂತಿಸಿದ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ವಾಸ್ತವವಾಗಿ ರನ್ ಮಾಡುವ ಕೋಡ್ ಅನ್ನು ನೀವು ಇನ್ನೂ ಬರೆಯಬೇಕಾಗುತ್ತದೆ (ಅಥವಾ ಇಂಪೋರ್ಟ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ).
ಸಮಸ್ಯೆಯನ್ನು ಮರುನಾಮಕರಣ ಮಾಡಿದಾಗ ಡೆಬಗ್ಗಿಂಗ್ ಸುಲಭವಾಗುತ್ತದೆ
"ಗೊಂದಲಕ್ಕೊಳಗಾದ ಏಜೆಂಟ್" ಎಂದು ದೂಬುವ ಬದಲು, ಸಮಸ್ಯೆ "ಮಾದರಿಯ ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲಿ ಯಾವುದೇ ಟೂಲ್ ಕಾಲ್ಗಳು ಇರಲಿಲ್ಲ" ಎಂದು ಹೇಳಿ. ಈ ವ್ಯತ್ಯಾಸವು ಮುಖ್ಯವಾಗಿದೆ:
- ಟೂಲ್ ಕಾಲ್ ಇಲ್ಲ (No tool call) – ಮಾಡೆಲ್ ನೇರವಾಗಿ ಉತ್ತರಿಸಿತು ಅಥವಾ ಸರಿಯಾದ ಫಾರ್ಮ್ಯಾಟ್ನಲ್ಲಿ ವಿನಂತಿಯನ್ನು ತಯಾರಿಸಲು ವಿಫಲವಾಯಿತು.
- ತಪ್ಪಾದ ವಿನಂತಿ (Malformed request) – JSON ವ್ಯಾಕರಣಬದ್ಧವಾಗಿ ತಪ್ಪಾಗಿದೆ ಅಥವಾ ಅಗತ್ಯ ಫೀಲ್ಡ್ಗಳು ಇಲ್ಲದಿರುವುದರಿಂದ, ಡಿಸ್ಪ್ಯಾಚರ್ ಅದನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ.
- ವ್ಯಾಲಿಡೇಶನ್ ವೈಫಲ್ಯ (Validation failure) – ಆರ್ಗ್ಯುಮೆಂಟ್ಗಳು ಸ್ಕೀಮೆಗೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ, ಇದು ಎಕ್ಸಿಕ್ಯೂಶನ್ ಮೊದಲು ಎರರ್ ಅನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.
ವೈಫಲ್ಯಗಳನ್ನು ವರ್ಗೀಕರಿಸುವುದರಿಂದ ನೀವು ಲೂಪ್ನ ಪ್ರತಿ ಹಂತವನ್ನು ಲಾಗ್ ಮಾಡಬಹುದು ಮತ್ತು ವಿಷಯಗಳು ಎಲ್ಲಿ ತಪ್ಪಾದವು ಎಂಬುದನ್ನು ನಿಖರವಾಗಿ ಪತ್ತೆಹಚ್ಚಬಹುದು.
ವಿಶ್ವಾಸಾರ್ಹ ಪೈಪ್ಲೈನ್ಗಾಗಿ ಪ್ರಾಯೋಗಿಕ ಸಲಹೆಗಳು
- ಮಾದರಿ ಔಟ್ಪುಟ್ ಅನ್ನು ನಂಬಲಸಾಧ್ಯವಾದ ಇನ್ಪುಟ್ ಎಂದು ಪರಿಗಣಿಸಿ. ಯಾವುದೇ ಸೈಡ್-ಎಫೆಕ್ಟ್ ಮಾಡುವ ಕೋಡ್ ಅನ್ನು ಕರೆಯುವ ಮೊದಲು ಪ್ರತಿಯೊಂದು ವಿನಂತಿಯನ್ನು ನಿರ್ಣಾಯಕ ವ್ಯಾಲಿಡೇಶನ್ ಮೂಲಕ ರನ್ ಮಾಡಿ.
- ರಾವಾದ ವಿನಂತಿಯನ್ನು (raw request) ಮತ್ತು ಪ್ರತಿ ವ್ಯಾಲಿಡೇಶನ್ ಹಂತದ ಫಲಿತಾಂಶವನ್ನು ಲಾಗ್ ಮಾಡಿ. ಇದು ಏನಾದರೂ ತಪ್ಪಾದಾಗ ಮರುಸೃಷ್ಟಿಸಬಹುದಾದ (replayable) ದಾಖಲೆಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.
- ಸತತ ಟೂಲ್ ಕಾಲ್ಗಳಿಗೆ ಸ್ಪಷ್ಟ ಮಿತಿಗಳನ್ನು ನಿಗದಿಪಡಿಸಿ; ಅತಿಯಾದ ಲೂಪ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಖಾಲಿ ಮಾಡಬಹುದು ಅಥವಾ ರೇಟ್ ಲಿಮಿಟ್ಗಳನ್ನು ತಲುಪಬಹುದು.
- ಪ್ರತಿ ಫಂಕ್ಷನ್ ಅನ್ನು try/except ಬ್ಲಾಕ್ನಲ್ಲಿ ಸುತ್ತುವರಿಯಿರಿ, ಇದು ಮಾಡೆಲ್ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದಾದ ರಚನಾತ್ಮಕ ಎರರ್ ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಇದರಿಂದ ಮರುಪ್ರಯತ್ನ ಅಥವಾ ಸುಗಮ ಫಾಲ್ಬ್ಯಾಕ್ (fallback) ಸಾಧ್ಯವಾಗುತ್ತದೆ.
- ಅನುಮತಿ ಪರಿಶೀಲನೆಗಳನ್ನು ಬಿಸಿನೆಸ್ ಲಾಜಿಕ್ನಿಂದ ಪ್ರತ್ಯೇಕಿಸಿ. ಫಂಕ್ಷನ್ ರನ್ ಆಗುವ ಮೊದಲು ಕರೆಯುವವರ ಹಕ್ಕುಗಳನ್ನು ಪರಿಶೀಲಿಸಿ, ವಿಶೇಷವಾಗಿ "ಬಳಕೆದಾರರನ್ನು ಅಳಿಸಿ" (delete user) ನಂತಹ ವಿಶೇಷ ಹಕ್ಕುಗಳಿರುವ ಕ್ರಿಯೆಗಳಿಗೆ.
- ಸ್ಕೀಮಾ-ಚಾಲಿತ ವ್ಯಾಖ್ಯಾನಗಳನ್ನು ಬಳಸಿ (ಉದಾಹರಣೆಗೆ, Pydantic ಮಾಡೆಲ್ಗಳು), ಇದರಿಂದ ಮಾಡೆಲ್ ಅನುಸರಿಸಬೇಕಾದ JSON ಸ್ಕೀಮಾವನ್ನು ಫ್ರೇಮ್ವರ್ಕ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ತಯಾರಿಸಬಹುದು.
ಮುಂದೆ ಏನನ್ನು ಗಮನಿಸಬೇಕು
ಪ್ರೊವೈಡರ್ಗಳು ನೇರ ಟೂಲ್-ಕಾಲಿಂಗ್ APIಗಳನ್ನು ಸುಧಾರಿಸುತ್ತಿದ್ದಂತೆ, ವಿನಂತಿ ಫಾರ್ಮ್ಯಾಟ್ಗಳ ಸುತ್ತ ಕಟ್ಟುನಿಟ್ಟಾದ ನಿಯಮಗಳು ಮತ್ತು ಸಮೃದ್ಧ ಎರರ್ ಕೋಡ್ಗಳನ್ನು ನಿರೀಕ್ಷಿಸಿ. ಆ ಬದಲಾವಣೆಗಳು ವ್ಯಾಲಿಡೇಶನ್ ಅನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತವೆ ಮತ್ತು ಡೆವಲಪರ್ಗಳು ಕಟ್ಟುನಿಟ್ಟಾದ ಸೆಕ್ಯೂರಿಟಿ ಫೆನ್ಸ್ಗಳನ್ನು (security fences) ನಿರ್ಮಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತವೆ. ಲೈಬ್ರರಿ ಅಪ್ಡೇಟ್ಗಳ ಮೇಲೆ ಕಣ್ಣಿಡಿ—ಅನೇಕವು ಹೊಸ ಪ್ರೊವೈಡರ್ ಫೀಚರ್ಗಳಿಗಾಗಿ ಇನ್ಬಿಲ್ಟ್ ಬೆಂಬಲವನ್ನು ಸೇರಿಸುತ್ತಿವೆ.
ಸಾರಾಂಶ (Takeaway)
LLM ಎಂಬುದು ಒಂದು ಅತ್ಯಾಧುನಿಕ ಪಠ್ಯ ಜನಕವೇ ಹೊರತು, ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಾಧನವಲ್ಲ. ಕ್ರಮಗಳನ್ನು ಕೈಗೊಳ್ಳುವ ಏಕೈಕ ಅಧಿಕಾರ ನಿಮ್ಮ ಕೋಡ್ ಆಗಿರುತ್ತದೆ, ಮತ್ತು ನೀವು ನಿರ್ಮಿಸುವ (ಅಥವಾ ಇಂಪೋರ್ಟ್ ಮಾಡುವ) dispatcher ಎಂಬುದು ಆ ಕ್ರಮಗಳನ್ನು ದೃಢೀಕರಿಸುವ, ಅಧಿಕಾರ ನೀಡುವ ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಗೇಟ್ಕೀಪರ್ ಆಗಿರುತ್ತದೆ. ವರ್ಕ್ಫ್ಲೋ ಅನ್ನು ಮರುರೂಪಿಸುವುದರಿಂದ "ಮ್ಯಾಜಿಕ್" ಎಂಬ ಮಿಥ್ಯೆಯು ದೂರವಾಗುತ್ತದೆ, ಡಿಬಗ್ಗಿಂಗ್ ಪ್ರಕ್ರಿಯೆಯು ನಿಖರವಾಗುತ್ತದೆ ಮತ್ತು ಪ್ರತಿಯೊಂದು ಪ್ರೊಡಕ್ಷನ್ ಸಿಸ್ಟಮ್ಗೂ ಅಗತ್ಯವಿರುವ ಭದ್ರತಾ ಶಿಸ್ತನ್ನು ಇದು ಬಲಪಡಿಸುತ್ತದೆ.