ವೆಚ್ಚ ಆಪ್ಟಿಮೈಸೇಶನ್: ಪ್ರಾಂಪ್ಟ್ ಕ್ಯಾಶಿಂಗ್

ಲಾಭಗಳು:

• ಪ್ರಾಂಪ್ಟ್ ಕ್ಯಾಶಿಂಗ್‌ನ ಪೂರ್ವಪ್ರತ್ಯಯ ಹೊಂದಾಣಿಕೆಯ ತರ್ಕವನ್ನು ವಿವರಿಸಿ
• ಸ್ಥಿರ ಸಂದರ್ಭವನ್ನು ಮೊದಲು ಮತ್ತು ನಂತರ ವೇರಿಯಬಲ್ ಸಂದರ್ಭವನ್ನು ಹಾಕುವ ಮೂಲಕ ಕ್ಯಾಶ್ ಹಿಟ್ ಅನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ
• ಕ್ಯಾಶ್ ರೈಟ್/ರೀಡ್ ಅರ್ಥಶಾಸ್ತ್ರ ಮತ್ತು ಬ್ರೇಕ್-ಈವ್ ಪಾಯಿಂಟ್ ಅನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಬಹುದು

ಒಂದು LLM ಉತ್ಪನ್ನವು ಮೂಲಮಾದರಿಯಲ್ಲಿ ಅಗ್ಗವಾಗಿ ಕಾಣುತ್ತದೆ; ನೀವು ಅಳತೆಗೆ ಏರಿದಾಗ, ಬಿಲ್ ಆಶ್ಚರ್ಯವಾಗುತ್ತದೆ. ಹೆಚ್ಚಿನ ಕೆಲಸದ ಹೊರೆಗಳಲ್ಲಿ, ಹೆಚ್ಚಿನ ಬಿಲ್ ಒಂದೇ ಸ್ಥಿರ ಸಂದರ್ಭದಿಂದ ಬರುತ್ತದೆ, ಅದನ್ನು ಪ್ರತಿ ವಿನಂತಿಯೊಂದಿಗೆ ಮತ್ತೆ ಮತ್ತೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ: ದೀರ್ಘ ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್, ರೂಲ್‌ಬುಕ್, ಉಲ್ಲೇಖ ದಾಖಲಾತಿ. ಪ್ರಾಂಪ್ಟ್ ಕ್ಯಾಶಿಂಗ್ ನಿಖರವಾಗಿ ಈ ತ್ಯಾಜ್ಯವನ್ನು ನಿವಾರಿಸುತ್ತದೆ. ಈ ಘಟಕದಲ್ಲಿ, ಸಂಗ್ರಹವು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಹೊಡೆಯಲು ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಹೇಗೆ ವ್ಯವಸ್ಥೆ ಮಾಡುವುದು ಮತ್ತು ಸಂಗ್ರಹ ಆರ್ಥಿಕತೆಯ ಬ್ರೇಕ್-ಈವ್ ಪಾಯಿಂಟ್ ಅನ್ನು ಹೇಗೆ ಲೆಕ್ಕಾಚಾರ ಮಾಡುವುದು ಎಂಬುದನ್ನು ನೀವು ಕಲಿಯುವಿರಿ. ಸರಿಯಾಗಿ ಇನ್‌ಸ್ಟಾಲ್ ಮಾಡಿದಾಗ, ಅದು ಮಾತ್ರ ನಿಮ್ಮ ಬಿಲ್ ಅನ್ನು ಅರ್ಧ ಅಥವಾ ಅದಕ್ಕಿಂತ ಕಡಿಮೆ ಮಾಡಬಹುದು.

ಸಂಗ್ರಹ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ? ಒಂದು ಬದಲಾಗದ ನಿಯಮ

ಪ್ರಾಂಪ್ಟ್ ಕ್ಯಾಶಿಂಗ್ ಒಂದು ಪೂರ್ವಪ್ರತ್ಯಯ ಹೊಂದಾಣಿಕೆಯಾಗಿದೆ. ಒದಗಿಸುವವರು ನಿಮ್ಮ ಪ್ರಾಂಪ್ಟ್‌ನ ಪ್ರಾರಂಭದಿಂದಲೂ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದ ಟೋಕನ್‌ಗಳನ್ನು ತಾತ್ಕಾಲಿಕವಾಗಿ ಸಂಗ್ರಹಿಸುತ್ತಾರೆ. ಮುಂದಿನ ವಿನಂತಿಯಲ್ಲಿ ಅದೇ ಪೂರ್ವಪ್ರತ್ಯಯದೊಂದಿಗೆ ಪ್ರಾಂಪ್ಟ್ ಪ್ರಾರಂಭವಾದರೆ, ಈ ಸಾಮಾನ್ಯ ಭಾಗವನ್ನು ಮರು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲಾಗುವುದಿಲ್ಲ; ಸಂಗ್ರಹಕ್ಕಿಂತ ಓದಲು ಇದು ತುಂಬಾ ಅಗ್ಗವಾಗಿದೆ.

