Quy trình lập trình tác nhân với mô hình nhỏ

Được rồi.

Chào các bạn!

Tôi là Jose, và tôi có mặt ở đây cùng với Ian và Zoe.

Chúng ta đều biết về LLM.

Chúng tôi dùng các mô hình này cho mọi việc: tìm công thức nấu ăn, tóm tắt video trên YouTube và lập trình.

Có những LLM thực sự lớn, chẳng hạn như các mô hình Gemini, có khả năng làm những điều thực sự đáng kinh ngạc, nhưng trong bài nói chuyện này, chúng ta sẽ nói về các mô hình ngôn ngữ nhỏ.

Chúng cũng là LLM vì một mô hình có 4 tỷ tham số thì không thể nhỏ được, nhưng từ giờ trở đi, chúng ta sẽ phân biệt hai loại này: Mô hình tiên phong và Mô hình ngôn ngữ nhỏ, giống như tên lửa và xe đạp.

Chúng ta sẽ thảo luận về các mô hình nhỏ, không nhất thiết là giải pháp thay thế cho các mô hình tiên phong, mà chủ yếu là để bổ sung cho các mô hình đó.

Chúng ta sẽ khám phá tất cả lợi ích của mô hình ngôn ngữ nhỏ, đặc biệt là khi chúng là mô hình mở, có trọng số mở và có thể tải xuống, nhưng hãy xem xét chi phí trong giây lát.

Để chuẩn bị cho bài nói chuyện này, tôi đã chạy rất nhiều điểm chuẩn, và một trong số đó là một tập dữ liệu gồm 200 nhiệm vụ trung bình và khó, sử dụng gần 131 triệu token với chi phí chưa đến 9 đô la.

Tôi đã sử dụng Gemma 4 cho việc này, vì vậy, tôi có thể tải xuống và chạy miễn phí trên phần cứng của riêng mình, nhưng tôi đã chạy trên một cổng thương mại chỉ để so sánh công bằng.

Vậy chi phí cho một mô hình tiên phong là bao nhiêu?

Nhiều hơn khoảng 20 đến 200 lần, tuỳ thuộc vào việc lưu mã thông báo vào bộ nhớ đệm và các yếu tố khác.

Vì vậy, xe đạp có thể không phải là phương tiện di chuyển nhanh nhất, nhưng chắc chắn là phương tiện hiệu quả nhất.

Thật đấy.

Vậy giờ đây, câu hỏi rõ ràng là chất lượng và độ chính xác có gì khác biệt?

Trong tập dữ liệu cụ thể này, Gemma 4 có thể giải quyết 53% nhiệm vụ.

Điều này có hai ý nghĩa.

Nếu bạn đang sử dụng một mô hình tiên phong để chạy các nhiệm vụ ở bên trái, thì có thể là quá mức cần thiết.

Còn nếu dùng một mô hình nhỏ để chạy các nhiệm vụ này ở bên phải, bạn sẽ phải hướng dẫn mô hình tìm ra giải pháp hoặc sử dụng một mô hình lớn hơn.

Trong buổi trò chuyện này, chúng tôi muốn giúp bạn khai thác tối đa từng mã thông báo.

Zoe sẽ hướng dẫn bạn cách chọn một mô hình nhỏ, còn Ian sẽ nói về các mô hình Gemma để bạn hiểu cách định hình tư duy về những gì các mô hình này có thể làm được.

Sau đó, tôi sẽ nhanh chóng hướng dẫn bạn cách dùng thử Gemma 4 trong Android Studio. Cuối cùng, chúng tôi sẽ hướng dẫn bạn cách đưa các mô hình nhỏ vào quy trình làm việc hằng ngày, cũng như các điểm chuẩn phát triển thực tế trên Android để giúp bạn hiểu rõ khả năng của các mô hình này.

Giờ thì xin mời Zoe.

Cảm ơn Jose rất nhiều!

Vậy nên, việc dùng một mô hình cho mọi thứ giống như dùng búa tạ để đập hạt dẻ, đúng không?

Cách này hiệu quả nhưng hơi mất cân đối.

Vì vậy, khi nghĩ về các mô hình nhỏ, bạn gần như đang mở rộng bộ công cụ của mình.

Để biết những gì bạn phải đưa vào quy trình làm việc của mình, bạn cần mở bộ công cụ, xem những gì có sẵn, thông số kỹ thuật của chúng là gì, chúng phù hợp với mục đích gì.

Vì vậy, để chọn mô hình nhỏ, bạn cần biết về mô hình nhỏ.

Và loại mô hình mà hầu hết mọi người nghĩ đến khi nghĩ về mô hình ngôn ngữ là mô hình ngôn ngữ tự hồi quy.

Đây là mô hình tự hồi quy vì dựa trên một đoạn dữ liệu đầu vào được phân tách thành các mã thông báo, mô hình này sẽ chọn mã thông báo tiếp theo có khả năng xảy ra nhất trong danh sách các mã thông báo đề xuất.

Sau đó, mã thông báo tiếp theo có nhiều khả năng được chọn nhất sẽ quay lại dữ liệu đầu vào và chúng ta tiếp tục, có khả năng tạo ra các phản hồi mạch lạc và thông minh, nhưng nó có một số lưu ý, bao gồm nhưng không giới hạn ở việc hoạt động tuyến tính.

Vì vậy, chúng ta có thể làm việc theo cách phi tuyến tính.

Mô hình khuếch tán cũng có cách tiếp cận tương tự, nhưng xử lý một khối mã thông báo tại một thời điểm.

Nó gần giống như một bản phác thảo đang được lấy nét.

Và trong trường hợp này, DiffusionGemma hoạt động trên các đoạn gồm 256 mã thông báo cùng một lúc.

