ನೀವು ದೊಡ್ಡ ಭಾಷಾ ಮಾದರಿಯನ್ನು (LLM) ಇಮೇಲ್ ಮೂಲಕ ಮನುಷ್ಯನ ಅನುಮೋದನೆ ಬೇಕಾಗುವ ವರ್ಕ್‌ಫ್ಲೋಗೆ ಜೋಡಿಸಿದಾಗ, ಮಾದರಿಯೇ ವಿಫಲವಾಗುವುದು ಅಪರೂಪ. ಕೋಡ್ ಮುಗಿದು ಇನ್‌ಬಾಕ್ಸ್ ಪ್ರಾರಂಭವಾಗುವಲ್ಲಿ ಈ ವಿಫಲತೆ ಸಂಭವಿಸುತ್ತದೆ. ಒಂದು ಸ್ವಾಯತ್ತ ರನ್ (autonomous run) ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ. ಮೊದಲನೆಯದು ಪೂರ್ಣಗೊಳ್ಳುವ ಮೊದಲೇ ಮತ್ತೊಂದು ರನ್ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಒಂದು ಹಂಚಿಕೆಯ ಇನ್‌ಬಾಕ್ಸ್ ವಿವಿಧ ಪ್ರಕ್ರಿಯೆಗಳಿಂದ ಬಂದ ಥ್ರೆಡ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಹನ್ನೆರಡು ಗಂಟೆ ತಡವಾಗಿ ಬಂದ ಸಂದೇಶಕ್ಕೆ ಯಾರೋ 'ಅಪ್ರೂವ್' (approve) ಕ್ಲಿಕ್ ಮಾಡುತ್ತಾರೆ. ಈಗ ನಿಮ್ಮ ಬಳಿ ಔಟ್‌ಪುಟ್ ಇದೆ. ನಿರ್ಧಾರವೂ ಇದೆ. ಆದರೆ ಯಾವ ರನ್ ಯಾವುದನ್ನು ಸೃಷ್ಟಿಸಿತು ಅಥವಾ ಆ ಅನುಮೋದನೆಯು ಈ ಜನರೇಷನ್‌ಗಾಗಿ ಇತ್ತೇ ಎಂದು ನೀವು ಸಾಬೀತುಪಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಈ ಮಾದರಿಯನ್ನು ತಿಳಿಯಲು ನಾನು ಸಾಕಷ್ಟು ಆಂತರಿಕ ಆಟೊಮೇಷನ್ ಪೈಪ್‌ಲೈನ್‌ಗಳನ್ನು ಸರಿಪಡಿಸಿದ್ದೇನೆ. ಇದು ಗೊಂದಲದಿಂದ ಘಟನೆಯಾಗಿ (incident) ಬದಲಾಗುವುದು ಹೆಚ್ಚಿನ ತಂಡಗಳು ನಿರೀಕ್ಷಿಸುವതിಗಿಂತ ವೇಗವಾಗಿ ನಡೆಯುತ್ತದೆ.

ಕಾರ್ಯಾಚರಣೆಯ ಗಡಿ

ನಿಮ್ಮ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ (orchestrator) ಮತ್ತು ಇಮೇಲ್ ಪ್ರೊವೈಡರ್ ನಡುವಿನ ಗಡಿಯು ಕೇವಲ ನೆಟ್‌ವರ್ಕ್ ಹॉप (network hop) ಅಲ್ಲ. ಇದು ಒಂದು ಸ್ಟೇಟ್ ಬೌಂಡರಿ (state boundary). LLM ಡ್ರಾಫ್ಟ್ ಸಿದ್ಧಪಡಿಸಿದ ನಂತರವೂ, ಆ ರನ್ ಇನ್ನೂ ಜೀವಂತವಾಗಿರುತ್ತದೆ. ಅದು ಕಾಯುತ್ತಿರುತ್ತದೆ. ನಿಮ್ಮ ಸಿಸ್ಟಮ್ 'ಸೆಂಡ್' (send) ಅನ್ನು ಕಳುಹಿಸಿ ಮರೆತುಬಿಡುವ (fire-and-forget) ಘಟನೆಯೆಂದು ಪರಿಗಣಿಸಿದರೆ, ನೀವು ಈಗಾಗಲೇ ನಿಯಂತ್ರಣವನ್ನು ಕಳೆದುಕೊಂಡಿದ್ದೀರಿ ಎಂದರ್ಥ.

