Mỗi lần một frontier model mới ra mắt, bên cạnh những biểu đồ đi lên, tôi lại thấy những lời tiếc nuối model cũ.
Model cũ viết có hồn hơn. Model cũ hiểu ý hơn. Model cũ code ít phải sửa hơn. Đôi khi model đang được tiếc nuối chính là model từng bị chê ở lần ra mắt trước.
Đọc một lúc thì có cảm giác model tốt nhất luôn là model vừa bị thay thế.
Nhưng tôi nghĩ những lời phàn nàn ấy có điều đáng nghe. Một người dùng có thể đang mất đi thứ thực sự hữu ích với họ, dù bảng điểm của model mới đẹp hơn. Có người cần khả năng suy luận. Có người cần giọng văn. Có người chỉ muốn giao một việc quen thuộc và nhận lại kết quả đúng như trước, khỏi mất thêm một buổi học cách nói chuyện.
Một con số tổng hợp khó kể hết những chuyện đó.
Một câu trả lời chưa phải một công việc hoàn thành
Tôi làm việc với các tác nhân AI hằng ngày. Vì thế, điều tôi quan tâm khi một model mới xuất hiện khá thực dụng: nó sẽ làm công việc của tôi thay đổi như thế nào?
Tôi có phải giải thích ít hơn không? Có phải sửa ít hơn không? Khi làm sai, nó có tiếp nhận được bằng chứng mới và sửa đúng chỗ không? Sau vài vòng làm việc, chúng tôi có đến được một kết quả dùng được không?
Câu trả lời đầu tiên chỉ là một phần của câu chuyện.
Một công việc kỹ thuật thường bắt đầu khi vấn đề còn chưa rõ. Yêu cầu thiếu một đoạn. Code có một quyết định cũ mà chẳng ai nhớ lý do. Tài liệu mô tả điều từng đúng. Một bản sửa vượt qua kiểm tra trước mắt nhưng có thể làm hỏng thứ nằm ngoài phạm vi vừa xem.
AI bước vào đúng cái môi trường ấy.
Tôi gọi quá trình làm việc này là engineering loop: hiểu vấn đề, thực hiện một thay đổi, kiểm tra kết quả, nhận phản hồi, điều chỉnh, rồi tiếp tục. Có khi vòng tiếp theo cần thêm code. Có khi nó chỉ cần một câu hỏi đúng.
Giá trị của model phải được nhìn trong cả vòng lặp đó.
Chẳng hạn, hãy hình dung một agent sửa lỗi rất nhanh nhưng chọn sai nguyên nhân. Một agent khác dành thêm thời gian đọc đường đi của dữ liệu, rồi thực hiện một thay đổi nhỏ hơn. Nếu chỉ nhìn tốc độ xuất hiện của bản diff đầu tiên, agent thứ nhất khá ấn tượng. Nếu tính cả thời gian tìm ra vì sao bản sửa chưa giải quyết được vấn đề, kết quả có thể khác.
Phần việc của người kỹ sư vì thế vẫn nằm ở những quyết định rất cụ thể: đang giải quyết đúng vấn đề chưa, bằng chứng nào đủ đáng tin, kiểm tra đến đâu thì hợp lý, và khi nào có thể coi công việc đã hoàn thành.
Nút “Accept” bấm rất nhẹ. Trách nhiệm đi kèm thì tùy hôm.
Giữ context cũng là một công việc kỹ thuật
Làm việc qua nhiều vòng như vậy cũng khiến tôi quan tâm đến context hơn.
Một agent có thể xử lý yêu cầu hiện tại khá tốt mà vẫn đi sai hướng vì thiếu một quyết định từ phiên trước. Hoặc nó tìm thấy quyết định đó, nhưng quyết định đã hết hiệu lực. Hoặc có ba tài liệu cùng nói về một việc, mỗi tài liệu đúng vào một thời điểm khác nhau.
Lúc ấy, thêm một đoạn “hãy suy nghĩ thật kỹ” có lẽ chưa giải quyết được nhiều.
Cách tôi chọn là giữ global instructions đơn giản nhất có thể và dùng ít skills nhất có thể. Với phần workflow cá nhân tự xây, tôi chủ yếu dùng context-docs .
Global instructions giữ những điều tương đối ổn định về cách cộng tác. Context của dự án giữ mục tiêu, quyết định, trạng thái và những việc còn dang dở. Skill cung cấp phương pháp cho một loại công việc cần lặp lại.
Tách được ba thứ đó giúp tôi biết một thông tin nên nằm ở đâu.
Một quyết định kiến trúc của dự án không cần đi theo mọi cuộc trò chuyện. Một sở thích giao tiếp không cần được chép lại vào từng tài liệu dự án. Một quy trình chỉ dùng khi xuất bản cũng không cần xuất hiện trong mọi lần sửa lỗi.
Tôi muốn agent tìm được điều cần biết vào đúng lúc. Và khi tìm thấy, nó có cơ sở để biết điều ấy vẫn còn đúng.
Đó là lý do tôi dành sự chú ý cho việc giữ context qua các phiên làm việc. Lưu một cuộc hội thoại dài khá dễ. Giữ lại được quyết định quan trọng, lý do của nó và trạng thái hiện tại mới cần phương pháp.
Skills có thể giúp làm việc này. Một skill tốt có thể đóng gói quy trình, tài liệu tham chiếu, script và cách kiểm tra kết quả để dùng lại. Nhưng mỗi skill cũng là một thứ cần viết cho đúng, kích hoạt đúng lúc và bảo trì khi thực tế thay đổi. Tài liệu OpenAI cũng mô tả skills theo vai trò đóng gói những workflow có thể lặp lại như vậy.
Vì thế, tôi không coi số lượng skills là thước đo độ hoàn thiện của một setup.
Tôi sẽ thêm khi gặp một nhu cầu lặp lại đủ rõ. Nếu một hướng dẫn chỉ ghi lại cách chữa cho một lần agent làm sai, tôi muốn xem nó có thực sự cần trở thành luật lâu dài hay không.
Agent cũng có thể được giao một cuốn nội quy dài đến mức đọc xong thì quên mất hôm nay đến để làm gì.
Điểm cao cho chúng ta biết điều gì?
Đến đây, chuyện context lại nối với câu hỏi ban đầu: khi so sánh hai model, thực ra chúng ta đang so sánh cái gì?
Cùng một model, nhưng context khác, công cụ khác và cách kiểm tra khác, trải nghiệm làm việc có thể khác. Khi đổi model, những hướng dẫn từng hữu ích cũng cần được xem lại. Điều này không có nghĩa mọi phàn nàn đều là lỗi người dùng. Model mới hoàn toàn có thể kém hơn ở một việc cụ thể.
Nó chỉ khiến câu “model này thông minh hơn” cần thêm một đoạn phía sau: trong việc gì, với điều kiện nào, và được đánh giá ra sao?
Đó cũng là chỗ tôi thấy benchmark vừa hữu ích, vừa dễ bị kỳ vọng quá mức.
Benchmark cho chúng ta một phép đo trong những điều kiện xác định. Nó giúp so sánh, phát hiện thay đổi và đặt câu hỏi về một năng lực cụ thể. Vấn đề xuất hiện khi kết luận đi xa hơn thứ đã được đo.
Làm tốt một bộ câu hỏi chưa đủ để bảo đảm agent sẽ làm tốt một công việc kéo dài, có yêu cầu mơ hồ và những quyết định thay đổi giữa chừng.
Nhưng bỏ benchmark để chỉ dựa vào cảm giác cũng không làm việc đánh giá đáng tin hơn. Tôi có thể nhớ rất rõ một lần model làm điều khiến mình bất ngờ, rồi quên hàng chục lần phải nhắc lại cùng một yêu cầu.
Còn chuyện model được luyện để đạt điểm cao thì sao?
Tôi nghĩ cần phân biệt giữa học được năng lực giúp giải bài mới, quen với một dạng đề, và đã tiếp xúc với chính nội dung dùng để đánh giá. Cả ba đều có thể tạo ra điểm số đẹp, nhưng ý nghĩa của điểm số khác nhau.
Điểm cao tự nó chưa cho biết điều gì đã xảy ra.
Phép so sánh với “lò luyện thi” khá dễ hiểu ở đây. Tuy vậy, tôi không muốn đi đến kết luận rằng người kiệt xuất phải là người đứng ngoài hệ thống luyện thi. Vài tiểu sử nổi tiếng không đủ giải quyết câu hỏi ấy.
Điều tôi muốn hỏi đơn giản hơn: sau khi đổi đề, bỏ gợi ý quen thuộc hoặc đưa người làm bài vào một tình huống mới, năng lực đó còn thể hiện được bao nhiêu?
Với model cũng vậy.
Trong thử nghiệm nhỏ về quyết định xử lý sự cố website mà tôi thực hiện với sự hỗ trợ của AI, cả ba model đều đạt điểm tuyệt đối ở bộ pilot. Bước tiếp theo là tạo các cặp tình huống chỉ thay đổi một dữ kiện, để xem quyết định có thay đổi theo bằng chứng hay không.
Thử nghiệm đó vẫn có giới hạn: tình huống giả lập, phạm vi nhỏ, đáp án chưa được chuyên gia độc lập thẩm định. Nó cho thấy một hướng kiểm tra cụ thể, chưa đủ để xếp hạng trí thông minh của các model.
Điều tôi thấy hữu ích là quá trình đặt câu hỏi tiếp theo sau một bảng điểm đẹp.
Trong công việc hằng ngày, tôi cũng muốn đánh giá theo cách ấy. Ngoài việc kết quả có đúng hay không, tôi quan tâm mình đã phải can thiệp bao nhiêu, bỏ ra bao nhiêu thời gian kiểm tra, và còn lỗi nào lọt qua. Việc chọn bài đánh giá sát với công việc thực tế cũng là một nguyên tắc trong hướng dẫn eval của OpenAI .
Nếu ghi lại được những điều đó, tôi có cơ sở tốt hơn để chọn model và điều chỉnh cách làm việc. Có thể model mới hợp hơn. Có thể model cũ vẫn phù hợp với một số việc. Có thể thứ cần sửa trước tiên là đống context mà tôi đang đưa cho cả hai.
Khi kết quả mang trách nhiệm của mình
Lần tới có model mới, tôi vẫn sẽ xem benchmark. Tôi cũng sẽ đọc những lời phàn nàn. Một bước tiến thực sự đáng được ghi nhận, và một bước lùi trong công việc cụ thể cũng đáng được nói rõ.
Rồi tôi sẽ đưa nó vào công việc của mình.
Ở đó, tôi cần biết nhiều hơn việc nó trả lời hay đến đâu. Khi thiếu dữ kiện, nó làm gì? Khi gặp bằng chứng trái với kết luận ban đầu, nó có sửa hướng không? Và khi nó sai, cách làm việc của tôi có giúp phát hiện được không?
Câu hỏi cuối cùng khiến tôi phải nhìn lại cả phần việc của mình. Tôi đã cung cấp đúng context chưa? Tiêu chí hoàn thành có rõ không? Tôi đang kiểm tra kết quả, hay chỉ đọc một lời giải thích đủ trôi chảy để thấy yên tâm?
Tôi muốn setup của mình đủ gọn để hiểu và đủ rõ để kiểm tra. Mỗi instruction, mỗi skill, mỗi tài liệu context cần giúp công việc tiến lên hoặc giúp một sai sót dễ bị phát hiện hơn. Những thứ còn lại đều có chi phí bảo trì.
Một model đứng đầu bảng vẫn có thể tạo ra một bản sửa sai. Một bản sửa sai được chấp nhận vẫn có thể đi vào production. Đến lúc ấy, thứ hạng của model không làm hậu quả nhẹ đi.
Khi một bản sửa gây lỗi trên production, tôi vẫn phải giải thích vì sao nó được đưa vào sử dụng, đã được kiểm tra thế nào và sẽ khắc phục ra sao. Việc code do AI viết không giúp tôi bỏ qua những câu hỏi ấy.
Ngay cả khi AI làm toàn bộ công việc, trách nhiệm vẫn thuộc về con người.
No comments yet