Bỏ qua đến nội dung chính

The capability curve

TL;DR

  • Các phiên bản Claude gần đây, đặc biệt là Opus 4.7, đã tăng cường đáng kể năng suất của nhà phát triển, giúp họ hoàn thành công việc nhanh hơn gấp nhiều lần và xây dựng những dự án trước đây không thể trong khung thời gian ngắn.
  • Những cải tiến chính của mô hình bao gồm khả năng lập kế hoạch kỹ lưỡng hơn, khả năng phục hồi lỗi được nâng cao để tránh "vòng lặp vô tận", và khả năng duy trì sự chú ý nhất quán trong các tác vụ dài.
  • Để tối đa hóa lợi ích từ Claude, nhà phát triển nên tập trung vào các đánh giá (evals) phù hợp và liên tục được làm mới, đơn giản hóa cấu trúc khung sườn và lời nhắc, đồng thời cung cấp không gian và công cụ cho mô hình để làm việc tự chủ và có kiểm soát.

Điểm chính

  • Thiết lập Đánh giá (Evals) hiệu quả: Sử dụng các đánh giá đo lường gần với phân phối sản phẩm thực tế, đảm bảo chúng không bị bão hòa (tăng độ khó theo sự phát triển của mô hình), và thường xuyên kiểm thử với các mô hình tiên tiến nhất khi chúng ra mắt.
  • Đơn giản hóa Khung sườn (Scaffolding): Rà soát lại và loại bỏ các yếu tố không còn cần thiết từ mã nguồn, lời nhắc, kỹ năng và thiết lập công cụ bao quanh mô hình. Các mô hình mới hơn thường cho phép hiệu suất tốt hơn khi đơn giản hóa quy trình làm việc.
  • Tinh gọn Lời nhắc (Prompts): Định kỳ xem xét và cắt giảm những quy tắc hoặc hướng dẫn đã tích lũy trong lời nhắc qua nhiều thế hệ mô hình để cải thiện hiệu suất tác vụ và tiết kiệm token.
  • Cung cấp Không gian và Thời gian cho Mô hình Suy nghĩ: Cho phép Claude có thời gian lập kế hoạch và suy nghĩ trước khi hành động. Sử dụng "tư duy thích ứng" và tham số nỗ lực để điều chỉnh lượng token mà Claude dành cho việc suy nghĩ và hành động.
  • Cho phép Truy cập Công cụ có Kiểm soát: Mở rộng quyền truy cập của tác nhân AI vào nhiều công cụ hơn một cách an toàn, ví dụ thông qua các bộ phân loại để yêu cầu chấp thuận rõ ràng của con người cho các lời gọi công cụ nhạy cảm (như Claude Code Auto Mode).
  • Đóng Vòng lặp cho Tác nhân: Thiết kế hệ thống sao cho Claude có thể tự kiểm tra đầu ra của chính nó và lặp lại để cải thiện. Cung cấp các tiện ích (như công cụ tương tác trên trang web cho tác nhân front-end) để mô hình có thể xác minh và tinh chỉnh công việc.

Từ vựng

  • PM nghiên cứu — Research PM
  • lập trình tác nhân — agentic programming
  • yêu cầu kéo — pull request
  • điểm chuẩn — benchmark
  • mô hình — model
  • khả năng lập kế hoạch — planning capabilities
  • khả năng phục hồi lỗi — error resilience
  • sự chú ý trong các lần chạy dài — attention in long runs
  • đánh giá (Evals) — evaluations (Evals)
  • khung sườn (Scaffolding) — scaffolding
  • tư duy thích ứng — adaptive thinking
  • tham số nỗ lực — effort parameter
  • lời gọi công cụ — tool calls
  • đóng vòng lặp — close the loop

Nội dung chi tiết

Lời giới thiệu từ Alex Albert

Xin chào mừng đến sân khấu, Alex Albert, thành viên đội ngũ kỹ thuật của Anthropic. Albert: Xin chào, xin chào mọi người. Được rồi, để tôi đặt chai nước xuống đây. Tôi là Alex Albert, một trong những PM nghiên cứu của chúng tôi tại Anthropic. Ừm, tôi vừa nghe quản lý sân khấu, Alom, nói rằng một buổi happy hour vừa bắt đầu. Vì vậy, tôi muốn cảm ơn tất cả các bạn đã chọn tôi thay vì đồ uống và đồ ăn nhẹ. Tôi thực sự rất trân trọng điều đó. Và tôi hứa buổi nói chuyện này sẽ xứng đáng với 15-20 phút của các bạn.