ರಿಟ್ರೈ ಪಾಲಿಸಿ (retry policy) ಅತಿಯಾಗಿದ್ದ ಕಾರಣ, ಒಂದೇ ರನ್ ಎರಡು ಪ್ರತ್ಯೇಕ ಅನುಮೋದನಾ ವಿನಂತಿಗಳನ್ನು ಸೃಷ್ಟಿಸುವ ಪೈಪ್‌ಲೈನ್‌ಗಳನ್ನು ನಾನು ನೋಡಿದ್ದೇನೆ. ಕಳೆದ ವಾರದ ಸಂದೇಶಗಳನ್ನು ಇಟ್ಟುಕೊಂಡಿದ್ದ ಮೇಲ್‌ಬಾಕ್ಸ್ ಅನ್ನು ಮತ್ತೊಂದು ರನ್ ಮರುಬಳಕೆ ಮಾಡುವುದನ್ನು ನಾನು ನೋಡಿದ್ದೇನೆ. ಮನುಷ್ಯ ಅನುಮೋದಕರು (approver) ರನ್ ಐಡಿಗಳನ್ನು (run IDs) ನೋಡುವುದಿಲ್ಲ. ಅವರು ವಿಷಯದ ಸಾಲು (subject line) ಮತ್ತು ಒಂದು ಬಟನ್ ಅನ್ನು ಮಾತ್ರ ನೋಡುತ್ತಾರೆ. ಯಾವುದೇ ರಚನೆ ಇಲ್ಲದಿದ್ದರೆ, ಅವರು ಮಾರ್ಕೆಟಿಂಗ್ ನ್ಯೂಸ್‌ಲೆಟರ್‌ಗಳು ಮತ್ತು ಮಾನಿಟರಿಂಗ್ ಅಲರ್ಟ್‌ಗಳು ಇರುವ ಅದೇ ಇನ್‌ಬಾಕ್ಸ್‌ನಲ್ಲಿ ಅಂದಾಜಿಸುತ್ತಿರುತ್ತಾರೆ.

ನಿರ್ಲಕ್ಷಿತ ಹಂತ

