ನಿಮ್ಮ LLM-ಚಾಲಿತ ಏಜೆಂಟ್ (agent) დೆಮೋದಲ್ಲಿ ಪರಿಪೂರ್ಣವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು, ಆದರೆ ಕೆಲವು ಹಂತಗಳ ನಂತರ ಅದು ನಿಧಾನಗತಿಯಗೊಳ್ಳಬಹುದು ಮತ್ತು ಬಿಲ್ ಅನ್ನು ಹೆಚ್ಚಿಸಬಹುದು. ಇದರ ಹಿಂದಿರುವ ಗುಪ್ತ ಕಾರಣ ಅಸ್ಥಿರವಾದ ಮಾಡೆಲ್ ಅಲ್ಲ—ಅದು 'ಟೋಕನ್ ಡ್ರಿಫ್ಟ್' (token drift), ಅಂದರೆ ಪ್ರತಿ ಬಾರಿಯೂ ಮಾಡೆಲ್ ಪ್ರೊಸೆಸ್ ಮಾಡಬೇಕಾದ ಪ್ರಾಂಪ್ಟ್‌ನ (prompt) ಕ್ರಮೇಣ ಹೆಚ್ಚಾಗುವ ಗಾತ್ರ.

ಪ್ರತಿ ಸಂವಹನವು ಮಾಡೆಲ್‌ನ ಇನ್‌ಪುಟ್ ಕಾನ್ಟೆಕ್ಸ್ಟ್‌ಗೆ (input context) ಹೆಚ್ಚಿನ ಪಠ್ಯವನ್ನು ಸೇರಿಸಿದಾಗ ಟೋಕನ್ ಡ್ರಿಫ್ಟ್ ಸಂಭವಿಸುತ್ತದೆ. ಸಂಭಾಷಣೆಯ ಇತಿಹಾಸ, ಟೂಲ್ ಸ್ಕೀಮಾಗಳು (tool schemas), API ಪ್ರತಿಕ್ರಿಯೆಗಳು ಮತ್ತು ಹುಡುಕಿದ ದಾಖಲೆಗಳು ಎಲ್ಲವೂ ಒಂದರ ಮೇಲೊಂದು ಶೇಖರಣೆಯಾಗುತ್ತವೆ, ಆದ್ದರಿಂದ ಪ್ರತಿ ಮುಂದಿನ ಕರವು (call) ದೊಡ್ಡ ಪೇಲೋಡ್ ಅನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಇನ್‌ಪುಟ್ ಟೋಕನ್‌ಗಳ ಸಂಖ್ಯೆಯೊಂದಿಗೆ ಮಾಡೆಲ್‌ನ ಪ್ರೊಸೆಸಿಂಗ್ ಸಮಯ ಮತ್ತು ಬೆಲೆ ಏರಿಕೆಯಾಗುವುದರಿಂದ, ವೆಚ್ಚವು ರೇಖೀಯವಾಗಿ (linearly) ಏರಿಕೆಯಾಗುವ ಬದಲು ವರ್ಗಾತ್ಮಕವಾಗಿ (quadratically) ಏರುತ್ತದೆ.

ಸಮಸ್ಯೆಗಳು ಪ್ರೊಡಕ್ಷನ್‌ನಲ್ಲಿ ಏಕೆ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ, დೆಮೋಗಳಲ್ಲಿ ಅಲ್ಲ

ನೈಜ ನಿಯೋಜನೆಗಳು (deployments) ಎಲ್ಲವನ್ನೂ ಉಳಿಸಿಕೊಳ್ಳುತ್ತವೆ: ಪ್ರತಿ ಬಳಕೆದಾರರ ಮಾತು, ಪ್ರತಿ ಟೂಲ್ ಔಟ್‌ಪುಟ್, ಹುಡುಕಿದ ಜ್ಞಾನದ ಪ್ರತಿ ತುಣುಕನ್ನು. ಲೇಟೆನ್ಸಿ (latency) ಹೆಚ್ಚಾಗುವವರೆಗೆ ಮತ್ತು ಇನ್‌ವಾಯ್ಸ್ ಬರುವವರೆಗೆ ಈ ಶೇಖರಣೆಯು ಗುಪ್ತವಾಗಿ ಉಳಿಯುತ್ತದೆ.