ಇದರಿಂದ ಒಂದು ಬದಲಾಗದ ನಿಯಮವು ಅನುಸರಿಸುತ್ತದೆ: ಒಂದು ಬೈಟ್ ಪೂರ್ವಪ್ರತ್ಯಯದಲ್ಲಿ ಎಲ್ಲಿಯಾದರೂ ಬದಲಾದರೆ, ಆ ಹಂತದಿಂದ ಸಂಪೂರ್ಣ ಸಂಗ್ರಹವು ಅಮಾನ್ಯವಾಗುತ್ತದೆ. ಅಂದರೆ, ಸ್ಥಿರ ವಿಷಯವು ಪ್ರಾರಂಭದಲ್ಲಿರಬೇಕು ಮತ್ತು ವೇರಿಯಬಲ್ ವಿಷಯವು ಅಂತ್ಯದಲ್ಲಿರಬೇಕು. "ಇಂದಿನ ದಿನಾಂಕ: 18.07.2026" ನಂತಹ ಪ್ರತಿ ವಿನಂತಿಯೊಂದಿಗೆ ಬದಲಾಗುವ ಸಿಸ್ಟಂ ಪ್ರಾಂಪ್ಟ್‌ನ ಪ್ರಾರಂಭದಲ್ಲಿ ನೀವು ಸಾಲನ್ನು ಹಾಕಿದರೆ, ಅದರ ಹಿಂದೆ ಇರುವ ಎಲ್ಲವೂ ಸಂಗ್ರಹವನ್ನು ನಮೂದಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.

ಪ್ರಕ್ರಿಯೆಯ ಕ್ರಮವು ಸಾಮಾನ್ಯವಾಗಿ: ಉಪಕರಣಗಳು → ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್ → ಸಂದೇಶಗಳು. ನೀವು ಸ್ಥಿರ ವಿಭಾಗದ ಕೊನೆಯಲ್ಲಿ ಕ್ಯಾಶ್ ಪಾಯಿಂಟ್ (ಬ್ರೇಕ್ ಪಾಯಿಂಟ್) ಅನ್ನು ಹಾಕುತ್ತೀರಿ.

ಸಂಗ್ರಹ ಆರ್ಥಿಕತೆ

ಸಂಗ್ರಹವು ಮೂರು ಬೆಲೆ ಶ್ರೇಣಿಗಳನ್ನು ಹೊಂದಿದೆ:

• ಸಂಗ್ರಹ ಬರೆಯಿರಿ: ಮೊದಲ ಬಾರಿಗೆ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತಿದೆ. ~1.25x ಸಾಮಾನ್ಯ ಇನ್‌ಪುಟ್ ಬೆಲೆ (5 ನಿಮಿಷಗಳ ಸಂಗ್ರಹಣೆಗಾಗಿ).
• ಸಂಗ್ರಹ ಓದುವಿಕೆ: ನಂತರದ ವಿನಂತಿಗಳನ್ನು ಓದುವುದು. ಸಾಮಾನ್ಯ ಇನ್‌ಪುಟ್ ಬೆಲೆಗಿಂತ ~0.1 ಪಟ್ಟು - ಅಂದರೆ ಹತ್ತನೇ ಒಂದು ಭಾಗ.
• ಸಾಮಾನ್ಯ ಇನ್‌ಪುಟ್: ಸಂಗ್ರಹವನ್ನು ನಮೂದಿಸದ ಮತ್ತು ಪ್ರತಿ ಬಾರಿ ಪೂರ್ಣ ವೆಚ್ಚದಲ್ಲಿ ಸಂಸ್ಕರಿಸುವ ಭಾಗ.

ಬ್ರೇಕ್-ಈವ್ ಪಾಯಿಂಟ್: ಮೊದಲ ವಿನಂತಿಯು ಬರೆಯುವ ಪ್ರೀಮಿಯಂ ಅನ್ನು ಪಾವತಿಸುತ್ತದೆ (1.25×). ಎರಡನೇ ವಿನಂತಿಯಿಂದ, ಓದುವಿಕೆ (0.1×) ಕಾರ್ಯರೂಪಕ್ಕೆ ಬರುತ್ತದೆ. ಸರಿಸುಮಾರು, ನೀವು ಎರಡು ವಿನಂತಿಗಳನ್ನು ಕುತ್ತಿಗೆ ಮತ್ತು ಕುತ್ತಿಗೆ ಮಾಡುತ್ತೇವೆ; ಅದರ ನಂತರ, ಇದು ನಿವ್ವಳ ಉಳಿತಾಯವಾಗಿದೆ. ಸ್ಥಿರ ಸನ್ನಿವೇಶವು ದೊಡ್ಡದಾಗಿದೆ ಮತ್ತು ಹೆಚ್ಚಿನ ವಿನಂತಿಗಳನ್ನು ಮರುಬಳಕೆ ಮಾಡಲಾಗುತ್ತದೆ, ದೊಡ್ಡ ಲಾಭವಾಗುತ್ತದೆ.

ಸನ್ನಿವೇಶ

ಸಂಗ್ರಹವು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆಯೇ?

ದೊಡ್ಡ ಸ್ಥಿರ ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್, ಸಾವಿರಾರು ವಿನಂತಿಗಳು

ಹೌದು - ಅತ್ಯಧಿಕ ಗಳಿಕೆಗಳು

