Senior SWE-Bench: benchmark mã nguồn mở để đánh giá agent ở cấp kỹ sư senior

 (senior-swe-bench.snorkel.ai)
4 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Senior SWE-Bench là một benchmark nhằm đánh giá coding agent không bằng các bài junior được dọn dẹp quá mức, mà bằng các tác vụ gần với phát triển tính năng, sửa lỗi và vấn đề hiệu năng mà kỹ sư senior thực sự đảm nhận
  • Các bài tính năng dùng chỉ dẫn thực tế đọc giống như thông điệp ngôn ngữ tự nhiên, và nâng độ tin cậy đánh giá bằng một validation agent tạo bài kiểm thử hành vi phù hợp với lời giải được nộp
  • Các bài lỗi xuất phát từ báo cáo của người dùng, được lấy từ các PR đòi hỏi điều tra runtime như chạy dịch vụ, xem log, dữ liệu profiling và quy trình tái hiện
  • Điểm số không chỉ dựa trên tính đúng đắn runtime mà còn kết hợp các chỉ số chất lượng dựa trên thông lệ của codebase để đánh giá tasteful solve; các thông lệ quan trọng không có trong chỉ dẫn cũng có thể được kiểm chứng
  • Ngay cả model đứng đầu leaderboard là Claude Opus 4.8 cũng chỉ đạt pass@1 24,0% với cấu hình Mini-SWE-Agent max, nghĩa là các model hàng đầu vẫn thất bại hơn 75% trước các lời giải có tính đúng đắn và taste ở cấp senior

Thiết kế bài gần với PR thực tế

  • Senior SWE-Bench là benchmark nhằm thu hẹp khoảng cách giữa việc coding agent trên thực tế được dùng như kỹ sư senior, nhưng lại được đánh giá bằng các bài kiểu junior
  • Các bài được lấy từ PR của nhiều repository, từ thư viện đến ứng dụng đa dịch vụ, và nhắm tới PR do các kỹ sư đã viết hàng trăm commit trong từng repository tạo ra
  • Các loại bài chính được chia thành hai nhánh
    • PR tính năng trải qua nhiều bước và nhiều stack
    • PR lỗi·hiệu năng từng cần điều tra runtime đáng kể
  • Có 50 bài công khai và 50 bài không công khai
  • Ví dụ các repository được đưa vào như sau

Bài tính năng: chỉ dẫn gần với ngôn ngữ tự nhiên

  • Các bài tính năng dùng chỉ dẫn thực tế đọc giống thông điệp ngôn ngữ tự nhiên, thay vì các yêu cầu bị chia nhỏ quá mức
  • Để đánh giá ổn định những bài như vậy, benchmark đưa vào validation agent
    • Dùng recipe do chuyên gia thiết kế
    • Viết bài kiểm thử hành vi phù hợp với lời giải được nộp
  • Chỉ dẫn phản ánh cách giao tiếp tự nhiên với agent, và độ dài trung vị ở mức 31% so với SWE-Bench Pro

Bài lỗi: từ báo cáo người dùng đến điều tra runtime

  • Các bài lỗi phản ánh báo cáo người dùng khó xử lý, đòi hỏi nhiều hơn ở khâu tìm nguyên nhân và tái hiện so với chỉ sửa code đơn giản
  • Bài có thể bao gồm các công việc như
    • Khởi động dịch vụ
    • Debug vấn đề runtime tinh vi
    • Kiểm tra log
    • Sử dụng dữ liệu profiling
    • Theo dõi quy trình tái hiện
  • Nguồn là các PR mà quá trình giải quyết từng cần điều tra runtime đáng kể

Tiêu chí đánh giá: đo cả tính đúng đắn và taste

  • Senior SWE-Bench chấm điểm tasteful solve bằng cách kết hợp kiểm thử tính đúng đắn runtime với nhiều chỉ số chất lượng
  • Các chỉ số chất lượng dựa trên những thông lệ quan sát được trong codebase
  • Verifier và validation agent có thể kiểm thử các thông lệ quan trọng trong codebase, kể cả khi chúng không được viết trong chỉ dẫn
  • Điều kiện solve trên leaderboard bao gồm các mục sau
    • Verifiers pass
    • Validation pass
    • Rubric > 0.5
    • Bloat < 2×
    • Practice > 2/5
    • Rel. taste > 2/5