ತಂಡಗಳು ಪ್ರಾಂಪ್ಟ್‌ಗಳನ್ನು (prompts) ಟ್ಯೂನ್ ಮಾಡಲು, ಗಾರ್ಡ್‌ರೈಲ್‌ಗಳನ್ನು (guardrails) ಸೇರಿಸಲು ಮತ್ತು ಔಟ್‌ಪುಟ್‌ಗಳನ್ನು ಬೆಂಚ್‌ಮಾರ್ಕ್ ಮಾಡಲು ವಾರಗಟ್ಟಲೆ ಸಮಯ ವ್ಯಯಿಸುತ್ತವೆ. ನಂತರ ಅವರು ಅನುಮೋದನಾ ಹಂತವನ್ನು ಸ್ಲ್ಯಾಕ್ (Slack) ಚಾನಲ್ ಅಥವಾ ಹಂಚಿಕೆಯ ಸಪೋರ್ಟ್ ಇನ್‌ಬಾಕ್‌ಗೆ ಜೋಡಿಸಿ ಕೆಲಸ ಮುಗಿದಿದೆ ಎಂದು ಭಾವಿಸುತ್ತಾರೆ. ಇದು ಮೂರು ಅನಿವಾರ್ಯ ಸಮಸ್ಯೆಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ:

  • ಹಂಚಿಕೆಯ ಇನ್‌ಬಾಕ್ಸ್ವು ಅನೇಕ ರನ್‌ಗಳಿಂದ ಬರುವ ಘಟನೆಗಳ ಡಂಪಿಂಗ್ ಗ್ರೌಂಡ್ ಆಗುತ್ತದೆ. ಸಂದರ್ಭದ ಸ್ಪಷ್ಟತೆ (context) ಇಲ್ಲದಂತಾಗುತ್ತದೆ. ಥ್ರೆಡ್‌ಗಳನ್ನು ತೆರೆಯದೆ ಮತ್ತು ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ಗಳನ್ನು ಕೈಯಾರೆ ಪರಿಶೀಲಿಸದೆ, ಯಾವ ಸಂದೇಶವು ಯಾವ ವ್ಯವಹಾರದ ವಹಿವಾಟಿಗೆ (business transaction) ಸೇರಿದ್ದು ಎಂದು ನೀವು ಮರುನಿರ್ಮಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
  • ರಿಟ್ರೈಗಳು (Retries) ಪುರಾವೆಗಳನ್ನು ಅಳಿಸಿಹಾಕುತ್ತವೆ. ಒಂದು ರನ್ ತನ್ನ ಅನುಮೋದನಾ ವಿನಂತಿಯನ್ನು ಮರುಕಳುಹಿಸಿದರೆ, ಮೂಲ ಸಂದೇಶವು ಹೂತುಹೋಗಬಹುದು, ಅಳಿಸಲ್ಪಟ್ಟಿರಬಹುದು ಅಥವಾ ಇಮೇಲ್ ಕ್ಲೈಂಟ್‌ನಿಂದ ಡ್ಯೂಪ್ಲಿಕೇಟ್ ಎಂದು ಗುರುತಿಸಲ್ಪಟ್ಟಿರಬಹುದು. ಇದರಿಂದ ಆಡಿಟ್ ಟ್ರೈಲ್ (audit trail) ಹದಗೆಡುತ್ತದೆ.
  • ಮನುಷ್ಯನ ನಿರ್ಧಾರಗಳು ಸಿಸ್ಟಮ್‌ನ ಹೊರಗಡೆ ಇರುತ್ತವೆ. ಯಾರೋ ಒಬ್ಬರು ಟಿಕೆಟ್‌ನಲ್ಲಿ ಅಥವಾ ನೇರ ಸಂದೇಶದಲ್ಲಿ "looks good" ಎಂದು ಉತ್ತರಿಸಬಹುದು. ಆ ಪ್ರತಿಕ್ರಿಯೆಯು ವರ್ಕ್‌ಫ್ಲೋದ ಒಳಗಿನ ಸ್ಟ್ರಕ್ಚರ್ಡ್ ಡೇಟಾ (structured data) ಆಗಿ ಎಂದಿಗೂ ಬದಲಾಗುವುದಿಲ್ಲ. ಯಾರು, ಏನು ಮತ್ತು ಯಾವಾಗ ಹೇಳಿದರು ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಲು ಏಜೆಂಟ್‌ಗೆ ಯಾವುದೇ ದಾರಿಯಿಲ್ಲ.

ಏನಾದರೂ ತಪ್ಪಾದಾಗ ಮತ್ತು ನೀವು ತನಿಖೆ ನಡೆಸಬೇಕಾದಾಗ, ನಿಮಗೆ ಕೇವಲ ವದಂತಿಗಳು ಅಥವಾ ಅಂದಾಜುಗಳು ಮಾತ್ರ ಸಿಗುತ್ತವೆ. "ಅದು ಸರಿಯಾದ ಇಮೇಲ್ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ." ನೆನಪಿನ ಶಕ್ತಿಯು ಟ್ರೇಸಿಬಿಲಿಟಿ (traceability) ಅಲ್ಲ. ಆಡಿಟ್ ಲಾಗ್ (audit log) ಕೇವಲ ಒಂದು ಕಲ್ಪನೆಯನ್ನು (hunch) ಸ್ವೀಕರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಡೆಲಿವರಿ ವಿವರದಿಂದ ಚೆಕ್‌ಪಾಯಿಂಟ್‌ವರೆಗೆ

