Model là một, harness là năm

Suốt phần lớn tháng Chín, tôi tranh cãi hoài về việc model nào mạnh nhất. Người này đăng kết quả model A xử lý được một vấn đề hóc búa, người kia phản bác bằng model B làm được điều tương tự, và cuối cùng chẳng ai chịu ai, vì chẳng kết quả nào tái lập được trên máy người kia. Hai người đem so những thứ mình không nhìn thấy, trong điều kiện mình không kiểm soát, rồi gọi khác biệt đó là chất lượng model.

Cuộc tranh luận kết thúc bằng một câu của ông đồng nghiệp, ông chán ngấy chuyện này rồi: model là một, harness là năm. Không phải nghĩa đen. Ý là chọn model chỉ là phần nhỏ trong những gì bạn quan sát, phần còn lại là mọi thứ quanh model. Chấp nhận điều đó xong, bất đồng nhỏ đi tới mức đủ để test, và test là kết thúc chúng.

Vì sao các bảng xếp hạng model gây nhầm lẫn

Một benchmark đo một model bên trong harness của người khác. Router của họ, prompt của họ, quyền tool của họ, cách họ xử lý context, container của họ. Mang model đó về setup của mình, bạn chẳng mang theo được thứ nào trong đó. Bạn chỉ có router của mình, prompt của mình, mọi thứ của mình. Con số đó không áp dụng được cho setup của mình. Lỗi không phải ở chỗ benchmark nói dối. Lỗi là benchmark đo một hệ thống khác với hệ thống bạn đang chạy.

Tôi từng chứng kiến chuyện này với một model mà ai cũng đồng ý là mạnh. Trong setup của một người tôi làm cùng, nó xuất sắc. Trong setup của người khác, cùng task đó, nó tầm thường. Cùng model, cùng version, cùng ngày. Biến số là mọi thứ còn lại. Người cho ra kết quả tốt hơn đã bỏ nhiều thời gian hơn cho harness, ít hơn cho model.

So sánh model cho tử tế thì phải giữ harness cố định và chỉ đổi một thứ. Thí nghiệm nhỏ hơn, nhưng cho ra câu trả lời thật. Còn xếp hạng model bằng cảm giác qua các setup khác nhau thì chỉ đẻ ra một cuộc tranh luận không thể thắng, vì hai người đâu có đo cùng một thứ.

Những tín hiệu thực sự có ý nghĩa

Thôi xếp hạng, chuyển sang đo, tôi thấy nổi lên vài hành vi cụ thể đáng để biết. Chúng hẹp, và đó chính là điểm mấu chốt. Biết một model nói chung tốt hay dở thì chẳng làm gì được. Biết nó giỏi đúng một việc cụ thể thì mới hành động được.

Một model hoá ra cực giỏi tìm bug mà dở viết văn. Văn do nó viết đọc như của một model hoàn toàn khác, phẳng và chung chung. Đổi lại, nó săn bug trong codebase cực chuẩn, độ chính xác mà model viết văn không có. Tôi thôi giao task viết, chuyển sang giao task săn bug, và giá trị của nó tăng vọt ngay.

Một model khác thì rẻ và chính xác với task có giới hạn, nhưng nguy hiểm khi thả lỏng. Giao việc rõ ràng, nó làm gọn gàng. Thả cho tự do, nó đọc lại context, lặp, đốt trọn cửa sổ quota vào một task lẽ ra chỉ mất hai mươi phút. Rẻ trên mỗi token, đắt trên mỗi task.

Model thứ ba, tầm trung và chẳng có gì nổi bật trên benchmark, lại cho kết quả trọn vẹn hơn ở medium so với high. Ở effort high, nó trôi sang overthinking và trả lời kém dùng được hơn. Tôi để nó ở high vì thói quen, và trả nhiều tiền hơn để nhận output tệ hơn. Effort giờ là thiết lập riêng theo từng role, tôi test chứ không đoán.

Chẳng phát hiện nào ở trên đến từ bảng xếp hạng. Tất cả đều đến từ chỗ chạy model trên chính công việc của mình, trong harness của mình, rồi ghi lại những gì đã xảy ra. Và tôi muốn nói rõ mức của chúng: đây là những pattern tôi nhận thấy qua vài tuần chạy task của chính mình, do chính tôi chấm, trên những setup mà tôi không giữ cố định giữa các lần quan sát. Chúng là tín hiệu đáng test, không phải phát hiện. Bản sạch thì tôi chưa chạy, cùng task, cùng harness, đổi một biến, ghi kết quả lại, và cho tới khi làm điều đó, câu ở đầu bài này là nguyên tắc để tranh luận cho tử tế, không phải phép đo của bất kỳ thứ gì.

Những điểm lạ dạy tôi nhiều nhất