Vì vậy, về cơ bản, bạn sẽ nhận được một thẻ hoạt động trên toàn bộ khối, có thể tạo kết quả với độ trễ thấp hơn.

Vậy là bộ công cụ của chúng ta có các mô hình có thể viết, đúng không?

Sai.

Vì vậy, về cơ bản, mô hình nhúng sẽ chuyển đổi các đối tượng như hình ảnh, văn bản hoặc bất kỳ khái niệm nào khác thành một vectơ.

Vì vậy, điều đó cung cấp cho chúng ta một bản đồ, giả sử là toạ độ, vào một không gian nhiều chiều cho phép chúng ta so sánh hai thứ về mặt khái niệm.

Ví dụ: nếu bánh kẹp xúc xích là bánh mì kẹp, thì có thể chúng sẽ dẫn đến một không gian hẹp hoặc kết thúc trong một không gian hẹp.

Vì vậy, việc có thể kiểm tra xem hai khái niệm có liên quan hay không sẽ trở thành một phép toán nhỏ thay vì một lượt truyền mô hình, điều này được cho là cũng có một chút toán học, nhưng Vì vậy, mô hình này thậm chí còn tiến xa hơn, phải không?

Ngoài ra, còn có các mô hình nhỏ hơn và chuyên biệt hơn, có khả năng thực hiện một công việc và thực hiện rất tốt.

Một số ví dụ ở đây là, chẳng hạn như chúng ta có các mô hình hàm chuyển đổi ngôn ngữ tự nhiên thành lệnh gọi API, các mô hình thị giác mà tôi chắc chắn rằng bạn biết chúng có khả năng làm gì theo tên, hoặc, ví dụ, các bộ phân loại có thể cho điểm cho một đầu vào dựa trên một số tham số nhất định.

Như vậy, có rất nhiều lựa chọn, đúng không?

Có rất nhiều loại mô hình khác nhau, với các kích thước, cửa sổ ngữ cảnh, khả năng và mức sử dụng bộ nhớ khác nhau. Khi bạn mở hộp công cụ và xem xét mọi khả năng, các lựa chọn sẽ tăng lên theo cấp số nhân, đến mức bất kỳ người hâm mộ DIY nào cũng sẽ vô cùng phấn khích hoặc bị choáng ngợp trước quá nhiều lựa chọn.

Vậy làm cách nào để chọn một mô hình nhỏ?

Hãy bắt đầu bằng cách mở một hộp công cụ gồm các mô hình nhỏ và mở có thể chạy trên máy, đó là các mô hình Gemma.

Xin mời Ian.

Cảm ơn Zoe.

Như Jose đã đề cập ở phần đầu, một mô hình ngôn ngữ nhỏ có thể thực hiện khoảng 50% nhiệm vụ ngay từ đầu.

Nhưng cụ thể, tại sao bạn có thể chọn một mô hình cục bộ?

Vậy nên, có khoảng 4 điều cần lưu ý.

Đầu tiên là quyền riêng tư.

Ví dụ: bạn có thể có khoá API, mã độc quyền hoặc những thứ không thể rời khỏi máy tính xách tay của bạn.

Thứ hai là độ trễ.

Vì vậy, khi mô hình thực sự được tải vào bộ nhớ, dù là bộ nhớ đồ hoạ hay bộ nhớ hợp nhất, bạn sẽ nhận được phản hồi ngay khi mô hình hoàn tất quá trình tính toán.

Vì vậy, không có thời gian khứ hồi đến máy chủ, không có thêm độ trễ.

Tiếp theo là chi phí cận biên bằng 0.

Vì vậy, các mô hình sẽ tiết kiệm chi phí khi bạn có thể kiểm soát nơi chúng chạy.

Vì vậy, trong trường hợp chạy một nội dung nào đó trên máy cục bộ, chẳng hạn như có thể thực hiện thêm các lần thử lại trong một vòng lặp lỗi.

Bạn không phải trả phí và không có bất kỳ chi phí API bất ngờ nào cho phần đó.

Và cuối cùng, lợi ích thứ tư là xem không cần mạng.

Vì vậy, hãy tưởng tượng bạn có thể sử dụng mô hình này trên máy bay, tàu hoả, xe buýt hoặc tàu điện ngầm, về cơ bản là ở bất cứ nơi nào bạn có mô hình chạy trên phần cứng của mình.

Nghe thì có vẻ hay, nhưng có hai yếu tố chính mà chúng ta cần cân nhắc khi đưa ra những quyết định này.

Vì vậy, một là bộ nhớ và hai là tốc độ.

Vì vậy, nếu bạn nhìn vào biểu đồ này, nếu bạn nhìn vào hai mô hình dưới cùng, 26B và 31B, cả hai đều cần hơn 50 GB RAM video để chạy trong BF16, tức là lượng tử hoá 16 bit.

Vì vậy, thách thức ở đây là mô hình này sẽ không phù hợp với nhiều loại phần cứng.

Vì vậy, chúng tôi thực hiện một quy trình gọi là lượng tử hoá để thu hẹp độ chính xác đó xuống, chẳng hạn như 4 bit thành số thực.

Giờ thì hợp lý hơn một chút rồi.

Chúng ta đang nói về 14 GB và 17 GB, đúng không?

Giờ đây, mô hình này có thể chạy trên những thiết bị như máy Mac có bộ nhớ hợp nhất.

Giờ đây, thách thức của việc này là trong quá trình lượng tử hoá sau huấn luyện thông thường, điều sẽ xảy ra là khi bạn nén các trọng số đó, bạn sẽ mất một chút độ chính xác trong mô hình so với mô hình cơ sở và chúng tôi có một kỹ thuật để chống lại điều đó.

