ಲಾಭಗಳು:
- ಸ್ಟ್ರೀಮಿಂಗ್ ಎಂದರೇನು, ಈವೆಂಟ್ ಪ್ರಕಾರಗಳು ಮತ್ತು ಅದು ಏಕೆ ಅಗತ್ಯವಿದೆ ಎಂಬುದನ್ನು ವಿವರಿಸಬಹುದು.
- max_tokens ಸಮಯ ಮೀರುವಿಕೆ ಮತ್ತು 128K ದೀರ್ಘ ಔಟ್ಪುಟ್ ಸಂಬಂಧವನ್ನು ಗ್ರಹಿಸುತ್ತದೆ
- ಕೆಲಸದ ಹೊರೆಗೆ ಅನುಗುಣವಾಗಿ ಸ್ಟ್ರೀಮಿಂಗ್ ಮತ್ತು ಸ್ಟ್ರೀಮಿಂಗ್ ಅಲ್ಲದ ವಿನಂತಿಗಳ ನಡುವೆ ಸರಿಯಾದ ಆಯ್ಕೆಯನ್ನು ಮಾಡಬಹುದು
ಚಾಟ್ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ, ಪ್ರತಿಕ್ರಿಯೆಯು ಪದದಿಂದ ಪದವನ್ನು "ಟೈಪ್" ಮಾಡಿರುವುದನ್ನು ನೀವು ಗಮನಿಸಿರಬಹುದು. ಇದು ದೃಶ್ಯ ಏಳಿಗೆಯಲ್ಲ; ಇದು ಸ್ಟ್ರೀಮಿಂಗ್ ಎಂಬ ತಂತ್ರದ ಫಲಿತಾಂಶವಾಗಿದೆ ಮತ್ತು ಉತ್ಪಾದನೆ-ಗುಣಮಟ್ಟದ LLM ಏಕೀಕರಣಕ್ಕೆ ಸಾಮಾನ್ಯವಾಗಿ ಕಡ್ಡಾಯವಾಗಿದೆ. ಈ ಘಟಕದಲ್ಲಿ, ಹರಿವು ಏನು, ಅದು ಯಾವ ಘಟನೆಗಳನ್ನು ಒಳಗೊಂಡಿದೆ, ದೀರ್ಘ ಔಟ್ಪುಟ್ ಮತ್ತು ಸಮಯ ಮೀರುವಿಕೆಯೊಂದಿಗೆ ಅದರ ಸಂಬಂಧ ಮತ್ತು ಹರಿವನ್ನು ಯಾವಾಗ ಬಳಸಬೇಕು ಮತ್ತು ಯಾವಾಗ ಮಾಡಬಾರದು ಎಂಬುದನ್ನು ನೀವು ಕಲಿಯುವಿರಿ. ನಾವು ವೃತ್ತಿಪರರ ನೈಜ ಕಾರ್ಯಗಳ ಮೂಲಕ ವಿಷಯವನ್ನು ಒಳಗೊಳ್ಳುತ್ತೇವೆ - ಲೈವ್ ಸಹಾಯಕ, ದೀರ್ಘ ವರದಿ ಉತ್ಪಾದನೆ, ಬ್ಯಾಚ್ ಪ್ರಕ್ರಿಯೆ.
ಹರಿವು ಎಂದರೇನು?
ಸ್ಟ್ರೀಮಿಂಗ್ ಅಲ್ಲದ (ಸಿಂಕ್ರೊನಸ್) ವಿನಂತಿಯೊಂದಿಗೆ, ಮಾದರಿಯು ಸಂಪೂರ್ಣ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಉತ್ಪಾದಿಸುವವರೆಗೆ ನೀವು ಕಾಯಿರಿ; ಉತ್ತರ ಸಿದ್ಧವಾದಾಗ, ಅದು ಒಂದೇ ತುಣುಕಿನಲ್ಲಿ ಬರುತ್ತದೆ. ಸ್ಟ್ರೀಮಿಂಗ್ ವಿನಂತಿಯಲ್ಲಿ, ಮಾದರಿಯು ಉತ್ಪಾದಿಸಿದಂತೆ ಸರ್ವರ್ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ತುಂಡು ತುಂಡು ಕಳುಹಿಸುತ್ತದೆ. ತಾಂತ್ರಿಕವಾಗಿ, ಇದನ್ನು ಸರ್ವರ್-ಸೆಂಟ್ ಈವೆಂಟ್ಗಳೊಂದಿಗೆ ಮಾಡಲಾಗುತ್ತದೆ (ಎಸ್ಎಸ್ಇ - ಸರ್ವರ್-ಸೆಂಟ್ ಈವೆಂಟ್ಗಳು, ಸರ್ವರ್ ತೆರೆದ ಸಂಪರ್ಕದ ಮೂಲಕ ಸಣ್ಣ ಘಟನೆಗಳನ್ನು ಅನುಕ್ರಮವಾಗಿ ಕಳುಹಿಸುವ ವಿಧಾನ).
ಬಳಕೆದಾರರ ಅನುಭವದಲ್ಲಿ ವ್ಯತ್ಯಾಸವು ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ: 8 ಸೆಕೆಂಡುಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲಿ, ಸ್ಟ್ರೀಮ್ ಅಲ್ಲದ ಬಳಕೆದಾರರು 8 ಸೆಕೆಂಡುಗಳ ಕಾಲ ಖಾಲಿ ಪರದೆಯತ್ತ ನೋಡುತ್ತಾರೆ; ಸ್ಟ್ರೀಮಿಂಗ್ ಬಳಕೆದಾರರು ಮೊದಲ ಪದಗಳನ್ನು ~0.5 ಸೆಕೆಂಡುಗಳಲ್ಲಿ ನೋಡುತ್ತಾರೆ ಮತ್ತು ಪಠ್ಯವು ಹರಿಯಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಗ್ರಹಿಸಿದ ಸುಪ್ತತೆ-ಬಳಕೆದಾರರು ನಿರೀಕ್ಷಿಸುವ ಕಾಯುವಿಕೆ-ಬಹಳವಾಗಿ ಕಡಿಮೆಯಾಗುತ್ತದೆ, ಆದರೆ ಒಟ್ಟು ಸಮಯವು ಬದಲಾಗದೆ ಉಳಿಯುತ್ತದೆ.
ಈವೆಂಟ್ ಹರಿವಿನ ವಿಧಗಳು
ಹರಿವು ಘಟನೆಗಳ ಅನುಕ್ರಮವಾಗಿದೆ. ಕಲ್ಪನಾತ್ಮಕವಾಗಿ, ಒಂದು ವಿಶಿಷ್ಟ ಹರಿವು ಈ ರೀತಿ ಇರುತ್ತದೆ:
ಘಟನೆ
ಅರ್ಥ
ಸಂದೇಶ_ಪ್ರಾರಂಭ
ಪ್ರತಿಕ್ರಿಯೆ ಪ್ರಾರಂಭವಾಯಿತು; ಮಾಡೆಲ್ ಮತ್ತು ಐಡಿ ಮುಂತಾದ ಹೆಡರ್ ಮಾಹಿತಿ ಬಂದಿದೆ.
ವಿಷಯ_ಬ್ಲಾಕ್_ಪ್ರಾರಂಭ
ವಿಷಯದ ಬ್ಲಾಕ್ (ಉದಾ. ಪಠ್ಯ) ಪ್ರಾರಂಭವಾಗಿದೆ
ವಿಷಯ_ಬ್ಲಾಕ್_ಡೆಲ್ಟಾ
ಪಠ್ಯದ ಒಂದು ಸಣ್ಣ ತುಣುಕು (ಡೆಲ್ಟಾ) ಬಂದಿತು; ನೀವು ಇವುಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ
ವಿಷಯ_ಬ್ಲಾಕ್_ಸ್ಟಾಪ್
ಬ್ಲಾಕ್ ಪೂರ್ಣಗೊಂಡಿದೆ
ಸಂದೇಶ_ಡೆಲ್ಟಾ
stop_reason ಮತ್ತು ಬಳಕೆಯಂತಹ ಅಂತ್ಯದ ಮಾಹಿತಿಯನ್ನು ನವೀಕರಿಸಲಾಗಿದೆ
ಸಂದೇಶ_ಸ್ಟಾಪ್
ಉತ್ತರಿಸಿ
ವಿಷಯ_ಬ್ಲಾಕ್_ಡೆಲ್ಟಾ ಈವೆಂಟ್ಗಳಲ್ಲಿ ನಿಮ್ಮ ಕೋಡ್ ಅನುಕ್ರಮವಾಗಿ ಪಠ್ಯದ ತುಣುಕುಗಳನ್ನು ಸಂಯೋಜಿಸುತ್ತದೆ; ನೀವು ಸ್ಟ್ರೀಮ್ ಮಾಡದ ಪ್ರತಿಕ್ರಿಯೆಯಂತೆಯೇ ಅದೇ ನಿಖರವಾದ ಪಠ್ಯದೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತೀರಿ. ಬಳಕೆ (ಟೋಕನ್ ಸಂಖ್ಯೆಗಳು) ಸಾಮಾನ್ಯವಾಗಿ ಹರಿವಿನ ಕೊನೆಯಲ್ಲಿ ಸ್ಪಷ್ಟವಾಗಿರುತ್ತದೆ - ಹರಿವು ಮುಗಿದ ನಂತರ ನೀವು ವೆಚ್ಚವನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತೀರಿ.
ಸಲಹೆ: ಹೆಚ್ಚಿನ ಅಧಿಕೃತ SDK ಗಳು (ಸಾಫ್ಟ್ವೇರ್ ಡೆವಲಪ್ಮೆಂಟ್ ಕಿಟ್ — ಪೂರೈಕೆದಾರರ ಸಿದ್ಧ ಲೈಬ್ರರಿ) ನಿಮಗಾಗಿ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಸಂಗ್ರಹಿಸುವ ಸಹಾಯಕವನ್ನು ಒದಗಿಸುತ್ತದೆ (ಉದಾ. stream.get_final_message()). ನೀವು ಎಲ್ಲಾ ಟ್ರ್ಯಾಕ್ಗಳನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ನಿರ್ವಹಿಸಬೇಕಾಗಿಲ್ಲ; ನೀವು ಪೂರ್ಣ ಪಠ್ಯವನ್ನು ಬಯಸಿದರೆ, ವೈಯಕ್ತಿಕ ಈವೆಂಟ್ಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಆದರೆ ಲೈವ್ ಮುದ್ರಣಕ್ಕಾಗಿ ಈ ಸಹಾಯಕವನ್ನು ಬಳಸಿ.
ದೀರ್ಘ ಪ್ರತಿಕ್ರಿಯೆಗಳು, max_tokens ಮತ್ತು ಸಮಯ ಮೀರಿದೆ
ಸ್ಟ್ರೀಮಿಂಗ್ನ ಎರಡನೆಯ ಮತ್ತು ಹೆಚ್ಚು ತಾಂತ್ರಿಕ ಕಾರಣವೆಂದರೆ ಸಮಯ ಮೀರುವುದು. ಒಂದು HTTP ವಿನಂತಿಯು ಒಂದು ನಿರ್ದಿಷ್ಟ ಅವಧಿಯೊಳಗೆ ಪೂರ್ಣಗೊಳ್ಳದಿದ್ದರೆ, ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕವನ್ನು ಕೈಬಿಡುತ್ತದೆ. ನೀವು ಮಾದರಿಯಿಂದ ದೊಡ್ಡ ಔಟ್ಪುಟ್ಗೆ ವಿನಂತಿಸಿದಾಗ (ಉದಾಹರಣೆಗೆ 40,000 ಟೋಕನ್ಗಳ ವರದಿ), ಫ್ಲೋ ಅಲ್ಲದ ಕರೆಯು ಈ ಮಿತಿಯನ್ನು ಮೀರಬಹುದು ಮತ್ತು ಸಮಯ ಮೀರಬಹುದು - ವಿನಂತಿಯು ವಿಫಲಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ರಚಿಸಲಾದ ಟೋಕನ್ಗಳಿಗೆ ನೀವು ಪಾವತಿಸಬೇಕಾಗುತ್ತದೆ.
ಆಧುನಿಕ ಮಾದರಿಗಳು ಒಂದೇ ವಿನಂತಿಯಲ್ಲಿ 128,000 ಟೋಕನ್ಗಳವರೆಗೆ ಔಟ್ಪುಟ್ ಮಾಡಬಹುದು. ಆದರೆ ಹೆಬ್ಬೆರಳಿನ ನಿಯಮವು ಸ್ಪಷ್ಟವಾಗಿದೆ: `max_tokens` ಮೌಲ್ಯವು ಅಧಿಕವಾಗಿದ್ದರೆ (ಸರಿಸುಮಾರು 16,000 ಕ್ಕಿಂತ ಹೆಚ್ಚು) ಸ್ಟ್ರೀಮ್ಗಳನ್ನು ಬಳಸಿ. ಸ್ಟ್ರೀಮಿಂಗ್ ಸಂಪರ್ಕವನ್ನು ಜೀವಂತವಾಗಿರಿಸುತ್ತದೆ ಮತ್ತು ಸಮಯ ಮೀರುವುದನ್ನು ತಡೆಯುತ್ತದೆ; ನೀವು ತಕ್ಷಣ ಪ್ರಗತಿಯನ್ನು ಸಹ ನೋಡುತ್ತೀರಿ.
- `max_tokens`: ಮಾದರಿ ಉತ್ಪಾದಿಸಬಹುದಾದ ಗರಿಷ್ಠ ಔಟ್ಪುಟ್ ಟೋಕನ್ಗಳು; ಒಂದು ಗಟ್ಟಿಯಾದ ಸೀಲಿಂಗ್. ಅಡಚಣೆ ಉಂಟಾದರೆ, stop_reason max_tokens ಹಿಂತಿರುಗಿಸಲಾಗುತ್ತದೆ.
- ಸಂದರ್ಭ ವಿಂಡೋ: ಇನ್ಪುಟ್ + ಔಟ್ಪುಟ್ ಮೊತ್ತವು ಹೊಂದಿಕೊಳ್ಳಬೇಕಾದ ವಿಂಡೋ. max_tokens ಔಟ್ಪುಟ್ನ ಸೀಲಿಂಗ್ ಆಗಿದೆ; ಎರಡನ್ನೂ ಬೆರೆಸಬೇಡಿ.
ಎಚ್ಚರಿಕೆ: ದೊಡ್ಡ ಮ್ಯಾಕ್ಸ್_ಟೋಕನ್ಗಳೊಂದಿಗೆ ಹರಿವಲ್ಲದ ವಿನಂತಿಗಳನ್ನು ಎಸೆಯುವುದು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಒಂದು ಶ್ರೇಷ್ಠ ತಪ್ಪು. ಪ್ರತಿಕ್ರಿಯೆಯಿಲ್ಲದೆ, ಸಂಪರ್ಕವು ಇಳಿಯುತ್ತದೆ, ಬಳಕೆದಾರರು ದೋಷವನ್ನು ನೋಡುತ್ತಾರೆ ಮತ್ತು ಟೋಕನ್ ವೆಚ್ಚವು ವ್ಯರ್ಥವಾಗುತ್ತದೆ. ದೀರ್ಘ ಔಟ್ಪುಟ್ = ಸ್ಟ್ರೀಮ್.
ಯಾವಾಗ ಹರಿಯಬೇಕು ಮತ್ತು ಯಾವಾಗ ಅಲ್ಲ?
ಸ್ಥಿತಿ
ಆದ್ಯತೆ
ಏಕೆ
ಲೈವ್ ಚಾಟ್ / ಸಹಾಯಕ
ಹರಿವು
ಗ್ರಹಿಸಿದ ಸುಪ್ತತೆ ಕಡಿಮೆಯಾಗುತ್ತದೆ, ಬಳಕೆದಾರರು ಪ್ರಗತಿಯನ್ನು ನೋಡುತ್ತಾರೆ
ದೀರ್ಘ ವರದಿ / ದಾಖಲೆ ಉತ್ಪಾದನೆ
ಹರಿವು
ಸಮಯ ಮೀರುವುದನ್ನು ತಡೆಯುತ್ತದೆ, ದೊಡ್ಡ ಔಟ್ಪುಟ್ ಅನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಒಯ್ಯುತ್ತದೆ
ಸಣ್ಣ ವರ್ಗೀಕರಣ (ಉದಾ. ಏಕ ಪದದ ಟ್ಯಾಗ್)
ಹರಿವು ಇಲ್ಲ
ಔಟ್ಪುಟ್ ಈಗಾಗಲೇ ಚಿಕ್ಕದಾಗಿದೆ; ಹೆಚ್ಚುವರಿ ಸಂಕೀರ್ಣತೆ ಅನಗತ್ಯ
ಬ್ಯಾಚ್ ಸಂಸ್ಕರಣೆ
ಫ್ಲೋಲೆಸ್/ಬ್ಯಾಚ್
ಫಲಿತಾಂಶಗಳನ್ನು ತಕ್ಷಣವೇ ತೋರಿಸಲಾಗುವುದಿಲ್ಲ; ಘಟಕ 7 ನೋಡಿ
ಆಟೊಮೇಷನ್ ಹಂತ (ಹಿನ್ನೆಲೆಯಲ್ಲಿ)
ಸಾಮಾನ್ಯವಾಗಿ ಹರಿವು ಇರುವುದಿಲ್ಲ
ನೀವು ಫಲಿತಾಂಶವನ್ನು ಮುಂದಿನ ಹಂತಕ್ಕೆ ರವಾನಿಸುತ್ತೀರಿ, ನೇರ ಪ್ರದರ್ಶನವಿಲ್ಲ
ನಕಲು ಮಾಡಬಹುದಾದ ಪ್ರಾಂಪ್ಟ್/ಟೆಂಪ್ಲೇಟ್ಗಳು
ಸ್ಟ್ರೀಮ್ ಸ್ವತಃ ಪ್ರಾಂಪ್ಟ್ ಅಲ್ಲ, ಆದರೆ ಸ್ಟ್ರೀಮ್ನಿಂದ ಉತ್ಪತ್ತಿಯಾಗುವ ಔಟ್ಪುಟ್ ಅನ್ನು ನಿರ್ವಹಿಸಲು ಪ್ರಾಂಪ್ಟ್ಗಳು ನಿರ್ಣಾಯಕವಾಗಿವೆ. ದೀರ್ಘ ಮತ್ತು ಹರಿವಿನ ಉತ್ಪಾದನೆಗಳಲ್ಲಿ, ಮುಂಭಾಗದಿಂದ ರಚನೆಯನ್ನು ಹೇರುವುದು ಗುಣಮಟ್ಟ ಮತ್ತು ಪತ್ತೆಹಚ್ಚುವಿಕೆ ಎರಡನ್ನೂ ಹೆಚ್ಚಿಸುತ್ತದೆ.
# ದೀರ್ಘ ವರದಿಯನ್ನು ವಿಭಾಗಗಳಾಗಿ ವಿಂಗಡಿಸಿ (ಪ್ರಗತಿಯು ಹರಿವಿನಲ್ಲಿ ಗೋಚರಿಸುವಂತೆ) ಈ ನಿಖರವಾದ ಕ್ರಮದಲ್ಲಿ ಕೆಳಗಿನ ಶೀರ್ಷಿಕೆಗಳೊಂದಿಗೆ ವರದಿಯನ್ನು ಬರೆಯಿರಿ. ಪ್ರತಿ ಶಿರೋನಾಮೆಯನ್ನು '##' ನೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿ:## ಸಾರಾಂಶ## ಸಂಶೋಧನೆಗಳು## ಶಿಫಾರಸುಗಳು## ಮುಂದಿನ ಹಂತಗಳು
# ದೀರ್ಘ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಮೊಟಕುಗೊಳಿಸುವುದನ್ನು ತಪ್ಪಿಸಲು ಗುರಿಯ ಉದ್ದವನ್ನು ನೀಡಿ. ಒಟ್ಟು ಪಠ್ಯವು ಸರಿಸುಮಾರು 800 ಪದಗಳಾಗಿರುತ್ತದೆ. ಭಾಗಗಳನ್ನು ಸಮತೋಲಿತವಾಗಿ ಇರಿಸಿ; ಕೊನೆಯಲ್ಲಿ ಅರ್ಧ ವಾಕ್ಯವನ್ನು ಬಿಡಬೇಡಿ.
# ಸ್ಟ್ರೀಮಿಂಗ್ ಸಹಾಯಕರಿಗೆ ಮೊದಲ ವಾಕ್ಯವನ್ನು ತಕ್ಷಣವೇ ನೀಡಿ. ಮೊದಲು ನೇರವಾದ ಒಂದು ವಾಕ್ಯದ ಉತ್ತರವನ್ನು ನೀಡಿ, ನಂತರ ವಿವರವಾಗಿ ಹೋಗಿ. ಆದ್ದರಿಂದ ಬಳಕೆದಾರರು ಕಾಯುತ್ತಿರುವಾಗ ತಕ್ಷಣದ ಫಲಿತಾಂಶವನ್ನು ನೋಡುತ್ತಾರೆ.
# ದೀರ್ಘವಾದ ಔಟ್ಪುಟ್ ಅನ್ನು ರಚನಾತ್ಮಕವಾಗಿ ಇರಿಸಿ (ಆದ್ದರಿಂದ ಇದನ್ನು ನಂತರ ಪಾರ್ಸ್ ಮಾಡಬಹುದು) ಈ ವಿಭಾಗಗಳಲ್ಲಿ ಔಟ್ಪುಟ್ ಅನ್ನು ಔಟ್ಪುಟ್ ಮಾಡಿ ಮತ್ತು ಪ್ರತಿ ವಿಭಾಗವನ್ನು ಪ್ರತ್ಯೇಕ '###' ಹೆಡರ್ನೊಂದಿಗೆ ಗುರುತಿಸಿ ಇದರಿಂದ ನಾನು ಅದನ್ನು ಪ್ರೋಗ್ರಾಮಿಕ್ ಆಗಿ ಪಾರ್ಸ್ ಮಾಡಬಹುದು: ### ಪರಿಚಯ ### ದೇಹ ### ಮೂಲಗಳು
ದುರ್ಬಲ ಪ್ರಾಂಪ್ಟ್ / ಬಲವಾದ ಪ್ರಾಂಪ್ಟ್ (ದೀರ್ಘ ಉತ್ಪಾದನೆ)
# ದುರ್ಬಲ ಈ ವಿಷಯದ ಕುರಿತು ದೀರ್ಘ ಮತ್ತು ವಿವರವಾದ ವರದಿಯನ್ನು ಬರೆಯಿರಿ.
# STRONGಈ ವಿಷಯದ ಕುರಿತು ಸುಮಾರು 900 ಪದಗಳ ವರದಿಯನ್ನು ಬರೆಯಿರಿ. ಶೀರ್ಷಿಕೆಗಳು: ## ಸಾರಾಂಶ, ## ವಿಶ್ಲೇಷಣೆ, ## ಅಪಾಯಗಳು, ## ಶಿಫಾರಸುಗಳು. ಪ್ರತಿ ಶೀರ್ಷಿಕೆಯು ಗರಿಷ್ಠ 3 ಪ್ಯಾರಾಗ್ರಾಫ್ಗಳಾಗಿರಬೇಕು. ಕೊನೆಯಲ್ಲಿ ಅರ್ಧ ವಾಕ್ಯವನ್ನು ಬಿಡಬೇಡಿ.
ಶಕ್ತಿಯುತ ಆವೃತ್ತಿ; ಇದು ಉದ್ದ, ರಚನೆ ಮತ್ತು ಮುಕ್ತಾಯದ ಗುಣಮಟ್ಟವನ್ನು ಮುಂಚಿತವಾಗಿ ನಿರ್ಧರಿಸುತ್ತದೆ. ಹರಿವಿನಲ್ಲಿ ವಿಭಾಗಗಳು ಬರುತ್ತಿದ್ದಂತೆ, ಬಳಕೆದಾರರು ಪ್ರಗತಿಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ನೋಡುತ್ತಾರೆ ಮತ್ತು ಮಾದರಿ ಅಡಚಣೆಯ ಅಪಾಯದ ವಿರುದ್ಧ ಉದ್ದವನ್ನು ಸ್ವತಃ ನಿರ್ವಹಿಸುತ್ತಾರೆ.
ಮೂರು ಮಿನಿ ಪ್ರಕರಣಗಳು
ಪ್ರಕರಣ 1 - ಖಾಲಿ ಪರದೆಯ ದೂರು. ಸಲಹಾ ತಂಡದ ಕ್ಲೈಂಟ್ ಅಸಿಸ್ಟೆಂಟ್ ಹರಿವು ಇಲ್ಲದೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಿದ್ದರು; ಸರಾಸರಿ ಪ್ರತಿಕ್ರಿಯೆ 7 ಸೆಕೆಂಡುಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಬಳಕೆದಾರರು "ಇದು ಫ್ರೀಜ್ ಆಗುತ್ತದೆಯೇ?" ಅವರು ದೂರಿದರು. ಒಮ್ಮೆ ನಾನು ಹರಿವಿಗೆ ಬಂದರೆ, ಮೊದಲ ಪದವು ~0.6 ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಬಂದಿತು; ಒಟ್ಟು ಸಮಯವು ಒಂದೇ ಆಗಿರುತ್ತದೆ, ಆದರೆ "ನಿಧಾನ" ದೂರುಗಳು ಬಹುತೇಕ ಕಣ್ಮರೆಯಾಯಿತು.
ಪ್ರಕರಣ 2 - ಅವಧಿ ಮೀರಿದ ವರದಿ. ಒಂದು ಹಣಕಾಸು ತಂಡವು 30-ಪುಟಗಳ ತ್ರೈಮಾಸಿಕ ವರದಿಯನ್ನು ತಯಾರಿಸಿದೆ; max_tokens: 30000 ಜೊತೆಗೆ, ನೋ-ಫ್ಲೋ ವಿನಂತಿಯು 60-ಸೆಕೆಂಡ್ ಕ್ಲೈಂಟ್ ಟೈಮ್ಔಟ್ನಲ್ಲಿ ಸಿಲುಕಿಕೊಳ್ಳುತ್ತದೆ, ವಿನಂತಿಯು ವಿಫಲಗೊಳ್ಳುತ್ತದೆ - ಮತ್ತು ರಚಿತವಾದ ಟೋಕನ್ಗಳನ್ನು ಇನ್ವಾಯ್ಸ್ಗೆ ಬರೆಯಲಾಗುತ್ತದೆ. ಅವರು ಹರಿವಿನೊಂದಿಗೆ ಹೋದರು; ಸಂಪರ್ಕವು ಲೈವ್ ಆಗಿ ಉಳಿಯಿತು, ವರದಿಯನ್ನು ಪೂರ್ಣವಾಗಿ ವಿತರಿಸಲಾಯಿತು ಮತ್ತು ವ್ಯರ್ಥ ವೆಚ್ಚಗಳನ್ನು ತೆಗೆದುಹಾಕಲಾಯಿತು.
ಪ್ರಕರಣ 3 - ಅನಗತ್ಯ ಹರಿವು. ಕಾರ್ಯಾಚರಣೆಯ ತಂಡವು ಒಳಬರುವ ಇಮೇಲ್ಗಳನ್ನು "ತುರ್ತು/ನಿಯಮಿತ" ಎಂದು ಲೇಬಲ್ ಮಾಡುತ್ತಿದೆ; ಔಟ್ಪುಟ್ ಒಂದು ಪದವಾಗಿತ್ತು, ಆದರೆ ಅವರು ಅಭ್ಯಾಸವಾಗಿ ಹರಿವನ್ನು ಬಳಸಿದರು. ಹರಿವು ಒಂದು ಪದದ ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲಿ ಯಾವುದೇ ಪ್ರಯೋಜನವನ್ನು ನೀಡಲಿಲ್ಲ, ಕೋಡ್ ಅನ್ನು ಅನಗತ್ಯವಾಗಿ ಸಂಕೀರ್ಣಗೊಳಿಸುತ್ತದೆ. ನಾನು ಫ್ಲೋಲೆಸ್ಗೆ ಬದಲಾಯಿಸಿದಾಗ, ಕೋಡ್ ಅನ್ನು ಸರಳಗೊಳಿಸಲಾಯಿತು ಮತ್ತು ನಡವಳಿಕೆಯು ಒಂದೇ ಆಗಿರುತ್ತದೆ. ಪಾಠ: ಸ್ಟ್ರೀಮಿಂಗ್ ದೀರ್ಘ/ಲೈವ್ ಔಟ್ಪುಟ್ನಲ್ಲಿ ಮೌಲ್ಯಯುತವಾಗಿದೆ, ಎಲ್ಲೆಡೆ ಅಲ್ಲ.
ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳು
- ದೀರ್ಘವಾದ ಔಟ್ಪುಟ್ನಲ್ಲಿ ಸ್ಟ್ರೀಮ್ಗಳನ್ನು ಬಳಸದಿರುವುದು: ಸಮಯ ಮೀರುವುದು ಮತ್ತು ಟೋಕನ್ ವೆಚ್ಚವನ್ನು ವ್ಯರ್ಥ ಮಾಡುವುದು.
- ಸಣ್ಣ ಔಟ್ಪುಟ್ನಲ್ಲಿ ಸ್ಟ್ರೀಮಿಂಗ್ ಅನ್ನು ಬಳಸುವುದು: ಅನಗತ್ಯ ಸಂಕೀರ್ಣತೆ, ಶೂನ್ಯ ಪ್ರಯೋಜನ.
- ಸ್ಟ್ರೀಮ್ನ ಕೊನೆಯಲ್ಲಿ `stop_reason` ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತಿಲ್ಲ: max_tokens ನೊಂದಿಗೆ ಮೊಟಕುಗೊಳಿಸಿದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸಂಪೂರ್ಣವೆಂದು ಪರಿಗಣಿಸಲಾಗಿದೆ.
- ತಪ್ಪಾಗಿ ಡೆಲ್ಟಾಗಳನ್ನು ವಿಲೀನಗೊಳಿಸುವುದು: SDK ಸಹಾಯಕದೊಂದಿಗೆ ಹಸ್ತಚಾಲಿತ ಸಂಕಲನವು ಅನುಕ್ರಮ/ಕಾಣೆಯಾದ ಭಾಗಗಳ ದೋಷವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.
- `ಬಳಕೆ~ ಮಧ್ಯ-ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಓದಲು ಪ್ರಯತ್ನಿಸಲಾಗುತ್ತಿದೆ: ಟೋಕನ್ ಸಂಖ್ಯೆಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಕೊನೆಯಲ್ಲಿ ಸ್ಪಷ್ಟವಾಗುತ್ತವೆ; ಕೊನೆಯಲ್ಲಿ ವೆಚ್ಚವನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಿ.
- ವೆಚ್ಚ-ಕಡಿತಕ್ಕಾಗಿ ತಪ್ಪಾದ ಸ್ಟ್ರೀಮಿಂಗ್: ಸ್ಟ್ರೀಮಿಂಗ್ ಅನುಭವ ಮತ್ತು ಸಹಿಷ್ಣುತೆಯನ್ನು ಸುಧಾರಿಸುತ್ತದೆ; ಇದು ಟೋಕನ್ ಬೆಲೆಯನ್ನು ಬದಲಾಯಿಸುವುದಿಲ್ಲ.
ಆಳವಾದ: ಹರಿವು ವಿರಾಮಗಳು ಮತ್ತು ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವ
ಸ್ಟ್ರೀಮಿಂಗ್ ನೇರ ಸಂಪರ್ಕವಾಗಿದೆ; ಇದು ಅದರ ಶಕ್ತಿ ಮತ್ತು ದುರ್ಬಲತೆ ಎರಡೂ ಆಗಿದೆ. ಸಂಪರ್ಕವು ಮಧ್ಯದಲ್ಲಿ ಬಿದ್ದರೆ (ನೆಟ್ವರ್ಕ್ ಏರಿಳಿತ, ಕ್ಲೈಂಟ್ ಸಮಯ ಮೀರಿದೆ), ನೀವು ಇಲ್ಲಿಯವರೆಗೆ ಸಂಗ್ರಹಿಸಿದ ಪಠ್ಯವನ್ನು ನೀವು ಉಳಿಸಿಕೊಳ್ಳುತ್ತೀರಿ, ಆದರೆ ಪ್ರತಿಕ್ರಿಯೆಯು ಅಪೂರ್ಣವಾಗಿರುತ್ತದೆ. ಉತ್ಪಾದನೆ-ಗುಣಮಟ್ಟದ ಸ್ಟ್ರೀಮಿಂಗ್ ಕ್ಲೈಂಟ್ ಇದಕ್ಕಾಗಿ ಸಿದ್ಧರಾಗಿರಬೇಕು: ಇದು ಭಾಗಶಃ ಪಠ್ಯವನ್ನು "ಸಂಪೂರ್ಣ ಪ್ರತಿಕ್ರಿಯೆ" ಎಂದು ಪರಿಗಣಿಸಬಾರದು ಅಥವಾ ಸಂದೇಶ_ಸ್ಟಾಪ್ ಈವೆಂಟ್ ಅನ್ನು ನೋಡುವವರೆಗೆ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸಬೇಕು ಎಂದು ಪರಿಗಣಿಸಬಾರದು.
ಎರಡನೆಯ ಸೂಕ್ಷ್ಮತೆಯೆಂದರೆ ಹರಿವು ವೆಚ್ಚವನ್ನು ಬದಲಾಯಿಸುವುದಿಲ್ಲ. ಸ್ಟ್ರೀಮಿಂಗ್ನೊಂದಿಗೆ ಅಥವಾ ಇಲ್ಲದೆಯೇ ನೀವು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸಿದರೆ ಟೋಕನ್ ಬೆಲೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ; ಹರಿವು ಅನುಭವ ಮತ್ತು ಸಹಿಷ್ಣುತೆಯನ್ನು ಮಾತ್ರ ಸುಧಾರಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ "ನಾವು ಸ್ಟ್ರೀಮಿಂಗ್ಗೆ ಹೋದರೆ, ಅವು ಅಗ್ಗವಾಗುತ್ತವೆಯೇ?" ಪ್ರಶ್ನೆಗೆ ಉತ್ತರ ಇಲ್ಲ - ವೆಚ್ಚಕ್ಕಾಗಿ, 5 ನೇ ಮತ್ತು 6 ನೇ ಘಟಕವನ್ನು ನೋಡಿ (ಮಾದರಿ ಆಯ್ಕೆ, ಸಂಗ್ರಹ).
ಮೂರನೆಯ ಅಂಶವು ಪ್ರಾಯೋಗಿಕ ಸಮತೋಲನವನ್ನು ಹೊಡೆಯುವುದು: ಲೈವ್ ಸಹಾಯಕರೊಂದಿಗೆ, ಮೊದಲ ಪದದ ತ್ವರಿತ ಆಗಮನ (ಗ್ರಹಿಸಿದ ವಿಳಂಬ) ಹೆಚ್ಚು ಮೌಲ್ಯಯುತವಾಗಿದೆ; ಆದ್ದರಿಂದ, ಮಾದರಿಯನ್ನು ನೇರವಾಗಿ ಉತ್ತರವನ್ನು ನಮೂದಿಸಲು ಮತ್ತು ಮೊದಲು ಸಣ್ಣ ಫಲಿತಾಂಶವನ್ನು ನೀಡಲು ಕೇಳುವುದು (4 ನೇ ಘಟಕದಲ್ಲಿ ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್ ಮೂಲಕ) ಹರಿವಿನ ಪ್ರಯೋಜನವನ್ನು ಗುಣಿಸುತ್ತದೆ. ಬಳಕೆದಾರರು ಮೊದಲ ಸೆಕೆಂಡಿನಲ್ಲಿ ಏನನ್ನಾದರೂ ಅರ್ಥಪೂರ್ಣವಾಗಿ ನೋಡಿದರೆ, ಅವರು ಅನುಸರಿಸುವ ವಿವರಗಳಿಗಾಗಿ ತಾಳ್ಮೆಯಿಂದ ಕಾಯುತ್ತಾರೆ. ಮತ್ತೊಂದೆಡೆ, ಹಿನ್ನಲೆಯಲ್ಲಿ ನಡೆಯುವ ಉದ್ಯೋಗಗಳಿಗೆ ಹರಿವು ಯಾವುದೇ ಕೊಡುಗೆಯನ್ನು ಹೊಂದಿಲ್ಲ, ಅದರ ಔಟ್ಪುಟ್ ಮುಂದಿನ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಹಂತಕ್ಕೆ ಹೋಗುತ್ತದೆ; ಕೆಲಸವನ್ನು ಸರಿಯಾಗಿ ಮತ್ತು ಸಂಪೂರ್ಣವಾಗಿ ಪೂರ್ಣಗೊಳಿಸುವುದು ಮಾತ್ರ ಮಾನದಂಡವಾಗಿದೆ.
ಸಾರಾಂಶದಲ್ಲಿ
ಸ್ಟ್ರೀಮಿಂಗ್ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ತುಂಡಾಗಿ ಹಿಂಪಡೆಯುತ್ತದೆ, ಗ್ರಹಿಸಿದ ಸುಪ್ತತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ದೊಡ್ಡ ಥ್ರೋಪುಟ್ಗಳಲ್ಲಿ ಸಮಯ ಮೀರುವುದನ್ನು ತಡೆಯುತ್ತದೆ. ಲೈವ್ ಸಹಾಯಕ ಮತ್ತು ದೀರ್ಘ ದಾಖಲೆ ಉತ್ಪಾದನೆಗೆ ಬಹುತೇಕ ಕಡ್ಡಾಯವಾಗಿದೆ; ಸಣ್ಣ/ಹಿನ್ನೆಲೆ ಕೆಲಸಕ್ಕೆ ಇದು ಅನಗತ್ಯ. ದೀರ್ಘ ನಿರ್ಮಾಣಗಳಲ್ಲಿ, ಪ್ರಾಂಪ್ಟ್ನೊಂದಿಗೆ ಮುಂಭಾಗದಿಂದ ರಚನೆ ಮತ್ತು ಉದ್ದವನ್ನು ಹೇರುವುದು ಗುಣಮಟ್ಟ ಮತ್ತು ಪತ್ತೆಹಚ್ಚುವಿಕೆ ಎರಡನ್ನೂ ಹೆಚ್ಚಿಸುತ್ತದೆ; ಹರಿವು ಪೂರ್ಣಗೊಂಡಾಗ, stop_reason ಮತ್ತು ಬಳಕೆಯನ್ನು ಖಂಡಿತವಾಗಿ ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ.
ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯ
ಎರಡು ಸನ್ನಿವೇಶಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಿ: ಒಂದು ಲೈವ್/ಲಾಂಗ್ (ಉದಾ. ಗ್ರಾಹಕರಿಗೆ ವರದಿ), ಒಂದು ಚಿಕ್ಕ/ಹಿನ್ನೆಲೆ (ಉದಾ. ಟ್ಯಾಗ್ ಮಾಡುವುದು). (1) ಪ್ರತಿಯೊಂದಕ್ಕೂ ನೀವು ಹರಿವನ್ನು ಬಳಸುತ್ತೀರಾ ಎಂದು ನಿರ್ಧರಿಸಿ ಮತ್ತು ಸಮರ್ಥಿಸಿ. (2) ದೀರ್ಘ ಸ್ಕ್ರಿಪ್ಟ್ಗೆ ರಚನೆಯನ್ನು ವಿಧಿಸುವ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಬರೆಯಿರಿ (ಶೀರ್ಷಿಕೆಗಳು + ಗುರಿ ಉದ್ದ). (3) max_tokens ಮೌಲ್ಯಗಳನ್ನು ನಿರ್ಧರಿಸಿ. (4) ಹರಿವಿನ ಕೊನೆಯಲ್ಲಿ stop_reason ಮತ್ತು ಬಳಕೆಯೊಂದಿಗೆ ನೀವು ಯಾವ ತಪಾಸಣೆಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತೀರಿ ಎಂಬುದನ್ನು ಪಟ್ಟಿ ಮಾಡಿ.
ಪರಿಶೀಲನಾಪಟ್ಟಿ
- [ ] ಸ್ಟ್ರೀಮಿಂಗ್ ಎಂದರೇನು ಮತ್ತು ಅದು ಗ್ರಹಿಸಿದ ಸುಪ್ತತೆಯನ್ನು ಹೇಗೆ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ನಾನು ವಿವರಿಸಬಲ್ಲೆ.
- [ ] ನಾನು ಸ್ಟ್ರೀಮ್ ಮತ್ತು ಡೆಲ್ಟಾ ಸೇರುವಿಕೆಯ ಮೂಲಭೂತ ಈವೆಂಟ್ ಪ್ರಕಾರಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ.
- [ ] ದೊಡ್ಡ ಮ್ಯಾಕ್ಸ್_ಟೋಕನ್ಗಳೊಂದಿಗೆ ಸ್ಟ್ರೀಮ್ ಮಾಡುವ ಅಗತ್ಯತೆ ಮತ್ತು ಸಮಯ ಮೀರುವ ಸಂಬಂಧದ ಬಗ್ಗೆ ನನಗೆ ತಿಳಿದಿದೆ.
- [ ] ನಾನು ಯಾವ ಕೆಲಸದ ಹೊರೆಯಲ್ಲಿ ಸ್ಟ್ರೀಮಿಂಗ್ ಅನ್ನು ಬಳಸುತ್ತೇನೆ ಮತ್ತು ಯಾವುದರಲ್ಲಿ ನಾನು ಬಳಸುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ನಾನು ನಿರ್ಧರಿಸಬಹುದು.
- [ ] ನಾನು ಸ್ಟ್ರೀಮ್ನ ಕೊನೆಯಲ್ಲಿ stop_reason ಮತ್ತು ಬಳಕೆಯನ್ನು ಪರಿಶೀಲಿಸಬಹುದು.