ಒಂದೇ ಉಲ್ಲೇಖ ಡಾಕ್ಸ್‌ನಲ್ಲಿ ಹಲವು ಪ್ರಶ್ನೆಗಳು

ಹೌದು

ಪ್ರತಿ ವಿನಂತಿಗೆ ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾದ ಕಿರು ಪಠ್ಯ

ಇಲ್ಲ - ಬರೆಯುವ ಬೋನಸ್ ವ್ಯರ್ಥವಾಗುತ್ತದೆ

ಒಂದು ಬಾರಿ ವಿನಂತಿ

ಇಲ್ಲ - ಓದುವುದೇ ಇಲ್ಲ

ಸಿಸ್ಟಂ ಪ್ರಾಂಪ್ಟ್‌ನಲ್ಲಿ ಪ್ರತಿ ವಿನಂತಿಯೊಂದಿಗೆ ದಿನಾಂಕ/ID ಬದಲಾಗುತ್ತಿದೆ

ಇಲ್ಲ - ಪೂರ್ವಪ್ರತ್ಯಯ ಮುರಿದುಹೋಗಿದೆ, ಹಿಟ್ ಶೂನ್ಯವಾಗಿದೆ

ಹಂತ ಹಂತವಾಗಿ: ಹಿಟ್ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಹೇಗೆ ಹೊಂದಿಸುವುದು?

1. ಸ್ಥಿರ ಮತ್ತು ವೇರಿಯಬಲ್ ಅನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ. ಯಾವ ವಿಷಯವು ಎಂದಿಗೂ ಬದಲಾಗುವುದಿಲ್ಲ (ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್, ರೂಲ್‌ಬುಕ್, ಡಾಕ್ಯುಮೆಂಟೇಶನ್)? ಪ್ರತಿ ವಿನಂತಿಯೊಂದಿಗೆ ಯಾವ ಬದಲಾವಣೆಗಳು (ಬಳಕೆದಾರರ ಪ್ರಶ್ನೆ, ದಿನಾಂಕ, ID)?
2. ಆರಂಭದಲ್ಲಿ ಸ್ಥಿರವನ್ನು ಹಾಕಿ. ಸಂಸ್ಕರಣೆಯ ಸಮಯದಲ್ಲಿ, ಮೊದಲು ಬರುವ ಭಾಗವು (ಪರಿಕರಗಳು, ವ್ಯವಸ್ಥೆ) ಸ್ಥಿರವಾಗಿರಬೇಕು.
3. ವೇರಿಯಬಲ್ ಅನ್ನು ಕೊನೆಯಲ್ಲಿ ಹಾಕಿ. ಬಳಕೆದಾರರ ಪ್ರಸ್ತುತ ಪ್ರಶ್ನೆ, ಕೊನೆಯದು.
4. ಗಡಿಯ ಕೊನೆಯಲ್ಲಿ ಚಿಹ್ನೆಯನ್ನು ಇರಿಸಿ. ಸ್ಥಿರ ಭಾಗದ ಕೊನೆಯ ಬ್ಲಾಕ್ನಲ್ಲಿ ಸಂಗ್ರಹ ಬಿಂದುವನ್ನು ಹಾಕಿ.
5. ಹಿಟ್ ಪರಿಶೀಲಿಸಿ. ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲಿ ಬಳಕೆಯ ಕ್ಷೇತ್ರದಲ್ಲಿ cache_read_input_tokens ಸೊನ್ನೆಗಿಂತ ಹೆಚ್ಚಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಶೂನ್ಯವಾಗಿದ್ದರೆ, ಪೂರ್ವಪ್ರತ್ಯಯದಲ್ಲಿ ಗುಪ್ತ ಅಡ್ಡಿಯುಂಟಾಗುತ್ತದೆ.

{ "system": [ { "type": "text", "text": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "ephemeral" } } ], "messages": [ { "role": "user", "{questertion}_" ]}

ಸಲಹೆ: ಕ್ಯಾಶ್ ಹಿಟ್‌ಗಳನ್ನು ಊಹಿಸಬೇಡಿ, ಅವುಗಳನ್ನು ಅಳೆಯಿರಿ. Use.cache_read_input_tokens ಅನುಕ್ರಮ ವಿನಂತಿಗಳಲ್ಲಿ ಇನ್ನೂ ಶೂನ್ಯವಾಗಿದ್ದರೆ, ಸಿಸ್ಟಂ ಪ್ರಾಂಪ್ಟ್‌ನಲ್ಲಿ ಸೈಲೆಂಟ್ ಬ್ರೇಕರ್ (datetime.now(), ಆದೇಶವಿಲ್ಲದ JSON, ಪ್ರತಿ ವಿನಂತಿಯೊಂದಿಗೆ ಬದಲಾಗುತ್ತಿರುವ ಪರಿಕರಗಳ ಪಟ್ಟಿ) ಚಾಲನೆಯಲ್ಲಿದೆ. ಬೈಟ್ ಮೂಲಕ ಎರಡು ವಿನಂತಿಗಳ ಕಚ್ಚಾ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಬೈಟ್ ಮೂಲಕ ಹೋಲಿಕೆ ಮಾಡಿ ಮತ್ತು ವ್ಯತ್ಯಾಸವನ್ನು ಕಂಡುಹಿಡಿಯಿರಿ.