Quá trình này được gọi là huấn luyện nhận biết lượng tử hoá.

Khi chúng ta làm như vậy, mô hình sẽ được huấn luyện để biết rằng nó sẽ có kích thước nhỏ hơn, và do đó, mức tổn thất thực tế sẽ ít hơn so với việc cắt tỉa sau khi huấn luyện.

Vì vậy, chúng tôi giảm được 75% yêu cầu về RAM và giờ đây, mô hình này có thể hoạt động trên các thiết bị đó.

Và chúng tôi còn tiến xa hơn nữa.

Vì vậy, các phương pháp lượng tử hoá di động mà chúng tôi có, hoạt động trên nhiều điện thoại di động, có thể thu nhỏ các mô hình đó hơn nữa bằng cách hiểu cách tất cả các lớp khác nhau hoạt động và kích thước mà chúng có thể hoạt động.

Vì vậy, chúng ta có một số loại lượng tử hoá kết hợp.

Vì vậy, chúng ta chuyển từ Gemma E2B 11,4 GB xuống còn 1,1 GB.

Vì vậy, giờ đây, việc này thực sự hợp lý hơn nhiều đối với các loại điện thoại tầm trung đến cao cấp.

Tiếp theo là tốc độ.

Vì vậy, khi sử dụng mô hình tự hồi quy, như Zoe đã đề cập, bạn sẽ dự đoán tập hợp mã thông báo tiếp theo.

Vì vậy, trong một nhiệm vụ lập trình, bạn có thể thấy nhiều mã thông báo trong số này thực sự khá dễ đoán, chẳng hạn như phần cuối của một chữ ký phương thức, hoặc dấu ngoặc nhọn mở hoặc đóng.

Vì vậy, bạn có thể sử dụng một kỹ thuật gọi là giải mã suy đoán.

Và điều đó sẽ làm là nó sẽ sử dụng một mô hình soạn thảo nhỏ hơn để dự đoán một số mã thông báo sau đó được xác thực bởi một mô hình lớn hơn.

Và lý do khiến tính năng này hoạt động trong cấu trúc Gemma 4 là vì chúng dùng chung bộ nhớ đệm KV.

Vì vậy, hãy coi đây như bộ nhớ ngắn hạn của mô hình.

Vì vậy, điều sẽ xảy ra là một mô hình soạn thảo nhỏ sẽ dự đoán trước 3 hoặc 4 mã thông báo, sau đó mô hình lớn hơn sẽ xem xét cùng một bộ nhớ đệm KV đó và về cơ bản sẽ xác thực kết quả đầu ra.

Và điều này có thể giúp tăng hiệu suất lên khoảng 3 lần mà không làm giảm chất lượng đầu ra của mô hình, vì mô hình chỉ dự đoán rồi quyết định xem kết quả là đạt hay không đạt, đúng hay sai.

Vì vậy, một lần nữa, điều này phụ thuộc một chút vào nhiệm vụ bạn đang thực hiện.

Vì vậy, phương pháp này không hiệu quả lắm đối với những việc như viết sáng tạo vì có nhiều biến số hơn, nhưng lại rất hiệu quả đối với những việc có thể dự đoán được như cấu trúc JSON và lập trình.

Vậy làm cách nào để đánh giá một trong những mô hình này?

Vì vậy, điều rõ ràng nhất bạn có thể làm là xem xét một điểm chuẩn như LiveCodeBench hoặc MMLU và xem điểm số.

Nhưng điều đó chỉ cung cấp cho bạn một chỉ báo tổng quát về khả năng của mô hình.

Điều bạn thực sự cần làm là đánh giá toàn bộ ngăn xếp mà ứng dụng đang chạy.

Đây là mô hình bạn đang sử dụng, trọng số và phương pháp lượng tử hoá, đây là suy luận của thời gian chạy, vì vậy, bạn có thể sử dụng một công cụ như llama.cpp hoặc Ollama hoặc LiteRT, khung vận hành tác nhân mà bạn đang sử dụng, cho dù đó là Pi hay OpenCode hay Antigravity, và sau đó là cửa sổ ngữ cảnh, đây là không gian cho tất cả dữ liệu mà bạn muốn mô hình của mình có thể xử lý.

Và sự kết hợp của tất cả những điều này sẽ quyết định liệu nó có khả thi hay không.

Để đưa ra một ví dụ nhanh, chúng tôi đã tiến hành một số thử nghiệm với Gemma 4 trên Android Bench và chạy một phiên bản Ollama với bối cảnh mặc định là 32k.

Chúng tôi nhận thấy rằng trong một trong các bài kiểm thử, khi tìm lỗi, quá trình nén khung vận hành tác nhân sẽ di chuyển tệp đó ra khỏi bộ nhớ, sau đó mô hình sẽ không thể hoàn thành nhiệm vụ và sẽ không thành công.

Vì vậy, chỉ bằng cách tăng bối cảnh từ 32.000 lên 256.000, giờ đây, mô hình có thể lưu giữ thông tin đó trong bộ nhớ và vượt qua bài kiểm tra cụ thể đó.

Và chúng tôi nhận thấy tỷ lệ thành công của công việc cụ thể đó đã tăng gấp đôi.

Vì vậy, chỉ cần một trong những yếu tố nhỏ này cũng có thể ảnh hưởng lớn đến việc mô hình này có phù hợp hay không.

Vậy làm cách nào để bạn tự đánh giá?

Sau đây là 3 đề xuất nhanh.

Một cách là bạn có thể lấy nhật ký Git, tức là một loạt yêu cầu kéo (PR) thành công mà bạn đã có, rồi dùng chúng làm dữ liệu đầu vào cho câu lệnh của mô hình và xem mô hình hoạt động hiệu quả như thế nào trên những dữ liệu đó.