Thật thú vị khi so sánh không khí tại hội nghị năm nay với hội nghị năm ngoái. Năm ngoái, Claude Code thậm chí còn chưa được phát hành rộng rãi (GA). Nó mới ra mắt khoảng hai hoặc ba tháng. Mọi người mới bắt đầu làm quen với mô hình lập trình tác nhân. Ngày nay, khi tôi trò chuyện với mọi người ở đây, có vẻ như mọi người đang làm được nhiều việc hơn. Họ tin tưởng Claude. Họ triển khai mọi thứ nhanh hơn với Claude. Họ đang xây dựng những thứ mà trước đây họ chưa từng xây dựng, những thứ không thể xây dựng được trong khung thời gian như hiện tại.

Tác động của Claude đối với năng suất nhà phát triển

Thực tế, vì tò mò, tôi muốn thực hiện một bài tập nhỏ ở đây. Vì vậy, tôi sẽ hỏi, nếu câu hỏi là dành cho bạn, vui lòng giơ tay lên và giữ nguyên. Tôi muốn nắm bắt được không khí của căn phòng. Ừm, hãy giơ tay nếu bạn cảm thấy Claude đã giúp bạn làm việc nhanh hơn gấp 10 lần so với một năm trước. Được rồi, wow, khá nhiều người! Cứ giữ tay lên nhé. Ừm, còn ai nhanh hơn gấp 5 lần? Được rồi, nhanh hơn gấp 2 lần? Giơ tay nếu bạn sử dụng Claude. Tuyệt vời. Được rồi, rất thích điều đó.

Một trong những cách tốt nhất mà chúng tôi đo lường khả năng lập trình của Claude và cách chúng tôi thấy Claude tạo ra tác động này đến mọi người là thông qua điểm chuẩn có tên Bench Verified. Bench Verified đo lường khả năng của mô hình trong việc hoàn thành các yêu cầu kéo phần mềm một cách tự chủ. Khoảng một năm trước, trên mô hình của chúng tôi vào thời điểm đó, Sonnet 3.7, nó đạt 62% trong đánh giá này. Ngày nay, với Opus 4.7, nó đạt 87%. Đó là một bước nhảy vọt hơn 25% chỉ trong hơn một năm. Nói cách khác, Opus 4.7 có khả năng thành công gấp hơn ba lần đối với một số yêu cầu kéo khó mà Sonnet 3.7 đã thất bại một năm trước.

Ví dụ thực tế: So sánh Sonnet 4 và Opus 4.7

Các con số rất tuyệt, nhưng các ví dụ còn tốt hơn. Vì vậy, để làm rõ hơn, tôi có một bản demo nhanh ở đây mà chúng tôi đã xây dựng cho cùng một tác vụ, nhưng cách nhau 12 tháng. Vậy, hãy bắt đầu. Trong ví dụ này, chúng ta sẽ so sánh Sonnet 4 với Opus 4.7, và chúng ta sẽ giao cho chúng cùng một tác vụ. Ồ, hãy... Hãy quay lại đây và làm cho bản demo này hoạt động. Đợi một lát. Xem nó có đang bật phát cho những người đang xem không. Ồ, nó hoạt động rồi! Đúng vậy. Không, vẫn chưa có gì. Được rồi. Ừm, có một bản demo ở đây và nó thực sự rất hay. Vậy nên các bạn sẽ phải tin tôi về điều đó. Ồ, đây rồi!

Được rồi, Sonnet 4 hoạt động trong Claude Code. Tác vụ chúng tôi giao cho nó là tái tạo claw.ai chỉ với một lời nhắc duy nhất. Các bạn có thể thấy nó hoạt động như thế nào ở đây. Chúng ta có một ứng dụng chat đen trắng rất chung chung. Chúng ta có thể nhập một lời nhắc. Chúng ta sẽ gửi nó đi và ngay lập tức chúng ta gặp lỗi. Vì vậy, nó thực sự không hoạt động. Về cơ bản, nó chỉ tạo ra một giao diện người dùng đồ họa (GUI) cho chúng ta.