ಸೈಲೆಂಟ್ ಡಿಸ್ಟ್ರಪ್ಟರ್ಸ್

ಅರಿವಿಲ್ಲದೆ ಸಂಗ್ರಹವನ್ನು ಭ್ರಷ್ಟಗೊಳಿಸುವ ವಿಶಿಷ್ಟ ಮಾದರಿಗಳು:

# BREAKER: ಸಿಸ್ಟಂ ಪ್ರಾಂಪ್ಟ್‌ನಲ್ಲಿ ಎಂಬೆಡಿಂಗ್ ಮಾಹಿತಿಯನ್ನು ಪ್ರತಿ ವಿನಂತಿಯೊಂದಿಗೆ ಬದಲಾಯಿಸುವ "ಇಂದಿನ ದಿನಾಂಕ: {{ಈಗ}}. ನೀವು ಸಹಾಯಕರಾಗಿದ್ದೀರಿ..." ← ಪ್ರತಿ ವಿನಂತಿಯೊಂದಿಗೆ ಪೂರ್ವಪ್ರತ್ಯಯ ಬದಲಾವಣೆಗಳು, ಹಿಟ್ ಶೂನ್ಯ# ನಿಜ: ವೇರಿಯೇಬಲ್ ಅನ್ನು ಸಂದೇಶ ವ್ಯವಸ್ಥೆಗೆ ಸರಿಸಿ: "ನೀವು ಸಹಾಯಕರು..." ← ನಿರಂತರವಾಗಿ ಕ್ಯಾಕೆಮೆಸೇಜ್‌ಗಳನ್ನು ಪ್ರವೇಶಿಸುತ್ತದೆ. [ ಪ್ರಶ್ನೆ: ..."}] ← ಕೊನೆಯಲ್ಲಿ ವೇರಿಯಬಲ್

ಇತರೆ ಬ್ರೇಕರ್‌ಗಳು: JSON ಪ್ರತಿ ವಿನಂತಿಯ ಮೇಲೆ ವಿಭಿನ್ನವಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ (ಕೀಗಳನ್ನು ಸ್ಥಿರ ಕ್ರಮದಲ್ಲಿ ಇರಿಸಿ), ಬಳಕೆದಾರರಿಂದ ಬದಲಾಗುವ ಪರಿಕರಗಳ ಪಟ್ಟಿ (ಉಪಕರಣಗಳನ್ನು ಮೊದಲು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತದೆ; ಅವು ಬದಲಾದರೆ ಯಾವುದೂ ಸಂಗ್ರಹಕ್ಕೆ ಹೋಗುವುದಿಲ್ಲ), ಮಧ್ಯ-ಸಂಭಾಷಣೆಯ ಮಾದರಿಯನ್ನು ಬದಲಾಯಿಸುವುದು (ಸಂಗ್ರಹಣೆಗಳು ನಿರ್ದಿಷ್ಟ ಮಾದರಿ).

ದುರ್ಬಲ ಪ್ರಾಂಪ್ಟ್ / ಬಲವಾದ ಪ್ರಾಂಪ್ಟ್ (ಸಂಗ್ರಹ ಸ್ನೇಹಿ ರಚನೆ)

# ದುರ್ಬಲ (ಕ್ಯಾಶ್ ಬಸ್ಟಿಂಗ್ ಬಿಲ್ಡ್)ಸಿಸ್ಟಮ್: "ದಿನಾಂಕ: 18.07.2026 14:32. ಬಳಕೆದಾರ: ಅಹ್ಮೆಟ್ (ಐಡಿ 8842). ನೀವು ಬೆಂಬಲ ಬೋಟ್. ನಿಯಮಗಳು: ...(2000 ಟೋಕನ್‌ಗಳು)..."

# STRONG (ಸಂಗ್ರಹ-ಸ್ನೇಹಿ ರಚನೆ)ಸಿಸ್ಟಮ್: "ನೀವು ಬೆಂಬಲ ಬೋಟ್ ಆಗಿದ್ದೀರಿ. ನಿಯಮಗಳು: ...(2000 ಟೋಕನ್‌ಗಳು, ಎಂದಿಗೂ ಬದಲಾಗುವುದಿಲ್ಲ)..." [ಸಂಗ್ರಹ ಚಿಹ್ನೆ] ಸಂದೇಶಗಳು: [ { ಪಾತ್ರ: ಬಳಕೆದಾರ, ವಿಷಯ: "ದಿನಾಂಕ: 18.07.2026 14:32. ಬಳಕೆದಾರ ಐಡಿ: 8842. ಪ್ರಶ್ನೆ: ನಾನು ಹೇಗೆ ಮರುಪಾವತಿ ಮಾಡುತ್ತೇನೆ?" }]