Tiếp theo, bạn cần một công cụ chấm điểm tất định để giúp bạn đánh giá xem kết quả của mô hình có chính xác hay không.

Chúng tôi có hai ví dụ rất hay về điều đó.

Chúng ta có một trình biên dịch và các kiểm thử đơn vị.

Bất kể kết quả tạo ra là gì, bạn đều có thể chạy kết quả đó thông qua công cụ này và công cụ này sẽ cho bạn biết kết quả đạt/không đạt để biết bạn có thành công với nhiệm vụ cụ thể đó hay không.

Và thứ ba là quỹ đạo nhật ký.

Vì vậy, khi chạy một tác nhân, bạn muốn có thể theo dõi các hành vi khác nhau của tác nhân đó, xem tác nhân đó thành công ở đâu và thất bại ở đâu, đồng thời bạn có thể sử dụng thông tin đó để đánh giá mức độ tương tác và sử dụng công cụ của mô hình.

Và tôi muốn bạn thử thay đổi cách đặt câu hỏi, thay vì hỏi "Mô hình này có thông minh như mô hình tiên phong lớn này không?"

cho đến "Liệu có thể thực hiện nhiệm vụ này trên phần cứng này với cấu hình cụ thể này không?"

Để tìm hiểu điều đó, chúng tôi đã phát minh ra một khung có tên là "Chúng ta đã đến đó chưa?"

Hoặc AWTY.

Và nguyên tắc chung của khung này là chấm điểm tất cả các nhiệm vụ khác nhau này trên trục đó về mức độ sẵn sàng.

Đó là bản thân mô hình, công cụ suy luận mà bạn đang sử dụng, bộ điều khiển và sau đó là cấu hình phần cứng.

Và điều đó sẽ cho bạn biết liệu bạn đã sẵn sàng hay chưa.

Ví dụ: bạn có thể xem xét mức độ tin cậy của nhiệm vụ cụ thể đó.

Nếu bạn chạy 10 lần liên tiếp, thì kết quả mỗi lần có giống nhau không?

Có thể bạn đang xem xét độ trễ.

Có thể bạn cần câu trả lời theo thời gian thực.

Vậy, bạn biết đấy, ngưỡng tốc độ của bạn khi thực hiện nhiệm vụ là bao nhiêu?

Và sau đó, bạn có thể xem xét các yêu cầu về RAM.

Vì vậy, không chỉ là RAM mà thiết bị có, mà còn là RAM mà thiết bị – phần mà bạn có thể sử dụng, cũng như các ứng dụng và công cụ khác mà bạn cũng cần chạy trên phần cứng đó.

Vậy bạn có thể chiếm 50% hay chỉ chiếm 10% RAM?

Và bạn sẽ nhận được chỉ số sẵn sàng cuối cùng này.

Vì vậy, nếu cấu hình có màu xanh lục, thì tức là cấu hình đó đã sẵn sàng để sử dụng.

Nếu có màu cam, vàng hoặc đỏ, thì có thể bạn cần thay đổi cấu hình.

Có thể bạn cần một bộ tăng tốc nhanh hơn để có độ trễ thấp hơn, có thể bạn cần một mô hình lớn hơn và có nhiều khả năng hơn.

Vì vậy, bạn nên xem xét vấn đề này.

Chúng tôi hiện có một bản xem trước và rất mong nhận được ý kiến phản hồi của bạn về mức độ hữu ích của công cụ này.

Zoe sẽ trình bày thêm về cách chúng tôi thiết lập một số quy trình đánh giá sau, nhưng bây giờ tôi sẽ chuyển sang Jose, người sẽ hướng dẫn bạn cách nhanh chóng bắt đầu sử dụng Gemma 4.

Cảm ơn Ian.

Vì vậy, cách nhanh nhất để dùng thử Gemma 4 hiện nay có lẽ là thông qua Android Studio.

Hãy để tôi hướng dẫn bạn cách thực hiện.

Vui lòng chuyển sang máy tính xách tay.

Được rồi đó.

Vì vậy, nếu tôi truy cập vào trang nhà cung cấp mô hình trong phần cài đặt và chọn Gemma, bạn sẽ biết khá rõ về kích thước của từng mô hình.

Tôi chỉ cần tải các mô hình xuống ổ đĩa cứng của mình.

Vì vậy, thao tác này sẽ mở hoặc khởi động một máy chủ llama.cpp và máy chủ này được định cấu hình chính xác cho bạn ngay từ đầu.

Nhưng bạn cũng có thể sử dụng máy chủ llama.cpp của riêng mình hoặc Ollama hoặc LM Studio, tuỳ ý.

Để làm việc đó, bạn chỉ cần đến đây và thêm một nhà cung cấp địa phương.

Ngoài ra, việc sử dụng các mô hình nhỏ thông qua một nhà cung cấp từ xa cũng rất hợp lý.

Vì vậy, bạn có thể thêm một mô hình tại đây, miễn là mô hình đó tương thích với OpenAI hoặc Anthropic, bạn có thể kết nối với mô hình đó.

Được rồi, hãy cùng xem.

Giờ thì, à, nhân tiện, cách bạn chọn một mô hình trong Android Studio là thông qua trình đơn thả xuống này, tất nhiên rồi.

Vì vậy, tôi đã chọn Gemma 4 26B và có thể hỏi: "ViewModel là gì?"

Được rồi.

Vì vậy, một điều rất quan trọng bạn cần nhớ là bất cứ khi nào bạn thay đổi mô hình, toàn bộ cuộc trò chuyện sẽ được gửi lại cho mô hình mới ngay từ đầu.