Bây giờ, hãy chạy cùng tác vụ này nhưng với Opus 4.7 thay thế và xem nó hoạt động ra sao. Chúng ta sẽ có cùng một thiết lập. Nó sẽ chạy trong Claude Code. Nó sẽ viết rất nhiều dòng mã, gọi công cụ rất nhiều công cụ, và cuối cùng chúng ta sẽ nhận được một đầu ra. Và ngay lập tức, đầu ra này trông tốt hơn. Vậy nên chúng ta có bảng màu Claude. Nó đã biết điều đó rồi. Chúng ta thực sự nhận được phản hồi từ API của Claude khi gửi tin nhắn. Chúng ta có thể bắt đầu một cuộc trò chuyện mới và nó vẫn nhớ cuộc trò chuyện cũ. Vì vậy, chúng ta đang theo dõi mọi thứ. Thậm chí nó còn kết xuất trực tiếp trực quan hóa như ứng dụng claw.ai vẫn làm. Và giống như một nhà phát triển thực thụ, nó thậm chí còn triển khai chế độ tối (dark mode). Vì vậy, ngoài việc là một đầu ra tốt hơn, nó còn thực hiện điều đó với ít dòng mã hơn. Vì vậy, nó cũng hiệu quả hơn.

Xây dựng trên nền tảng mô hình AI cải tiến liên tục

Bài nói chuyện này không tập trung cụ thể vào bất kỳ mô hình nào. Điều tôi muốn nhấn mạnh là ý nghĩa của việc xây dựng trên một nền tảng đang ngày càng cải thiện đáng kể, tháng này qua tháng khác.

Những cải tiến chính của Claude

Trước khi đi sâu vào các mẹo cụ thể, tôi muốn xem xét những cải tiến này của mô hình đang được thể hiện ở đâu.

Khả năng lập kế hoạch

Đầu tiên là về khả năng lập kế hoạch của Claude. Các mô hình cũ hơn thường mắc phải một chế độ thất bại đặc biệt tệ, đó là chúng sẽ hành động trước rồi mới suy nghĩ sau. Nó giống như tôi khi phải xây dựng một bộ đồ nội thất IKEA mới vậy: tôi lao thẳng vào làm, và chỉ khi mọi thứ trở thành một mớ hỗn độn, tôi mới quay lại và nghĩ: "À, có lẽ mình nên đọc hướng dẫn thì hơn." Ừm, tôi không biết có ai khác cũng vậy không, nhưng Sonnet 3.7 về cơ bản là như vậy. Các mô hình mới hơn thì kỹ lưỡng hơn rất nhiều. Chúng dành thời gian ngay từ đầu để thực sự suy nghĩ về vấn đề, chiến lược hóa một chút, lập kế hoạch cho những gì chúng sẽ làm, rồi mới bắt tay vào hành động và viết những dòng mã đó. Điều này có ý nghĩa gì đối với bạn với tư cách là một nhà phát triển? Đó là bạn nên cho phép Claude có thời gian suy nghĩ. Ừm, hãy dành cho nó một chút thời gian để thực sự suy nghĩ về vấn đề và những gì nó sẽ làm. Đừng ép buộc nó nhảy thẳng vào hành động vì điều này có thể làm giảm hiệu suất đầu ra của bạn.

Khả năng phục hồi lỗi

Lĩnh vực lớn thứ hai mà chúng ta đang thấy những cải tiến là ở khả năng phục hồi lỗi của Claude. Các mô hình trước đây thường gặp phải điều mà chúng tôi gọi là vòng lặp vô tận (doom loop). Mô hình sẽ gặp một vấn đề, cố gắng đề xuất một giải pháp, nhưng giải pháp đó không hiệu quả. Và rồi đột nhiên, nó thực sự bị mắc kẹt. Nó sẽ cứ xoắn ốcxoắn ốc cho đến khi ngữ cảnh đó bị đình trệ, và bạn phải xóa bỏ mọi thứ. Các mô hình mới hơn thì linh hoạt hơn nhiều. Nếu chúng gặp vấn đề, giờ đây chúng có thể quay lại và thực sự suy nghĩ về nó theo một cách khác, và có thể đi theo một con đường khác. Điều này có nghĩa là bạn sẽ nhận được hiệu suất tác vụ tốt hơn từ Claude với ít token bị lãng phí hơn vì nó sẽ không bị mắc kẹt trong những vòng lặp đó.

Sự chú ý trong các lần chạy dài