ದುರ್ಬಲ ಆವೃತ್ತಿಯಲ್ಲಿ, 2000 ಟೋಕನ್ಗಳ ನಿಯಮ ಬ್ಲಾಕ್ ಅನ್ನು ಪ್ರತಿ ವಿನಂತಿಯ ಮೇಲೆ ಪೂರ್ಣ ವೆಚ್ಚದಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತದೆ. ಬಲವಾದ ಆವೃತ್ತಿಯಲ್ಲಿ, ಅದೇ ಬ್ಲಾಕ್ ಅನ್ನು ಒಮ್ಮೆ ಬರೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಬೆಲೆಯ ಹತ್ತನೇ ಒಂದು ಭಾಗಕ್ಕೆ ಎಲ್ಲಾ ನಂತರದ ವಿನಂತಿಗಳನ್ನು ಓದಲಾಗುತ್ತದೆ.

ಮೂರು ಮಿನಿ ಪ್ರಕರಣಗಳು

ಪ್ರಕರಣ 1 - ನಿಯಮಪುಸ್ತಕವನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವುದು. ಪ್ರತಿ ಸರಕುಪಟ್ಟಿಗೆ 12,000 ಟೋಕನ್ ರೂಲ್‌ಬುಕ್ ಅನ್ನು ಅಕೌಂಟಿಂಗ್ ಆಟೊಮೇಷನ್ ಸೇರಿಸುತ್ತಿತ್ತು; ದಿನಕ್ಕೆ 5,000 ವಿನಂತಿಗಳು. ಕ್ಯಾಶೆಲೆಸ್ ಇನ್‌ಪುಟ್ ದಿನಕ್ಕೆ ~$180 ವೆಚ್ಚವಾಗುತ್ತದೆ. ಅವರು ರೂಲ್‌ಬುಕ್ ಅನ್ನು ಸ್ಥಿರವಾಗಿ ಇರಿಸಿದರು ಮತ್ತು ಅದನ್ನು ಸಂಗ್ರಹಿಸಿದರು: ಮೊದಲ ವಿನಂತಿಗಳು ಬರೆಯುವ ಪ್ರೀಮಿಯಂ ಅನ್ನು ಪಾವತಿಸಿದವು, ನಂತರದ ಓದುವಿಕೆಗಳು 0.1×. ಇನ್‌ಪುಟ್ ವೆಚ್ಚವು ದಿನಕ್ಕೆ ~90% ರಿಂದ ~$18 ಕ್ಕೆ ಇಳಿದಿದೆ.

ಪ್ರಕರಣ 2 - ಗುಪ್ತ ದಿನಾಂಕ ರೇಖೆಯ ವೆಚ್ಚ. ಒಂದು ತಂಡವು ಸಂಗ್ರಹವನ್ನು ಸ್ಥಾಪಿಸಿತು ಆದರೆ ಯಾವುದೇ ಹಿಟ್‌ಗಳನ್ನು ಪಡೆಯುತ್ತಿಲ್ಲ; cache_read_input_tokens ಯಾವಾಗಲೂ ಶೂನ್ಯವಾಗಿರುತ್ತದೆ. ಕಾರಣ: ಸಿಸ್ಟಂ ಪ್ರಾಂಪ್ಟ್‌ನ ಮೊದಲ ಸಾಲಿನಲ್ಲಿ datetime.now() ಇತ್ತು, ಪ್ರತಿ ವಿನಂತಿಯೊಂದಿಗೆ ಪೂರ್ವಪ್ರತ್ಯಯವು ಬದಲಾಗುತ್ತಿದೆ. ನಾವು ಬಳಕೆದಾರರ ಸಂದೇಶಕ್ಕೆ ದಿನಾಂಕವನ್ನು ಸರಿಸಿದಾಗ, ಹಿಟ್ ದರವು ಇದ್ದಕ್ಕಿದ್ದಂತೆ 0% ರಿಂದ 94% ಕ್ಕೆ ಏರಿತು.

ಪ್ರಕರಣ 3 - ತಪ್ಪಾದ ಸಂಗ್ರಹ. ಒಂದು ಹುಡುಕಾಟ ಅಪ್ಲಿಕೇಶನ್ ಪ್ರತಿ ವಿನಂತಿಯೊಂದಿಗೆ ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾದ ಸಣ್ಣ ಪ್ರಶ್ನೆಗಳನ್ನು ಕಳುಹಿಸುತ್ತಿದೆ; ಅವರು ಕುತೂಹಲದಿಂದ ಸಂಗ್ರಹ ಚಿಹ್ನೆಯನ್ನು ಸೇರಿಸಿದರು. ಯಾವುದೇ ಸಾಮಾನ್ಯ ಪೂರ್ವಪ್ರತ್ಯಯವಿಲ್ಲದೆ, ಪ್ರತಿ ವಿನಂತಿಯು ಬರವಣಿಗೆ ಪ್ರೀಮಿಯಂ ಅನ್ನು ಮಾತ್ರ ಪಾವತಿಸುತ್ತದೆ, ಯಾವುದೇ ಓದುವಿಕೆಗಳಿಲ್ಲ - ವೆಚ್ಚವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ಅವರು ಚಿಹ್ನೆಯನ್ನು ತೆಗೆದುಹಾಕಿದರು. ಪಾಠ: ಮರುಬಳಕೆಯ ದೊಡ್ಡ ಮತ್ತು ಸ್ಥಿರವಾದ ಪೂರ್ವಪ್ರತ್ಯಯವಿದ್ದರೆ ಮಾತ್ರ ಸಂಗ್ರಹವನ್ನು ಪಾವತಿಸಲಾಗುತ್ತದೆ.

ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳು

• ಸ್ಥಿರ ಮತ್ತು ವೇರಿಯಬಲ್ ಮಿಶ್ರಣ: ವೇರಿಯಬಲ್ ವಿಷಯವು ಪೂರ್ವಪ್ರತ್ಯಯದಲ್ಲಿದ್ದರೆ, ಹಿಟ್ ಅನ್ನು ಮರುಹೊಂದಿಸಲಾಗುತ್ತದೆ.
• ಸಿಸ್ಟಂ ಪ್ರಾಂಪ್ಟ್‌ನಲ್ಲಿ ದಿನಾಂಕ/ಐಡಿ ಎಂಬೆಡಿಂಗ್: ಅತ್ಯಂತ ಸಾಮಾನ್ಯವಾದ ಮೂಕ ಅಡ್ಡಿಪಡಿಸುವಿಕೆ.
• ಹಿಟ್ ಅನ್ನು ಅಳೆಯುತ್ತಿಲ್ಲ: cache_read_input_tokens ಅನ್ನು ಪರಿಶೀಲಿಸದಿದ್ದರೆ, ತ್ಯಾಜ್ಯವನ್ನು ಗಮನಿಸಲಾಗುವುದಿಲ್ಲ.
• ಸಾರ್ವಜನಿಕ ಪೂರ್ವಪ್ರತ್ಯಯವಿಲ್ಲದಿದ್ದಾಗ ಸಂಗ್ರಹವನ್ನು ಸೇರಿಸುವುದು: ನೀವು ಬರೆಯುವ ಪ್ರೀಮಿಯಂ ಅನ್ನು ಮಾತ್ರ ಪಾವತಿಸುತ್ತೀರಿ, ವೆಚ್ಚವು ಹೆಚ್ಚಾಗುತ್ತದೆ.
• ವಾಹನ ಪಟ್ಟಿ ಅಥವಾ ಮಾದರಿಯನ್ನು ಬದಲಾಯಿಸುವುದು: ಪೂರ್ವಪ್ರತ್ಯಯವು ಮೊದಲಿನಿಂದಲೂ ಮುರಿದುಹೋಗಿದೆ; ಎಲ್ಲವನ್ನೂ ಪುನಃ ಬರೆಯಲಾಗಿದೆ.
• ಕನಿಷ್ಠ ಸಂಗ್ರಹ ಗಾತ್ರವನ್ನು ಮರೆತುಬಿಡುವುದು: ಅತಿ ಕಡಿಮೆ ಸಂಗ್ರಹಗಳು (ಮಾದರಿಯನ್ನು ಅವಲಂಬಿಸಿ ~1–4k ಟೋಕನ್‌ಗಳ ಅಡಿಯಲ್ಲಿ) ಸಂಗ್ರಹವನ್ನು ಮೌನವಾಗಿ ನಮೂದಿಸುವುದಿಲ್ಲ.

ಆಳವಾದ: ವರ್ಕ್‌ಲೋಡ್ ಪ್ರಕಾರದಿಂದ ಸಂಗ್ರಹವನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವುದು

ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವಿಕೆಯ ನಿಜವಾದ ಪ್ರತಿಫಲವು ನಿಮ್ಮ ಕೆಲಸದ ಹೊರೆಯ ಸ್ವರೂಪವನ್ನು ಅವಲಂಬಿಸಿ ಬದಲಾಗುತ್ತದೆ; ಆದ್ದರಿಂದ ಮೊದಲು ನಿಮ್ಮ ಸಂಚಾರವನ್ನು ತಿಳಿದುಕೊಳ್ಳಿ. ಮೂರು ವಿಶಿಷ್ಟ ಮಾದರಿಗಳು ಮತ್ತು ಸರಿಯಾದ ಸ್ಥಾಪನೆ:

ಸಾಮಾನ್ಯ ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್, ವಿಭಿನ್ನ ಪ್ರಶ್ನೆಗಳು. ಅತ್ಯಂತ ಸಾಮಾನ್ಯವಾದ ಎಂಟರ್‌ಪ್ರೈಸ್ ಮಾದರಿ: ನೂರಾರು ವಿಭಿನ್ನ ಬಳಕೆದಾರರ ಪ್ರಶ್ನೆಗಳೊಂದಿಗೆ ದೊಡ್ಡ ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್ (ಪಾತ್ರ, ನಿಯಮಗಳು, ಬಹುಶಃ ಉಲ್ಲೇಖ ದಾಖಲೆ). ಇಲ್ಲಿ ಸ್ಥಿರ ಭಾಗ (ಸಿಸ್ಟಮ್) ಆರಂಭದಲ್ಲಿ ಸಂಗ್ರಹವಾಗುತ್ತದೆ; ಪ್ರತಿ ಹೊಸ ಪ್ರಶ್ನೆಯು ಅದರ ಸ್ವಂತ ಸಣ್ಣ ಭಾಗಕ್ಕೆ ಮಾತ್ರ ಪೂರ್ಣ ಬೆಲೆಯನ್ನು ಪಾವತಿಸುತ್ತದೆ. ದೊಡ್ಡ ಭಾಗವನ್ನು ಬೆಲೆಯ ಹತ್ತನೇ ಒಂದು ಭಾಗಕ್ಕೆ ಪದೇ ಪದೇ ಪಠಿಸುವುದರಿಂದ ಲಾಭವು ತುಂಬಾ ಹೆಚ್ಚಾಗಿದೆ.