Vì vậy, nếu bạn tạo một cuộc trò chuyện thực sự dài với một mô hình và muốn chuyển sang một mô hình mới, bạn nên bắt đầu một cuộc trò chuyện mới hoặc thu gọn cuộc trò chuyện đó, hoặc làm bất cứ điều gì khác.

Bây giờ, hãy quay lại trang trình bày và gặp Zoe để tìm hiểu về các quy trình công việc mà bạn có thể chạy bằng mô hình nhỏ.

Cảm ơn Jose và cảm ơn Ian rất nhiều vì đã cung cấp thông tin tổng quan về các mô hình Gemma và cho biết liệu chúng ta đã đạt được mục tiêu hay chưa.

Vậy là chúng ta đã tìm hiểu về các loại mô hình và thông số kỹ thuật của chúng. Giờ là lúc tìm hiểu về một số loại công việc mà bạn có thể giao cho các mô hình này.

Loại công việc đầu tiên mà có thể bạn đã làm là quy trình lập trình như gỡ lỗi hoặc khắc phục sự cố, hoặc một việc mà tôi chắc chắn rằng mọi người, hoặc ít nhất là tôi, sẽ rất nhớ khi làm thủ công, đó là tăng mức độ bao phủ của kiểm thử.

Đúng không?

Vì vậy, đây là một số điều mà tôi khá chắc chắn rằng mọi người đều đang làm, thậm chí có thể là không nhận ra.

Nhưng tôi muốn khuyến khích bạn, hoặc tôi muốn khuyến khích bạn nghĩ xa hơn thế, đúng không?

Vì vậy, khi xem xét rằng các mô hình nhỏ có thể có trọng số mở và chạy cục bộ, điều gì có thể giúp bạn tiết kiệm thời gian?

Đúng không?

Chúng ta đang nói về việc không sử dụng tên lửa, vậy tại sao chúng ta lại sử dụng bộ não cho việc đó?

Vậy nếu chúng ta có thể vượt qua giới hạn đó, thì các mô hình nhỏ có thể làm được những gì?

Bạn có thể áp dụng AI vào những quy trình làm việc nào để giúp cuộc sống của bạn dễ dàng hơn và giúp bạn có thêm thời gian để làm những việc mà bạn muốn làm nhiều hơn?

Ví dụ: đảm bảo tài liệu của bạn luôn được cập nhật theo những thay đổi bạn đã thực hiện, hoặc đảm bảo bạn có các bài kiểm thử hồi quy tự động trong một hook trước khi cam kết, hoặc thậm chí đảm bảo rằng bối cảnh mà tác nhân của bạn có thể nhận được trong quy trình làm việc được tối ưu hoá cho tác nhân đó và tác nhân đó hoạt động nhanh hơn nữa.

Đây là một số ví dụ, đúng không?

Và cuối cùng, ở một mức độ nào đó, không có giới hạn nào cả, hoặc kiến trúc là giới hạn, và có rất nhiều điều bạn có thể nghĩ đến về cách triển khai.

Nhưng khi đã có thông số kỹ thuật, công cụ và quy trình làm việc, bạn vẫn chưa biết nên bắt đầu từ đâu?

Đó là lý do chúng ta cần điểm chuẩn.

Và như Ian đã nói, một bảng xếp hạng chung, đặc biệt là bảng xếp hạng cho Python, sẽ cho bạn biết rất ít về việc liệu một mô hình nhỏ có hữu ích cho quy trình công việc của bạn trên Android hay không.

Cũng giống như việc máy khoan tường thạch cao có thể không cho bạn biết nhiều về máy khoan bê tông.

Tuy nhiên, bạn nên đầu tư vào các bản đánh giá của riêng mình.

Bạn nên đầu tư vào việc thử nghiệm kiến trúc của riêng mình, nhưng trước khi làm việc đó, bạn có thể không muốn dồn tất cả tài nguyên.

Việc này tốn thời gian, tiền bạc và công sức, vì vậy, việc xem xét các điểm chuẩn công khai có thể giúp bạn có ý tưởng và danh sách rút gọn trước khi quyết định đầu tư vào các bản đánh giá của riêng mình.

Và có 3 điều bạn nên xem xét mỗi khi đánh giá điểm chuẩn, đúng không?

Hơi trừu tượng một chút, nhưng về cơ bản, điều đầu tiên là loại nhiệm vụ mà mô hình này đang thực hiện là gì?

Mức độ cụ thể của nội dung.

Nó có giống với loại nhiệm vụ mà bạn sẽ giao cho nó không?

Thứ hai là phạm vi của nhiệm vụ.

Vậy, đó có phải là viết tài liệu, giải quyết PR hay một công việc tương tự như công việc của bạn không?

Và cuối cùng, độ phức tạp của hệ thống có tương đồng với độ phức tạp mà bạn sẽ đưa ra không?

Và đây là nơi chúng ta có thể thấy lý do tại sao điểm chuẩn Python sẽ không đại diện cho Android.

Đó là lý do chúng tôi xây dựng Android Bench, một điểm chuẩn ghi lại hệ sinh thái Android và công việc trên Android.

Phiên bản đầu tiên có 100 nhiệm vụ Android có quy mô PR và bạn có thể tự chạy phiên bản này ngay hôm nay thông qua Harbor để kiểm tra mọi tổ hợp tác nhân, mô hình và kỹ năng.

Chúng tôi ra mắt phiên bản 2.0 với các nhiệm vụ phức tạp và kéo dài hơn để hiểu rõ khả năng của các mô hình tiên phong trong những công việc như bạn giao cho mô hình hôm nay.