Lĩnh vực cuối cùng mà chúng ta đang thấy những cải tiến này là ở sự chú ý của Claude trong các lần chạy dài. Các mô hình cũ hơn thường mất đi chủ đề chính khi chúng đang thực hiện một việc gì đó. Có thể chúng bắt đầu quên mọi thứ. Chúng không chú ý nhiều. Những hướng dẫn mà bạn đặt trong lời nhắc hệ thống không được chú ý nhiều trong luồng đó. Các mô hình mới hơn có khả năng duy trì sự nhất quán tốt hơn nhiều trong các lần chạy. Chúng có thể ghi nhớ những hướng dẫn lời nhắc hệ thống đó và duy trì sự tập trung trong suốt hàng trăm nghìn hoặc thậm chí một triệu token. Về mặt ứng dụng của bạn và cách bạn sử dụng Claude, điều này có nghĩa là bạn không cần phải can thiệp vào cửa sổ ngữ cảnh quá nhiều. Bạn không cần phải chia nhỏ công việc, và bạn có thể tin tưởng rằng Claude có thể hoạt động cho bạn trong các lần chạy dài một cách tự chủ.

Tổng hợp tất cả những điều này lại, chúng ta có khả năng lập kế hoạch tốt hơn, ít thất bạikhả năng phục hồi lỗi hơn, và các tác nhân chạy lâu hơn. Và điều này kết hợp lại thành hiệu suất tác vụ từ đầu đến cuối tốt hơn. Khách hàng của chúng tôi cũng đang thấy điều này. Verscell nhận thấy trong khả năng lập kế hoạch của Opus 4.7, nó thực sự viết các bằng chứng cho mã hệ thống trước khi triển khai bất kỳ dòng mã nào. Winser nhận thấy trong các đánh giá của họ rằng Claude thực sự duy trì sự chú ý trong suốt các lần chạy tác nhân dài nhất của họ. Và Shopify phát hiện ra rằng khi mô hình đang lập trình, nó thực sự đã quay lại và tinh chỉnh liên tục đầu ra của nó. Vậy làm thế nào bạn, với tư cách là một nhà phát triển, có thể thấy những điều tương tự mà khách hàng của chúng tôi đang thấy trong ứng dụng của mình?

Lời khuyên cho nhà phát triển

1. Tập trung vào đánh giá (Evals) phù hợp và không bị bão hòa

Điều này nghe có vẻ ngược đời, nhưng nó không bắt đầu từ ứng dụng của bạn mà từ đánh giá của bạn. Nếu bạn có thể đo lường được điều gì đó, bạn có thể cải thiện nó. Vì vậy, điều quan trọng là: a) bạn phải có các đánh giá, và b) các đánh giá này phải đo lường một thứ gì đó gần với phân phối sản phẩm mà bạn thực sự muốn cải thiện. Điều này có vẻ hiển nhiên, nhưng thường là điều tôi thấy khiến các nhà phát triển đi lạc hướng khi họ cố gắng đánh giá sản phẩm của mình dựa trên một thứ gì đó tiếp giáp với trường hợp sử dụng của họ, nhưng không phải trên phân phối tác vụ thực tế. Ví dụ, có thể họ có một tác nhân lập trình và thay vì đánh giá tác nhân lập trình đó trên lưu lượng truy cập thực tế hoặc lưu lượng truy cập có mô hình tương tự với những gì người dùng của họ đang làm, họ lại đánh giá nó trên một điểm chuẩn lập trình học thuật.

Điều thứ hai bạn muốn làm, một khi bạn có những đánh giá đó, là đảm bảo rằng chúng không bị bão hòa. Khi các mô hình ngày càng thông minh hơn, các đánh giá liên tục cần phải ngày càng khó hơn để có được nhiều tín hiệu hơn từ các mô hình tiên tiến. Bạn muốn đảm bảo rằng các đánh giá mà bạn đang xây dựng phát triển song song với mô hình để bạn có thể tiếp tục nhận được tín hiệu mới khi các mô hình thông minh hơn ra mắt.

Cuối cùng, một khi bạn có những đánh giá đó và đã đảm bảo chúng không bị bão hòa, hãy kiểm thử chúng trên các mô hình tiên tiến mới nhất. Tôi nhận thấy rằng đôi khi, tối ưu hóa tốt nhất bạn có thể thực hiện cho ứng dụng của mình chỉ đơn giản là thay thế mô hình mới nhất. Vì vậy, việc dành một lượng thời gian đáng kể để kiểm thử và thử nghiệm các mô hình khi chúng ra mắt là rất đáng giá.

2. Xem xét lại khung sườn (Scaffolding) và lời nhắc (Prompts)