ಟೋಕನ್ ಡ್ರಿಫ್ಟ್‌ನ ಸಾಮಾನ್ಯ ಮೂಲಗಳು

  • ಪುನರಾವರ್ತಿತ ಟ್ರಾನ್ಸ್‌ಕ್ರಿಪ್ಟ್‌ಗಳು (Repeated transcripts) – ಹಳೆಯ ಸಂದೇಶಗಳನ್ನು ಸಾರಾಂಶಗೊಳಿಸುವ ಅಥವಾ ಕೈಬಿಡುವ ಬದಲು ಪ್ರಾಂಪ್ಟ್‌ನಲ್ಲಿ ಇಡುತ್ತಿರುವುದು.
  • ಭಾರೀ ಟೂಲ್ ಸ್ಕೀಮಾಗಳು (Heavy tool schemas) – ಪ್ರತಿ ಹಂತದಲ್ಲೂ ಟೂಲ್ ಸಾಮರ್ಥ್ಯಗಳ ದೊಡ್ಡ JSON ವ್ಯಾಖ್ಯಾನಗಳನ್ನು ಕಳುಹಿಸುವುದು.
  • ದೊಡ್ಡ ಟೂಲ್ ಫಲಿತಾಂಶಗಳು (Bulky tool results) – ಏಜೆಂಟ್‌ಗೆ ನಿಜವಾಗಿಯೂ ಅಗತ್ಯವಿರುವതിಗಿಂತ ಹೆಚ್ಚಿನ ಡೇಟಾವನ್ನು ಹೊಂದಿರುವ ಪೂರ್ಣ API ಪ್ರತಿಕ್ರಿಯೆಗಳು ಅಥವಾ ಡೇಟಾಬೇಸ್ ಸಾಲುಗಳನ್ನು ಸೇರಿಸುವುದು.
  • RAG ಬ್ಲೋಟ್ (RAG bloat) – ರಿಟ್ರಿவல்-ಆಗ್ಮೆಂಟೆಡ್ ಜನರೇಷನ್ (RAG) ಅನೇಕ ದಾಖಲೆ ತುಣುಕುಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ, ಅವುಗಳಲ್ಲಿ ಕೆಲವು ಹಳೆಯದಾಗಿರಬಹುದು ಅಥವಾ ಅಪ್ರಸ್ತುತವಾಗಿರಬಹುದು.
  • ಡ್ಯುಪ್ಲಿಕೇಟೆಡ್ ಮೆಮೊರಿ (Duplicated memory) – ಸಾರಾಂಶ, ಸ್ಟೇಟ್ ಆಬ್ಜೆಕ್ಟ್ ಮತ್ತು ರ）」 ಟ್ರಾನ್ಸ್‌ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಒಟ್ಟಿಗೆ ಸೇರಿಸುವುದು, ಇದು ಒಂದೇ ಮಾಹಿತಿಯನ್ನು ಮೂರು ಬಾರಿ ಪುನರಾವರ್ತಿಸುತ್ತದೆ.

ಇವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಹೊಸ ತರ್ಕ ಶಕ್ತಿಯನ್ನು (reasoning power) ನೀಡದಿದ್ದರೂ, ಟೋಕನ್‌ಗಳನ್ನು ಸೇರಿಸುತ್ತವೆ ಮತ್ತು ಪ್ರಾಂಪ್ಟ್‌ನ ಗಾತ್ರವನ್ನು ಹೆಚ್ಚಿಸುತ್ತವೆ.

ಟೋಕನ್ ಬಜೆಟ್ ಅನ್ನು ಹೇಗೆ ನಿಯಂತ್ರಣದಲ್ಲಿಡಬೇಕು