Bây giờ, tôi xin nhường lời cho Jose để giới thiệu cho bạn kết quả mà chúng tôi đạt được thông qua việc này và một số cách bạn có thể tối ưu hoá việc làm việc với các mô hình nhỏ.

Cảm ơn Zoe.

Được rồi, hãy cùng xem những nhiệm vụ mà một mô hình nhỏ có thể giải quyết và những nhiệm vụ mà mô hình đó bắt đầu gặp khó khăn.

Và chúng ta hãy tuỳ ý xác định 4 loại nhiệm vụ: nhỏ, vừa, lớn và có phạm vi kéo dài.

Nhiệm vụ có phạm vi kéo dài là những nhiệm vụ có thể khiến con người mất nhiều ngày hoặc nhiều tuần để hoàn thành.

Ví dụ: di chuyển, tái cấu trúc lớn, và xin tiết lộ trước là bạn không thể làm những việc đó bằng một mô hình nhỏ.

Ít nhất là trong một lần.

Chúng ta sẽ nói về việc đó sau.

Được rồi, việc nhỏ.

Đây là những công việc yêu cầu đọc và ghi có thể là một hoặc hai tệp và không yêu cầu nhiều kiến thức.

Ví dụ: các mô hình nhỏ khá giỏi về Compose, ít nhất là những kiến thức cơ bản về Compose.

Vì vậy, những điều như phải có 8 dp giữa các phần tử, hoặc sử dụng giao diện thay vì màu được mã hoá cứng, hoặc trích xuất chuỗi.

Đây là những việc rất dễ đối với một mô hình nhỏ.

Tuy nhiên, nhiệm vụ này đề cập đến một chủ đề nâng cao hơn, nhưng vẫn dễ thực hiện.

@Composable
 fun AnimatedDrawer() {
   val offsetX = remember { Animatable(0f) }
-  Box(modifier = Modifier.offset(x = offsetX.value.dp)) {}
+  Box(modifier = Modifier.graphicsLayer { translationX = offsetX.value }) {}
 }

Trong trường hợp này, khó khăn nằm ở phạm vi chứ không phải kiến thức.

Vì vậy, câu lệnh thực sự cho chúng ta biết composable nào cần tối ưu hoá và vấn đề của composable đó: composable đó đang recomposition trên mọi khung hình.

Vì vậy, việc này giúp công việc trở nên khá dễ dàng ngay cả đối với một mô hình nhỏ, chẳng hạn như Gemma 4.

Trong trường hợp này, việc này mất 3 phút và chỉ cần thay đổi một dòng.

Được rồi.

Vậy nên, tôi nghĩ chúng ta đã hiểu khá rõ về mô hình nhỏ.

Hãy xem xét một việc cần làm nhỏ.

Hãy cùng xem các nhiệm vụ có độ khó trung bình.

Các mô hình nhỏ có thể thực hiện hầu hết các tác vụ này.

Trong nhiệm vụ này, từ ứng dụng Pocket Casts, tác nhân người dùng bị thiếu trong một yêu cầu và cũng có lỗi trong logic thử lại.

Yêu cầu này khó hơn một chút vì trước tiên, chúng ta yêu cầu hai việc cùng một lúc và không có gợi ý nào về vị trí của những việc này trong toàn bộ mã nguồn.

Nhưng rồi cũng qua.

Quá trình này mất 10 phút.

Lệnh này đã sửa đổi 3 tệp.

Và nhân tiện, chi phí là 6 xu thông qua OpenRouter.

Bây giờ, hãy xem một nhiệm vụ không thành công trong cùng một tập dữ liệu.

Đây là ví dụ về Now in Android với một báo cáo hoặc câu lệnh khá toàn diện, nhưng không đề cập đến tên lớp hoặc tệp, vì vậy, tác nhân cần nỗ lực nhiều hơn để hiểu cấu trúc của ứng dụng, lớp dữ liệu, cơ chế đồng bộ hoá và trong trường hợp này, v.v. Vì vậy, trong lần chạy cụ thể này, tác nhân đã không thành công.

Mọi thứ đều được triển khai gần như chính xác, nhưng giả định rằng giá trị của lần đồng bộ hoá ban đầu sẽ là -1, nhưng thực tế là 0.

val isInitialSync = currentVersion == -1

val isInitialSync = currentVersion == 0

Vậy là xong.

Lỗi này sẽ được phát hiện nếu tác nhân chỉ chạy kiểm thử đơn vị, tức là các kiểm thử đơn vị hiện có.

Vì vậy, điều này cho thấy các mô hình nhỏ hơn, nói chung, có xu hướng dừng sớm hơn một chút so với các mô hình tiên phong.

Chúng tôi chỉ yêu cầu nhân viên hỗ trợ khắc phục vấn đề chứ không yêu cầu xác minh vấn đề.

Vì vậy, có thể chúng ta nên sửa đổi nhiệm vụ để nhiệm vụ đó có bước xác minh.

Chúng ta cũng sẽ nói về vấn đề đó sau ít phút nữa.

Giờ hãy cùng nói về những việc lớn.

Theo định nghĩa này, khoảng một nửa số nhiệm vụ lớn luôn vượt qua.

Một số câu lệnh không thành công thực ra quá dài và phức tạp đối với một mô hình nhỏ, nên không thể làm gì nhiều.

Nhưng có một số trường hợp khi xem xét những gì thực sự xảy ra, bạn nhận ra rằng mô hình đã đạt được 90 hoặc 90%.

Vậy nên, hãy chọn một trong số đó.

Tôi chọn bài kiểm thử này vì đây là một bài kiểm thử không ổn định.

Khoảng một nửa số lần chạy thử nghiệm này đều thành công.