Leaderboard: model tốt nhất cũng có pass@1 thấp

  • Leaderboard hiển thị kết quả theo Tasteful solve rate(pass@1)
  • Các kết quả đứng đầu như sau
    • Claude Opus 4.8, Mini-SWE-Agent max: 24,0%
    • Claude Sonnet 5, Mini-SWE-Agent max: 19,4%
    • GPT-5.5, Mini-SWE-Agent xhigh: 16,0%
    • Claude Opus 4.7, Mini-SWE-Agent max: 14,1%
    • GPT-5.4, Mini-SWE-Agent xhigh: 14,0%
    • GLM-5.2, Mini-SWE-Agent max: 12,5%
    • Kimi K2.6, Mini-SWE-Agent default: 8,2%
    • Claude Sonnet 4.6, Mini-SWE-Agent high: 8,2%
    • Gemini 3.1 Pro, Mini-SWE-Agent high: 6,1%
    • Gemini 3.5 Flash, Mini-SWE-Agent medium: 3,0%
  • Ngay cả những frontier model mạnh nhất cũng không hoàn thành được hơn 75% các bài đòi hỏi tính đúng đắn và taste ở cấp senior

Phạm vi bài và đặc tính benchmark

  • Loại bài được biểu thị là feature, bug, perf, migrat
  • Stack bao gồm Py Svc, Elixir, Go, SQL, TS Lib, Py Lib, Rust, TS FE, v.v.
  • Bài tính năng có thể trải qua nhiều dịch vụ và trung bình chạm tới 11 file mỗi bài
  • Được thiết kế để đòi hỏi workflow dài, nên ngay cả agent mạnh nhất cũng cần hàng trăm bước
  • SLOC và số file của lời giải tham chiếu được đo theo cùng một cách trong ba benchmark
  • Độ dài chỉ dẫn không tính boilerplate của harness
  • Số token và số bước của các benchmark khác dựa trên chỉ số tự báo cáo của từng benchmark

Bài viết liên quan

