- GitHub đặt tầm nhìn phát triển AI xoay quanh việc trao quyền cho nhà phát triển, duy trì họ "in flow" và tăng tốc độ làm việc của đội ngũ bằng các công cụ hiệu quả, đáng tin cậy ở quy mô lớn. Mọi quyết định về sản phẩm đều dựa trên các trụ cột này.
- Việc vận hành các mô hình AI lớn như Copilot yêu cầu tối ưu hóa chi phí và hiệu suất nghiêm ngặt, với "bộ nhớ đệm lời nhắc" (prompt caching) là yếu tố then chốt, mang lại lợi ích hàng triệu đô la chỉ với 1% cải thiện hiệu suất.
- Chiến lược "mô hình cố vấn" (advisor model) kết hợp các mô hình nhỏ hơn (Hikou) với mô hình thông minh hơn (Opus) giúp đạt được trí tuệ cấp cao với chi phí thấp hơn đáng kể, bằng cách chỉ gọi mô hình lớn khi thực sự cần thiết.
Caching, harnesses, and advisors: Building on Claude at GitHub scale
- Ưu tiên Bộ nhớ Đệm Lời Nhắc (Prompt Caching): Đây là yếu tố sống còn để vận hành các dịch vụ suy luận AI ở quy mô lớn và tiết kiệm chi phí. Mục tiêu là đạt tỷ lệ bộ đệm trên 94%.
- Tối ưu hóa Cấu trúc Lời Nhắc: Đảm bảo
tiền tố(prefix) vàlời nhắc hệ thống(system prompt) làtĩnh(static) nhất có thể, tránhnội dung độngnhư UUID để không làmvô hiệu hóa bộ đệmliên tục. - Quản lý
Công cụ(Tools) Cẩn thận: Tránhtải động các công cụhoặc thay đổitiền tố công cụtrong quá trìnhcuộc hội thoại, vì điều này cũng dẫn đếnvô hiệu hóa bộ đệmtoàn bộ. Cần cókiểm thử hồi quychokỹ năngvàcông cụ. - Đảm bảo
Tính Liên Kết Bộ Đệm(Cache Affinity) quaĐa Kênh: Đối với các hệ thốngđa kênh(ví dụ: Copilot gọi nhiều mô hình khác nhau), phải làm việc để đảm bảo cáclời gọiliên tiếp tới cùng một mô hình vẫn duy trìtính liên kết bộ đệm. - Sử dụng
Cửa Sổ Ngữ Cảnh(Context Window) Dài một cách Thông minh:Cửa sổ ngữ cảnhdài hơn không nhất thiết có nghĩa làchi phícao hơn. Việcnén/thu gọn(compaction) quá mức có thể làm tăngmã thông báo đầu ravà làm giảmtỷ lệ bộ đệm, dẫn đếnchi phícao hơn.Quản lýnén/thu gọnphù hợp vớikịch bảnsử dụng. - Triển khai
Bảng Điều KhiểnvàPhân Tích Delta:Cài đặt(instrument) đểđo lườngtỷ lệ bộ đệmvàhiệu suất mô hìnhtrên cácbề mặt(surface) khác nhau (VS Code, CLI, mobile, v.v.). Thực hiệnphân tích deltatrước và sau khi ra mắt mô hìnhmới để đánh giácải thiệnhoặcthụt lùi. - Áp dụng
Mô Hình Cố Vấn(Advisor Model): Sử dụngmô hìnhnhỏ hơn (người thực thi) để xử lý hầu hết các tác vụ và chỉgọimô hìnhlớn hơn (cố vấn) cho những trường hợp phức tạp, giúp giảmchi phívàđộ trễđáng kể trong khi vẫn duy trì chất lượngtrí thông minh.
in flow— trạng thái làm việc liền mạch, tập trungvelocity— tốc độ phát triển/hoàn thành công việcprompt caching— bộ nhớ đệm lời nhắccache hit ratios— tỷ lệ truy cập bộ đệm thành côngadvisor model— mô hình cố vấnexecutor model— mô hình thực thicontext window— cửa sổ ngữ cảnhcompaction— nén/thu gọn (ngữ cảnh)input tokens— mã thông báo đầu vàooutput tokens— mã thông báo đầu racache affinity— tính liên kết bộ đệmdynamic content— nội dung độngsystem prompt— lời nhắc hệ thốngregression tests— kiểm thử hồi quydelta analysis— phân tích chênh lệch/delta
Lời giới thiệu từ GitHub và Tầm nhìn Phát triển
Xin mời chào đón Giám đốc Sản phẩm của GitHub, Mario Rodriguez, lên sân khấu. Xin chào tất cả mọi người. Rất vui được trở lại. Tôi lập trình với Claude Code. Tôi yêu các hội nghị dành cho nhà phát triển. Chúng hơi lộn xộn, nhưng đầy sôi động. Chúng vẫn ưu tiên nhà phát triển, không phải ưu tiên tác nhân. Và đây là điều chúng ta đã có niềm vui khi làm. Chúng ta ở đây để vui vẻ và học hỏi cùng nhau.
Các bạn ở đây vì muốn tìm hiểu thêm về nền tảng. Và tôi ở đây để chia sẻ với các bạn một số điều quan trọng nhất mà chúng tôi đã làm để vận hành Copilot và tất cả các suy luận của chúng tôi trên nền tảng này. Tôi muốn bắt đầu bằng lý do. Tôi đã trình bày một phần rất tập trung vào sứ mệnh. Tầm nhìn của chúng tôi là trao quyền cho các nhà phát triển, cung cấp những công cụ tốt nhất hiện có để thúc đẩy tiến bộ của con người. Nhưng khi tôi nói chuyện với khách hàng nói chung, tôi đang nói với họ về điều họ muốn đạt được. Họ muốn đạt được một tập hợp các kết quả. Và đối với họ, họ muốn giữ cho đội ngũ của mình in flow. Họ muốn giữ cho các nhà phát triển in flow. Họ muốn các nhóm của họ tăng velocity. Họ muốn các nhóm thực sự đạt được nhiều hơn với những người mà họ có. Và họ muốn làm điều này ở quy mô. Để có thể làm được ở quy mô, bạn phải có hiệu suất và bạn cũng phải có sự tin cậy. Tôi bắt đầu với điều này bởi vì hầu hết mọi quyết định về sản phẩm mà tôi đưa ra đều dựa trên những trụ cột này. Ngay cả khi chúng tôi nói về nền tảng và tích hợp với nền tảng đám mây của chúng tôi, tôi muốn đảm bảo rằng tôi giữ cho các nhà phát triển in flow. Tôi muốn đảm bảo các nhóm đạt được velocity đó. Và tôi muốn đảm bảo các công ty có thể làm điều đó với trí thông minh và sự tin cậy.
Vận hành Nền tảng và Bài học chính
Khi tôi suy nghĩ về tương lai, tôi đã nghĩ rất kỹ: Tôi muốn nói điều gì ở đây? Nếu tôi đang ngồi ở đó, điều tôi muốn hiểu là: "Được rồi, bạn vận hành như thế nào?". Chúng tôi xử lý hàng tỷ, có lẽ qua một khoảng thời gian đủ lớn, hàng nghìn tỷ tin nhắn gửi đến nền tảng. Vì vậy, tôi muốn cung cấp cho bạn những phương pháp tốt nhất, hoặc thậm chí không phải phương pháp tốt nhất vì mọi thứ thay đổi rất thường xuyên, gần như hàng tuần. Nhưng đó là những bài học chính, những điều nằm sâu dưới đáy của hầu hết các quyết định mà chúng tôi đưa ra để có thể tích hợp với nền tảng và đạt được quy mô và hiệu suất cần thiết.
Vì vậy, tôi muốn chia nó thành ba điều. Đầu tiên là bộ nhớ đệm lời nhắc (prompt caching). Nếu không có nó, chúng tôi không chết, nhưng ôi trời ơi! Lượng chi phí chúng tôi bỏ ra so với những gì chúng tôi làm thật đáng kinh ngạc, phải không? Vì vậy, chỉ cần 1% hiệu suất trong lĩnh vực này có ý nghĩa rất lớn đối với chúng tôi. Nó giống như giao dịch tần số cao (high frequency trading). 1% hiệu suất có nghĩa là hàng triệu đô la nói chung. Vì vậy, tôi chỉ muốn dành thêm một chút thời gian để nói về cách chúng tôi thực hiện điều đó.
Điều thứ hai là chúng tôi đang hợp tác với Anthropic về các khả năng để đảm bảo khách hàng của chúng tôi đang sử dụng suy luận đúng (right inference), lượng trí thông minh đúng (right amount of intelligence) vào đúng thời điểm (right time). Và một trong số đó là mô hình cố vấn này. Chúng tôi có hai cách nhìn nhận nó, thông qua cả cố vấn và nhà phê bình. Vì vậy, Brad và tôi cũng sẽ chia sẻ thêm một chút về điều đó.
Và điều thứ ba là mỗi khi một mô hình mới ra mắt, và nếu bạn đang tích hợp với nền tảng, bạn biết điều này xảy ra liên tục, và bạn nhận được một cuộc gọi vào 5 giờ sáng thứ Bảy rằng: "Này, chúng ta sẽ ra mắt vào thứ Ba". Vậy làm thế nào để chúng ta thực sự thực hiện điều đó đúng cách? Làm thế nào để chúng ta đưa ra các quyết định như mô hình mặc định nào để giữ cho các nhà phát triển in flow? Làm thế nào để chúng ta đưa ra các quyết định để thực sự định tuyến (route) đến trí thông minh đúng (right intelligence) vào đúng thời điểm (right time) nói chung?
Tối ưu hóa Bộ nhớ Đệm Lời Nhắc và Hiệu suất Mô hình
Tôi sẽ bắt đầu với điều này. Và đây là một bảng điều khiển (dashboard). Đây không phải bảng điều khiển của chúng tôi, nhưng nếu bạn đang sử dụng nền tảng, tôi tin rằng Anthropic đã phát hành nó vào tuần trước, chúng tôi đã có một bản xem trước nhỏ về nó. Và điều nó cho phép bạn hiểu là bạn đang hoạt động như thế nào, ví dụ như tỷ lệ lượt truy cập bộ đệm (cache hit ratios) của bạn, số lượng tin nhắn bạn đang gửi, đối với API tin nhắn, phải không? Và tôi nghĩ điều này rất tuyệt. Đây là bước đầu tiên vì không có dữ liệu thì rất, rất khó để đưa ra quyết định, rất, rất khó. Vì vậy, nếu bạn chưa kiểm tra, hãy làm điều đó.
Bây giờ, điều tôi muốn dành thêm một chút thời gian là của chúng tôi. Và đây chỉ là một cái nhìn. Đây không phải là toàn bộ các bảng điều khiển mà chúng tôi có. Nhưng đây là nơi chúng tôi xem xét sự khác biệt giữa các mô hình. Trong trường hợp này, tôi muốn bạn chủ yếu nhìn vào phía bên trái là Opus 4.6. Và sau đó ở bên phải là 4.7. Và sau đó là góc tiếp theo liệt kê sự khác biệt giữa chúng. Vì vậy, khi một mô hình mới ra mắt, và đôi khi chúng tôi nhận được nó trong EAP (Early Access Program), chúng tôi tiến hành chạy một tập hợp các điểm chuẩn (benchmarks) chống lại nó. Vì vậy, hãy nghĩ về điểm chuẩn terminal benchmark 2. Và sau đó hoặc một trong các bộ, chúng tôi cũng có những bộ của riêng mình. Và sau đó chúng tôi cố gắng quyết định, "Được rồi, mô hình đang hoạt động như thế nào?". Và sau đó chúng tôi triển khai (ship) nó và sau đó chúng tôi chú ý đến dữ liệu đó một lần nữa. Và sau một khoảng thời gian có lẽ 30 ngày, chúng tôi có lẽ đã hoàn thành (done), hoặc đôi khi thậm chí sớm hơn, chúng tôi hoàn thành tất cả các tối ưu hóa cho mô hình đó.
Bây giờ bạn có thể thấy ở đây, loại mã thông báo bộ đệm (cache tokens) trung bình, và cuối cùng, tỷ lệ bộ đệm (cache rate). Để chúng tôi vận hành dịch vụ ở quy mô, chúng tôi cần chạy trên 94%, thường là 94, 95, 96%. Nếu chúng tôi hoạt động ở mức 70%, điều đó thường có nghĩa là chúng tôi có một lỗi (bug), tin hay không thì tùy. Giống như chúng tôi đang làm điều gì đó không đúng. Và sau đó chúng tôi cần thay đổi cách tiếp cận về cách chúng tôi gọi mô hình, cách chúng tôi tập hợp lời nhắc (assembling the prompt), cách chúng tôi thực hiện end-to-end để giữ cho nhà phát triển in flow. Vì vậy, chúng tôi chú ý đến điều đó. Tương tự, nếu tôi muốn thực sự thay đổi tỷ lệ bộ đệm từ, tôi xin lỗi, thay đổi mô hình mặc định từ 4.6 sang 4.7, tôi cần hiểu sự khác biệt về tỷ lệ bộ đệm. Và điều đó thực sự có ý nghĩa gì đối với tôi, một lần nữa, chúng tôi thực hiện hàng tỷ và hàng tỷ lời gọi (calls) nói chung. Vì vậy, chỉ 1% trong đó, trong trường hợp này, là 1.3%, có ý nghĩa rất lớn đối với chúng tôi.
Bây giờ bạn cũng phải tính đến rằng từ góc độ đầu vào, tỷ lệ bộ đệm của bạn chỉ là 10% chi phí, phải không? Vì vậy, có một sự khác biệt 10 lần ở đó. Vì vậy, bạn liên tục vô hiệu hóa bộ đệm (invalidating that cache). Đó không phải là một điều tốt, vì bạn sẽ phải trả chi phí cao hơn 10 lần. Và sau đó chúng tôi xem xét điều đó. Trong trường hợp này, chúng tôi đã đặt một đường cơ sở (baseline) chống lại 4.6 và sau đó cũng trên high queue. Bây giờ hãy tưởng tượng nó giữ nguyên như thế này trong giây lát và có rất nhiều màu đỏ như bạn có thể thấy trên màn hình này nói chung. Sau đó, chúng tôi có một quyết định phải đưa ra. Chúng tôi phải đưa ra quyết định để tìm cách biến tất cả những màu đỏ đó thành màu xanh lá cây. Và đó không phải là may mắn, đó là rất nhiều công việc khó khăn. Và tôi muốn đảm bảo bạn hiểu điều đó. Đó là rất nhiều công việc khó khăn để đạt được, có thể từ 50% lên 70% không phải vì bạn chỉ đang hái quả thấp (easy hunting fruit). Nhưng từ 70% lên 80%, từ 80% lên 90% và 90% trở lên, có rất nhiều công việc khó khăn được đầu tư vào điều này, về kỹ thuật.
Bài học về Tối ưu hóa Bộ nhớ Đệm
Và có ba điều chúng tôi xem xét. Điều đầu tiên là, chúng tôi đảm bảo rằng không có, và đây là những bài học kinh nghiệm. Chúng tôi đã mắc những sai lầm này trước đây và đó là lý do tại sao tôi muốn chia sẻ với bạn. Chúng tôi không đặt nội dung động (dynamic content) nào vào tiền tố (prefix), phải không? Bạn cần giữ tiền tố đó tĩnh (static) nhất có thể. Và làm ví dụ, tại một thời điểm, chúng tôi có UUID trong lời nhắc hệ thống (system prompt) thực tế. Và sau đó chúng tôi liên tục bị đặt lại (reset) và điều đó đã vô hiệu hóa toàn bộ tỷ lệ bộ đệm. Vì vậy, hãy nhớ, hệ thống (system), sau đó là công cụ (tools), sau đó là cuộc hội thoại (conversation), và sau đó là tin nhắn cuối cùng (last message) bạn đang gửi. Đó là loại hệ thống phân cấp. Vì vậy, bạn muốn giữ lời nhắc hệ thống đó ổn định nhất có thể, không có nội dung động nào trên đó.
Sau đó là công cụ (tools). Đôi khi chúng tôi đã mắc rất nhiều sai lầm trong công cụ. Nếu bạn đang tải động các công cụ (loading tools dynamically) và bạn đang thay đổi tiền tố công cụ (tool's prefix) đó, thì đột nhiên, mọi thứ, toàn bộ cuộc hội thoại, lại bị vô hiệu hóa (invalidated) một lần nữa. Vì vậy, bạn phải làm việc và bạn phải đảm bảo bạn có nhiều kiểm thử hồi quy (regression tests) vì bạn sẽ thử nghiệm với cái gì? Kỹ năng (skills) và công cụ (tools) nói chung trong end-to-end của bạn, bạn phải có kiểm thử hồi quy để đảm bảo bạn không ảnh hưởng đến công cụ của mình.
Sau đó, điều thứ ba nói chung là chúng ta cần có tính liên kết bộ đệm (cache affinity) đó. Và tôi phải nói với bạn, điều đó thực sự khó khăn khi bạn đang thực hiện đa kênh (multi-modal harness). Vì vậy, lấy ví dụ, Copilot. Khách hàng có thể gọi Opus, sau đó gọi mô hình GPT, và sau đó đến mô hình OSS và sau đó quay lại Opus một lần nữa. Và sau tất cả những điều đó, tôi phải đảm bảo rằng lời gọi Opus tiếp theo, lời gọi cuối cùng đã xảy ra, thực sự có tính liên kết bộ đệm đúng. Vì vậy, chúng tôi làm rất nhiều việc khi nói đến đa kênh của mình để đảm bảo điều đó được đảm bảo.
Cửa sổ Ngữ cảnh Lớn và Chi phí
Đây là một ví dụ về điều mà chúng tôi cũng đã chạy trong bonken mesh. Một trong những điều quan trọng mà tôi nghe nhiều lần, thực ra khi tôi đến gặp khách hàng và họ hỏi tôi về việc tích hợp với nền tảng, là, "Này, ngữ cảnh dài (long context) có nghĩa là nó đắt hơn." Và câu trả lời đối với chúng tôi là không. Và đây là một thử nghiệm nhanh mà chúng tôi đã thực hiện. Vì vậy, có một cửa sổ ngữ cảnh (context window) nhỏ hơn. Và bạn có thể thấy ở đó rằng nén/thu gọn (compaction) trung bình của tôi đã tăng gấp ba lần, so với cửa sổ ngữ cảnh lớn hơn. Đây là điều chúng tôi đã mô phỏng. Chúng tôi giữ cùng một mô hình với cùng một cửa sổ ngữ cảnh. Chúng tôi chỉ thực hiện nhiều nén/thu gọn hơn trên đó và điền nó với một tỷ lệ.
Bây giờ điều quan trọng ở đây, nếu bạn nhớ phép tính về số lượng mã thông báo đầu vào và đầu ra và những gì đang xảy ra là 5 lần, phải không? Vì vậy, đối với Opus, ví dụ, nó sẽ là 5.25 đô la. Trong trường hợp đó, bất cứ khi nào bạn thực hiện nén/thu gọn, bạn nhận được 4.000 mã thông báo đầu ra. Và sau đó bạn có, vì bạn phải tóm tắt tin nhắn, v.v. Vì vậy, bất cứ khi nào điều đó xảy ra, bạn thường phải trả nhiều hơn, bởi vì bạn thực hiện nhiều nén/thu gọn hơn, điều đó có nghĩa là mã thông báo đầu ra của bạn tăng vọt. Và sau đó tỷ lệ bộ đệm của bạn cũng bị vô hiệu hóa nhiều hơn vì điều đó. Chà, bị vô hiệu hóa đáng kể vì điều đó nữa. Vì vậy, cửa sổ ngữ cảnh dài hơn không có nghĩa là bạn chi tiêu nhiều hơn. Thực tế, điều bạn phải hiểu là nén/thu gọn đang được thực hiện như thế nào. Và tùy thuộc vào kịch bản, bạn muốn quản lý điều đó cho người dùng một cách thích hợp.
Tóm tắt Thực hành Tối ưu hóa Bộ nhớ Đệm
Ở cấp độ cao, hãy cài đặt (instrument) tỷ lệ bộ đệm của bạn, có một bảng điều khiển thực sự hiển thị nó cho bạn. Dành thời gian để làm điều đó. Họ đã cung cấp một cái cho bạn, vì vậy ít nhất hãy sử dụng cái đó. Nhưng hãy đầu tư vào phân tích delta, hãy đầu tư vào trước khi ra mắt mô hình và sau khi ra mắt mô hình nữa.
Bây giờ, không có hiệu suất nào khác quan trọng cho đến khi bạn thấy điều đó một lần nữa. Bạn muốn thúc đẩy điều đó từ 50, 70, 90 nói chung, và nó sẽ đòi hỏi rất nhiều công việc khó khăn, rất nhiều thời gian kỹ thuật. Và sau đó bạn muốn đo lường theo từng bề mặt (per surface). Chúng tôi có VS Code, là một trong những bảng điều khiển mà chúng tôi đã hiển thị cho bạn ở đó. Nhưng chúng tôi cũng có CLI Copilot. Chúng tôi cũng có tác nhân mã hóa (coding agent) của chúng tôi trong đám mây. Chúng tôi cũng có IntelliJ và chúng tôi cũng có di động. Vì vậy, có rất nhiều bề mặt mà bạn sẽ phải đi và hiểu, hoặc là chia sẻ sự khó khăn (hardness) giữa chúng, hoặc sau đó điều chỉnh (tweak) riêng lẻ. Vì vậy, bạn muốn có một ý thức rất tốt về việc chúng tôi triển khai một cái gì đó, chúng tôi thụt lùi (regress) hay không, chúng tôi triển khai một cái gì đó, chúng tôi cải thiện (improved) hay không.
Trí thông minh phù hợp vào đúng thời điểm: Mô hình Cố vấn
Một điều khác mà tôi đã nói với bạn là, được rồi, nếu bạn đã thực hiện bộ nhớ đệm lời nhắc, thì làm thế nào để đảm bảo rằng trí thông minh (intelligence) được viết là người dùng vào đúng thời điểm? Và vì điều đó, Anthropic và chúng tôi đã hợp tác trên mô hình cố vấn này. Và điều tôi muốn làm là mời Brad Adams từ nhóm Anthropic đến để nói thêm về nó. Mời Brad.
Cảm ơn Mario đã có mặt ở đây. Thật tuyệt vời khi có một đối tác như GitHub Copilot. Chúng tôi nhận được phản hồi rất tốt từ nhóm Copilot. Chúng tôi cho họ rất ít thời gian để đánh giá các mô hình trước khi chúng tôi ra mắt và họ đưa ra phản hồi tuyệt vời và sâu sắc. Và điều đó cũng đúng với các tính năng API của chúng tôi. Thực tế, nếu bạn đang sử dụng nền tảng Claude, rất nhiều điều bạn đang thấy là nhờ những gì Mario và nhóm của anh ấy đang làm trên Copilot. Và đó thực sự là một trong những phản hồi mà tôi muốn nói đến ngày hôm nay.
Chiến lược Cố vấn: Opus và Hikou
Một trong những phản hồi chúng tôi nhận được từ đội ngũ Copilot là họ thực sự muốn có trí thông minh ở cấp độ Opus, nhưng với mức giá ở cấp độ Hikou. Điều đó nghe có vẻ hấp dẫn phải không? Trí thông minh Opus. Tôi không trực tiếp tham gia vào các thỏa thuận, nhưng tôi được xây dựng các tính năng API thú vị. Vì vậy, tôi muốn nói về chiến lược cố vấn.
Sự hiểu biết sâu sắc về chiến lược cố vấn thực sự đến từ các đội ngũ phát triển phần mềm. Chúng ta đều biết rằng nếu bạn giao cho một kỹ sư mới vào nghề (junior engineer) một người hướng dẫn là kỹ sư cấp cao (senior engineer), kỹ sư mới vào nghề đó sẽ tiến bộ rất nhiều. Bởi vì kỹ sư cấp cao sẽ theo dõi công việc của họ, họ cùng nhau đánh giá mã, xem xét tài liệu thiết kế (design docs), kỹ sư cấp cao có thể giúp kỹ sư mới vào nghề năng suất hơn nhiều mà không tốn quá nhiều thời gian của mình.
Và hóa ra điều tương tự cũng đúng với các mô hình. Bạn có thể sử dụng một mô hình "mới vào nghề" như Hikou—mà chúng tôi gọi ở đây là người thực thi (executor)—và cấp cho nó quyền truy cập vào Opus, đồng thời bạn có thể sử dụng các token của Opus một cách rất tiết kiệm. Trong biểu đồ tuyệt đẹp mà Claude đã tạo cho tôi, bạn có thể thấy rằng người thực thi, Hikou, có khả năng nhận diện mọi hình dạng khi chúng xuất hiện mà không gặp vấn đề gì, ngoại trừ một hình dạng nhỏ kỳ lạ. Hình dạng kỳ lạ đó nằm ngoài khả năng của Hikou. Vì vậy, Hikou có một công cụ, nó gọi công cụ cố vấn. Nó gọi Opus. Opus sau đó, vì nó là một mô hình lớn hơn, sẽ thực hiện nhiều suy luận hơn và biết cách xử lý.
Những gì chúng tôi thấy từ điều này trong các đánh giá (e-val) của mình là chúng tôi đạt được trí thông minh gần như cấp độ Opus với chi phí thấp hơn nhiều, bởi vì chúng tôi rất tiết kiệm trong việc sử dụng các token mà người cố vấn thực sự gửi đi. Do sự khác biệt về chi phí giữa hai mô hình, cách làm này mang lại hiệu quả rất tốt. Và điều tôi rất hào hứng là một tích hợp mà chúng tôi đang build cùng với đội ngũ Copilot.
Hãy chuyển sang máy demo. Vâng, hãy chuyển sang máy demo. Và những gì bạn đang thấy là GitHub Copilot ở phía bên trái chỉ là GitHub Copilot với Hikou. Và ở phía bên phải, bạn đang thấy GitHub Copilot với Hikou cộng với công cụ cố vấn mới được kết nối. Tôi sẽ nhấn Enter ở đây để nó có thời gian chạy. Và có một vấn đề nhỏ giống như trò "đố mẹo" ở đây mà nó phải giải quyết. Nó phải giải quyết chính xác cùng một vấn đề.
Chúng ta thấy Hikou đã bắt đầu chạy ở bên trái, trong khi ở bên phải, nó đang tham vấn cố vấn. Vì vậy, nó đang chạy chậm hơn một chút. Tôi đang rất hy vọng rằng Hikou – ý tôi là Opus – sẽ trả về kết quả. Và ở phía bên trái, Hikou đang cứ thế chạy, thử một loạt thứ. Giống như bạn sẽ thấy một kỹ sư mới vào nghề rất hăng hái thử rất nhiều thứ, nhưng vẫn chưa tìm ra giải pháp. Ở bên phải, cố vấn Opus vừa trả về kết quả. Và bởi vì đó là Opus, nó thực sự biết dữ liệu này. Và vì vậy, nó có thể đưa dữ liệu đó trở lại ngữ cảnh. Và bây giờ chúng ta đã hoàn thành với Opus. Và mọi thứ vẫn nằm trong Hikou. Nhưng vì nó nhận được một chút gợi ý đó, phía bên phải đã kết thúc ở đây.
Vì vậy, chúng ta thấy phía bên phải đã kết thúc. Phía bên trái vẫn đang cố gắng tìm hiểu xem nên đi hướng nào. Chỉ một chút gợi ý nhỏ đó từ Opus, với chi phí rất nhỏ, độ trễ rất thấp, đã khiến Hikou trở nên mạnh mẽ hơn rất nhiều. Đây là một thử nghiệm mà chúng tôi đang thực hiện trong CLI của GitHub Copilot và sẽ sớm phát hành. Rất mong các bạn sẽ trải nghiệm. Cảm ơn. Và chào mừng trở lại, Mario. Cảm ơn, cảm ơn. Tôi yêu thích trí thông minh Opus, một quá trình Hikou. Đó là điều chúng ta phải làm.
RoverDuck: Đánh giá phản biện mô hình
Được rồi. Vì vậy, chúng tôi sẽ chỉ cho bạn một số lời khuyên từ mô hình. Có một thuật toán khác mà bạn thực sự có thể áp dụng khi bạn đang mày mò nhiều hơn về cách gọi đúng công cụ để đạt được trí thông minh phù hợp. Và chúng tôi gọi đó – vì chúng tôi là GitHub, chúng tôi hơi khác thường một chút về một số điều – chúng tôi sẽ gọi nó là RoverDuck. Và RoverDuck thực sự là gì, và đây là một bản demo tôi sẽ cho bạn xem trong giây lát, nó thực sự là việc chèn một đánh giá phản biện (critique) vào những thời điểm thích hợp.
Vì vậy, tôi có một tính năng mà tính năng đó có một vấn đề và tôi đang triển khai nó vào thời điểm hiện tại. Và điều tôi muốn nhấn mạnh, và nó sẽ sớm ra mắt, đó là mô hình hiện đang yêu cầu một đánh giá phản biện. Và bạn có thể thấy cách nó yêu cầu một đánh giá phản biện từ 4.6 và 4.5 Opus. Sau đó, nó nhận được đánh giá phản biện đó và sau đó có thể thực sự thay đổi kế hoạch trước khi triển khai và sau đó tiếp tục triển khai đúng cách. Và sau đó chúng tôi có tính năng đó và chúng tôi triển khai nó.
Điều đó rất nhanh chóng. Nhưng điều tôi thực sự muốn nhấn mạnh là một mô hình khác. Một mô hình khác hoạt động ít như một người cố vấn hơn và giống như một đánh giá phản biện hơn về, "này, đây là điều tôi nghĩ bạn nên làm." Và chúng tôi chèn điều này vào ba vị trí cốt lõi. Một trong số đó là sau khi phác thảo một kế hoạch. Chúng tôi có rất nhiều người dùng thực hiện kế hoạch trước và sau khi phác thảo kế hoạch đó, họ tiến hành thực thi.
Chúng tôi có một vị trí khác sau khi triển khai phức tạp. Vì vậy, hãy nghĩ về nó. Tôi vừa hoàn thành tất cả những điều này. Hãy đưa ra đánh giá phản biện. Nó giống như một đánh giá mã (pre-code review) ở một mức độ nào đó. Và chúng tôi thực hiện nó đôi khi ở đó vì nó giúp tiết kiệm token hơn là chờ đợi cho đến khi có một đánh giá mã chính thức. Và sau đó, một vị trí khác là sau khi viết kiểm thử nhưng trước khi chạy chúng. Và ở một số nơi mà bộ CI của bạn với các kiểm thử mất một lượng thời gian đáng kể, thì bạn có thể thấy cách điều đó cuối cùng giúp bạn đạt được quy trình đó nhanh hơn và giữ cho nhà phát triển tập trung vào công việc (in flow).
Vì vậy, đó là ba vị trí mà chúng tôi đang thực hiện ngay bây giờ. Và từ phía tôi, điều tôi thực sự thấy hiệu quả là ở giai đoạn lập kế hoạch. Giống như rất nhiều hệ thống này đang làm rất tốt việc lập kế hoạch. Và sau đó, nếu bạn nắm bắt nó ở đó, bạn sẽ nhận được nhiều lợi ích nhất sau đó. Hiện tại, RoverDuck đã là một thử nghiệm. Vì vậy, nếu bạn tải xuống Copilot CLI và bật thử nghiệm đó, bạn sẽ thấy nó ở đó. Bạn có thể gọi nó bất cứ khi nào bạn muốn. Vì vậy, bạn có thể nói, "này, hãy tạo một kế hoạch về điều này và tham khảo ý kiến RoverDuck." Và sau đó bạn nhận được một đánh giá phản biện nhanh chóng trên các họ mô hình khác nhau.
Mở rộng và Đánh giá Mô hình Mới
Bây giờ, hãy tiếp tục. Điều thứ ba mà chúng tôi muốn nói đến là, làm thế nào để chúng tôi mở rộng quy mô (at scale) các mô hình mới? Quá trình chúng tôi thực hiện là gì? Ban đầu, nó rất lộn xộn đối với chúng tôi. Nhưng trong khoảng hai năm rưỡi qua, chúng tôi đã thực hiện rất nhiều công việc để đảm bảo chúng tôi rất có phương pháp trong cách chúng tôi tiếp cận mô hình này.
Vì vậy, bạn có thể thấy, và Robert có một mô hình để thử. Chúng tôi tích hợp (onboard) mô hình đó vào cái mà chúng tôi gọi là KAPI, là API của Copilot. Và sau đó chúng tôi có một endpoint. Và sau đó từ endpoint đó, ba điều thực sự cần phải xảy ra.
Thứ nhất, như tất cả các bạn đều biết, bạn phải tiếp tục làm việc trong harness và làm việc trong prompt của mình. Vì vậy, đối với chúng tôi, chúng tôi có một harness đa mô hình (multi-model harness), phải không? Vì vậy, đó không chỉ là một họ mô hình. Vì vậy, chúng tôi phải đến đó và đảm bảo rằng chúng tôi cập nhật các prompt hệ thống. Đó là một vòng lặp rất chặt chẽ và lưu lượng truy cập vào đó.
Sau đó, chúng tôi phải đảm bảo hai giao diện là đúng và được tối ưu hóa. Sau đó, chúng tôi phải, và chúng tôi không làm điều này nhiều nữa, nhưng chúng tôi phải thực hiện vòng lặp tác nhân (agent loop) một chút. Và sau đó nhiều công việc hơn nữa được dành cho quản lý ngữ cảnh (context management), vào nén/thu gọn (compaction), vào việc đảm bảo rằng chúng tôi đạt được tỷ lệ cache hit phù hợp nói chung.
Sau đó, từ đó, chúng tôi làm hai việc. Chúng tôi chạy các điểm chuẩn ngoại tuyến (offline benchmarks). Và sau đó chúng tôi cũng tiến hành thử nghiệm nội bộ (internal dogfooding). Hãy coi đó là các điểm chuẩn trực tuyến (online benchmarks) nói chung. Vì vậy, rất nhiều nhà phát triển của Microsoft sử dụng nó, rất nhiều nhà phát triển của GitHub sử dụng nó. Và chúng tôi có một nhóm người dùng khác mà chúng tôi hợp tác rất chặt chẽ để nhận phản hồi. Vì vậy, chúng tôi có các điểm chuẩn ngoại tuyến đó, và sau đó chúng tôi có thử nghiệm nội bộ đó.
Sau đó, từ đó, chúng tôi chắc chắn tìm thấy điều này với Anthropic. Và đây là một bản trình bày, trước đây chúng tôi thường viết một tài liệu, bây giờ chúng tôi viết một tài liệu và mở rộng nó chi tiết, nơi chúng tôi nói, đây là tất cả những gì chúng tôi đang thấy. Và sau đó chúng tôi lặp lại với họ về những thay đổi mà chúng tôi cần, hoặc ở API, hoặc thậm chí thay đổi trên một số mô hình đó cũng như trên các checkpoint mà chúng tôi nhận được. Và sau đó từ đó, chúng tôi thực hiện một vòng lặp khác cho đến khi phát hành mô hình.
Bây giờ có hai điều rất quan trọng. Vâng, chúng tôi thực hiện ngoại tuyến. Và ngoại tuyến cung cấp cho bạn một dấu hiệu, nhưng tôi sẽ nói rằng nó sẽ không phải là thực tế của thời điểm. Bạn học được nhiều điều hơn từ các đánh giá trực tuyến (online evals) tổng thể của mình, và các thử nghiệm trực tuyến sau khi ra mắt, hơn là thực sự từ ngoại tuyến. Ngoại tuyến chỉ thiết lập một cơ sở. Và nếu cơ sở đó nhất quán, bạn sẽ biết những gì mong đợi ở đó. Và nó cung cấp cho bạn một dấu hiệu khá tốt về điều đó, những gì mong đợi. Nhưng tất cả các chi tiết không được thực hiện thông qua ngoại tuyến. Vì vậy, chúng tôi thường mất vài ngày, đôi khi thậm chí vài tuần, để điều chỉnh mọi thứ của mô hình đó thông qua các thử nghiệm trực tuyến đó. Chúng tôi thực hiện rất nhiều thử nghiệm A/B và chúng tôi rất có phương pháp về điều đó. Và chúng tôi có báo cáo hàng tuần mà chúng tôi báo cáo cho Anthropic và cũng cho tất cả các nhóm mà chúng tôi có để đảm bảo rằng chúng tôi đang điều chỉnh đúng mô hình vào đúng thời điểm.
Tối ưu hóa Harness và Đo lường Kết quả
Khi nói đến việc tối ưu hóa harness cho chúng tôi, có bốn điều. Một là xây dựng prompt và ngữ cảnh. Hai là gọi mô hình vì đó là công cụ được thực thi và sau đó tùy thuộc vào kết quả và kéo lại và nhìn lại. Và điều tôi đang nói ở đây, những nơi tôi dành nhiều thời gian nhất với nhóm thường là trong công cụ thực thi (execute tool) và xây dựng prompt và ngữ cảnh đó.
Công cụ rất quan trọng đối với chúng tôi. Bạn càng có nhiều công cụ, càng có nhiều sự nhầm lẫn xảy ra. Bạn càng phải điều chỉnh nhiều. Vì vậy, hàng trăm công cụ không phải là một điều tốt. Vì vậy, bạn muốn đảm bảo bạn đang điều chỉnh theo bề mặt và bạn đang điều chỉnh cho các tình huống chính xác với các công cụ phù hợp trong gói đó. Vì vậy, chúng tôi dành rất nhiều thời gian ở đó và tối ưu hóa mô hình đó. Và sau đó là kiểm tra quyền và chạy. Chúng tôi lại kết thúc trong việc thực thi công cụ đó. Bạn phải làm những việc đúng đắn để truyền ngữ cảnh phù hợp vào đó và sau đó đọc đúng kết quả. Vì vậy, bất cứ khi nào chúng tôi muốn giới thiệu một công cụ mới làm ví dụ, chúng tôi dành rất nhiều thời gian để đảm bảo rằng chúng tôi tối ưu hóa harness ở cả cấp độ mô hình và cấp độ thực thi công cụ.
Điều này có ý nghĩa gì ở cấp độ cao? Có hai điều. Bạn phải có cả điểm chuẩn đã công bố và điểm chuẩn đã tạo ra. Nhưng quan trọng hơn, hãy thử nghiệm nội bộ (dogfooding) với AMD và đảm bảo rằng bạn đã thiết lập e-val trực tuyến. Và đảm bảo bạn có thể tin tưởng vào số liệu thống kê.
Sau đó, điều thứ hai là, bạn muốn đo lường kết quả (outcomes), không phải hoạt động (activity). Khi tôi nói về các công cụ, chẳng hạn như tỷ lệ chấp nhận trên một dòng mã, điều đó vẫn ổn. Tỷ lệ tồn tại (survival rate) thực sự là một số liệu thậm chí còn tốt hơn nói chung, bởi vì nếu bạn đã chấp nhận nó và sau đó bạn đã xóa nó, thì điều đó thực sự không đạt được kết quả tổng thể. Vì vậy, mặc dù tôi có thể có tỷ lệ chấp nhận tuyệt vời, nếu tỷ lệ tồn tại kết thúc rất thấp, điều đó có nghĩa là chúng tôi đã không làm đúng việc. Vì vậy, điều rất quan trọng là nếu bạn ở trong bộ phận sản phẩm và sản phẩm thực sự thay đổi trong RFAI rằng bạn đang tối ưu hóa cho các kết quả chứ không chỉ là các hàng riêng lẻ. Như tôi đã nói, bạn sẽ kết thúc việc tối ưu hóa cho một số liệu, sau đó gắn thẻ, gắn thẻ phép đo của toàn bộ sản phẩm của bạn.
Tổng kết
Được rồi, với điều đó, một lần nữa, chúng ta đã xem xét bộ nhớ đệm lời nhắc (prompt caching), chiến lược cố vấn, và sau đó chúng ta đã nói một chút về đo lường và cách chúng tôi cải thiện harness của mình. Và sau đó đối với chúng tôi, tôi chỉ muốn để lại lời cảm ơn. Thực sự rất vui khi lại được ở bên các bạn. Hy vọng các bạn học được một vài điều hôm nay.
TL;DR
- GitHub đặt tầm nhìn phát triển AI xoay quanh việc trao quyền cho nhà phát triển, duy trì họ "in flow" và tăng tốc độ làm việc của đội ngũ bằng các công cụ hiệu quả, đáng tin cậy ở quy mô lớn. Mọi quyết định về sản phẩm đều dựa trên các trụ cột này.
- Việc vận hành các mô hình AI lớn như Copilot yêu cầu tối ưu hóa chi phí và hiệu suất nghiêm ngặt, với "bộ nhớ đệm lời nhắc" (prompt caching) là yếu tố then chốt, mang lại lợi ích hàng triệu đô la chỉ với 1% cải thiện hiệu suất.
- Chiến lược "mô hình cố vấn" (advisor model) kết hợp các mô hình nhỏ hơn (Hikou) với mô hình thông minh hơn (Opus) giúp đạt được trí tuệ cấp cao với chi phí thấp hơn đáng kể, bằng cách chỉ gọi mô hình lớn khi thực sự cần thiết.
Điểm chính
- Ưu tiên Bộ nhớ Đệm Lời Nhắc (Prompt Caching): Đây là yếu tố sống còn để vận hành các dịch vụ suy luận AI ở quy mô lớn và tiết kiệm chi phí. Mục tiêu là đạt tỷ lệ bộ đệm trên 94%.
- Tối ưu hóa Cấu trúc Lời Nhắc: Đảm bảo
tiền tố(prefix) vàlời nhắc hệ thống(system prompt) làtĩnh(static) nhất có thể, tránhnội dung độngnhư UUID để không làmvô hiệu hóa bộ đệmliên tục. - Quản lý
Công cụ(Tools) Cẩn thận: Tránhtải động các công cụhoặc thay đổitiền tố công cụtrong quá trìnhcuộc hội thoại, vì điều này cũng dẫn đếnvô hiệu hóa bộ đệmtoàn bộ. Cần cókiểm thử hồi quychokỹ năngvàcông cụ. - Đảm bảo
Tính Liên Kết Bộ Đệm(Cache Affinity) quaĐa Kênh: Đối với các hệ thốngđa kênh(ví dụ: Copilot gọi nhiều mô hình khác nhau), phải làm việc để đảm bảo cáclời gọiliên tiếp tới cùng một mô hình vẫn duy trìtính liên kết bộ đệm. - Sử dụng
Cửa Sổ Ngữ Cảnh(Context Window) Dài một cách Thông minh:Cửa sổ ngữ cảnhdài hơn không nhất thiết có nghĩa làchi phícao hơn. Việcnén/thu gọn(compaction) quá mức có thể làm tăngmã thông báo đầu ravà làm giảmtỷ lệ bộ đệm, dẫn đếnchi phícao hơn.Quản lýnén/thu gọnphù hợp vớikịch bảnsử dụng. - Triển khai
Bảng Điều KhiểnvàPhân Tích Delta:Cài đặt(instrument) đểđo lườngtỷ lệ bộ đệmvàhiệu suất mô hìnhtrên cácbề mặt(surface) khác nhau (VS Code, CLI, mobile, v.v.). Thực hiệnphân tích deltatrước và sau khi ra mắt mô hìnhmới để đánh giácải thiệnhoặcthụt lùi. - Áp dụng
Mô Hình Cố Vấn(Advisor Model): Sử dụngmô hìnhnhỏ hơn (người thực thi) để xử lý hầu hết các tác vụ và chỉgọimô hìnhlớn hơn (cố vấn) cho những trường hợp phức tạp, giúp giảmchi phívàđộ trễđáng kể trong khi vẫn duy trì chất lượngtrí thông minh.
Từ vựng
in flow— trạng thái làm việc liền mạch, tập trungvelocity— tốc độ phát triển/hoàn thành công việcprompt caching— bộ nhớ đệm lời nhắccache hit ratios— tỷ lệ truy cập bộ đệm thành côngadvisor model— mô hình cố vấnexecutor model— mô hình thực thicontext window— cửa sổ ngữ cảnhcompaction— nén/thu gọn (ngữ cảnh)input tokens— mã thông báo đầu vàooutput tokens— mã thông báo đầu racache affinity— tính liên kết bộ đệmdynamic content— nội dung độngsystem prompt— lời nhắc hệ thốngregression tests— kiểm thử hồi quydelta analysis— phân tích chênh lệch/delta
Nội dung chi tiết
Lời giới thiệu từ GitHub và Tầm nhìn Phát triển
Xin mời chào đón Giám đốc Sản phẩm của GitHub, Mario Rodriguez, lên sân khấu. Xin chào tất cả mọi người. Rất vui được trở lại. Tôi lập trình với Claude Code. Tôi yêu các hội nghị dành cho nhà phát triển. Chúng hơi lộn xộn, nhưng đầy sôi động. Chúng vẫn ưu tiên nhà phát triển, không phải ưu tiên tác nhân. Và đây là điều chúng ta đã có niềm vui khi làm. Chúng ta ở đây để vui vẻ và học hỏi cùng nhau.
Các bạn ở đây vì muốn tìm hiểu thêm về nền tảng. Và tôi ở đây để chia sẻ với các bạn một số điều quan trọng nhất mà chúng tôi đã làm để vận hành Copilot và tất cả các suy luận của chúng tôi trên nền tảng này. Tôi muốn bắt đầu bằng lý do. Tôi đã trình bày một phần rất tập trung vào sứ mệnh. Tầm nhìn của chúng tôi là trao quyền cho các nhà phát triển, cung cấp những công cụ tốt nhất hiện có để thúc đẩy tiến bộ của con người. Nhưng khi tôi nói chuyện với khách hàng nói chung, tôi đang nói với họ về điều họ muốn đạt được. Họ muốn đạt được một tập hợp các kết quả. Và đối với họ, họ muốn giữ cho đội ngũ của mình in flow. Họ muốn giữ cho các nhà phát triển in flow. Họ muốn các nhóm của họ tăng velocity. Họ muốn các nhóm thực sự đạt được nhiều hơn với những người mà họ có. Và họ muốn làm điều này ở quy mô. Để có thể làm được ở quy mô, bạn phải có hiệu suất và bạn cũng phải có sự tin cậy. Tôi bắt đầu với điều này bởi vì hầu hết mọi quyết định về sản phẩm mà tôi đưa ra đều dựa trên những trụ cột này. Ngay cả khi chúng tôi nói về nền tảng và tích hợp với nền tảng đám mây của chúng tôi, tôi muốn đảm bảo rằng tôi giữ cho các nhà phát triển in flow. Tôi muốn đảm bảo các nhóm đạt được velocity đó. Và tôi muốn đảm bảo các công ty có thể làm điều đó với trí thông minh và sự tin cậy.
Vận hành Nền tảng và Bài học chính
Khi tôi suy nghĩ về tương lai, tôi đã nghĩ rất kỹ: Tôi muốn nói điều gì ở đây? Nếu tôi đang ngồi ở đó, điều tôi muốn hiểu là: "Được rồi, bạn vận hành như thế nào?". Chúng tôi xử lý hàng tỷ, có lẽ qua một khoảng thời gian đủ lớn, hàng nghìn tỷ tin nhắn gửi đến nền tảng. Vì vậy, tôi muốn cung cấp cho bạn những phương pháp tốt nhất, hoặc thậm chí không phải phương pháp tốt nhất vì mọi thứ thay đổi rất thường xuyên, gần như hàng tuần. Nhưng đó là những bài học chính, những điều nằm sâu dưới đáy của hầu hết các quyết định mà chúng tôi đưa ra để có thể tích hợp với nền tảng và đạt được quy mô và hiệu suất cần thiết.
Vì vậy, tôi muốn chia nó thành ba điều. Đầu tiên là bộ nhớ đệm lời nhắc (prompt caching). Nếu không có nó, chúng tôi không chết, nhưng ôi trời ơi! Lượng chi phí chúng tôi bỏ ra so với những gì chúng tôi làm thật đáng kinh ngạc, phải không? Vì vậy, chỉ cần 1% hiệu suất trong lĩnh vực này có ý nghĩa rất lớn đối với chúng tôi. Nó giống như giao dịch tần số cao (high frequency trading). 1% hiệu suất có nghĩa là hàng triệu đô la nói chung. Vì vậy, tôi chỉ muốn dành thêm một chút thời gian để nói về cách chúng tôi thực hiện điều đó.
Điều thứ hai là chúng tôi đang hợp tác với Anthropic về các khả năng để đảm bảo khách hàng của chúng tôi đang sử dụng suy luận đúng (right inference), lượng trí thông minh đúng (right amount of intelligence) vào đúng thời điểm (right time). Và một trong số đó là mô hình cố vấn này. Chúng tôi có hai cách nhìn nhận nó, thông qua cả cố vấn và nhà phê bình. Vì vậy, Brad và tôi cũng sẽ chia sẻ thêm một chút về điều đó.
Và điều thứ ba là mỗi khi một mô hình mới ra mắt, và nếu bạn đang tích hợp với nền tảng, bạn biết điều này xảy ra liên tục, và bạn nhận được một cuộc gọi vào 5 giờ sáng thứ Bảy rằng: "Này, chúng ta sẽ ra mắt vào thứ Ba". Vậy làm thế nào để chúng ta thực sự thực hiện điều đó đúng cách? Làm thế nào để chúng ta đưa ra các quyết định như mô hình mặc định nào để giữ cho các nhà phát triển in flow? Làm thế nào để chúng ta đưa ra các quyết định để thực sự định tuyến (route) đến trí thông minh đúng (right intelligence) vào đúng thời điểm (right time) nói chung?
Tối ưu hóa Bộ nhớ Đệm Lời Nhắc và Hiệu suất Mô hình
Tôi sẽ bắt đầu với điều này. Và đây là một bảng điều khiển (dashboard). Đây không phải bảng điều khiển của chúng tôi, nhưng nếu bạn đang sử dụng nền tảng, tôi tin rằng Anthropic đã phát hành nó vào tuần trước, chúng tôi đã có một bản xem trước nhỏ về nó. Và điều nó cho phép bạn hiểu là bạn đang hoạt động như thế nào, ví dụ như tỷ lệ lượt truy cập bộ đệm (cache hit ratios) của bạn, số lượng tin nhắn bạn đang gửi, đối với API tin nhắn, phải không? Và tôi nghĩ điều này rất tuyệt. Đây là bước đầu tiên vì không có dữ liệu thì rất, rất khó để đưa ra quyết định, rất, rất khó. Vì vậy, nếu bạn chưa kiểm tra, hãy làm điều đó.
Bây giờ, điều tôi muốn dành thêm một chút thời gian là của chúng tôi. Và đây chỉ là một cái nhìn. Đây không phải là toàn bộ các bảng điều khiển mà chúng tôi có. Nhưng đây là nơi chúng tôi xem xét sự khác biệt giữa các mô hình. Trong trường hợp này, tôi muốn bạn chủ yếu nhìn vào phía bên trái là Opus 4.6. Và sau đó ở bên phải là 4.7. Và sau đó là góc tiếp theo liệt kê sự khác biệt giữa chúng. Vì vậy, khi một mô hình mới ra mắt, và đôi khi chúng tôi nhận được nó trong EAP (Early Access Program), chúng tôi tiến hành chạy một tập hợp các điểm chuẩn (benchmarks) chống lại nó. Vì vậy, hãy nghĩ về điểm chuẩn terminal benchmark 2. Và sau đó hoặc một trong các bộ, chúng tôi cũng có những bộ của riêng mình. Và sau đó chúng tôi cố gắng quyết định, "Được rồi, mô hình đang hoạt động như thế nào?". Và sau đó chúng tôi triển khai (ship) nó và sau đó chúng tôi chú ý đến dữ liệu đó một lần nữa. Và sau một khoảng thời gian có lẽ 30 ngày, chúng tôi có lẽ đã hoàn thành (done), hoặc đôi khi thậm chí sớm hơn, chúng tôi hoàn thành tất cả các tối ưu hóa cho mô hình đó.
Bây giờ bạn có thể thấy ở đây, loại mã thông báo bộ đệm (cache tokens) trung bình, và cuối cùng, tỷ lệ bộ đệm (cache rate). Để chúng tôi vận hành dịch vụ ở quy mô, chúng tôi cần chạy trên 94%, thường là 94, 95, 96%. Nếu chúng tôi hoạt động ở mức 70%, điều đó thường có nghĩa là chúng tôi có một lỗi (bug), tin hay không thì tùy. Giống như chúng tôi đang làm điều gì đó không đúng. Và sau đó chúng tôi cần thay đổi cách tiếp cận về cách chúng tôi gọi mô hình, cách chúng tôi tập hợp lời nhắc (assembling the prompt), cách chúng tôi thực hiện end-to-end để giữ cho nhà phát triển in flow. Vì vậy, chúng tôi chú ý đến điều đó. Tương tự, nếu tôi muốn thực sự thay đổi tỷ lệ bộ đệm từ, tôi xin lỗi, thay đổi mô hình mặc định từ 4.6 sang 4.7, tôi cần hiểu sự khác biệt về tỷ lệ bộ đệm. Và điều đó thực sự có ý nghĩa gì đối với tôi, một lần nữa, chúng tôi thực hiện hàng tỷ và hàng tỷ lời gọi (calls) nói chung. Vì vậy, chỉ 1% trong đó, trong trường hợp này, là 1.3%, có ý nghĩa rất lớn đối với chúng tôi.
Bây giờ bạn cũng phải tính đến rằng từ góc độ đầu vào, tỷ lệ bộ đệm của bạn chỉ là 10% chi phí, phải không? Vì vậy, có một sự khác biệt 10 lần ở đó. Vì vậy, bạn liên tục vô hiệu hóa bộ đệm (invalidating that cache). Đó không phải là một điều tốt, vì bạn sẽ phải trả chi phí cao hơn 10 lần. Và sau đó chúng tôi xem xét điều đó. Trong trường hợp này, chúng tôi đã đặt một đường cơ sở (baseline) chống lại 4.6 và sau đó cũng trên high queue. Bây giờ hãy tưởng tượng nó giữ nguyên như thế này trong giây lát và có rất nhiều màu đỏ như bạn có thể thấy trên màn hình này nói chung. Sau đó, chúng tôi có một quyết định phải đưa ra. Chúng tôi phải đưa ra quyết định để tìm cách biến tất cả những màu đỏ đó thành màu xanh lá cây. Và đó không phải là may mắn, đó là rất nhiều công việc khó khăn. Và tôi muốn đảm bảo bạn hiểu điều đó. Đó là rất nhiều công việc khó khăn để đạt được, có thể từ 50% lên 70% không phải vì bạn chỉ đang hái quả thấp (easy hunting fruit). Nhưng từ 70% lên 80%, từ 80% lên 90% và 90% trở lên, có rất nhiều công việc khó khăn được đầu tư vào điều này, về kỹ thuật.
Bài học về Tối ưu hóa Bộ nhớ Đệm
Và có ba điều chúng tôi xem xét. Điều đầu tiên là, chúng tôi đảm bảo rằng không có, và đây là những bài học kinh nghiệm. Chúng tôi đã mắc những sai lầm này trước đây và đó là lý do tại sao tôi muốn chia sẻ với bạn. Chúng tôi không đặt nội dung động (dynamic content) nào vào tiền tố (prefix), phải không? Bạn cần giữ tiền tố đó tĩnh (static) nhất có thể. Và làm ví dụ, tại một thời điểm, chúng tôi có UUID trong lời nhắc hệ thống (system prompt) thực tế. Và sau đó chúng tôi liên tục bị đặt lại (reset) và điều đó đã vô hiệu hóa toàn bộ tỷ lệ bộ đệm. Vì vậy, hãy nhớ, hệ thống (system), sau đó là công cụ (tools), sau đó là cuộc hội thoại (conversation), và sau đó là tin nhắn cuối cùng (last message) bạn đang gửi. Đó là loại hệ thống phân cấp. Vì vậy, bạn muốn giữ lời nhắc hệ thống đó ổn định nhất có thể, không có nội dung động nào trên đó.
Sau đó là công cụ (tools). Đôi khi chúng tôi đã mắc rất nhiều sai lầm trong công cụ. Nếu bạn đang tải động các công cụ (loading tools dynamically) và bạn đang thay đổi tiền tố công cụ (tool's prefix) đó, thì đột nhiên, mọi thứ, toàn bộ cuộc hội thoại, lại bị vô hiệu hóa (invalidated) một lần nữa. Vì vậy, bạn phải làm việc và bạn phải đảm bảo bạn có nhiều kiểm thử hồi quy (regression tests) vì bạn sẽ thử nghiệm với cái gì? Kỹ năng (skills) và công cụ (tools) nói chung trong end-to-end của bạn, bạn phải có kiểm thử hồi quy để đảm bảo bạn không ảnh hưởng đến công cụ của mình.
Sau đó, điều thứ ba nói chung là chúng ta cần có tính liên kết bộ đệm (cache affinity) đó. Và tôi phải nói với bạn, điều đó thực sự khó khăn khi bạn đang thực hiện đa kênh (multi-modal harness). Vì vậy, lấy ví dụ, Copilot. Khách hàng có thể gọi Opus, sau đó gọi mô hình GPT, và sau đó đến mô hình OSS và sau đó quay lại Opus một lần nữa. Và sau tất cả những điều đó, tôi phải đảm bảo rằng lời gọi Opus tiếp theo, lời gọi cuối cùng đã xảy ra, thực sự có tính liên kết bộ đệm đúng. Vì vậy, chúng tôi làm rất nhiều việc khi nói đến đa kênh của mình để đảm bảo điều đó được đảm bảo.
Cửa sổ Ngữ cảnh Lớn và Chi phí
Đây là một ví dụ về điều mà chúng tôi cũng đã chạy trong bonken mesh. Một trong những điều quan trọng mà tôi nghe nhiều lần, thực ra khi tôi đến gặp khách hàng và họ hỏi tôi về việc tích hợp với nền tảng, là, "Này, ngữ cảnh dài (long context) có nghĩa là nó đắt hơn." Và câu trả lời đối với chúng tôi là không. Và đây là một thử nghiệm nhanh mà chúng tôi đã thực hiện. Vì vậy, có một cửa sổ ngữ cảnh (context window) nhỏ hơn. Và bạn có thể thấy ở đó rằng nén/thu gọn (compaction) trung bình của tôi đã tăng gấp ba lần, so với cửa sổ ngữ cảnh lớn hơn. Đây là điều chúng tôi đã mô phỏng. Chúng tôi giữ cùng một mô hình với cùng một cửa sổ ngữ cảnh. Chúng tôi chỉ thực hiện nhiều nén/thu gọn hơn trên đó và điền nó với một tỷ lệ.
Bây giờ điều quan trọng ở đây, nếu bạn nhớ phép tính về số lượng mã thông báo đầu vào và đầu ra và những gì đang xảy ra là 5 lần, phải không? Vì vậy, đối với Opus, ví dụ, nó sẽ là 5.25 đô la. Trong trường hợp đó, bất cứ khi nào bạn thực hiện nén/thu gọn, bạn nhận được 4.000 mã thông báo đầu ra. Và sau đó bạn có, vì bạn phải tóm tắt tin nhắn, v.v. Vì vậy, bất cứ khi nào điều đó xảy ra, bạn thường phải trả nhiều hơn, bởi vì bạn thực hiện nhiều nén/thu gọn hơn, điều đó có nghĩa là mã thông báo đầu ra của bạn tăng vọt. Và sau đó tỷ lệ bộ đệm của bạn cũng bị vô hiệu hóa nhiều hơn vì điều đó. Chà, bị vô hiệu hóa đáng kể vì điều đó nữa. Vì vậy, cửa sổ ngữ cảnh dài hơn không có nghĩa là bạn chi tiêu nhiều hơn. Thực tế, điều bạn phải hiểu là nén/thu gọn đang được thực hiện như thế nào. Và tùy thuộc vào kịch bản, bạn muốn quản lý điều đó cho người dùng một cách thích hợp.
Tóm tắt Thực hành Tối ưu hóa Bộ nhớ Đệm
Ở cấp độ cao, hãy cài đặt (instrument) tỷ lệ bộ đệm của bạn, có một bảng điều khiển thực sự hiển thị nó cho bạn. Dành thời gian để làm điều đó. Họ đã cung cấp một cái cho bạn, vì vậy ít nhất hãy sử dụng cái đó. Nhưng hãy đầu tư vào phân tích delta, hãy đầu tư vào trước khi ra mắt mô hình và sau khi ra mắt mô hình nữa.
Bây giờ, không có hiệu suất nào khác quan trọng cho đến khi bạn thấy điều đó một lần nữa. Bạn muốn thúc đẩy điều đó từ 50, 70, 90 nói chung, và nó sẽ đòi hỏi rất nhiều công việc khó khăn, rất nhiều thời gian kỹ thuật. Và sau đó bạn muốn đo lường theo từng bề mặt (per surface). Chúng tôi có VS Code, là một trong những bảng điều khiển mà chúng tôi đã hiển thị cho bạn ở đó. Nhưng chúng tôi cũng có CLI Copilot. Chúng tôi cũng có tác nhân mã hóa (coding agent) của chúng tôi trong đám mây. Chúng tôi cũng có IntelliJ và chúng tôi cũng có di động. Vì vậy, có rất nhiều bề mặt mà bạn sẽ phải đi và hiểu, hoặc là chia sẻ sự khó khăn (hardness) giữa chúng, hoặc sau đó điều chỉnh (tweak) riêng lẻ. Vì vậy, bạn muốn có một ý thức rất tốt về việc chúng tôi triển khai một cái gì đó, chúng tôi thụt lùi (regress) hay không, chúng tôi triển khai một cái gì đó, chúng tôi cải thiện (improved) hay không.
Trí thông minh phù hợp vào đúng thời điểm: Mô hình Cố vấn
Một điều khác mà tôi đã nói với bạn là, được rồi, nếu bạn đã thực hiện bộ nhớ đệm lời nhắc, thì làm thế nào để đảm bảo rằng trí thông minh (intelligence) được viết là người dùng vào đúng thời điểm? Và vì điều đó, Anthropic và chúng tôi đã hợp tác trên mô hình cố vấn này. Và điều tôi muốn làm là mời Brad Adams từ nhóm Anthropic đến để nói thêm về nó. Mời Brad.
Cảm ơn Mario đã có mặt ở đây. Thật tuyệt vời khi có một đối tác như GitHub Copilot. Chúng tôi nhận được phản hồi rất tốt từ nhóm Copilot. Chúng tôi cho họ rất ít thời gian để đánh giá các mô hình trước khi chúng tôi ra mắt và họ đưa ra phản hồi tuyệt vời và sâu sắc. Và điều đó cũng đúng với các tính năng API của chúng tôi. Thực tế, nếu bạn đang sử dụng nền tảng Claude, rất nhiều điều bạn đang thấy là nhờ những gì Mario và nhóm của anh ấy đang làm trên Copilot. Và đó thực sự là một trong những phản hồi mà tôi muốn nói đến ngày hôm nay.
Chiến lược Cố vấn: Opus và Hikou
Một trong những phản hồi chúng tôi nhận được từ đội ngũ Copilot là họ thực sự muốn có trí thông minh ở cấp độ Opus, nhưng với mức giá ở cấp độ Hikou. Điều đó nghe có vẻ hấp dẫn phải không? Trí thông minh Opus. Tôi không trực tiếp tham gia vào các thỏa thuận, nhưng tôi được xây dựng các tính năng API thú vị. Vì vậy, tôi muốn nói về chiến lược cố vấn.
Sự hiểu biết sâu sắc về chiến lược cố vấn thực sự đến từ các đội ngũ phát triển phần mềm. Chúng ta đều biết rằng nếu bạn giao cho một kỹ sư mới vào nghề (junior engineer) một người hướng dẫn là kỹ sư cấp cao (senior engineer), kỹ sư mới vào nghề đó sẽ tiến bộ rất nhiều. Bởi vì kỹ sư cấp cao sẽ theo dõi công việc của họ, họ cùng nhau đánh giá mã, xem xét tài liệu thiết kế (design docs), kỹ sư cấp cao có thể giúp kỹ sư mới vào nghề năng suất hơn nhiều mà không tốn quá nhiều thời gian của mình.
Và hóa ra điều tương tự cũng đúng với các mô hình. Bạn có thể sử dụng một mô hình "mới vào nghề" như Hikou—mà chúng tôi gọi ở đây là người thực thi (executor)—và cấp cho nó quyền truy cập vào Opus, đồng thời bạn có thể sử dụng các token của Opus một cách rất tiết kiệm. Trong biểu đồ tuyệt đẹp mà Claude đã tạo cho tôi, bạn có thể thấy rằng người thực thi, Hikou, có khả năng nhận diện mọi hình dạng khi chúng xuất hiện mà không gặp vấn đề gì, ngoại trừ một hình dạng nhỏ kỳ lạ. Hình dạng kỳ lạ đó nằm ngoài khả năng của Hikou. Vì vậy, Hikou có một công cụ, nó gọi công cụ cố vấn. Nó gọi Opus. Opus sau đó, vì nó là một mô hình lớn hơn, sẽ thực hiện nhiều suy luận hơn và biết cách xử lý.
Những gì chúng tôi thấy từ điều này trong các đánh giá (e-val) của mình là chúng tôi đạt được trí thông minh gần như cấp độ Opus với chi phí thấp hơn nhiều, bởi vì chúng tôi rất tiết kiệm trong việc sử dụng các token mà người cố vấn thực sự gửi đi. Do sự khác biệt về chi phí giữa hai mô hình, cách làm này mang lại hiệu quả rất tốt. Và điều tôi rất hào hứng là một tích hợp mà chúng tôi đang build cùng với đội ngũ Copilot.
Hãy chuyển sang máy demo. Vâng, hãy chuyển sang máy demo. Và những gì bạn đang thấy là GitHub Copilot ở phía bên trái chỉ là GitHub Copilot với Hikou. Và ở phía bên phải, bạn đang thấy GitHub Copilot với Hikou cộng với công cụ cố vấn mới được kết nối. Tôi sẽ nhấn Enter ở đây để nó có thời gian chạy. Và có một vấn đề nhỏ giống như trò "đố mẹo" ở đây mà nó phải giải quyết. Nó phải giải quyết chính xác cùng một vấn đề.
Chúng ta thấy Hikou đã bắt đầu chạy ở bên trái, trong khi ở bên phải, nó đang tham vấn cố vấn. Vì vậy, nó đang chạy chậm hơn một chút. Tôi đang rất hy vọng rằng Hikou – ý tôi là Opus – sẽ trả về kết quả. Và ở phía bên trái, Hikou đang cứ thế chạy, thử một loạt thứ. Giống như bạn sẽ thấy một kỹ sư mới vào nghề rất hăng hái thử rất nhiều thứ, nhưng vẫn chưa tìm ra giải pháp. Ở bên phải, cố vấn Opus vừa trả về kết quả. Và bởi vì đó là Opus, nó thực sự biết dữ liệu này. Và vì vậy, nó có thể đưa dữ liệu đó trở lại ngữ cảnh. Và bây giờ chúng ta đã hoàn thành với Opus. Và mọi thứ vẫn nằm trong Hikou. Nhưng vì nó nhận được một chút gợi ý đó, phía bên phải đã kết thúc ở đây.
Vì vậy, chúng ta thấy phía bên phải đã kết thúc. Phía bên trái vẫn đang cố gắng tìm hiểu xem nên đi hướng nào. Chỉ một chút gợi ý nhỏ đó từ Opus, với chi phí rất nhỏ, độ trễ rất thấp, đã khiến Hikou trở nên mạnh mẽ hơn rất nhiều. Đây là một thử nghiệm mà chúng tôi đang thực hiện trong CLI của GitHub Copilot và sẽ sớm phát hành. Rất mong các bạn sẽ trải nghiệm. Cảm ơn. Và chào mừng trở lại, Mario. Cảm ơn, cảm ơn. Tôi yêu thích trí thông minh Opus, một quá trình Hikou. Đó là điều chúng ta phải làm.
RoverDuck: Đánh giá phản biện mô hình
Được rồi. Vì vậy, chúng tôi sẽ chỉ cho bạn một số lời khuyên từ mô hình. Có một thuật toán khác mà bạn thực sự có thể áp dụng khi bạn đang mày mò nhiều hơn về cách gọi đúng công cụ để đạt được trí thông minh phù hợp. Và chúng tôi gọi đó – vì chúng tôi là GitHub, chúng tôi hơi khác thường một chút về một số điều – chúng tôi sẽ gọi nó là RoverDuck. Và RoverDuck thực sự là gì, và đây là một bản demo tôi sẽ cho bạn xem trong giây lát, nó thực sự là việc chèn một đánh giá phản biện (critique) vào những thời điểm thích hợp.
Vì vậy, tôi có một tính năng mà tính năng đó có một vấn đề và tôi đang triển khai nó vào thời điểm hiện tại. Và điều tôi muốn nhấn mạnh, và nó sẽ sớm ra mắt, đó là mô hình hiện đang yêu cầu một đánh giá phản biện. Và bạn có thể thấy cách nó yêu cầu một đánh giá phản biện từ 4.6 và 4.5 Opus. Sau đó, nó nhận được đánh giá phản biện đó và sau đó có thể thực sự thay đổi kế hoạch trước khi triển khai và sau đó tiếp tục triển khai đúng cách. Và sau đó chúng tôi có tính năng đó và chúng tôi triển khai nó.
Điều đó rất nhanh chóng. Nhưng điều tôi thực sự muốn nhấn mạnh là một mô hình khác. Một mô hình khác hoạt động ít như một người cố vấn hơn và giống như một đánh giá phản biện hơn về, "này, đây là điều tôi nghĩ bạn nên làm." Và chúng tôi chèn điều này vào ba vị trí cốt lõi. Một trong số đó là sau khi phác thảo một kế hoạch. Chúng tôi có rất nhiều người dùng thực hiện kế hoạch trước và sau khi phác thảo kế hoạch đó, họ tiến hành thực thi.
Chúng tôi có một vị trí khác sau khi triển khai phức tạp. Vì vậy, hãy nghĩ về nó. Tôi vừa hoàn thành tất cả những điều này. Hãy đưa ra đánh giá phản biện. Nó giống như một đánh giá mã (pre-code review) ở một mức độ nào đó. Và chúng tôi thực hiện nó đôi khi ở đó vì nó giúp tiết kiệm token hơn là chờ đợi cho đến khi có một đánh giá mã chính thức. Và sau đó, một vị trí khác là sau khi viết kiểm thử nhưng trước khi chạy chúng. Và ở một số nơi mà bộ CI của bạn với các kiểm thử mất một lượng thời gian đáng kể, thì bạn có thể thấy cách điều đó cuối cùng giúp bạn đạt được quy trình đó nhanh hơn và giữ cho nhà phát triển tập trung vào công việc (in flow).
Vì vậy, đó là ba vị trí mà chúng tôi đang thực hiện ngay bây giờ. Và từ phía tôi, điều tôi thực sự thấy hiệu quả là ở giai đoạn lập kế hoạch. Giống như rất nhiều hệ thống này đang làm rất tốt việc lập kế hoạch. Và sau đó, nếu bạn nắm bắt nó ở đó, bạn sẽ nhận được nhiều lợi ích nhất sau đó. Hiện tại, RoverDuck đã là một thử nghiệm. Vì vậy, nếu bạn tải xuống Copilot CLI và bật thử nghiệm đó, bạn sẽ thấy nó ở đó. Bạn có thể gọi nó bất cứ khi nào bạn muốn. Vì vậy, bạn có thể nói, "này, hãy tạo một kế hoạch về điều này và tham khảo ý kiến RoverDuck." Và sau đó bạn nhận được một đánh giá phản biện nhanh chóng trên các họ mô hình khác nhau.
Mở rộng và Đánh giá Mô hình Mới
Bây giờ, hãy tiếp tục. Điều thứ ba mà chúng tôi muốn nói đến là, làm thế nào để chúng tôi mở rộng quy mô (at scale) các mô hình mới? Quá trình chúng tôi thực hiện là gì? Ban đầu, nó rất lộn xộn đối với chúng tôi. Nhưng trong khoảng hai năm rưỡi qua, chúng tôi đã thực hiện rất nhiều công việc để đảm bảo chúng tôi rất có phương pháp trong cách chúng tôi tiếp cận mô hình này.
Vì vậy, bạn có thể thấy, và Robert có một mô hình để thử. Chúng tôi tích hợp (onboard) mô hình đó vào cái mà chúng tôi gọi là KAPI, là API của Copilot. Và sau đó chúng tôi có một endpoint. Và sau đó từ endpoint đó, ba điều thực sự cần phải xảy ra.
Thứ nhất, như tất cả các bạn đều biết, bạn phải tiếp tục làm việc trong harness và làm việc trong prompt của mình. Vì vậy, đối với chúng tôi, chúng tôi có một harness đa mô hình (multi-model harness), phải không? Vì vậy, đó không chỉ là một họ mô hình. Vì vậy, chúng tôi phải đến đó và đảm bảo rằng chúng tôi cập nhật các prompt hệ thống. Đó là một vòng lặp rất chặt chẽ và lưu lượng truy cập vào đó.
Sau đó, chúng tôi phải đảm bảo hai giao diện là đúng và được tối ưu hóa. Sau đó, chúng tôi phải, và chúng tôi không làm điều này nhiều nữa, nhưng chúng tôi phải thực hiện vòng lặp tác nhân (agent loop) một chút. Và sau đó nhiều công việc hơn nữa được dành cho quản lý ngữ cảnh (context management), vào nén/thu gọn (compaction), vào việc đảm bảo rằng chúng tôi đạt được tỷ lệ cache hit phù hợp nói chung.
Sau đó, từ đó, chúng tôi làm hai việc. Chúng tôi chạy các điểm chuẩn ngoại tuyến (offline benchmarks). Và sau đó chúng tôi cũng tiến hành thử nghiệm nội bộ (internal dogfooding). Hãy coi đó là các điểm chuẩn trực tuyến (online benchmarks) nói chung. Vì vậy, rất nhiều nhà phát triển của Microsoft sử dụng nó, rất nhiều nhà phát triển của GitHub sử dụng nó. Và chúng tôi có một nhóm người dùng khác mà chúng tôi hợp tác rất chặt chẽ để nhận phản hồi. Vì vậy, chúng tôi có các điểm chuẩn ngoại tuyến đó, và sau đó chúng tôi có thử nghiệm nội bộ đó.
Sau đó, từ đó, chúng tôi chắc chắn tìm thấy điều này với Anthropic. Và đây là một bản trình bày, trước đây chúng tôi thường viết một tài liệu, bây giờ chúng tôi viết một tài liệu và mở rộng nó chi tiết, nơi chúng tôi nói, đây là tất cả những gì chúng tôi đang thấy. Và sau đó chúng tôi lặp lại với họ về những thay đổi mà chúng tôi cần, hoặc ở API, hoặc thậm chí thay đổi trên một số mô hình đó cũng như trên các checkpoint mà chúng tôi nhận được. Và sau đó từ đó, chúng tôi thực hiện một vòng lặp khác cho đến khi phát hành mô hình.
Bây giờ có hai điều rất quan trọng. Vâng, chúng tôi thực hiện ngoại tuyến. Và ngoại tuyến cung cấp cho bạn một dấu hiệu, nhưng tôi sẽ nói rằng nó sẽ không phải là thực tế của thời điểm. Bạn học được nhiều điều hơn từ các đánh giá trực tuyến (online evals) tổng thể của mình, và các thử nghiệm trực tuyến sau khi ra mắt, hơn là thực sự từ ngoại tuyến. Ngoại tuyến chỉ thiết lập một cơ sở. Và nếu cơ sở đó nhất quán, bạn sẽ biết những gì mong đợi ở đó. Và nó cung cấp cho bạn một dấu hiệu khá tốt về điều đó, những gì mong đợi. Nhưng tất cả các chi tiết không được thực hiện thông qua ngoại tuyến. Vì vậy, chúng tôi thường mất vài ngày, đôi khi thậm chí vài tuần, để điều chỉnh mọi thứ của mô hình đó thông qua các thử nghiệm trực tuyến đó. Chúng tôi thực hiện rất nhiều thử nghiệm A/B và chúng tôi rất có phương pháp về điều đó. Và chúng tôi có báo cáo hàng tuần mà chúng tôi báo cáo cho Anthropic và cũng cho tất cả các nhóm mà chúng tôi có để đảm bảo rằng chúng tôi đang điều chỉnh đúng mô hình vào đúng thời điểm.
Tối ưu hóa Harness và Đo lường Kết quả
Khi nói đến việc tối ưu hóa harness cho chúng tôi, có bốn điều. Một là xây dựng prompt và ngữ cảnh. Hai là gọi mô hình vì đó là công cụ được thực thi và sau đó tùy thuộc vào kết quả và kéo lại và nhìn lại. Và điều tôi đang nói ở đây, những nơi tôi dành nhiều thời gian nhất với nhóm thường là trong công cụ thực thi (execute tool) và xây dựng prompt và ngữ cảnh đó.
Công cụ rất quan trọng đối với chúng tôi. Bạn càng có nhiều công cụ, càng có nhiều sự nhầm lẫn xảy ra. Bạn càng phải điều chỉnh nhiều. Vì vậy, hàng trăm công cụ không phải là một điều tốt. Vì vậy, bạn muốn đảm bảo bạn đang điều chỉnh theo bề mặt và bạn đang điều chỉnh cho các tình huống chính xác với các công cụ phù hợp trong gói đó. Vì vậy, chúng tôi dành rất nhiều thời gian ở đó và tối ưu hóa mô hình đó. Và sau đó là kiểm tra quyền và chạy. Chúng tôi lại kết thúc trong việc thực thi công cụ đó. Bạn phải làm những việc đúng đắn để truyền ngữ cảnh phù hợp vào đó và sau đó đọc đúng kết quả. Vì vậy, bất cứ khi nào chúng tôi muốn giới thiệu một công cụ mới làm ví dụ, chúng tôi dành rất nhiều thời gian để đảm bảo rằng chúng tôi tối ưu hóa harness ở cả cấp độ mô hình và cấp độ thực thi công cụ.
Điều này có ý nghĩa gì ở cấp độ cao? Có hai điều. Bạn phải có cả điểm chuẩn đã công bố và điểm chuẩn đã tạo ra. Nhưng quan trọng hơn, hãy thử nghiệm nội bộ (dogfooding) với AMD và đảm bảo rằng bạn đã thiết lập e-val trực tuyến. Và đảm bảo bạn có thể tin tưởng vào số liệu thống kê.
Sau đó, điều thứ hai là, bạn muốn đo lường kết quả (outcomes), không phải hoạt động (activity). Khi tôi nói về các công cụ, chẳng hạn như tỷ lệ chấp nhận trên một dòng mã, điều đó vẫn ổn. Tỷ lệ tồn tại (survival rate) thực sự là một số liệu thậm chí còn tốt hơn nói chung, bởi vì nếu bạn đã chấp nhận nó và sau đó bạn đã xóa nó, thì điều đó thực sự không đạt được kết quả tổng thể. Vì vậy, mặc dù tôi có thể có tỷ lệ chấp nhận tuyệt vời, nếu tỷ lệ tồn tại kết thúc rất thấp, điều đó có nghĩa là chúng tôi đã không làm đúng việc. Vì vậy, điều rất quan trọng là nếu bạn ở trong bộ phận sản phẩm và sản phẩm thực sự thay đổi trong RFAI rằng bạn đang tối ưu hóa cho các kết quả chứ không chỉ là các hàng riêng lẻ. Như tôi đã nói, bạn sẽ kết thúc việc tối ưu hóa cho một số liệu, sau đó gắn thẻ, gắn thẻ phép đo của toàn bộ sản phẩm của bạn.
Tổng kết
Được rồi, với điều đó, một lần nữa, chúng ta đã xem xét bộ nhớ đệm lời nhắc (prompt caching), chiến lược cố vấn, và sau đó chúng ta đã nói một chút về đo lường và cách chúng tôi cải thiện harness của mình. Và sau đó đối với chúng tôi, tôi chỉ muốn để lại lời cảm ơn. Thực sự rất vui khi lại được ở bên các bạn. Hy vọng các bạn học được một vài điều hôm nay.