Quan sát LLM: 6 bài học từ CTO của Datadog

Bài học 1: AI đã phá vỡ cách rà soát mã cũ

Hãy bắt đầu với áp lực kéo theo mọi thứ khác: có nhiều mã hơn mức bất kỳ ai có thể đọc.

Lê-Quôc thẳng thắn rằng mô hình cũ—một người đọc pull request từng dòng—không còn trụ nổi trước phát triển có trợ lực AI. Mối lo ông nghe khắp ngành là việc rà soát trở nên bất khả thi vì có quá nhiều thứ diễn ra để theo kịp bằng cách đọc PR.

Phản ứng của ông không phải là bảo mọi người đọc nhanh hơn, mà là chuyển việc rà soát sang chỗ khác.

Vế cuối cùng đó rất dễ bỏ sót. Khi bạn điều phối một tác tử để lập kế hoạch, một tác tử để viết và một tác tử để kiểm thử, bạn cũng phải ngăn kẻ viết "lách" các bài kiểm thử tự động thay vì giải quyết vấn đề.

Ông còn đi xa hơn kiểm thử. Datadog giờ bổ sung các chứng minh bán hình thức và hình thức rằng một đặc tả làm đúng như yêu cầu—điều quá nặng nhọc để triển khai rộng rãi trước khi có tác tử gánh phần khó. Cách này hiệu quả nhất với hệ thống backend và điều phối, nơi hành vi đủ tính toán để suy luận chính xác.

Bài học 2: Sản xuất là bài kiểm tra duy nhất có ý nghĩa

Vượt qua mọi bài kiểm tra trong CI là điều kiện cần nhưng còn lâu mới đủ. Những lỗi quan trọng xảy ra về sau.

Mỗi lần phát hành đều dựa trên các giả định bạn không thể kiểm tra hết trước, về hình dạng dữ liệu và cách người dùng hành xử. Đưa các giả định đó ra trước đủ lượng truy cập thực, và các ca hiếm sẽ thôi hiếm; chúng trở thành những chậm trễ và lỗi thường ngày do trôi dạt dữ liệu và mô hình.

LLM làm điều này khó hơn: Với mã thông thường, bạn ít nhất có thể suy luận mọi nhánh, nhưng không ai có thể giải thích cơ chế vì sao một mô hình trả về điều nó trả về, nên cùng một đầu vào không bao giờ đảm bảo cùng đầu ra. Những kết quả lạ lùng đôi khi không thể triệt tiêu bằng kỹ thuật.

Vì vậy bạn ngừng cố chứng minh hệ thống đúng trước khi phát hành. Thay vào đó, bạn

• Viết đánh giá cho hành vi bạn mong muốn
• Giám sát trong sản xuất
• Giữ một cơ chế dừng khi đợt triển khai chuyển xấu.

Câu hỏi không còn là có vượt qua hay không, mà là vấn đề đó chỉ xảy ra một lần hay là khởi đầu của một xu hướng.

Tín hiệu trực tiếp đó không chỉ là một bảng điều khiển cho con người. Khi được nối vào hệ thống triển khai, nó cho phép một tác tử phát hành dần dần như một kỹ sư thận trọng: tới 1% người dùng, rồi 5%, và dựa vào dữ liệu thực để đánh giá thay đổi có đạt như mong muốn hay không.

Bài học 3: Để tác tử gánh phần việc mệt mỏi

Lê-Quôc lập luận về tác tử không phải để thay thế kỹ sư, mà để chúng đảm nhiệm những phần công việc bào mòn con người.

Khắc phục sự cố nghĩa là tung hàng loạt giả thuyết vào một triệu chứng, và trong các sự cố kéo dài, thường chính giả thuyết nghe xa vời lại đúng. Tác tử Bits AI của Datadog kiểm tra tất cả song song, đi trước kỹ sư, trong khi con người điều hướng nó theo trực giác mà dashboard sẽ không bao giờ gợi ý.

Điểm sâu xa là sự mệt mỏi. Trực on-call là trạng thái cảnh giác cao độ rồi hàng giờ không có gì, lặp đi lặp lại đến khi phán đoán của bạn mòn mỏi.

Một tác tử thì không bận tâm, và nó cũng không tệ đi sau bốn giờ dán mắt vào con số. Căng thẳng và mệt mỏi làm suy giảm hiệu suất con người, đó là lý do các đội phải xoay vòng người trực on-call ngay từ đầu.

Giao việc canh chừng không biết mệt cho máy, và con người trở lại với tinh thần tốt hơn cho những quyết định cần họ. Lý lẽ tương tự áp dụng cho phân loại bảo mật, nơi các nhà phân tích kiệt sức vì lọc dương tính giả khỏi mối đe doạ thực.

Bài học 4: Chia công việc thành hai vòng lặp

Lê-Quôc tổ chức công việc về tác tử của Datadog quanh hai vòng lặp.

Vòng lặp phát triển

Hầu hết kỹ sư sẽ nhận ra vòng đầu tiên:

1. Viết mã
2. Phát hành
3. Xem có hoạt động không
4. Sửa
5. Lặp lại

Góc nhìn của Datadog là vấn đề phát sinh từ mã thì thường có cách khắc phục cũng bằng mã, nên nền tảng cố gắng đưa cho bạn bản sửa đó, dựa trên những gì nó biết về ứng dụng: ai sở hữu, thay đổi gần đây, và lỗi đã phát sinh.

Ông lấy tối ưu hoá truy vấn cơ sở dữ liệu làm ví dụ. Bất kỳ mô hình nào cũng có thể viết lại một truy vấn chậm; phần khó hơn là chứng minh bản viết lại nhanh hơn và an toàn trước khi vào sản xuất, nên Datadog kiểm thử nó với bản sao dữ liệu sản xuất thực tế trước, rồi gửi kèm pull request với bằng chứng.