ಬಹು ಸುತ್ತಿನ ಸ್ವಗತ. ಸಂಭಾಷಣೆಯು ಎಳೆಯುತ್ತಿದ್ದಂತೆ, ಪ್ರತಿ ಹೊಸ ಸುತ್ತು ಹಿಂದಿನ ಎಲ್ಲಾ ಇತಿಹಾಸದ ಮೇಲೆ ನಿರ್ಮಿಸುತ್ತದೆ. ಕೊನೆಯ ಸುತ್ತಿನ ಕೊನೆಯಲ್ಲಿ ನೀವು ಕ್ಯಾಶ್ ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಹಾಕಿದರೆ, ಪ್ರತಿ ವಿನಂತಿಯು ಹಿಂದಿನ ಸಂಭಾಷಣೆಯ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಮರುಬಳಕೆ ಮಾಡುತ್ತದೆ; ಸಂಭಾಷಣೆ ಬೆಳೆದಂತೆ ಹಿಟ್‌ಗಳು ಸಂಗ್ರಹಗೊಳ್ಳುತ್ತವೆ. ಇದು ದೀರ್ಘ ಸಹಾಯಕ ಅವಧಿಗಳ ವೆಚ್ಚವನ್ನು ನಾಟಕೀಯವಾಗಿ ನಿಯಂತ್ರಿಸುತ್ತದೆ.

ಹಂಚಿದ ಪೂರ್ವಪ್ರತ್ಯಯವು ಬದಲಾಯಿಸಲು ಕೊನೆಯ ಬಿಟ್ ಆಗಿದೆ. ಬಹು ವಿನಂತಿಗಳು ಸ್ಥಿರವಾದ ಪೂರ್ವಜರ (ಮಾದರಿ ಸೆಟ್, ಸೂಚನೆಗಳು) ದೊಡ್ಡ ಸೆಟ್ ಅನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ ಆದರೆ ಕೊನೆಯಲ್ಲಿ ಒಂದೇ ಪ್ರಶ್ನೆಯಿಂದ ಪ್ರತ್ಯೇಕಿಸಲ್ಪಡುತ್ತವೆ. ಹಂಚಿದ ಭಾಗದ ಕೊನೆಯಲ್ಲಿ ನೀವು ಸಂಗ್ರಹ ಪಾಯಿಂಟರ್ ಅನ್ನು ಹಾಕುತ್ತೀರಿ; ಇಲ್ಲದಿದ್ದರೆ, ಪ್ರತಿಯೊಂದು ವಿನಂತಿಯು ತನ್ನದೇ ಆದ ಪ್ರತ್ಯೇಕ ಸಂಗ್ರಹವನ್ನು ಬರೆಯುತ್ತದೆ ಮತ್ತು ಅದರಲ್ಲಿ ಯಾವುದನ್ನೂ ಓದಲಾಗುವುದಿಲ್ಲ.

ಒಂದು ಎಚ್ಚರಿಕೆ: ಸಂಗ್ರಹವು ಮಾದರಿ ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಕನಿಷ್ಠ ಗಾತ್ರವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ನೀವು ಅವುಗಳನ್ನು ಫ್ಲ್ಯಾಗ್ ಮಾಡಿದರೂ ಸಹ ಸಣ್ಣ ಪೂರ್ವಪ್ರತ್ಯಯಗಳು (ಕೆಲವು ಸಾವಿರ ಟೋಕನ್‌ಗಳ ಅಡಿಯಲ್ಲಿ, ಮಾದರಿಯನ್ನು ಅವಲಂಬಿಸಿ) ಸಂಗ್ರಹವನ್ನು ಮೌನವಾಗಿ ನಮೂದಿಸುವುದಿಲ್ಲ - cache_creation_input_tokens ಶೂನ್ಯವಾಗಿ ಉಳಿಯುತ್ತದೆ. ಅಲ್ಲದೆ, ಮಾದರಿಯ ಮಧ್ಯ-ಸಂಭಾಷಣೆಯನ್ನು ಬದಲಾಯಿಸುವುದು ಸಂಪೂರ್ಣ ಸಂಗ್ರಹವನ್ನು ಅಮಾನ್ಯಗೊಳಿಸುತ್ತದೆ; ವಿಭಿನ್ನ ಕಾರ್ಯಕ್ಕೆ ಅಗ್ಗದ ಮಾದರಿ ಅಗತ್ಯವಿದ್ದರೆ, ಮುಖ್ಯ ಹರಿವನ್ನು ಒಂದು ಮಾದರಿಯಲ್ಲಿ ಇರಿಸಿ ಮತ್ತು ಸೈಡ್ ಕೆಲಸವನ್ನು ಪ್ರತ್ಯೇಕ ಕರೆಯಲ್ಲಿ ಇರಿಸಿ.

ಸಾರಾಂಶದಲ್ಲಿ