ಇದನ್ನು ಸರಿಪಡಿಸಲು ವಿನ್ಯಾಸದಲ್ಲಿ ಬದಲಾವಣೆ ಅಗತ್ಯವಿದೆ. ಇಮೇಲ್ ಅನ್ನು ಕೇವಲ ಒಂದು ಡೆಲಿವರಿ ವಿವರವೆಂದು ಭಾವಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ಅದನ್ನು ಸಿಸ್ಟಮ್ ಚೆಕ್‌ಪಾಯಿಂಟ್ (system checkpoint) ಎಂದು ಪರಿಗಣಿಸಲು ಪ್ರಾರಂಭಿಸಿ. ಅಂದರೆ ಪ್ರತಿ ಸಂದೇಶವು ಒಂದು ಸ್ಟೇಟ್ ಟ್ರಾನ್ಸಿಶನ್ (state transition) ಆಗಿದೆ, ಮತ್ತು ಪ್ರತಿ ಸ್ಟೇಟ್ ಟ್ರಾನ್ಸಿಶನ್‌ಗೆ ಗುರುತು (identity), ಅಧಿಕಾರ (authorization) ಮತ್ತು ಪುರಾವೆ (evidence) ಅಗತ್ಯವಿದೆ.

ನೀವು ಈ ಮನೋಭಾವವನ್ನು ಅಳವಡಿಸಿಕೊಂಡಾಗ, ಪ್ರಶ್ನೆಗಳು ಬದಲಾಗುತ್ತವೆ. ಇಮೇಲ್ ಯಶಸ್ವಿಯಾಗಿ ಕಳುಹಿಸಲ್ಪಟ್ಟಿದೆಯೇ ಎಂದು ಕೇಳುವ ಬದಲು, ಯಾವ ರನ್ ಅದನ್ನು ಕಳುಹಿಸಿತು, ಅದು ಯಾವ ಪುರಾವೆಯನ್ನು ಬಿಟ್ಟುಹೋಗಿದೆ ಮತ್ತು ಯಾವ ನಿಯಮವು ವರ್ಕ್‌ಫ್ಲೋವನ್ನು ಮುಂದುವರಿಸಲು ಅಧಿಕಾರ ನೀಡಿದೆ ಎಂದು ಕೇಳಲು ಪ್ರಾರಂಭಿಸುತ್ತೀರಿ. ಏಜೆಂಟ್ ಖಂಡಿತವಾಗಿಯೂ ಇಮೇಲ್ ಬಾಡಿಯನ್ನು ಬರೆಯಬಹುದು. ಆದರೆ ನಿಮ್ಮ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಗುರುತು ಮತ್ತು ಪರಿಶೀಲನಾ ಮಾರ್ಗಗಳನ್ನು (identity and verification paths) ಕಡ್ಡಾಯಗೊಳಿಸಬೇಕು. LLM ಬರಹಗಾರನಾದರೆ, ಇನ್ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್ ನೋಟರಿ (notary) ಇದ್ದಂತೆ.

ಕನಿಷ್ಠ ವಿನ್ಯಾಸ