Vì vậy, tôi cho rằng đây là giới hạn của một mô hình nhỏ.

Hoặc ít nhất là một mô hình từ tháng 4.

Đó là về việc phân tích cú pháp các URL không đúng định dạng trong thư viện Coil.

Như bạn có thể thấy, nội dung mô tả PR khá toàn diện, điều này rất tốt, nhưng thiếu một yêu cầu.

Hãy cùng xem nhanh nhé.

Tất cả các lần chạy đều kiểm tra các lỗi và mã hoá URL thông thường, nhưng chỉ một số, một nửa trong số đó, thêm các kiểm thử cho các ký tự được mã hoá không chính xác, vì vậy trường hợp kiểm thử đó.

Những người không vượt qua bài đánh giá.

Vì vậy, tất cả các lần chạy đều gần như hoàn hảo, nhưng điều này một lần nữa cho thấy rằng các mô hình nhỏ không phải lúc nào cũng thực hiện thêm bước này.

Chúng làm theo hướng dẫn nhưng không cố gắng gây ấn tượng với bạn như các mô hình tiên phong.

Bạn có biết cách thiết lập mức độ nỗ lực cho một tác nhân không?

Chỉ cần lưu ý rằng giá trị này được đặt quá thấp khi bạn sử dụng một mô hình nhỏ.

Vì vậy, hãy định nghĩa nhiệm vụ lớn là những nhiệm vụ mà các mô hình nhỏ có thể hoàn thành khoảng 50% thời gian, đây là mức mà Gemma 4 31B có thể đạt được so với tập dữ liệu Android Bench phiên bản 1, như Zoe đã đề cập trước đó.

Vậy trước khi nói về các nhiệm vụ có phạm vi kéo dài, chúng ta có thể làm gì để giúp các mô hình nhỏ thực hiện những nhiệm vụ đó không?

Chắc chắn rồi, và bạn không cần tốn chút công sức nào để làm những việc này.

Trước tiên, nếu bạn sử dụng một mô hình như Gemma 4 trên thiết bị như Ian đã đề cập, hãy đảm bảo rằng mô hình đó được định cấu hình chính xác.

Ví dụ: nếu bạn sử dụng Ollama để phân phát Gemma 4, thì theo mặc định, cửa sổ ngữ cảnh sẽ là 32.000 token, trong khi thực tế mô hình này hỗ trợ gấp 8 lần con số đó.

Tất nhiên, nếu sử dụng Gemma 4 thông qua Android Studio, bạn không cần phải định cấu hình.

Theo mặc định, tệp này được định cấu hình chính xác.

Trong bộ đánh giá của chúng tôi, việc bật toàn bộ bối cảnh đã giúp kết quả tăng từ 26% lên 53%.

Tiếp theo, hãy sử dụng Android CLI, công cụ Android CLI, đặc biệt là để tìm kiếm tài liệu.

Điều này không phải lúc nào cũng đúng vì các mô hình khá giỏi về những kiến thức cơ bản, nhưng bất cứ khi nào bạn sử dụng một API mới hoặc chuyên biệt, thì việc có tài liệu là yếu tố then chốt.

Theo kinh nghiệm của chúng tôi, cách này hiệu quả hơn nhiều so với việc sử dụng các công cụ tìm kiếm trên web.

Tiếp theo, hãy thêm gợi ý xác minh.

Chúng ta đã nói về việc này rồi.

Hãy cho mô hình biết cách chạy kiểm thử, loại kiểm thử nào có sẵn, cách quản lý trình mô phỏng, v.v. Bạn có thể thực hiện việc này trong tệp AGENTS.md, tệp này sẽ cung cấp hướng dẫn cho tất cả tác nhân, nhưng dù sao thì đó cũng là một điều tốt.

Bạn nên có.

Nhưng cũng cần chú ý đến các tệp AGENTS.md siêu dài, vì nếu thử các tác nhân khác nhau, bạn sẽ thấy một số tác nhân có câu lệnh hệ thống và nội dung mô tả công cụ rất dài, và có vẻ như chúng làm giảm hiệu suất của các mô hình nhỏ.

Chúng tôi thực sự đã thử chạy các điểm chuẩn này bằng OpenCode và hiệu suất của nó thấp hơn nhiều so với pi, có thể là do nó sử dụng nội dung mô tả công cụ và câu lệnh hệ thống lớn hơn.

Tiếp theo, hãy thêm kỹ năng, nhưng cũng xoá kỹ năng.

Các mô hình nhỏ có thể cần được gợi ý khi sử dụng các API mới và chuyên biệt, nhưng tốt hơn là không nên cung cấp cho các mô hình này những kỹ năng Compose chung chung.

Vậy còn các nhiệm vụ có phạm vi kéo dài thì sao?

Đó là những nhiệm vụ trải dài trên hàng chục tệp, đòi hỏi những quyết định quan trọng về cấu trúc và thường được xử lý bằng một mô hình tư duy. Mô hình này sẽ lập kế hoạch và khởi động một nhóm tác nhân phụ để thực thi các nhiệm vụ khác nhau.

Ví dụ về các nhiệm vụ có phạm vi kéo dài là di chuyển toàn bộ ứng dụng từ XML sang Compose, tạo một ứng dụng phức tạp từ đầu hoặc chuyển đổi ứng dụng nhiều nền tảng sang ứng dụng Android gốc.

Nếu xem xét kết quả từ Android Bench phiên bản 2 (tập trung hoàn toàn vào các tác vụ có phạm vi kéo dài), chúng ta sẽ thấy các mô hình tiên phong đạt điểm từ 3% đến 40%.

Vì vậy, đối với các mô hình nhỏ, tôi nghĩ có thể nói rằng việc này nằm ngoài khả năng của chúng.

