ನಾನು ನನ್ನ RAG ಪೈಪ್ಲೈನ್ ಅನ್ನು ಒಂದು ಬ್ಲಾಕ್ ಬಾಕ್ಸ್ನಂತೆ ಪರಿಗಣಿಸುತ್ತಿದ್ದೆ. ಎಂಬೆಡ್ಡಿಂಗ್ಸ್ (Embeddings) ಒಳಗೆ ಹೋಗುತ್ತಿದ್ದವು, ಉತ್ತರಗಳು ಹೊರಬರುತ್ತಿದ್ದವು, ಮತ್ತು ಅದರ ನಡುವೆ ಎಲ್ಲೋ ನನ್ನ ಕ್ಲೌಡ್ ಬಿಲ್ ಹೆಚ್ಚುತ್ತಾ ಹೋಗುತ್ತಿತ್ತು. ನಾನು ಮಾತನಾಡಿದ ಹೆಚ್ಚಿನ ಡೆವಲಪರ್ಗಳಂತೆ, ನಾನು ಕೂಡ ಡೆನ್ಸ್ ವೆಕ್ಟರ್ ಮಾಡೆಲ್ಗಳೇ (dense vector models) ಇದಕ್ಕೆ ಕಾರಣ ಎಂದು ಭಾವಿಸಿದ್ದೆ. ಅವು ದುಬಾರಿ ಎಂದು ಕೇಳಿಸುತ್ತಿದ್ದವು. ಸಾವಿರಾರು ಪುಟಗಳನ್ನು ಹೈ-ಡೈಮೆನ್ಷನಲ್ ಫ್ಲೋಟ್ಸ್ಗಳಾಗಿ (high-dimensional floats) ಪರಿವರ್ತಿಸುವುದು ಭಾರೀ ಉತ್ಪಾದನಾ ಪ್ರಕ್ರಿಯೆಯಂತೆ ಭಾಸವಾಗುತ್ತಿತ್ತು, ಆದ್ದರಿಂದ ನಾನು ಅದನ್ನು ಬಹಳ ಎಚ್ಚರಿಕೆಯಿಂದ ನಿರ್ವಹಿಸುತ್ತಿದ್ದೆ. ನಾನು ಈಗಾಗಲೇ ಪ್ರೊಸೆಸ್ ಮಾಡಿದ ಡೇಟಾವನ್ನು ಮತ್ತೆ ಎಂಬೆಡ್ ಮಾಡುವುದನ್ನು ತಪ್ಪಿಸಲು ನಿರ್ದಿಷ್ಟವಾಗಿ ಒಂದು ಕ್ಯಾಶಿಂಗ್ ಲೇಯರ್ ಅನ್ನು (caching layer) ಸಹ ನಿರ್ಮಿಸಿದ್ದೆ. ಆ ಆಪ್ಟಿಮೈಸೇಶನ್ ಬಗ್ಗೆ ನನಗೆ ಹೆಮ್ಮೆಯಿತ್ತು. ನಂತರ ನಾನು ಇನ್ವಾಯ್ಸ್ ತೆರೆದು ಲೆಕ್ಕ ಹಾಕಿದೆ.
ನಾನು ಸಂಪೂರ್ಣವಾಗಿ ತಪ್ಪು ವಿಷಯವನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡುತ್ತಿದ್ದೆ.
ಎಂಬೆಡ್ಡಿಂಗ್ ಬಲೆ (The Embedding Trap)
ನನ್ನ ಕಲ್ಪನೆಗಳನ್ನು ಬದಲಿಸಿದ ಆ ಸಂಖ್ಯೆ ಇಲ್ಲಿದೆ: 1,000 ಪುಟಗಳ ದಾಖಲೆಯನ್ನು ಎಂಬೆಡ್ ಮಾಡುವುದು ಸರಿಸುಮಾರು ಹದಿನೆಂಟು ಸೆಂಟ್ಸ್ ವೆಚ್ಚವಾಗುತ್ತದೆ. ಇದು ಟೈಪಿಂಗ್ ತಪ್ಪಲ್ಲ. ಹೆಚ್ಚಿನ ನಗರಗಳಲ್ಲಿ ಒಂದು ಕಪ್ ಕಾಫಿಯ ಬೆಲೆಗಿಂತ ಕಡಿಮೆ ವೆಚ್ಚದಲ್ಲಿ, ನೀವು ಇಡೀ ಪುಸ್ತಕವನ್ನೇ ವೆಕ್ಟರೈಸ್ ಮಾಡಬಹುದು. ಅತಿ ಮುಖ್ಯವಾಗಿ, ಈ ವೆಚ್ಚವು ಕೇವಲ ಡೇಟಾ ಇಂಜೆಸ್ಟಿನ್ (ingestion) ಸಮಯದಲ್ಲಿ ಒಮ್ಮೆ ಮಾತ್ರ ಆಗುತ್ತದೆ. ಆರಂಭಿಕ ಪ್ರಕ್ರಿಯೆಯ ನಂತರ, ಆ ವೆಕ್ಟರ್ಗಳು ಸ್ಟೋರೇಜ್ನಲ್ಲಿ ಕಾಯುತ್ತಿರುತ್ತವೆ. ಬಳಕೆದಾರರು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪ್ರತಿ ಬಾರಿ ಬಳಸಿದಾಗ ಅವು ಹೆಚ್ಚುವರಿ ಶುಲ್ಕವನ್ನು ವಿಧಿಸುವುದಿಲ್ಲ. ಅವು ಬಂಡವಾಳ ವೆಚ್ಚಗಳೇ ಹೊರತು (capital expense), ಮರುಕಳಿಸುವ ವೆಚ್ಚಗಳಲ್ಲ.
ಆದರೂ ಈ ತಪ್ಪು ಕಲ್ಪನೆ ಇಂದಿಗೂ ಇದೆ. ಈ ಗೊಂದಲಕ್ಕೆ ಒಂದು ಭಾಗದಷ್ಟು ರಚನಾತ್ಮಕ ಕಾರಣವಿದೆ. ಇಂಜಿನಿಯರ್ಗಳು ತಮ್ಮ ಆರಂಭಿಕ ಶಕ್ತಿಯನ್ನು ಇಂಜೆಸ್ಟಿನ್ ಪೈಪ್ಲೈನ್ನಲ್ಲಿಯೇ ವ್ಯಯಿಸುತ್ತಾರೆ. ನೀವು ಚಂಕರ್ (chunker) ಬರೆಯುತ್ತೀರಿ, ಟೋಕನೈಸರ್ (tokenizer) ಜೊತೆ ಹೋರಾಡುತ್ತೀರಿ, ಮತ್ತು ನಿಮ್ಮ ಟರ್ಮಿನಲ್ನಲ್ಲಿ ಪ್ರೋಗ್ರೆಸ್ ಬಾರ್ ಚಲಿಸುವುದನ್ನು ನೋಡುತ್ತೀರಿ. ಈ ದೃಶ್ಯಮಾನ ಶ್ರಮವು ಪ್ರಮಾಣದ ಬಗ್ಗೆ ಒಂದು ಭ್ರಮೆಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಇದು ಶ್ರಮದಾಯಕ ಪ್ರಕ್ರಿಯೆಯಾಗಿರುವುದರಿಂದ, ಇದು ಅತ್ಯಂತ ದುಬಾರಿ ಭಾಗ ಎಂದು ನಮಗೆ ಅನಿಸುತ್ತದೆ. ಆದರೆ ಶ್ರಮ ಮತ್ತು ವೆಚ್ಚ ಎರಡೂ ಒಂದೇ ಅಲ್ಲ, ಮತ್ತು RAG ನಲ್ಲಿ ಅವು ಹೆಚ್ಚಾಗಿ ವಿರುದ್ಧ ಸಂಬಂಧವನ್ನು ಹೊಂದಿರುತ್ತವೆ.
ಮೂರು ವಿಭಿನ್ನ ಬಿಲ್ಗಳು
ವೆಚ್ಚಗಳನ್ನು ಒಟ್ಟಿಗೆ ಸೇರಿಸುವ ಬದಲು ಹಂತಗಳ ಪ್ರಕಾರ ಪ್ರತ್ಯೇಕಿಸಿದಾಗ, ಚಿತ್ರಣ ಸ್ಪಷ್ಟವಾಯಿತು. ಒಂದು RAG ಸಿಸ್ಟಮ್ ಮೂರು ವಿಭಿನ್ನ ಆರ್ಥಿಕ ಮಾದರಿಗಳ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಮತ್ತು ನಿಮ್ಮ ಬಜೆಟ್ ಅನ್ನು ನಿಯಂತ್ರಣದಲ್ಲಿಡಲು ಈ ವ್ಯತ್ಯಾಸವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಅತ್ಯಗತ್ಯ.
ಎಂಬೆಡ್ಡಿಂಗ್ಸ್ ಎಂಬುದು ಒಂದು ಬಾರಿಯ ಉತ್ಪಾದನಾ ವೆಚ್ಚ. ನೀವು ದಾಖಲೆಗಳನ್ನು ವೆಕ್ಟರ್ಗಳಾಗಿ ಪರಿವರ್ತಿಸಲು ಪಾವತಿಸುತ್ತೀರಿ, ಮತ್ತು ನಂತರ ಅದು ಮುಗಿಯುತ್ತದೆ. ನಿಮ್ಮ ದಾಖಲೆಗಳು ಸ್ಥಿರವಾಗಿದ್ದರೆ (static), ಈ ವೆಚ್ಚವು ನಿಮ್ಮ ಮಾಸಿಕ ಬಿಲ್ನಲ್ಲಿ ಬಹುತೇಕ ಕಾಣಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ.
ವೆಕ್ಟರ್ ಡೇಟಾಬೇಸ್ಗಳು ಮೂಲಸೌಕರ್ಯ ಬಾಡಿಗೆಯಿದ್ದಂತೆ (infrastructure rent). ಸಿಸ್ಟಮ್ ಅನ್ನು ದಿನದ 24 ಗಂಟೆಯೂ ಕಾರ್ಯನಿರ್ವಹಣೆಯಲ್ಲಿಡಲು ನೀವು ಪಾವತಿಸುತ್ತೀರಿ. ಲಕ್ಷಾಂತರ ಚಂಕ್ಗಳನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ SSDಗಳು, ಇಂಡೆಕ್ಸ್ಗಳನ್ನು ನಿರ್ವಹಿಸುವ CPU ಕೋರ್ಗಳು ಮತ್ತು 100 ಮಿಲಿಸೆಕೆಂಡ್ಗಿಂತ ಕಡಿಮೆ ಸಮಯದಲ್ಲಿ ಹುಡುಕಾಟವನ್ನು ನೀಡುವ ನೆಟ್ವರ್ಕ್ಗಾಗಿ ನೀವು ಪಾವತಿಸುತ್ತೀರಿ. ಈ ವೆಚ್ಚವು ನಿಜವಾಗಿಯೂ ಇದೆ ಮತ್ತು ಡೇಟಾ ಪ್ರಮಾಣಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಹೆಚ್ಚಾಗುತ್ತದೆ, ಆದರೆ ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಮುನ್ಸೂಚನೆ ನೀಡಬಹುದಾದಂತಿದೆ. ಇದು ಜಿಮ್ ಸದಸ್ಯತ್ವದಂತೆ ವರ್ತಿಸುತ್ತದೆ. ನೀವು ಒಂದು ಬಾರಿ ಅಥವಾ ಹತ್ತು ಸಾವಿರ ಬಾರಿ ಕ್ವೆರಿ ಮಾಡಿದರೂ ಸಹ, ಮೂಲಭೂತ ಮೂಲಸೌಕರ್ಯ ವೆಚ್ಚವು ಸರಿಸುಮಾರು ಒಂದೇ ಆಗಿರುತ್ತದೆ.
ಲಾರ್ಜ್ ಲ್ಯಾಂಗ್ವೇಜ್ ಮಾಡೆಲ್ಗಳು (LLM) ಬಳಕೆಯ ತೆರಿಗೆಯಿದ್ದಂತೆ (consumption taxes). ಪ್ರತಿಯೊಂದು ಬಳಕೆದಾರರ ಪ್ರಶ್ನೆಯು ಒಂದು ಬಿಲ್ ಅನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ನಿಮ್ಮ ರಿಟ್ರಿೀವಲ್ ಲೇಯರ್ನಿಂದ ಹೊರಬಂದು ಪ್ರಾಂಪ್ಟ್ಗೆ ಪ್ರವೇಶಿಸುವ ಪ್ರತಿಯೊಂದು ಟೋಕನ್ ಕೂಡ ಹಣವನ್ನು ಖರ್ಚು ಮಾಡುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ತಾರ್ಕಿಕ ಹಂತ (reasoning step), ಪ್ರತಿಯೊಂದು ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ಸೂಚನೆ, ಮಾಡೆಲ್ ಜನರೇಟ್ ಮಾಡಬೇಕೆಂದು ನೀವು ಕೇಳುವ ಪ್ರತಿಯೊಂದು ಉಲ್ಲೇಖವು (citation) ಸಣ್ಣ ಪ್ರಮಾಣದ ವೆಚ್ಚವನ್ನು ಸೇರಿಸುತ್ತದೆ. ಆದರೆ ಈ ಸಣ್ಣ ಶುಲ್ಕಗಳು ಸೆಷನ್ ಸಂಖ್ಯೆಯಿಂದ ಗುಣಾಕಾರವಾಗುತ್ತವೆ ಮತ್ತು ಸೆಷನ್ ಸಂಖ್ಯೆಗಳು ಏರುತ್ತಲೇ ಇರುತ್ತವೆ. ಇಲ್ಲಿ ವಿಳಂಬ (latency) ಮತ್ತು ವೆಚ್ಚ ಎರಡೂ ಒಟ್ಟಾಗಿ ಹೆಚ್ಚಾಗುತ್ತವೆ. ನಿಧಾನಗತಿಯ ಕ್ವೆರಿ ಬಳಕೆದಾರರಿಗೆ ಕೇವಲ ಕಿರಿಕಿರಿ ಉಂಟುಮಾಡುವುದಿಲ್ಲ; ಬಳಕೆದಾರರು ಕಾಯುತ್ತಿರುವಾಗ ಅದು ಸಕ್ರಿಯವಾಗಿ ಹಣವನ್ನು ಸುರಿಸುತ್ತಿರುತ್ತದೆ.
ಇವು ಒಂದೇ ಸಮಸ್ಯೆಯ ವಿಭಿನ್ನ ರೂಪಗಳಲ್ಲ. ಇವು ಮೂರು ಪ್ರತ್ಯೇಕ ಸಮಸ್ಯೆಗಳು. ಇಂಜೆಸ್ಟಿನ್ ಅನ್ನು ಅಗ್ಗವಾಗಿಸುವ ಮೂಲಕ ನೀವು ಕ್ವೆರಿ-ಸಮಯದ ವೆಚ್ಚದ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಇದು ಪಾರ್ಕಿಂಗ್ ಹಣ ಉಳಿಸಲು ನಿಮ್ಮ ಕಾರಿನ ಇಂಜಿನ್ ಅನ್ನು ಟ್ಯೂನ್ ಮಾಡಿದಂತೆ.
ಹಣ ನಿಜವಾಗಿಯೂ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ
ನೀವು ಪ್ರೊಡಕ್ಷನ್ RAG ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ರನ್ ಮಾಡುತ್ತಿದ್ದರೆ, ನಿಮ್ಮ ಕಾಸ್ಟ್ ಎಕ್ಸ್ಪ್ಲೋರರ್ (cost explorer) ತೆರೆದು ಬಳಕೆಯ ಪ್ರಕಾರದ (usage type) ಮೂಲಕ ಫಿಲ್ಟರ್ ಮಾಡಿ. ನಿಮ್ಮ ಎಂಬೆಡ್ಡಿಂಗ್ ಕೆಲಸವು ದಿನಕ್ಕೆ ಒಮ್ಮೆ ಮಾತ್ರ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಆದರೆ ನಿಮ್ಮ LLM ಎಂಡ್ಪಾಯಿಂಟ್ ಟ್ರಾಫಿಕ್ ಹೆಚ್ಚಾದಂತೆ ಹೃದಯಬಡಿತದಂತೆ ಏರಿಳಿತಗೊಳ್ಳುತ್ತದೆ ಎಂದು ನಾನು ಪಣತೊಡಬಲ್ಲೆ. ಆ ಮಾದರಿಯೇ ಇಡೀ ಕಥೆಯನ್ನು ಹೇಳುತ್ತದೆ. ನಿಮ್ಮ ವೆಕ್ಟರ್ಗಳು ವಿಶ್ರಾಂತಿ ಪಡೆಯುತ್ತವೆ; ಆದರೆ ಬಳಕೆದಾರರು ಪ್ರಶ್ನೆ ಕೇಳಿದ ಪ್ರತಿ ಬಾರಿಯೂ ನಿಮ್ಮ ಮಾಡೆಲ್ ಎಚ್ಚರಗೊಳ್ಳುತ್ತದೆ.
ಈ ಅರಿವು ನಾನು ಇಂಜಿನಿಯರಿಂಗ್ ಕೆಲಸಗಳಿಗೆ ಆದ್ಯತೆ ನೀಡುವ ರೀತಿಯನ್ನೇ ಬದಲಿಸಿತು. ಇಂಜೆಸ್ಟಿನ್ ಅನ್ನು ಹೇಗೆ ಅಗ್ಗವಾಗಿಸುವುದು ಎಂದು ಕೇಳುವ ಬದಲು, ಪ್ರತಿ ಪ್ರಶ್ನೆಯನ್ನು ಹೇಗೆ ಅಗ್ಗವಾಗಿಸುವುದು ಎಂದು ಕೇಳಲು ನಾನು ಪ್ರಾರಂಭಿಸಿದೆ. ಈ ಬದಲಾವಣೆ ಸ್ಪಷ್ಟವಾಗಿ ಕಂಡರೂ, ಹೆಚ್ಚಿನ ತಂಡಗಳು ಇಂದಿಗೂ ಕೇವಲ ಅಂದಾಜಿನ ಮೇಲೆ ಕೆಲಸ ಮಾಡುತ್ತಿವೆ. ಅವರು ಎಂಬೆಡ್ಡಿಂಗ್ ಹಂತಕ್ಕಾಗಿ ಸಂಕೀರ್ಣವಾದ ಡಿಡ್ಯೂಪ್ಲಿಕೇಶನ್ ಲಾಜಿಕ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತಾರೆ ಮತ್ತು ನಂತರ ಯಾವುದೇ ಯೋಚನೆಯಿಲ್ಲದೆ ಅತಿಯಾದ, ಗಮನವಿಲ್ಲದ ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋಗಳನ್ನು (context windows) LLM ಗೆ ನೀಡುತ್ತಾರೆ. ಅವರು ಮೇಲ್ಛಾವಣಿ ಸೋರುತ್ತಿರುವಾಗ ನೆಲವನ್ನು ಪಾಲಿಶ್ ಮಾಡುತ್ತಿದ್ದಾರೆ ಎಂದರ್ಥ.
ನಿಮ್ಮ ಪೈಪ್ಲೈನ್ ಹಾಳಾಗದಂತೆ ವೆಚ್ಚವನ್ನು ಹೇಗೆ ಕಡಿಮೆ ಮಾಡುವುದು
RAG ಸಿಸ್ಟಮ್ನಲ್ಲಿ ಹಣ ಉಳಿಸಲು ವೆಚ್ಚದ ಮಾದರಿಗೆ ಅನುಗುಣವಾಗಿ ತಂತ್ರವನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುವುದು ಅಗತ್ಯ. ನಿಜವಾಗಿಯೂ ಕೆಲಸ ಮಾಡುವ ವಿಧಾನಗಳು ಇಲ್ಲಿವೆ.
ಪ್ರೊಸೆಸ್ ಮಾಡುವ ಮೊದಲು ಡಿಡ್ಯೂಪ್ಲಿಕೇಟ್ ಮಾಡಿ
ಹೆಚ್ಚಿನ ಸಾಂಸ್ಥಿಕ ಜ್ಞಾನ ಕೋಶಗಳು (knowledge bases) ನಿಧಾನವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ನೀತಿಗಳು, ಕೈಪಿಡಿಗಳು, ಸಂಶೋಧನಾ PDFಗಳು ಮತ್ತು ಆರ್ಕೈವ್ ಮಾಡಲಾದ ವರದಿಗಳು ತಿಂಗಳುಗಟ್ಟಲೆ ಮುಟ್ಟದೆಯೇ ಇರುತ್ತವೆ. ಅನೇಕ ಪೈಪ್ಲೈನ್ಗಳಲ್ಲಿ, ಇಂಜೆಸ್ಟಿನ್ (ingestion) ಪ್ರಕ್ರಿಯೆಗಳ ನಡುವೆ ಸುಮಾರು ಎಂಭತ್ತದಷ್ಟು ಮೂಲ ದಾಖಲೆಗಳು ಅಚ್ಚುಕಟ್ಟಾಗಿ ಒಂದೇ ರೀತಿಯಲ್ಲಿರುತ್ತವೆ. ಹೀಗಿದ್ದರೂ, ಅನೇಕ ವ್ಯವಸ್ಥೆಗಳು ಇಡೀ ದತ್ತಸಂಚಯವನ್ನು (corpus) ಕೈಬಿಟ್ಟು, ನಿಗದಿತ ಸಮಯದಲ್ಲಿ ಮೊದಲಿನಿಂದಲೇ ಸೂಚ್ಯಂಕವನ್ನು (index) ಮರುನಿರ್ಮಿಸುತ್ತವೆ. ಹಾಗೆ ಮಾಡಬೇಡಿ. ನಿಮ್ಮ ಪೈಪ್ಲೈನ್ನ ಪ್ರವೇಶದ್ವಾರದಲ್ಲಿ ಒಂದು ಗೇಟ್ ಅನ್ನು ನಿರ್ಮಿಸಿ. ಬರುವ ಫೈಲ್ಗಳಿಗೆ ಹ್ಯಾಶ್ (Hash) ಮಾಡಿ. ಕೊನೆಯದಾಗಿ ಮಾರ್ಪಡಿಸಿದ ಸಮಯದ (last-modified timestamps) ಅನ್ನು ಹೋಲಿಸಿ. ಒಂದು ದಾಖಲೆಯು ಬದಲಾಗಿಲ್ಲದಿದ್ದರೆ, ಅದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬಿಟ್ಟುಬಿಡಿ. ಸ್ಥಿರವಾದ (static) ಫೈಲ್ಗಳನ್ನು ಮರು-ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದು ಸಂಪೂರ್ಣ ವ್ಯರ್ಥ. ಇದು ಕಂಪ್ಯೂಟ್ ವೆಚ್ಚವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ, ಅನಗತ್ಯವಾಗಿ SSD ಗಳನ್ನು ಸವೆಸುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ಇಂಜೆಸ್ಟಿನ್ ಲಾಗ್ಗಳಲ್ಲಿ ಸುಳ್ಳು ಚಟುವಟಿಕೆಗಳನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ.
ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಫೈಲ್ ಪಾತ್ಗಳನ್ನು (file paths) ಚೆಕ್ಸಮ್ಗಳಿಗೆ (checksums) ನಕ್ಷೆ ಮಾಡುವ ಒಂದು ಲಘು ಮ್ಯಾನಿಫೆಸ್ಟ್ ಅನ್ನು (lightweight manifest) ಸಂಗ್ರಹಿಸಿ. ಶೆಡ್ಯೂಲರ್ (scheduler) ಕಾರ್ಯಗತಗೊಂಡಾಗ, ಮೊದಲು ಮ್ಯಾನಿಫೆಸ್ಟ್ ಅನ್ನು ಪರಿಶೀಲಿಸಲು ಬಿಡಿ. ಬದಲಾದ ಅಲ್ಪ ಪ್ರಮಾಣದ ಫೈಲ್ಗಳು ಮಾತ್ರ ಚಂಕರ್ (chunker) ಪ್ರಕ್ರಿಯೆಗೆ ಒಳಗಾಗಲಿ.
ದಾಖಲೆಗಳನ್ನು ಪ್ಯಾಚ್ ಮಾಡಿ, ಅವುಗಳನ್ನು ಬದಲಾಯಿಸಬೇಡಿ
ಒಂದು ದಾಖಲೆಯು ಬದಲಾದಾಗ, ಅದನ್ನು ಹೊಸ ಫೈಲ್ ಎಂದು ಪರಿಗಣಿಸುವ ಪ್ರವೃತ್ತಿಯನ್ನು ತಡೆಯಿರಿ. ಐವತ್ತು ಪುಟಗಳ ತಾಂತ್ರಿಕ ವಿವರಣೆಯಲ್ಲಿ (technical spec) ನಾಲ್ಕನೇ ವಿಭಾಗದಲ್ಲಿ ಕೇವಲ ಎರಡು ಪ್ಯಾರಾಗ್ರಾಫ್ಗಳ ತಿದ್ದುಪಡಿ ಇರಬಹುದು. ನಿಮ್ಮ ಪೈಪ್ಲೈನ್ ಇಡೀ ಫೈಲ್ ಅನ್ನು ಬದಲಾಯಿಸಿದರೆ, ನೀವು ಕಾರಣವಿಲ್ಲದೆ ನಲವತ್ತೊಂಬತ್ತು ಉತ್ತಮ ಪುಟಗಳನ್ನು ಮರು-ಚಂಕ್ (re-chunk) ಮತ್ತು ಮರು-ಎಂಬೆಡ್ (re-embed) ಮಾಡಬೇಕಾಗುತ್ತದೆ.
ಬದಲಾಗಿ, ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಹಳೆಯದರೊಂದಿಗೆ ಹೋಲಿಸಿ. ವ್ಯತ್ಯಾಸವನ್ನು (delta) ಗುರುತಿಸಿ. ನಂತರ ಬದಲಾದ ವಿಭಾಗಗಳನ್ನು ಮಾತ್ರ ಮರು-ಚಂಕ್ ಮತ್ತು ಮರು-ಎಂಬೆಡ್ ಮಾಡಿ. ಗಡಿಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಪುಟ ಸಂಖ್ಯೆಗಳು, ಸೆಕ್ಷನ್ ಐಡಿಗಳು (section IDs), ಹೆಡರ್ ಆಂಕರ್ಗಳು ಅಥವಾ ಪ್ಯಾರಾಗ್ರಾಫ್ ವ್ಯಾಪ್ತಿಗಳಂತಹ ಮೆಟಾಡೇಟಾವನ್ನು ಬಳಸಿ. ನಿಮ್ಮ ಚಂಕಿಂಗ್ ತಂತ್ರವು ದಾಖಲೆಯ ರಚನೆಯನ್ನು ಗೌರವಿಸುವುದಾದರೆ, ಇದು ಸುಲಭವಾಗಿದೆ. ಇಲ್ಲದಿದ್ದರೆ, ದೊಡ್ಡ ಇನ್ಫರೆನ್ಸ್ ಕ್ಲಸ್ಟರ್ (inference cluster) ಖರೀದಿಸುವುದಕ್ಕಿಂತ ನಿಮ್ಮ ಚಂಕರ್ ಅನ್ನು ಸರಿಪಡಿಸುವುದು ಉತ್ತಮ ಹೂಡಿಕೆಯಾಗಿದೆ. ನಿಮ್ಮ ದಾಖಲೆಗಳ ಸಂಖ್ಯೆ ಹೆಚ್ಚಾದಂತೆ, ಡಿಫ್-ಅವೇರ್ (diff-aware) ಪೈಪ್ಲೈನ್ ಅನ್ನು ನಿರ್ವಹಿಸುವ ಎಂಜಿನಿಯರಿಂಗ್ ವೆಚ್ಚವು ಕೆಲವೇ ವಾರಗಳಲ್ಲಿ ತಾನಾಗಿಯೇ ಸರಿದುಕೊಳ್ಳುತ್ತದೆ.
ಪುನರಾವರ್ತಿತ ವೆಚ್ಚಗಳನ್ನು ನೇರವಾಗಿ ಎದುರಿಸಿ
ಪ್ರತಿ ಕ್ವೆರಿಯಲ್ಲೂ (query) LLM ಕರೆಗಳು ನಡೆಯುವುದರಿಂದ, ಕೆಲವು ಟೋಕನ್ಗಳನ್ನು ಉಳಿಸುವುದು ಅಥವಾ ಕೆಲವು ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಕ್ಯಾಶ್ (cache) ಮಾಡುವುದು ಹೆಚ್ಚಿನ ಲಾಭವನ್ನು ನೀಡುತ್ತದೆ. ಪ್ರಾಂಪ್ಟ್ ಕ್ಯಾಶಿಂಗ್ನಿಂದ (prompt caching) ಪ್ರಾರಂಭಿಸಿ. ಒಬ್ಬ ಬಳಕೆದಾರನು ನಿಮ್ಮ ಮರುಪಾವತಿ ನೀತಿಯನ್ನು (refund policy) ಕೇಳಿದರೆ ಮತ್ತು ಇನ್ನೊಬ್ಬರು ಹತ್ತು ನಿಮಿಷಗಳ ನಂತರ ಅದೇ ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳಿದರೆ, ಮಾಡೆಲ್ ಅನ್ನು ಎರಡು ಬಾರಿ ಬಳಸುವ ಅಗತ್ಯವಿಲ್ಲ. ಸೆಮ್ಯಾಂಟಿಕ್ ಸಿಮಿಲಾರಿಟಿ ಮ್ಯಾಚಿಂಗ್ (semantic similarity matching) ಬಳಸಿ ಇತ್ತೀಚಿನ ಕ್ವೆರಿ-ಪ್ರತಿಕ್ರಿಯೆ ಜೋಡಿಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ. ಹೊಸ ಪ್ರಶ್ನೆಯು ಕ್ಯಾಶ್ ಮಾಡಲಾದ ಪ್ರಶ್ನೆಯ ಸಾಮ್ಯತೆಯ ಮಿತಿಯಲ್ಲಿದ್ದರೆ (similarity threshold), ಸಂಗ್ರಹಿಸಿದ ಉತ್ತರವನ್ನು ನೇರವಾಗಿ ನೀಡಿ. ಯಾವುದೇ ಟೋಕನ್ಗಳು ಬಳಕೆಯಾಗುವುದಿಲ್ಲ, ಯಾವುದೇ ಹಣ ವ್ಯಯವಾಗುವುದಿಲ್ಲ.
ಮುಂದೆ, ನಿಮ್ಮ ರಿಟ್ರಿವಲ್ ಗುಣಮಟ್ಟವನ್ನು (retrieval quality) ಸೂಕ್ಷ್ಮವಾಗಿ ಗಮನಿಸಿ. ಅಸಮರ್ಪಕ ರಿಟ್ರೈವರ್ (retriever) ಒಂದು ಸೂಜಿಯನ್ನು ಹುಡುಕಲು LLM ಅನ್ನು ಒಡಲಿನಲ್ಲಿನ ಒಣಹುಲ್ಲಿನ ರಾಶಿಯನ್ನು ಓದುವಂತೆ ಮಾಡುತ್ತದೆ. ನಿಮ್ಮ top-k ಕಟ್-ಆಫ್ (cutoff) ತುಂಬಾ ಸಡಿಲವಾಗಿದ್ದರೆ ಮತ್ತು ನೀವು ಇಪ್ಪತ್ತು ಅಪ್ರಸ್ತುತ ಚಂಕ್ಗಳನ್ನು ಪ್ರಾಂಪ್ಟ್ನಲ್ಲಿ ತುಂಬಿದರೆ, ನೀವು ಕೇವಲ ಗೊಂದಲದ ಮಾಹಿತಿಯನ್ನು (noise) ಓದಲು ಮಾಡೆಲ್ಗೆ ಹಣ ಪಾವತಿಸುತ್ತಿದ್ದೀರಿ ಎಂದರ್ಥ. ನಿಮ್ಮ ರಿಟ್ರಿವಲ್ ಅನ್ನು ಬಿಗಿಗೊಳಿಸಿ. ನಿಮ್ಮ top-k ಅನ್ನು ಕಡಿಮೆ ಮಾಡಿ. ಚಂಕ್ಗಳನ್ನು ಕಳುಹಿಸುವ ಮೊದಲು ಅವುಗಳನ್ನು ಸಂಕುಚಿತಗೊಳಿಸಿ (compress). ಇಂಜೆಸ್ಟಿನ್ ಸಮಯದಲ್ಲಿ ಬೋರಿಂಗ್ ಫುಟರ್ಗಳು ಮತ್ತು ಹೆಡರ್ಗಳನ್ನು ತೆಗೆದುಹಾಕಿ, ಇದರಿಂದ ಅವು ಪ್ರಾಂಪ್ಟ್ಗೆ ತಲುಪುವುದಿಲ್ಲ. ಕಾನ್ಟೆಕ್ಸ್ ವಿಂಡೋದಿಂದ (context window) ನೀವು ತೆಗೆದುಹಾಕುವ ಪ್ರತಿಯೊಂದು ಟೋಕನ್ ಒಂದು ಸಣ್ಣ ಉಳಿತಾಯವಾಗುತ್ತದೆ ಮತ್ತು ಈ ಸಣ್ಣ ಉಳಿತಾಯಗಳು ಪ್ರತಿದಿನದ ಸಾವಿರಾರು ಕ್ವೆರಿಗಳ ಮೂಲಕ ದೊಡ್ಡ ಮೊತ್ತವಾಗಿ ಸಂಗ್ರಹವಾಗುತ್ತವೆ.
ಉತ್ತಮ ರಿಟ್ರಿವಲ್ ವಿಳಂಬವನ್ನು (latency) ಕೂಡ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, ಇದು ವೆಚ್ಚದ ಇನ್ನೊಂದು ರೂಪವಾಗಿದೆ. ನಿಧಾನಗತಿಯ ಇಂಟರ್ಫೇಸ್ಗಳನ್ನು ಬಳಕೆದಾರರು ಬಳಸುವುದಿಲ್ಲ. ವೇಗವಾದ ಉತ್ತರವು ತಯಾರಿಸಲು ಅಗ್ಗ ಮತ್ತು ಬಳಕೆದಾರರನ್ನು ಉಳಿಸಿಕೊಳ್ಳಲು ಉತ್ತಮವಾಗಿದೆ.
ನಿಜವಾದ ಪಾಠ
ಯಾವುದು ದುಬಾರಿ ಎಂದು ನಿಮಗೆ ಅನಿಸುತ್ತದೆಯೋ ಅದನ್ನು ಆಪ್ಟಿಮೈಸ್ (optimize) ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಿ ಮತ್ತು ನಿಮ್ಮ ಇನ್ವಾಯ್ಸ್ (invoice) ಯಾವುದು ದುಬಾರಿ ಎಂದು ಹೇಳುತ್ತದೆಯೋ ಅದನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿ. ಪ್ರತಿಯೊಂದು ಹಂತವನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಅಳೆಯಿರಿ. ಎಂಬೆಡ್ಡಿಂಗ್ಗಳು (embeddings) ಅಗ್ಗದ ಭಾಗವಾಗಿವೆ, ವೆಕ್ಟರ್ ಸ್ಟೋರೇಜ್ (vector storage) ಸ್ಥಿರವಾದ ಭಾಗವಾಗಿದೆ ಮತ್ತು LLM ಇನ್ಫರೆನ್ಸ್ (inference) ಹಣವನ್ನು ವ್ಯಯಿಸುವ ಭಾಗವಾಗಿದೆ ಎಂದು ನೀವು ಕಂಡುಕೊಳ್ಳಬಹುದು. ಕ್ವೆರಿ-ಟೈಮ್ ದಕ್ಷತೆ (query-time efficiency), ಇನ್ಕ್ರಿಮೆಂಟಲ್ ಅಪ್ಡೇಟ್ಗಳು (incremental updates) ಮತ್ತು ಸರ್ಜಿಕಲ್ ಡಿಡ್ಯೂಪ್ಲಿಕೇಶನ್ (surgical deduplication) ಮೇಲೆ ನಿಮ್ಮ ಶಕ್ತಿಯನ್ನು ಕೇಂದ್ರೀಕರಿಸಿ. ಐವತ್ತನೇ ದಾಖಲೆ ಅಪ್ಲೋಡ್ಗಾಗಿ ಅಲ್ಲ, ಸಾವಿರನೇ ಬಳಕೆದಾರರ ಪ್ರಶ್ನೆಗಾಗಿ ಸಿದ್ಧರಾಗಿರಿ. ಅಡಚಣೆಯು (bottleneck) ನೀವು ಭಾವಿಸುವ ಕಡೆ ಇರುವುದಿಲ್ಲ.
Source: Where Does RAG Actually Cost You Money? I Decided to Stop Guessing
Join the discussion in the GyaanSetu AI learning community.