ಪ್ರಾಂಪ್ಟ್ ಕ್ಯಾಶಿಂಗ್ ಪೂರ್ವಪ್ರತ್ಯಯ ಹೊಂದಾಣಿಕೆಯಾಗಿದೆ: ಸ್ಥಿರ ವಿಷಯವು ಪ್ರಾರಂಭದಲ್ಲಿರಬೇಕು, ವೇರಿಯಬಲ್ ವಿಷಯವು ಕೊನೆಯಲ್ಲಿರಬೇಕು. ದೊಡ್ಡದಾದ, ಮರುಬಳಕೆಯ ಸಂದರ್ಭಕ್ಕಾಗಿ, ಓದುವ ವೆಚ್ಚವು ಪೂರ್ಣ ಬೆಲೆಯ ಹತ್ತನೇ ಒಂದು ಭಾಗವಾಗಿದೆ, ಸರಿಸುಮಾರು ಎರಡು ವಿನಂತಿಗಳಲ್ಲಿ ಸಹ ಮುರಿದುಹೋಗುತ್ತದೆ. ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್‌ನಲ್ಲಿ ವೇರಿಯಬಲ್ ಡೇಟಾವನ್ನು ಎಂಬೆಡ್ ಮಾಡುವ ಮೂಲಕ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಭ್ರಷ್ಟಗೊಳಿಸುವುದು ಸಾಮಾನ್ಯ ತಪ್ಪು; ಬಳಕೆಯ ಕ್ಷೇತ್ರದಲ್ಲಿ ಹಿಟ್ ಅನ್ನು ಅಳೆಯುವ ಮೂಲಕ ನೀವು ಅದನ್ನು ಪರಿಶೀಲಿಸುತ್ತೀರಿ.

ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯ

ಕೆಲಸದ ಹೊರೆ ಆಯ್ಕೆಮಾಡಿ. (1) ವಿಷಯವನ್ನು ಎರಡು ಕಾಲಮ್‌ಗಳಾಗಿ ವಿಭಜಿಸಿ: "ಎಂದಿಗೂ ಬದಲಾಗುವುದಿಲ್ಲ" ಮತ್ತು "ಪ್ರತಿ ವಿನಂತಿಯೊಂದಿಗೆ ಬದಲಾಗುವುದಿಲ್ಲ". (2) ಪ್ರಾಂಪ್ಟ್ ರಚನೆಯನ್ನು ಪುನಃ ಬರೆಯಿರಿ, ಸ್ಥಿರ ಭಾಗವನ್ನು ಆರಂಭದಲ್ಲಿ ಮತ್ತು ವೇರಿಯಬಲ್ ಭಾಗವನ್ನು ಕೊನೆಯಲ್ಲಿ ಇರಿಸಿ. (3) ಸ್ಥಿರ ಭಾಗದ ಟೋಕನ್ ಗಾತ್ರವನ್ನು ಅಂದಾಜು ಮಾಡಿ ಮತ್ತು ಮಾಸಿಕ ವೆಚ್ಚವನ್ನು ಸಂಗ್ರಹದೊಂದಿಗೆ/ಇಲ್ಲದೆ ಹೋಲಿಕೆ ಮಾಡಿ. (4) ಯಾವ ಕ್ಷೇತ್ರದಿಂದ (cache_read_input_tokens) ನೀವು ಹಿಟ್ ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತೀರಿ ಎಂಬುದನ್ನು ಗಮನಿಸಿ.

ಪರಿಶೀಲನಾಪಟ್ಟಿ

• [ ] ಸಂಗ್ರಹವು ಪೂರ್ವಪ್ರತ್ಯಯ ಹೊಂದಾಣಿಕೆ ಮತ್ತು ಒಂದೇ ಬದಲಾಗದ ನಿಯಮ ಎಂದು ನಾನು ವಿವರಿಸಬಲ್ಲೆ.
• [ ] ಸ್ಥಿರ ವಿಷಯವನ್ನು ಆರಂಭದಲ್ಲಿ ಮತ್ತು ವೇರಿಯಬಲ್ ಅನ್ನು ಕೊನೆಯಲ್ಲಿ ಹಾಕುವ ಮೂಲಕ ನಾನು ನಿಖರತೆಯನ್ನು ಹೆಚ್ಚಿಸಬಹುದು.
• [ ] ನಾನು ಅರ್ಥಶಾಸ್ತ್ರವನ್ನು ಬರೆಯಲು/ಓದಲು ಮತ್ತು ಎರಡು ವಿನಂತಿಯ ಬ್ರೇಕ್-ಈವನ್ ಪಾಯಿಂಟ್ ಅನ್ನು ತಿಳಿದಿದ್ದೇನೆ.
• [ ] ನಾನು ನಿಶ್ಯಬ್ದ ಅಡ್ಡಿಪಡಿಸುವವರನ್ನು ಗುರುತಿಸಬಲ್ಲೆ (ದಿನಾಂಕ, ಆರ್ಡರ್ ಮಾಡದ JSON, ಬದಲಾಗುತ್ತಿರುವ ವಾಹನ ಪಟ್ಟಿ).
• [ ] ನಾನು usage.cache_read_input_tokens ನೊಂದಿಗೆ ಹಿಟ್ ಅನ್ನು ಪರಿಶೀಲಿಸಬಹುದು.