Mẹo thứ hai dành cho bạn ở đây là hãy xem xét lại khung sườn của mình. Khi tôi nói khung sườn, điều tôi muốn nói đến là mã nguồn, các lời nhắc, các kỹ năngthiết lập công cụ – tất cả những thứ bao quanh mô hình và định hướng nó đạt được mục tiêu. Với các mô hình mới hơn, bạn có thể không cần một số thứ mà trước đây bạn cần. Vì vậy, có lẽ thay vì một quy trình làm việc đa bước, bạn có thể chỉ cần để mô hình thực hiện một tác vụ trong một luồng duy nhất. Thông thường, bạn thực sự có thể tăng hiệu suất bằng cách loại bỏ thay vì thêm các yếu tố vào khung sườn của mình.

Bên cạnh khung sườn, bạn cũng nên xem xét lại các lời nhắc của mình. Các lời nhắc bắt đầu tích tụ qua từng mô hình. Và sau một thời gian dài với nhiều thế hệ mô hình khác nhau, nó trở thành một mớ hỗn độn khủng khiếp gồm các quy tắchướng dẫn khác nhau, và bạn không thực sự chắc tại sao mình đã thêm một thứ gì đó và nó đang làm gì cho mô hình tương lai của bạn. Với mỗi mô hình mới, hãy xem xét lại những lời nhắc đó, cắt giảm những thứ có thể không cần thiết nữa. Và điều này sẽ giúp cả hiệu suất tác vụ của bạn mà còn tiết kiệm token cho bạn nữa.

3. Cung cấp không gian làm việc cho mô hình

Mẹo cuối cùng ở đây là hãy cho mô hình không gian để làm việc. Như tôi đã đề cập trước đó khi nói về khả năng lập kế hoạch, điều quan trọng là để Claude tự chọn thời điểm để suy nghĩ. Hãy sử dụng tư duy thích ứng (adaptive thinking) và điều chỉnh lượng tokenClaude suy nghĩ cũng như số lượng hành động mà nó thực hiện với tham số nỗ lực (effort parameter).

Điều thứ hai ở đây là cho phép các tác nhân của bạn truy cập nhiều công cụ hơn một cách có kiểm soát. Bây giờ, một số bạn nghe điều đó có thể hơi lo lắng. Tôi không nói là cứ để nó làm bất cứ điều gì, nhưng có những cáchphương pháp bạn có thể thực hiện để cho phép Claude thực sự thực thi trên nhiều hệ thống hơn một cách an toàn. Một ví dụ về điều này là Claude Code Auto Mode. Trong một trong những bài đăng blog kỹ thuật gần đây của chúng tôi, chúng tôi đã nói về Auto Mode. Auto Mode thực sự chạy các bộ phân loại (classifiers) trên các lời gọi công cụ mà nó đang đề xuất, và chúng tôi có thể xác định xem lời gọi công cụ đó có cần sự chấp thuận rõ ràng của con người hay không. Điều này cho phép chúng tôi để Claude chạy trong nền lâu hơn và nó có thể hoạt động tự chủ hơn mà không cần con người can thiệp.

Mẹo cuối cùng ở đây là đảm bảo rằng bạn đang đóng vòng lặp cho tác nhân của mình. Thiết kế hệ thống của bạn sao cho Claude thực sự có thể kiểm tra đầu ra của chính nó và lặp lại chúng. Quay trở lại ví dụ về tác nhân lập trình đó, nếu bạn có một tác nhân đang làm việc trên các ứng dụng giao diện người dùng (front-end applications), có lẽ bạn muốn cung cấp cho nó một công cụ sử dụng để nó có thể nhấp xung quanh trên trang webkiểm thử Q&A các lỗi hoặc tính năng khác nhau mà nó viết. Các mô hình liên tục trở nên tốt hơn trong việc xác minhlặp lại đầu ra của chúng. Vì vậy, điều quan trọng là cho phép nó các tiện ích (affordances) để làm như vậy.

Và với điều đó, đây là một cái nhìn nhanh về đường cong khả năng. Tôi muốn cảm ơn tất cả mọi người đã đến hôm nay. Tôi biết đây là buổi nói chuyện cuối cùng trong ngày. Tôi sẽ ở lại khu vực tiếp tân, vì vậy hãy đến tìm tôi. Tôi rất muốn trò chuyện về cách chúng ta có thể tạo ra Cl[transcript bị gián đoạn]

Lời Kết

Claude tốt hơn cho bạn. Cảm ơn bạn.

Góp ý / Báo lỗiPhát hiện sai sót hoặc có ý tưởng cải thiện?