1. ಪದರವಾದ ಕಾನ್ಟೆಕ್ಸ್ಟ್ ವಿನ್ಯಾಸವನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳಿ (Adopt a layered context design)

  • ಸ್ಥಿರ ಸೂಚನೆಗಳು (Stable instructions) – ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್‌ಗಳು ಮತ್ತು ಸುರಕ್ಷತಾ ನಿಯಮಗಳನ್ನು ಮೇಲ್ಭಾಗದಲ್ಲಿ ಇರಿಸಿ ಮತ್ತು ಪ್ರತಿ ಹಂತದಲ್ಲೂ ಅವುಗಳನ್ನು ಮರುಕಳುಹಿಸುವ ಬದಲು ಅವುಗಳನ್ನು ಉಲ್ಲೇಖಿಸಿ (reference).
  • ರಚನಾತ್ಮಕ ಸ್ಟೇಟ್ (Structured state) – ಏಜೆಂಟ್ ವೇಗವಾಗಿ ಓದಬಲ್ಲ ಗುರಿಗಳು, ನಿರ್ಧಾರಗಳು ಮತ್ತು ಐಡೆಂಟಿಫೈಯರ್‌ಗಳ ಸಂಕ್ಷಿಪ್ತ ರೂಪವನ್ನು ಸಂಗ್ರಹಿಸಿ.
  • ಸಂಕುಚಿತ ಇತಿಹಾಸ (Compressed history) – ಹಳೆಯ ಸಂಭಾಷಣೆಗಳನ್ನು ಸಣ್ಣ, ಮನುಷ್ಯನಿಗೆ ಓದಲು ಸುಲಭವಾದ ಪ್ಯಾರಾಗ್ರಾಫ್‌ನಲ್ಲಿ ಸಾರಾಂಶಗೊಳಿಸಿ, ಒಂದು ನಿರ್ದಿಷ್ಟ ಮಿತಿಯನ್ನು ತಲುಪಿದಾಗ ಮಾತ್ರ ಅಪ್‌ಡೇಟ್ ಮಾಡಿ.
  • ಇತ್ತೀಚಿನ ಹಂತಗಳು (Recent turns) – ನಿರಂತರತೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳಲು ಕೊನೆಯ ಕೆಲವು ಸಂದೇಶಗಳನ್ನು ಅಕ್ಷರಶಃ (verbatim) ಸೇರಿಸಿ.

ಸ್ಥಿರ ಪಠ್ಯವನ್ನು ಸಾರಾಂಶಗೊಳಿಸಬಹುದಾದ ವಿಷಯದಿಂದ ಪ್ರತ್ಯೇಕಿಸುವುದರಿಂದ ನೀವು ಒಂದೇ ಪದಗಳನ್ನು ಪದೇ ಪದೇ ಕಳುಹಿಸುವುದನ್ನು ತಪ್ಪಿಸಬಹುದು.

2. ಟೂಲ್ ಔಟ್‌ಪುಟ್‌ಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಿ (Trim tool outputs)

  • ಏಜೆಂಟ್ ನಿಜವಾಗಿಯೂ ಬಳಸುವ ಫೀಲ್ಡ್‌ಗಳನ್ನು ಮಾತ್ರ ಹೊರತೆಗೆಯಿರಿ; ವಿವರವಾದ ವಿವರಣೆಗಳನ್ನು ಕೈಬಿಡಿ.
  • ದೊಡ್ಡ ಫಲಿತಾಂಶಗಳನ್ನು ಸಂಕ್ಷಿಪ್ತ ಸಾರಾಂಶ ಅಥವಾ ರೆಫರೆನ್ಸ್ ಐಡಿ (reference ID) ಮೂಲಕ ಬದಲಾಯಿಸಿ ಮತ್ತು ಪೂರ್ಣ ಪೇಲೋಡ್ ಅನ್ನು ಡೇಟಾಬೇಸ್, ಕ್ಯಾಶ್ ಅಥವಾ ಬ್ಲಾಬ್ ಸ್ಟೋರ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಿ.
  • ಒಂದು ಟೂಲ್ ಪಟ್ಟಿಯನ್ನು (list) ನೀಡಿದಾಗ, ಪ್ರಸ್ತುತ ನಿರ್ಧಾರಕ್ಕೆ ಅಗತ್ಯವಿರುವ ಮೊದಲ N ಐಟಂಗಳನ್ನು ಮಾತ್ರ ಕಳುಹಿಸಿ.