Quan sát lạ nhất giai đoạn đó đến từ một đồng nghiệp: một model suy luận bằng tiếng Trung trước khi trả lời một câu hỏi tiếng Việt. Anh chỉ nghi, chưa bao giờ chứng minh được, rằng model này được train trên dữ liệu chưng cất từ một open-weight model gốc Trung Quốc, và vệt suy luận kia làm lộ nguồn gốc. Chẳng ai xác minh được điều đó đúng hay sai. Cái chốt lại là cách tôi đối xử với nó: coi như một giả thuyết về dữ liệu train, không phải sự thật đã chứng minh, và cũng không phải thứ làm thay đổi cách tôi dùng model hằng ngày.

Bài học hữu ích hơn nằm ở chỗ một quan sát lạc lõng dễ biến thành niềm tin chung nhanh tới mức nào. Chỉ một dòng kể rằng model hành xử lạ, truyền qua nhóm bốn mươi người là thành đồng thuận trong vòng một giờ, và đồng thuận trong nhóm lại thành quyết định mua tool nào. Tôi bắt đầu dán nhãn các quan sát theo mức bằng chứng, như vẫn làm trong mọi bối cảnh kỹ thuật khác. Phỏng đoán không phải phát hiện, và khác biệt đó quan trọng khi phát hiện sắp làm thay đổi ngân sách của bạn.

Kỷ luật đó cũng đúng cho một cuộc tranh luận dài về hai dòng model. Một bên đưa ra màn trình diễn model thất bại một bài toán logic. Bên kia chỉ ra rằng một vấn đề duy nhất, khéo đến đâu, cũng không đo được chất lượng suy luận của model, và rằng cùng một vấn đề mà các version khác nhau của cùng model cho kết quả khác nhau. Không bên nào có chuẩn để đo, nên không bên nào thắng được. Cuộc tranh luận kéo mấy ngày, và sinh ra câu thành quy tắc của tôi. Model là một. Chuẩn thì tôi thiếu.

Agent thực sự hụt hơi ở đâu

Tách chất lượng model khỏi chất lượng harness cũng cho thấy giới hạn thật nằm ở đâu, và hoá ra giới hạn đó thuộc về task, không phải về model.

Agent viết sách đọc như catalogue sản phẩm. Cho một chủ đề rộng, chúng cho ra một khảo sát rộng mà nông: chương nào cũng có, chương nào cũng hời hợt, vì đó là output an toàn về mặt thống kê cho bất kỳ chủ đề nào. Thu hẹp chủ đề lại là output khá hơn ngay. Cách sửa là khoanh phạm vi, không phải đổi model mạnh hơn.

Code do agent sinh ra phải đọc khác code người viết. Một đồng nghiệp kể lại là đọc chừng mười phần trăm, tập trung vào những pattern hay sai, những query trông quá khôn khéo, những logic đã rối lên, còn lại bỏ qua. Một người khác gọi đó là thói quen chứ không phải bộ lọc: cứ đặt câu hỏi cho code, đừng đọc từ trên xuống. Một codebase bạn không viết và không nắm hết trong đầu thì kiểu gì cũng phải tin ở đâu đó, và cái khó là biết chỗ nào cần kiểm.

Agent làm interface hay mắc một lỗi rất đặc thù trên mobile. Một landing page trông ổn trên laptop lại không dùng được trên điện thoại, mà không ai kiểm. Mấy người tôi làm cùng góp ý thiết kế và đưa ra một framework cụ thể để sửa: kể chuyện bằng cách đặt tình huống của người dùng lên tiêu đề thay vì đặt tính năng sản phẩm, một đường dẫn ngắn có hướng dẫn thay vì một bức tường lựa chọn, và lời kêu gọi hành động đặt trước phần testimonials chứ không phải sau. Framework đó không đến từ model. Nó đến từ một người đã từng xây và ship thật, và agent làm theo ngay khi framework được nêu rõ ràng.

Tôi đã thay đổi gì

Ba thói quen ra đời từ giai đoạn này và giữ nguyên tới giờ.

So sánh model thì đổi một biến, giữ nguyên phần còn lại. Cùng task, cùng harness, cùng ngày. Ghi kết quả lại. Một so sánh không tái lập được chỉ là ý kiến khoác lốt con số.

Ghi lại mỗi phát hiện kèm mức bằng chứng của nó. Một giai thoại đơn lẻ không phải benchmark. Một pattern lặp lại qua ba task là một tín hiệu. Một kết quả tái lập được trên harness cố định là một phát hiện. Phần lớn cuộc tranh luận model chỉ là hai người kể giai thoại cho nhau rồi gọi đó là phát hiện.

Khoanh việc theo thế mạnh thật của agent, không theo danh tiếng của model. Model giỏi tìm bug thì giao bug. Giỏi task có giới hạn thì giới hạn task. Effort cao hơn làm nó dở đi thì hạ effort xuống. Vị thế chung của model gần như chẳng nói gì về cách dùng nó cho tốt.

Bảng xếp hạng không vô dụng. Chúng giúp bạn biết bắt đầu từ đâu. Cái chúng không nói được là model sẽ cư xử thế nào bên trong setup của bạn, trên công việc của bạn, vì cái đó vừa thuộc về setup vừa thuộc về công việc, không chỉ riêng model. Điểm số quan trọng là điểm bạn tự đo, trên những task bạn thực sự chạy, với harness bạn thực sự xây.