ಇದನ್ನು ನಿರ್ಮಿಸಲು ನಿಮಗೆ ಅಪಾರ ಸಂಪತ್ತಿನ ಅಗತ್ಯವಿಲ್ಲ. ನನ್ನ ಕನಿಷ್ಠ ಕಾರ್ಯಸಾಧ್ಯವಾದ (minimum viable) ಆವೃತ್ತಿಯು ಐದು ಉದ್ದೇಶಪೂರ್ವಕ ಅಂಶಗಳನ್ನು ಬಳಸುತ್ತದೆ.

  • ವರ್ಕ್‌ಫ್ಲೋ ಪ್ರಾರಂಭವಾಗುವ ನಿಖರ ಕ್ಷಣದಲ್ಲಿ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಒಂದು run_id ಅನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಈ ಗುರುತಿನ ಸಂಖ್ಯೆಯು (identifier) ನಂತರದ ಪ್ರತಿಯೊಂದು ಕ್ರಿಯೆಯ ಬೆನ್ನೆಲುಬಾಗಿದೆ. ಇದು ಎಂದಿಗೂ ಬದಲಾಗುವುದಿಲ್ಲ ಮತ್ತು ಮರುಬಳಕೆಯಾಗುವುದಿಲ್ಲ.
  • ಪ್ರತಿ ಇಮೇಲ್ ಕ್ರಿಯೆಯು ಮೂರು ಫೀಲ್ಡ್‌ಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ: run_id, "approval_request" ಅಥವಾ "evidence_notification" ನಂತಹ message_type ಲೇಬಲ್, ಮತ್ತು ಯಾವ ಗವರ್ನೆನ್ಸ್ ನಿಯಮಗಳು ಸಕ್ರಿಯವಾಗಿವೆ ಎಂದು ಗುರುತಿಸುವ policy_version ಸ್ಟ್ರಿಂಗ್. ಇದು ಸಾಮಾನ್ಯ ಸಂದೇಶವನ್ನು ಟೈಪ್ಡ್ ಇವೆಂಟ್ (typed event) ಆಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.
  • ಪುರಾವೆಯು ರನ್‌ನಿಂದ ಪ್ರತ್ಯೇಕವಾದ ಇನ್‌ಬಾಕ್ಸ್‌ನಲ್ಲಿ ಇರುತ್ತದೆ. ಇದರರ್ಥ ಪ್ರತಿ ರನ್‌ಗಾಗಿ ಪ್ರತ್ಯೇಕ ಇಮೇಲ್ ಖಾತೆಯೆಂದಲ್ಲ. ಇದು ಒಂದು ಮೀಸಲಾದ ಲೇಬಲ್, ಸಬ್‌ಫೋಲ್ಡರ್ ಅಥವಾ ಥ್ರೆಡ್‌ಗಳನ್ನು ವಿಂಗಡಿಸುವ ರೂಟಿಂಗ್ ರೂಲ್ ಆಗಿರಬಹುದು, ಇದರಿಂದ ಒಂದು ರನ್‌ನ ಪತ್ರವ್ಯವಹಾರವು ಇನ್ನೊಂದರೊಂದಿಗೆ ಬೆರೆಯುವುದಿಲ್ಲ.
  • ಅನುಮೋದನಾ ಪ್ರತಿಕ್ರಿಯೆಯು ಒಂದು ಸ್ಟ್ರಕ್ಚರ್ಡ್ ಇವೆಂಟ್ ಆಗಿರಬೇಕು, ಕೇವಲ "ok" ಎಂಬ ಫ್ರೀ-ಟೆಕ್ಸ್ಟ್ ಆಗಿರಬಾರದು. ಮನುಷ್ಯನು ಕ್ಲಿಕ್ ಮಾಡಬಹುದು ಅಥವಾ ಉತ್ತರಿಸಬಹುದು, ಆದರೆ ಸಿಸ್ಟಮ್ ಆ ಕ್ರಿಯೆಯನ್ನು run_id, ನಿರ್ಧಾರ ಮತ್ತು ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ ಅನ್ನು ಒಳಗೊಂಡ ಯಂತ್ರ-ಓದಬಲ್ಲ (machine-readable) ಪೇಲೋಡ್ ಆಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.
  • ಪುರಾವೆ ಮತ್ತು ನಿರ್ಧಾರವು ಹೊಂದಿಕೆಯಾದರೆ ಮಾತ್ರ ಪ್ರಕ್ರಿಯೆಯು ಮುಂದುವರಿಯುತ್ತದೆ. ವರ್ಕ್‌ಫ್ಲೋವು ಅನುಮೋದನೆಯನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ನಂಬುವುದಿಲ್ಲ. LLM ಔಟ್‌ಪುಟ್ ಪ್ರೊಡಕ್ಷನ್‌ಗೆ ತಲುಪುವ ಮೊದಲು, ಅದು ಮೂಲ ವಿನಂತಿಯೊಂದಿಗೆ ಅನುಮೋದನಾ ಪೇಲೋಡ್ ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ.

ಒಂದು ಉಪಯುಕ್ತ ಚೆಕ್‌ಪಾಯಿಂಟ್ ಏನನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ

ಒಂದು ಉಪಯುಕ್ತ ಚೆಕ್‌ಪಾಯಿಂಟ್ ಮಾನವ ನಿರ್ಧಾರವನ್ನು ಸ್ವೀಕರಿಸುವ ಮೊದಲು ನಾಲ್ಕು ಷರತ್ತುಗಳನ್ನು ಜಾರಿಗೊಳಿಸುತ್ತದೆ.

  • ಸ್ವೀಕರಿಸುವವರು ರನ್ ಕಾನ್ಟೆಕ್ಸ್‌ನ (run context) ಭಾಗವಾಗಿರಬೇಕು. ಅನುಮೋದಕರು ಈ ನಿರ್ದಿಷ್ಟ ವರ್ಕ್‌ಫ್ಲೋ ಇನ್‌ಸ್ಟೆನ್ಸ್‌ನ (workflow instance) ನಿಯೋಜಿತ ವಿಮರ್ಶಕರಲ್ಲದಿದ್ದರೆ, ಸಿಸ್ಟಮ್ ಆ ಸಂಕೇತವನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ.
  • ವಿಷಯ ಅಥವಾ ರೂಟಿಂಗ್ ಮೆಟಾಡೇಟಾ ಪ್ರಸ್ತುತ ಹರಿವಿನ ಸ್ಥಿತಿಗೆ (flow state) ಹೊಂದಿಕೆಯಾಗಬೇಕು. ಹಂತ ಮೂರರ ಅನುಮೋದನೆಯು ಹಂತ ಎರಡನ್ನು ಕಡೆಗಣಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
  • ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ ನಿರೀಕ್ಷಿತ ಸಮಯದ ಮಿತಿಯೊಳಗೆ ಇರಬೇಕು. ಟೈಮ್‌ಔಟ್ ಆದ ನಂತರ ಬರುವ ನಿರ್ಧಾರವು ಹೊಸ ವಿಮರ್ಶೆಯನ್ನು ಪ್ರಚೋದಿಸಬೇಕೇ ಹೊರತು, ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಅಂಗೀಕರಿಸಬಾರದು.
  • ಸಾಕ್ಷ್ಯವನ್ನು (evidence) ಮತ್ತೊಂದು ರನ್‌ನಲ್ಲಿ ಮರುಬಳಕೆ ಮಾಡಬಾರದು. ಒಂದೇ ಮೆಸೇಜ್ ಐಡಿ ಅಥವಾ ಟೋಕನ್ ಎರಡು ಪ್ರತ್ಯೇಕ ಅನುಮೋದನಾ ವಿನಂತಿಗಳಲ್ಲಿ ಕಂಡುಬಂದರೆ, ಅದು ಸಂಘರ್ಷವಾಗುತ್ತದೆ ಮತ್ತು ಸಿಸ್ಟಮ್ ಅನ್ನು ನಿಲ್ಲಿಸಬೇಕು.

ನಿಜವಾದ ವೆಚ್ಚ

ಈ ಮಾದರಿಯು ಉಚಿತವಾಗಿ ಸಿಗುವುದಿಲ್ಲ. ನೀವು ಹೆಚ್ಚಿನ ಮೆಟಾಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೀರಿ. ಯಾರಾದರೂ ನಿರ್ವಹಿಸಬೇಕಾದ ಪಾಲಿಸಿ ಲೇಯರ್ ಅನ್ನು ನೀವು ಸೇರಿಸುತ್ತೀರಿ. ನಿಮ್ಮ ತಂಡವು ಅಡ್ಡಾದಿಡ್ಡಿ ಕಾಮೆಂಟ್‌ಗಳ ಬದಲಿಗೆ ಮಾನವ ನಿರ್ಧಾರಗಳನ್ನು ರಚನಾತ್ಮಕ ಡೇಟಾ (structured data) ಆಗಿ ದಾಖಲಿಸುವಂತೆ ನೀವು ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಇದು ಅಧಿಕಾರಶಾಹಿಯಂತೆ ಕಾಣಿಸಬಹುದು. ಆದರೆ ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಇದು ಅತ್ಯುತ್ತಮ ವಿನಿಮಯವಾಗಿದೆ.

ನೀವು ಸ್ಪಷ್ಟತೆಗಾಗಿ ವೇಗವನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುತ್ತಿದ್ದೀರಿ.