3. ಸ್ಮಾರ್ಟ್ ಸಾರಾಂಶವನ್ನು ಅನ್ವಯಿಸಿ (Apply smart summarization)

  • ಪ್ರತಿ ಹಂತದ ನಂತರ ಸಾರಾಂಶಗೊಳಿಸುವುದನ್ನು ಬಿಟ್ಟುಬಿಡಿ; ಹೆಚ್ಚುವರಿ ಪ್ರೊಸೆಸಿಂಗ್ ಹೊರೆ (overhead) ಉಂಟುಮಾಡುತ್ತದೆ.
  • ಹಳೆಯ ಹಂತಗಳ ಒಟ್ಟು ಟೋಕನ್ ಸಂಖ್ಯೆಯು ನಿಗದಿಪಡಿಸಿದ ಮಿತಿಯನ್ನು ಮೀರಿದಾಗ ಮಾತ್ರ ಸಾರಾಂಶವನ್ನು ನವೀಕರಿಸಿ.
  • ಪ್ರಮುಖ ಸತ್ಯಗಳನ್ನು—IDs, ಮೊತ್ತಗಳು, ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ಗಳು—ಗದ್ಯದಲ್ಲಿ (prose) ಸೇರಿಸುವ ಬದಲು ರಚನಾತ್ಮಕ ಸ್ಟೋರ್‌ನಲ್ಲಿ ಇರಿಸಿ, ಇದರಿಂದ ಸಾರಾಂಶವು ಚಿಕ್ಕದಾಗಿರುತ್ತದೆ.

4. ಸರಿಯಾದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಿ (Track the right metrics)

  • ಕೇವಲ ಬಳಕೆದಾರರ ವಿನಂತಿಗೆ (user request) ಮಾತ್ರವಲ್ಲದೆ, ಪ್ರತಿ ಮಾಡೆಲ್ ಕರವು (per model call) ಟೋಕನ್ ಬಳಕೆಯನ್ನು ಲಾಗ್ ಮಾಡಿ. ಇದು ಇನ್‌ಪುಟ್ ಕಡೆಯ ಗುಪ್ತ ಬೆಳವಣಿಗೆಯನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ.
  • ಪ್ರತಿ ಹಂತದಲ್ಲಿ ಸೇರ್ಪಡೆಯಾಗುವ ಇನ್‌ಪುಟ್ ಟೋಕನ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ; ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಏರಿಕೆಯಾದರೆ ಅದು ಡ್ರಿಫ್ಟ್ ಮೂಲವನ್ನು ಸೂಚಿಸುತ್ತದೆ.
  • ಕ್ಯಾಶ್ ಮಾಡಿದ ಟೋಕನ್‌ಗಳನ್ನು (ಹಿಂದಿನ ಕರವುಗಳಿಂದ ಮರುಬಳಕೆ ಮಾಡಿದವು) ಹೊಸದಾಗಿ ಸೃಷ್ಟಿಸಿದ ಟೋಕನ್‌ಗಳಿಂದ ಪ್ರತ್ಯೇಕಿಸಿ; ಮೊದಲನೆಯದೆಯು ಮಾತ್ರ ಡ್ರಿಫ್ಟ್‌ಗೆ ಕಾರಣವಾಗುತ್ತದೆ.

ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಅನಂತ ಟ್ರಾನ್ಸ್‌ಕ್ರಿಪ್ಟ್ ಎಂದು ಪರಿಗಣಿಸಬೇಡಿ, ಬದಲಿಗೆ ಅದನ್ನು ಒಂದು ಸೀಮಿತ ಸಂಪನ್ಮೂಲವಾಗಿ ಪರಿಗಣಿಸಿ. ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಅಳತೆ ಮಾಡುವ ಮೂಲಕ, ಸಾರಾಂಶಗೊಳಿಸುವ