Vòng lặp vận hành và bảo mật

Vòng còn lại chạy song song, do cùng người hoặc đội khác thực hiện:

1. Phát hiện
2. Điều tra
3. Khắc phục
4. Lặp lại

Đây là nơi AI Guard của Datadog phân loại sự kiện bảo mật và chặn tấn công nhanh hơn một nhà phân tích xử lý thủ công. Tác tử cũng có thể xử lý các việc vận hành thường nhật mà kỹ sư làm mỗi ngày không mấy hứng thú, như đổi kích thước cái pod Kubernetes kia.

Ở cả hai vòng lặp, Lê-Quôc nhấn mạnh thứ tự ưu tiên. Datadog không bắt đầu từ "đây là AI, giải được vấn đề gì?" mà bắt đầu từ một vấn đề khách hàng đã phàn nàn—thường là biến thể của "tôi không muốn làm việc lặp đi lặp lại này"—rồi lần ngược xem một tác tử có thể được tin cậy giao việc đó hay không.

Bài học 5: Giữ chi tiêu AI trong tầm kiểm soát

Chi phí là ràng buộc ngồi cạnh an toàn, và việc giữ giá thành đưa mô hình ngôn ngữ lớn vào vận hành trong tầm kiểm soát đang trở thành một kỷ luật riêng. Câu trả lời của Lê-Quôc tại DASH là Agent Console của Datadog.

Hỏi một lập trình viên họ cần mô hình nào, và thường họ sẽ nêu mô hình mạnh nhất (và đắt nhất). Đôi khi đó là lựa chọn đúng, nhưng nhiều việc là khuôn mẫu mà một mô hình rẻ hơn, nhanh hơn xử lý tốt không kém. Phân biệt hai loại nghĩa là đọc các quỹ đạo của tác tử trong tổ chức, công cụ chúng gọi, và tỉ lệ thành công—cho đến khi mẫu hình hiện ra.

Những mẫu hình đó trở thành kinh nghiệm thay vì quy tắc: mô hình tuyến đầu như Claude Opus hay các mô hình GPT mới nhất cho lập kế hoạch; loại rẻ như Claude Haiku để sinh kiểm thử.

Nguyên tắc bên dưới là về quyền sở hữu quyết định. Cuộn chi phí thành một con số duy nhất, bạn sẽ nhận thứ Lê-Quôc gọi là "tính khả thi rất thấp": hoặc ai cũng ngừng chi, giết chết công việc hữu ích, hoặc ai cũng tiếp tục chi, điều doanh nghiệp không chịu nổi. Ông muốn đặt dữ liệu trước mặt các lập trình viên và SRE—những người chọn mô hình.

Bài học 6: Học cách học

Khi được hỏi các kỹ sư mới nên học gì, Lê-Quôc đưa ra câu trả lời nghe cũ mà không cũ.

Các mô hình là gia sư kiên nhẫn nhất từng có, có thể giải thích bất cứ điều gì với bất kỳ nhịp độ nào—mức độ tiếp cận từng dành cho giới quý tộc có thầy riêng. Nhưng gia sư chỉ hữu dụng nếu bạn chất vấn họ. Kỹ năng là biết hỏi gì và kiểm tra câu trả lời ra sao.

Ông khuyến nghị hiểu máy tính theo từng lớp thay vì coi chúng là phép màu. Lấy một bộ lập lịch, bộ cân bằng tải, sandbox và yêu cầu một mô hình giải thích cách nó hoạt động, rồi tiếp tục đào sâu:

• Thuật ngữ này nghĩa là gì?
• Đo lường nó như thế nào?
• Toán học đằng sau là gì?
• Làm sao biết nó hoạt động tốt?

Học các kinh điển theo cách này là cố ý chậm. Ông ví như học nhạc cụ; bạn có thể nghe nhạc cả ngày, nhưng để chơi piano, bạn phải đặt tay lên phím.

Điều tương tự áp dụng cho mã do AI viết. Vibe coding là ổn, ông nói, miễn là bạn quay lại và hỏi vì sao nó hoạt động: vì sao thiết kế như vậy, còn cách nào tốt hơn, nó được mô phỏng theo đâu. Mục tiêu không phải là viết ít mã hơn với AI. Mà là hiểu lượng mã bạn nay tạo ra nhiều hơn rất nhiều.

Lời kết

Thông điệp trung tâm của Lê-Quôc là vòng lặp không đổi, nhưng nhịp độ đã đổi. Điều khác biệt là không con người nào có thể quan sát đủ sát với tốc độ AI vận hành hiện nay, nên việc quan sát—và một phần ngày càng lớn của việc xây dựng—được chuyển cho các tác tử không biết mệt và không hoảng loạn.

Ông đề xuất coi quan sát như một mặt phẳng điều khiển thay vì một tập biểu đồ. Nếu tác tử sẽ viết, kiểm thử, phát hành và vận hành phần mềm, chúng cần cùng nền tảng dữ liệu sản xuất thực mà các kỹ sư giỏi dựa vào, cộng với một con người nắm các quyết định phán đoán và nút dừng. Datadog đang định vị quan sát là lớp giúp trao đổi đó an toàn.

Kỹ năng mà cách tiếp cận này đòi hỏi ở kỹ sư là rõ ràng: đọc hệ thống qua cách chúng hành xử trong sản xuất, không chỉ qua mã nguồn. Nếu bạn muốn xây thói quen đó, lộ trình kỹ năng Machine Learning in Production của chúng tôi là nơi tốt để bắt đầu.