Tuy nhiên, việc định tuyến phân tích ban đầu thông qua một mô hình tiên phong, sau đó phân tầng các tác vụ đơn giản hơn cho các mô hình nhỏ hơn sẽ giúp tiết kiệm mã thông báo và tín dụng hơn nhiều.

Hãy xem cách thực hiện.

Quay lại với Zoe.

Cảm ơn Jose rất nhiều!

Chúng ta sẽ tìm hiểu về mô hình xếp tầng, nhưng trước khi tôi giới thiệu một số cách hoặc trước khi chúng ta tìm hiểu sâu hơn về vấn đề này, tôi muốn lùi lại một bước và giới thiệu cho bạn những cách khác mà việc điều phối các mô hình khác nhau có thể giúp ích cho bạn.

Vì vậy, việc điều phối có thể giúp bạn không bao giờ bị chặn, đúng không?

Vì vậy, cho dù bạn thấy một nhà cung cấp ngừng hoạt động, hay bạn đạt đến giới hạn tốc độ API, hay bạn đang ở trên máy bay hoặc tàu hoả, như Ian đã nói, bạn có thể thiết lập một mô hình dự phòng và đảm bảo rằng cho dù là trực tuyến hay cục bộ, bạn vẫn có thể tiếp tục nếu có bất cứ điều gì xảy ra.

Một việc khác mà bạn có thể làm thông qua quy trình điều phối là nhận được câu trả lời chính xác hơn.

Ví dụ: bạn có thể để một mô hình nhỏ tự hoạt động và gọi một cố vấn bất cứ khi nào cần hỗ trợ một chút để nhận được sự trợ giúp đó.

Bạn cũng có thể thiết lập một hội đồng trong đó các loại mô hình khác nhau hoặc các mô hình khác nhau đều thực hiện cùng một nhiệm vụ cùng một lúc, sau đó bạn có thể đánh giá các phản hồi khác nhau và mức độ ảnh hưởng của trọng số và độ lệch của từng mô hình đến kết quả.

Bạn cũng có thể sử dụng một mô hình riêng biệt làm mô hình kiểm thử.

Vì vậy, nó giống như một bài đánh giá ngang hàng.

Và bạn có thể thấy điều đó qua biểu đồ này.

Nhưng tất nhiên, cuối cùng, việc điều phối có thể giúp bạn tiết kiệm chi phí thông qua một quy trình như thác nước.

Về cơ bản, bạn có thể thiết lập mô hình theo cách thủ công, vì vậy, bạn có thể đặt một mô hình để lập kế hoạch, một mô hình khác để thực thi và một mô hình khác để kiểm thử.

Có nhiều cách để thực hiện việc này, trên đám mây hoặc bạn có thể thiết lập proxy LiteLLM để thực hiện việc này trên máy.

Hoặc bạn có thể chỉ cần sử dụng một thuật toán phân loại để tự động định tuyến đến đúng loại mô hình dựa trên yêu cầu, đây là ý tưởng proxy mà Ian đã đề cập, nhưng tự động.

Vậy nên, hãy kết thúc bằng cách quay lại câu hỏi mà Jose đã đặt ra ở đầu buổi nói chuyện, đó là: Sự khác biệt về chất lượng và độ chính xác giữa mô hình nhỏ và mô hình tiên phong là gì?

Và câu trả lời cũng giống như nhiều vấn đề khác trong khoa học máy tính, đó là tuỳ trường hợp.

Tuy nhiên, đây là điều mà tôi Bạn biết đấy, tôi muốn nhắc lại với bạn rằng đây là điều bạn có thể thiết kế.

Đây là điều mà bạn có thể tạo ra sự khác biệt, tuỳ thuộc vào cách bạn thiết lập và cách bạn chơi với các quân cờ.

Vì vậy, phần đầu tiên ở đây là chọn công cụ phù hợp, đúng không?

Có nhiều loại công cụ.

Tìm hiểu và khám phá chúng, đúng không?

Sau đó, tìm hiểu xem họ phù hợp với công việc nào hoặc thậm chí là họ có thể làm công việc nào.

Thứ hai, hãy nhớ điều chỉnh phạm vi mà mô hình đang nhận được để thực hiện công việc.

Ví dụ: những thông tin như hướng dẫn cho nhiệm vụ, thông tin như cung cấp bối cảnh phù hợp cho nhiệm vụ và chỉ bối cảnh phù hợp cho nhiệm vụ, cũng như cách kiểm tra kết quả của chính nhiệm vụ đó.

Sau đó, tất nhiên, bạn cần đặt-- kiểm thử toàn bộ quá trình thiết lập chứ không chỉ riêng mô hình, vì điều này sẽ tạo ra sự khác biệt và có thể kết quả bạn nhận được có thể được điều chỉnh nếu bạn thiết lập mô hình đó, giả sử là một cấu hình khác của các phần tử.

Và cuối cùng, bạn cần thiết lập hoặc tạo các bản đánh giá của riêng mình.

Cuối cùng, bạn có thể kết hợp xe đạp và tên lửa để không bao giờ phải lựa chọn giữa hai phương tiện này và chi tiêu hiệu quả.

Nhưng quan trọng nhất là bạn có thể tiếp tục khám phá, tiếp tục xây dựng và tiếp tục tận hưởng niềm vui, đúng không?

Bạn có thể bắt đầu ngay hôm nay bằng cách lập danh sách rút gọn các mô hình thông qua Android Bench và những thông tin bạn tìm thấy ở đó, hoặc bắt đầu với Gemma 4 trên Android Studio ngay hôm nay.

Cảm ơn các bạn rất nhiều!