1 bình luận

 
GN⁺ 4 giờ trước
Ý kiến trên Hacker News

  • Theo những gì tôi thấy trên Twitter, trong một lớp học về machine learning của Đại học Tsinghua, có một bài kiểm tra yêu cầu sinh viên tạo ra câu đố khiến càng nhiều LLM thất bại càng tốt
    Tôi tự hỏi nếu tạo một benchmark kiểu này rồi gắn điểm ELO thì sao. Các mô hình đấu với nhau, đưa ra câu hỏi, bug, hoặc phần triển khai chưa hoàn chỉnh, rồi bên kia trả lời, sửa, hoặc hoàn thiện

    • Có thể gọi thứ này là mạng sinh đối kháng (GAN) :)
      https://en.wikipedia.org/wiki/Generative_adversarial_network
    • Vấn đề là làm sao ngăn chiến lược suy thoái. Ví dụ chỉ cần đưa một hash SHA256 rồi yêu cầu đoán input gốc là quá dễ tạo ra bài toán bất khả thi
      Trong lớp học thì có thể đặt quy tắc rằng ít nhất một LLM phải trả lời được, nhưng trong đấu tay đôi thì tôi không biết nên giải quyết thế nào
    • Tôi nghĩ đó là Fudan, không phải Tsinghua

  • Tôi tò mò benchmark này sẽ duy trì tính liên quan theo thời gian như thế nào
    Nếu benchmark là triển khai tính năng cho các dự án open source, LLM có thể đã có những thay đổi đó trong dữ liệu huấn luyện, nên có thể đưa ra đáp án y nguyên hoặc biến đổi nhẹ
    Ngược lại, nếu chỉ đưa vào benchmark các thay đổi mã sau mốc cắt kiến thức của mô hình, thì bài toán ở thời điểm T và T+1 sẽ khác nhau, làm giảm khả năng so sánh theo thời gian

  • Nếu là Staff SWE Bench, có lẽ LLM sẽ nghi ngờ ngay từ đầu rằng liệu có nên làm việc này không, đặt vấn đề với toàn bộ dự án, từ chối merge code nhưng sẵn sàng xóa code

    • Nghe như đùa, nhưng tôi nghĩ từ chối thực sự là phần cốt lõi của công việc. Không phải chỉ là “không được, đi đi”, mà lùi lại một bước để yêu cầu bức tranh tổng thể, xem toàn tổ chức có thực sự cần và có thể gánh dự án đó về dài hạn hay không; đó gần như là thủ tục tối thiểu trước khi bắt đầu
      LLM cũng có thể làm việc này đủ tốt, thậm chí có lẽ tốt hơn chúng ta, nhưng cần được huấn luyện riêng cho việc đó. Có điều tôi chưa nghĩ ra sẽ lấy dữ liệu huấn luyện kiểu ấy ở đâu
    • Bản Principal cũng tương tự, nhưng còn nói rằng cách tiếp cận duy nhất được phép là cách đã làm ở công ty trước

  • Vậy là điều này giải thích vì sao tôi luôn cảm thấy Opus 4.8 đi trước GPT 5.5 rất xa. Khả năng nhận yêu cầu chưa hoàn chỉnh rồi tự điền chỗ trống theo cách hợp lý với dự án của nó thật sự rất tốt

    • Tôi không hiểu vì sao ngay từ đầu lại đưa yêu cầu chưa hoàn chỉnh. Cả hai mô hình đều giỏi xem xét giả định và edge case, cũng như đặt câu hỏi để làm rõ, nhưng có vẻ chỉ làm vậy khi được yêu cầu rõ ràng, chẳng hạn khi yêu cầu bằng các kỹ thuật như “brainstorming”
      Tôi cho rằng cả hai cách đánh giá đều chưa đủ khuyến khích mô hình nghi ngờ mọi giả định và đặt câu hỏi. Có thể vì người dùng sẽ thấy phiền, nhưng tôi nghĩ bước đó gần như bắt buộc
      Dòng GPT-5 đều rất tỉ mỉ, nên hữu ích cho code review và toán học. Điều đó quan trọng với công việc của tôi, nhưng có vẻ lại cản trở với code “thẩm mỹ”. Ví dụ như nó cố phòng vệ cả những edge case xác suất thấp
      Dường như cũng có sự đánh đổi giữa độ linh hoạt và tuân thủ chỉ dẫn. Theo trải nghiệm của tôi, Opus đôi khi phớt lờ chỉ dẫn nhưng điền chỗ trống tốt hơn, còn GPT-5.5 làm theo chỉ dẫn tốt hơn nhưng vì thế cũng cứng nhắc hơn
    • Benchmark tốt nhất là benchmark do chính bạn tự làm
      Theo trải nghiệm của tôi, Opus không vượt trội áp đảo hay tốt hơn hẳn. Dù sao GPT 5.5 có Instant, Medium, High, Extra High, Pro; trong bảng có vẻ so với Extra High, nên không phải cần so với Pro sao?
    • Không biết có phải tôi đang sống trong một bong bóng kỳ lạ không, nhưng với tôi GPT 5.5 tốt hơn Opus 4.8 rất nhiều. Tôi tò mò không biết mọi người đánh giá thế nào, làm loại công việc gì
      Có một số tác vụ cụ thể Opus làm tốt hơn, như phát triển frontend và thiết kế, nhưng ngoài các việc đó thì 5.5 đơn giản là áp đảo
    • Có thể tốt hơn với những vibe coder luôn mô tả thiếu chi tiết. Nhưng vấn đề là từ điểm nào mô hình quyết định rằng “yêu cầu chưa được mô tả đủ”, rồi lại triển khai vượt quá đặc tả thực ra đã đủ rõ
    • Tôi cũng quan sát thấy như vậy. Opus 4.8 trưởng thành hơn nhiều, và với các yêu cầu khiến nó băn khoăn, nó sẽ hỏi lại hoặc phản đối. Trong khi đó GPT 5.5 sẵn lòng đồng ý và làm theo, nhưng thường phải yêu cầu lại vài lần
      4.8 cũng cần hơn một prompt, nhưng chất lượng đầu ra cao hơn nhiều và đem lại nhiều insight hơn
      Tuy nhiên Fable 5 lại là một thực thể khác

  • Tỷ lệ giải tốt nhất hiện tại là 24% với Opus 4.8, vậy một con người có năng lực sẽ đạt khoảng bao nhiêu điểm?

    • Có lẽ con người cũng có thể dùng những gì mô hình tốt nhất dùng, nên chắc là cao hơn mức đó
      Ngược lại, tôi cũng tò mò nếu mô hình có thể tùy ý sai khiến con người thì liệu nó có đạt điểm cao hơn không
    • Nếu giả định các bài này đều là những bài đã được giải rồi thì tôi nghĩ là 100%. Dĩ nhiên không phải cùng một người giải tất cả, nhưng mô hình phải giỏi trên nhiều codebase khác nhau, trong khi con người có thể chuyên sâu và học một sản phẩm
      Tôi nghĩ so sánh với một cá nhân quen làm việc trên sản phẩm là công bằng
      Tôi tò mò hơn là Fable sẽ thể hiện thế nào

  • Giá trị của vai trò senior nằm ở việc áp dụng các lời giải và chiến lược đã biết vào vấn đề mới. Tôi không biết một benchmark không bao giờ thay đổi có thể còn là thách thức mới trong bao lâu
    Nếu là benchmark ổn, nó nên dùng toàn bộ TRIZ để trước hết tạo ra một khối vấn đề khổng lồ, rồi xem AI có suy luận được lời giải tối ưu không

  • Thật vui khi Snorkel đưa ra một benchmark công khai mới. Bên đó đang làm những thứ khá tinh vi

  • Thú vị là Sonnet 5 khá tiệm cận Opus 4.8

  • Nếu cách này hoạt động, chẳng phải điều đó có nghĩa là cũng có thể tự động hóa phỏng vấn kỹ thuật sao?

  • Cách để LLM đưa ra phán đoán chủ quan kiểu “You are a senior SWE-Bench reviewer, make no mistakes.” trông có vẻ có khiếm khuyết căn bản
    Tôi không biết cách nào tốt hơn mà vẫn khả thi

    • Quan trọng hơn, điều này thực ra có thể cản trở công việc. Khi LLM mắc lỗi, thay vì thừa nhận và sửa, nó có thể bị khuyến khích giảm nhẹ rồi cho qua
    • Cách này thực chất là cài bối cảnh về việc LLM nên hành xử thế nào. “senior reviewer” là phong cách phản hồi mong muốn, còn “SWE-Bench” là bối cảnh và lĩnh vực mà LLM hoạt động
      Đây là cách phổ biến trong system prompt và giúp định khung câu trả lời
      Ví dụ, nếu nói “một tên cướp biển viết shanty về lập trình”, “một phóng viên viết bài về vật lý”, “một kỹ sư phần mềm senior hiểu PostgreSQL hoàn hảo”, thì mỗi câu sẽ cho ra phản hồi khác nhau
      Với câu đầu, nó có thể trả lời theo phong cách Wellerman kiểu “There once was a program that was set to C ...”
      Tuy nhiên phần “make no mistakes” thì đáng ngờ. Sẽ thú vị nếu so sánh kết quả khi có và không có cụm đó, rồi thử cả các cách khác để đạt cùng hành vi mong muốn
    • Lời răn “make no mistakes” trông khá buồn cười. Trên YouTube nó cũng đã bị chế giễu nhiều, nhưng cũng dễ hình dung một cách mà nó có thể hoạt động. Ví dụ nó có thể đơn giản được diễn giải là “hãy rà soát công việc”
      Dĩ nhiên có vẻ không có nơi nào thực hiện công khai các phép đo so sánh kiểu này để đi đến kết luận hợp lý