Hongming@hongming731
85

Thủ thuật

Xây dựng hạ tầng Agent doanh nghiệp, phương pháp đánh giá IRT và thực tiễn thiết kế AI

(giờ Việt Nam)

Tóm tắt AI

Bài viết tổng hợp các chiến lược xây dựng hạ tầng Agent cho tổ chức, ứng dụng lý thuyết IRT để đánh giá mô hình chính xác hơn và quy trình phối hợp giữa con người với AI trong thiết kế sản phẩm.

Bản dịch AI

http://x.com/i/article/2076451125000286208

Bản tin sáng BestBlogs · 13/07 | Tổ chức sử dụng Agent để tiếp nhận bộ nhớ và ngân sách, đánh giá mô hình quay trở lại với chất lượng câu hỏi, thiết kế chuyển hướng sang hệ thống có thể điều chỉnh.

Đọc trực tuyến bản tin sáng kỳ này

BestBlogs.dev là trợ lý đọc tin cá nhân được hỗ trợ bởi AI. Đây là nội dung bản tin sáng hàng ngày dành cho tất cả mọi người. Nếu bạn muốn nội dung được tổng hợp dựa trên sở thích và thói quen đọc của mình, hãy trải nghiệm tính năng "Bản tin sáng của tôi".

Lời dẫn

Ba bài phân tích chuyên sâu hôm nay không nhất thiết phải gộp chung vào một chủ đề. Chúng lần lượt thảo luận về cách các tổ chức tiếp nhận Agent, cách các đội ngũ đánh giá điểm số mô hình và cách các nhà thiết kế biến những ý tưởng mơ hồ thành giao diện và tài liệu thương hiệu có thể lặp lại. Bối cảnh chung rất đơn giản: các công cụ đang ngày càng có khả năng thực thi tốt hơn, nhưng khi đưa chúng vào môi trường thực tế, con người vẫn phải chịu trách nhiệm về các ranh giới, sự phán đoán và phản hồi.

Bản tin sáng hai ngày trước đã đề cập đến vấn đề bộ nhớ doanh nghiệp và trách nhiệm trong lập trình dài hạn. Hôm nay, chúng ta có thể đẩy góc nhìn tiến xa hơn một bước: khi Agent bắt đầu tham gia công việc với ngữ cảnh và mục tiêu cụ thể, điều các đội ngũ cần không phải là những tuyên bố năng lực hào nhoáng, mà là những phương pháp có thể nhìn thấu năng lực, kiểm soát năng lực và liên tục điều chỉnh.

Khi đọc, bạn có thể coi mỗi bài viết là một tài liệu ra quyết định cụ thể: bài thứ nhất đặt câu hỏi về cách triển khai ủy quyền, bài thứ hai hỏi về cách tin tưởng vào điểm số, và bài thứ ba hỏi về cách kiểm chứng ý tưởng một cách lặp đi lặp lại. Chúng hướng tới các nhóm đối tượng khác nhau, nhưng đều nhắc nhở chúng ta rằng năng lực kỹ thuật chỉ trở thành năng lực có thể sử dụng lâu dài khi nó đi vào một vòng lặp phản hồi rõ ràng.

★ Phân tích chuyên sâu 1: Xây dựng tương lai của cơ sở hạ tầng Agent: Cách Claude Platform hướng tới năng lực cấp tổ chức

Thảo luận của Claude về "agentic infrastructure" (cơ sở hạ tầng đại lý) không tập trung vào việc mở rộng giao diện mô hình, mà tập trung vào cách tổ chức tiếp nhận các phần mềm đại lý có khả năng hành động liên tục. Tài liệu đề xuất rằng các managed agents (đại lý được quản lý) có thể sở hữu bộ nhớ, mục tiêu kết quả và ranh giới danh tính rõ ràng hơn; chúng cũng có thể gọi lẫn nhau thông qua API hoặc các MCP server tinh gọn. Nói cách khác, Agent không còn chỉ là người trả lời trong một cuộc hội thoại đơn lẻ, mà có thể trở thành một đơn vị cộng tác mang theo trạng thái và có thể được phân công nhiệm vụ. Xem chi tiết tại

Điều này có thể đối chiếu với hướng dẫn đánh giá Agent của Anthropic: khả năng gọi công cụ nhiều vòng, sửa đổi trạng thái và thích ứng với kết quả trung gian đồng nghĩa với việc đối tượng đánh giá là sự kết hợp giữa harness (khung điều khiển) vận hành nó và mô hình, chứ không chỉ riêng mô hình. Đưa điểm này trở lại bài viết, bộ nhớ, quyền hạn và sự bàn giao cho con người không còn chỉ là chi tiết thực thi, mà là một phần của việc liệu có thể kiểm chứng hành vi hệ thống hay không.

Điều này sẽ thay đổi các đánh giá về mặt kỹ thuật. Trước đây, để mô hình hoàn thành các bước phức tạp, các đội ngũ thường viết rất nhiều quy tắc cố định vào lớp điều khiển bên ngoài. Khi năng lực mô hình tăng lên, harness có thể tinh gọn hơn: để nhiều đại lý cạnh tranh các phương án khác nhau, hoặc sử dụng chiến lược đối kháng và cố vấn để đưa ra kiểm chứng. Tuy nhiên, "tinh gọn" không có nghĩa là không cần kỹ thuật. Nếu danh tính, quyền hạn, phạm vi bộ nhớ và mối quan hệ gọi hàm không được thiết kế rõ ràng, tự động hóa sẽ chỉ làm lan truyền các rủi ro phân tán nhanh hơn.

"Kết quả" trong tài liệu cũng đáng để phân tích kỹ. Nó không chỉ là việc nhiệm vụ có hoàn thành hay không, mà còn bao gồm việc đại lý đã sử dụng bao nhiêu ngân sách, đã thông qua những công cụ nào, và ở khâu nào cần nâng cấp lên cho con người. Đối với một đại lý viết code, kết quả có thể là một bản ghi sửa đổi và kiểm thử có thể tái lập; đối với đội ngũ dịch vụ, đó có thể là việc tổng hợp lịch sử khách hàng thành các đề xuất chờ xác nhận, thay vì thay mặt con người cam kết với khách hàng. Chỉ khi định nghĩa kết quả đủ cụ thể, chúng ta mới có thể biết chính xác mình đã cải thiện điều gì khi so sánh các đại lý, các prompt hoặc các cấp độ ủy quyền khác nhau trong tương lai.

Việc sắp xếp đa đại lý cũng có cái giá của nó. Các chiến lược cạnh tranh, đối kháng và cố vấn có thể mang lại sự kiểm chứng lẫn nhau, nhưng cũng làm tăng khả năng giao tiếp, gọi hàm trùng lặp và gây mờ nhạt trách nhiệm. Các tổ chức nên làm ổn định đầu vào, đầu ra và kiểm tra thủ công của một nhiệm vụ đơn đại lý trước, rồi mới đánh giá xem có thực sự cần thêm vai trò thứ hai hay không. Nếu một thất bại không thể xác định được là do bộ nhớ, công cụ, mô hình hay quyền hạn, thì việc thêm nhiều đại lý thường chỉ làm cho việc chẩn đoán khó khăn hơn chứ không tự động cải thiện độ tin cậy.

Các ví dụ về lưu trữ tri thức sản xuất và phát triển phần mềm end-to-end trong tài liệu cho thấy cơ sở hạ tầng này không chỉ nhắm vào việc tạo code. Điều mà nhiều tổ chức thực sự thiếu hụt là tính liên tục của lịch sử khách hàng, phán đoán báo giá, kinh nghiệm tùy chỉnh và ra quyết định liên phòng ban. Trước khi giao những nội dung này cho đại lý, cần biết thông tin nào có thể truy xuất, kết luận nào bắt buộc phải quay lại cho con người xác nhận, và ai có thể sửa đổi chúng trong điều kiện nào. Bộ nhớ không phải cứ nhiều là tốt; bộ nhớ không có nguồn gốc, quyền hạn và cơ chế cập nhật thường chỉ tạo ra sự tự tin khó truy xuất nguồn gốc hơn.

Nhịp độ áp dụng của doanh nghiệp do đó quan trọng hơn các bản demo sản phẩm. Đề xuất của Claude là bắt đầu đo lường từ tốc độ cá nhân, sau đó xem xét năng suất nhóm, và cuối cùng mới mở rộng ra kết quả liên nhóm. Trình tự này giúp ROI không chỉ dừng lại ở cảm giác hoàn thành nhiệm vụ đơn lẻ, mà còn dành chỗ cho an toàn, tuân thủ và đánh giá. Nếu đại lý có thể vận hành theo kết quả và ngân sách, thì bản thân ngân sách nên trở thành một phần của ủy quyền, thay vì là hóa đơn chi phí nhìn thấy sau khi sự việc đã rồi.

Đội ngũ kỹ thuật sẽ không vì thế mà rút lui. Việc hiểu hệ thống, vận hành và xử lý sự cố vẫn do con người đảm nhận, đại lý chỉ khuếch đại phạm vi thực thi dựa trên những năng lực đó. Đối với những độc giả đang thử nghiệm phương án đa đại lý, nội dung này phù hợp để kiểm tra một vấn đề cụ thể: khi đại lý chủ động phát hiện vấn đề và đề xuất sửa chữa, tổ chức đã chuẩn bị sẵn quyền hạn có thể giải thích, điều kiện dừng và lối vào để xem xét lại cho nó chưa?

Từ góc độ triển khai, điểm khởi đầu khả thi tối thiểu thường không phải là cho đại lý nhiều tự do hơn, mà là chọn một khâu có ranh giới rõ ràng và kết quả có thể kiểm tra lại. Đội ngũ có thể quan sát trước xem nó cần tài liệu gì, khi nào bị kẹt, con người can thiệp vào thì thay đổi điều gì, rồi mới quyết định có mở rộng phạm vi bộ nhớ hoặc quyền gọi hàm hay không. Những ghi chép như vậy cũng sẽ giúp việc tối ưu hóa sau này có căn cứ hơn: là do mô hình hiểu sai, kết nối công cụ chưa tốt, hay bản thân nhiệm vụ chưa được giải thích rõ ràng. Giá trị của cơ sở hạ tầng cuối cùng được thể hiện ở việc liệu những phản hồi có vẻ đơn giản này có thể được tích lũy liên tục hay không.

★ Phân tích chuyên sâu 2: Đừng dùng phương pháp của những năm 50 để đánh giá mô hình: Tái cấu trúc benchmark LLM bằng tâm trắc học

Chia sẻ từ AI Engineer bắt đầu từ một hiểu lầm phổ biến: nén benchmark thành một tỷ lệ chính xác duy nhất dễ khiến người ta lầm tưởng điểm số là toàn bộ năng lực của mô hình. Alejandro Vidal đề xuất giữ lại ma trận phản hồi đầy đủ "Câu hỏi × Mô hình", đồng thời quan sát độ khó của câu hỏi, khả năng phân biệt mô hình của câu hỏi và giá trị ước tính năng lực của mô hình. Như vậy, đánh giá không còn chỉ là xếp hạng trên bảng xếp hạng, mà là đặt câu hỏi liệu bản thân đề thi này có đáng tin hay không. Xem chi tiết tại

Lý thuyết ứng đáp câu hỏi (IRT) cung cấp một ngôn ngữ có thể vận hành. Nó có thể ước tính độ khó của câu hỏi, năng lực theta của mô hình, độ phân biệt và khoảng tin cậy. Hai mô hình có tỷ lệ chính xác thô gần bằng nhau chưa chắc đã không có sự khác biệt dưới góc nhìn này: nếu chúng trả lời đúng các câu hỏi có độ khó và độ phân biệt khác nhau, thì kết luận không thể chỉ nhìn vào tổng điểm. Đối với những người mua mô hình hoặc duy trì đánh giá nội bộ, điều này hữu ích hơn việc thêm một bảng xếp hạng tổng thể.

Đây không phải là việc bê nguyên thuật ngữ đo lường giáo dục sang AI. Nghiên cứu gần đây của Nature cũng liệt kê IRT là một trong những phương pháp đánh giá AI, nhấn mạnh rằng đo lường ở cấp độ thực thể nên đồng thời chú trọng vào độ nhạy đối với năng lực mục tiêu và khả năng loại trừ các năng lực không liên quan. Nó không quyết định thay cho đội ngũ nên đo lường cái gì, nhưng có thể giúp đội ngũ biến việc "tại sao tin vào điểm số này" thành một vấn đề có thể kiểm tra được.

Tài liệu cũng hướng sự chú ý trở lại chất lượng câu hỏi. Độ phân biệt âm hoặc các câu hỏi nhiễu có thể cho thấy việc gắn nhãn có vấn đề; phân tích phần dư có thể tìm ra các câu trả lời khó xảy ra, các mẫu suy luận không ổn định, thậm chí gợi ý rằng một số câu hỏi có thể đã bị rò rỉ trên internet công cộng. Chìa khóa ở đây không phải là coi phương pháp thống kê như một bộ lọc vạn năng, mà là xử lý tách biệt giữa "mô hình trả lời sai" và "câu hỏi có vấn đề". Nếu cả hai trộn lẫn vào nhau, việc huấn luyện và lựa chọn mô hình sau này sẽ dựa trên những phản hồi không đáng tin cậy.

Sự tách biệt này đặc biệt quan trọng đối với việc đánh giá hàng ngày. Một đội ngũ có thể thấy mô hình mới có tổng điểm cao hơn một chút và chuẩn bị đưa nó vào kịch bản khách hàng; nhưng nếu sự dẫn đầu chủ yếu đến từ một vài câu hỏi đáng ngờ, hoặc sự khác biệt giữa hai mô hình nằm trong khoảng tin cậy, thì kết luận nên thận trọng hơn. Ngược lại, khi một số câu hỏi có thể phân biệt ổn định các cấp độ năng lực, chúng xứng đáng được giữ lại và duy trì trọng điểm. Tập đánh giá không phải là ấn phẩm phát hành một lần, mà là một bộ công cụ đo lường cần được kiểm tra, thay thế và ghi lại các thay đổi phiên bản liên tục.

IRT cũng làm cho "ít câu hỏi hơn" trở thành một lựa chọn có thể thảo luận nghiêm túc. Nếu có thể chọn ra những câu hỏi có hàm lượng thông tin cao hơn và giữ lại tập anchor đủ để đối chiếu kết quả lịch sử, việc đánh giá có thể dành thời gian cho những mẫu thực sự có thể thay đổi phán đoán. Đối với các đội ngũ cần kiểm tra hệ thống đại lý thường xuyên, điều này có nghĩa là có thể dành ngân sách hạn hẹp cho các nhiệm vụ bao phủ các mô hình thất bại thực tế, thay vì dùng một lượng lớn câu hỏi tương tự để đổi lấy một tổng điểm có vẻ chính xác. Tiền đề vẫn là ghi lại việc lộ đề, phiên bản và ranh giới áp dụng của câu hỏi.

Khi benchmark trở nên nhỏ hơn và thích ứng hơn, các vấn đề quản trị cũng xuất hiện. Chia sẻ đề cập rằng có thể chọn câu hỏi cho các người dùng hoặc tổ chức khác nhau dưới các chiến lược phơi nhiễm; các tập anchor và fingerprint cung cấp thước đo chung và giúp điều tra nghi vấn rò rỉ. Các mẫu phản hồi cũng có thể được sử dụng để quan sát tính công bằng của nhóm, hoặc phân tích xem giữa các mô hình có tồn tại checkpoint chia sẻ, chưng cất hoặc liên kết thế hệ hay không. Chúng đều là manh mối phán đoán, không nên bị coi trực tiếp là kết luận nhân quả.

Điều này tạo ra sự đối chiếu thực tế với bài thảo luận về Agent cấp tổ chức ở bài thứ nhất: bài trước quan tâm đến cách đại lý đi vào môi trường sản xuất, bài này nhắc nhở chúng ta rằng bất kỳ phán đoán nào về "nâng cao năng lực" đều phụ thuộc vào việc công cụ đo lường có trung thực hay không. Nếu bạn đang so sánh nhiều mô hình, hãy mở bài chia sẻ này ra, kiểm tra xem benchmark hiện tại có thể giải thích sai số, chất lượng câu hỏi và tính không chắc chắn hay không, rồi hãy quyết định trả tiền cho điểm số nào.

★ Phân tích chuyên sâu 3: Sử dụng công cụ AI để mở ra phương thức thiết kế hoàn toàn mới: Từ Agent lập trình đến hệ thống thương hiệu có thể lặp lại

Phần tổng kết thiết kế của Y Combinator cho thấy một phương thức cộng tác rất cụ thể: nhà thiết kế E Bufar sử dụng Conductor và paper.design để hoàn thành dự án end-to-end, dùng Pinterest để thu thập tham chiếu hình ảnh, và cũng dùng Aqua để thuật lại ý tưởng thay vì gõ phím liên tục. Danh sách công cụ không phải là trọng tâm; điều đáng chú ý hơn là cô ấy làm rõ các yêu cầu, ảnh chụp màn hình và mood board trước, sau đó mới để Agent lập trình khám phá trong phạm vi tham chiếu xác định. Xem chi tiết tại

Paxel là một trong những thử nghiệm đó: nó đọc các bản ghi lập trình, chuyển đổi prompt, mô hình sử dụng, thói quen và những khoảnh khắc thất bại thành phản hồi mang tính trò chơi. Ví dụ này cho thấy AI tham gia thiết kế không chỉ là tạo ra một bức ảnh hoặc một đoạn code ở bước cuối cùng. Chỉ cần đầu vào và phương thức tương tác được thiết kế tốt, các bản ghi trong quá trình cũng có thể trở thành tư liệu sản phẩm, cho phép người dùng nhìn thấy hành vi của chính mình thay vì chỉ nhìn thấy một kết quả.

Mô tả sản phẩm của Paxel làm cho đầu vào trở nên cụ thể hơn: nó đọc các phiên hội thoại Claude, Codex và Cursor để giúp nhà phát triển hiểu thói quen xây dựng của chính mình. Điều này bổ sung một lớp ranh giới thực tế cho phương pháp trong video: dữ liệu quá trình có thể nhìn thấy giúp phản tư, nhưng đội ngũ vẫn nên xác nhận trước phiên hội thoại nào có thể tải lên, cách xử lý ngữ cảnh nhạy cảm và phản hồi sẽ được ai sử dụng.

Đối với cách làm của Paxel và Sodazine, trình tự mà bài chia sẻ đưa ra rất đơn giản: viết brief chi tiết, cung cấp ảnh chụp màn hình và mood board, để đại lý nghiên cứu tham chiếu, sau đó tạo ra các widget tương tác nhỏ có thể điều chỉnh shader, bố cục và hiệu ứng động. Nguyên mẫu có thể điều chỉnh dễ bộc lộ vấn đề hơn một bức ảnh tĩnh trông có vẻ đã hoàn thiện. Nó cho phép đội ngũ thảo luận "tốc độ ở đây có quá nhanh không", "thẻ này có quá giống đối tượng tham chiếu không", thay vì tranh cãi qua lại trong những tính từ trừu tượng.

Brief ở đây giống như sự ngoại hóa của một phán đoán thiết kế hơn là câu thần chú cho mô hình. Nó có thể giải thích đối tượng mục tiêu, cảm xúc muốn giữ lại, các trường hợp tương tự phải tránh và phần nào của trang web đáng thử nghiệm trước. Ảnh chụp màn hình và mood board cũng không phải để đầu ra bắt chước từng pixel, mà là giúp đội ngũ thiết lập tham chiếu chung. AI có thể tăng tốc độ đưa ra các tùy chọn, nhưng không thể thay thế việc đưa ra lựa chọn giữa các tùy chọn. Khi tham chiếu không đủ hoặc hướng đi mơ hồ, tạo ra nhanh hơn chỉ làm khuếch đại sự mơ hồ nhanh hơn.

Giá trị của các widget nhỏ còn nằm ở việc biến tranh luận thẩm mỹ thành những thay đổi có thể quan sát được. Ví dụ, cho phép điều chỉnh trực tiếp mật độ bố cục, nhịp điệu hiệu ứng động hoặc tham số shader, đội ngũ có thể phán đoán loại nào phù hợp hơn trong trạng thái cụ thể, thay vì phải dựa vào trí nhớ để so sánh vài vòng ảnh chụp màn hình. Những gì thu được không phải là một thành phẩm không thể chạm tới, mà là một bộ tài liệu thiết kế có thể tiếp tục được sửa đổi. Do đó, Agent lập trình giống như một người đồng đội giúp giảm chi phí thử nghiệm, nhà thiết kế vẫn cần quyết định biến số nào đáng mở, biến số nào cần giữ ổn định.

Phần thương hiệu của Startup School đã mở rộng phương pháp này thành hệ thống có thể tái sử dụng: thẻ diễn giả tạo sinh, paper shader, hiệu ứng động xã hội liền mạch và vé sự kiện cá nhân hóa, tất cả đều có thể từ vật liệu dùng một lần trở thành các bộ phận có thể tiếp tục sửa đổi cho các dự án sau. AI làm cho phần mềm dễ chỉnh sửa hơn, cũng làm cho thiết kế dễ lặp lại hơn; nhưng điều này không tự động mang lại tính nhận diện. Việc lựa chọn tham chiếu, gu thẩm mỹ và hướng đi rõ ràng vẫn quyết định liệu cuối cùng có chỉ là sự chắp vá nhanh chóng hay không.

Nếu bạn đang sử dụng Agent lập trình để làm thương hiệu hoặc trang sản phẩm, phần tổng kết này phù hợp để xem trước khi bắt đầu. Hãy chuẩn bị brief và tham chiếu có thể phán đoán, sau đó biến các biến số muốn thử thành các widget nhỏ, cuối cùng mới cân nhắc mở rộng sản xuất. Cách này vừa tận dụng được tốc độ của công cụ, vừa giữ được phán đoán thẩm mỹ ở nơi thực sự cần nó.

Điều này cũng mang lại một lời nhắc nhở cho phương thức cộng tác: càng sớm để người có khả năng ra quyết định nhìn thấy nguyên mẫu có thể vận hành, càng dễ tránh việc để dành phản hồi đến cuối cùng mới bùng nổ tập trung. Nhà thiết kế, kỹ sư và người phụ trách nội dung không nhất thiết phải sử dụng cùng một bộ công cụ, nhưng có thể giao tiếp xoay quanh cùng một bản brief và cùng một nhóm biến số có thể điều chỉnh. Công cụ làm cho việc sửa đổi trở nên rẻ, không có nghĩa là phải sửa đổi vô tận; các điểm dừng rõ ràng và tiêu chuẩn lựa chọn vẫn là điều kiện để quá trình lặp lại hội tụ.

Điểm tin nhanh

Ba dòng mô hình GPT-5.6 bao vây Claude Fable 5

OpenAI phát hành ba dòng mô hình GPT-5.6 Sol, Terra và Luna, lần lượt hướng tới năng lực cao nhất, cân bằng hàng ngày và hiệu quả chi phí, đồng thời thông báo đã dần triển khai trên ChatGPT, Codex và API. Báo cáo liệt kê giá đầu vào/đầu ra khác nhau, cơ chế bộ nhớ đệm Prompt, cũng như các sắp xếp về chế độ suy luận cao hơn và cộng tác đa Agent; trong đó các tuyên bố về hiệu suất tương đối và chi phí đến từ bên phát hành, phù hợp để xem cùng với các điều kiện đánh giá. Nếu gần đây bạn cần chọn lại mô hình hoặc tính toán ngân sách gọi hàm, khuyến nghị mở Xem chi tiết ngay bây giờ; nếu không có kịch bản rõ ràng, có thể lưu lại, đợi tập nhiệm vụ của mình ổn định rồi so sánh sau.

KAT-Coder-V2.5 chính thức phát hành: Từ "viết code" đến "làm kỹ thuật", năng lực Agentic được nâng cao toàn diện

Kuaishou giới thiệu kỹ thuật KAT-Coder-Pro V2.5, mục tiêu là xử lý các nhiệm vụ kỹ thuật dài hạn như đọc issue, định vị thay đổi nhiều tệp, tuân thủ các quy ước hiện có và chạy kiểm thử. Bài viết tập trung vào việc xây dựng môi trường kho lưu trữ có thể chạy được: AutoBuilder liên tục tạo và xác minh cấu hình, bài viết cho biết tỷ lệ thành công khi xây dựng môi trường tăng từ 16,5% lên 57,2%, và đã tích lũy được môi trường có thể xác minh bao phủ nhiều ngôn ngữ. Độc giả muốn hiểu sự khác biệt giữa "có thể bổ sung code" và "có thể hoàn thành kỹ thuật" đáng để đọc Xem chi tiết ngay bây giờ; nó cung cấp các điều kiện huấn luyện và xác minh, chứ không chỉ là kết luận mô hình.

Mô hình tiền huấn luyện "nguyên bản hiện thân" đầu tiên trên thế giới được phát hành, tạo não bộ cho robot từ thế giới vật lý!

QuantumBit đưa tin Ant Lingbo phát hành LingBot-VA 2.0, mô tả nó là mô hình nền tảng Video-Action nguyên bản hiện thân (embodied-native). Bài viết sử dụng ví dụ về khúc côn cầu trên băng, dọn dẹp bàn làm việc và gắp băng chuyền để giải thích tư duy của nó: hệ thống không chỉ phản ứng với khung hình hiện tại, mà còn phải dự đoán trạng thái vật lý tiếp theo, sau đó căn chỉnh trình tự hành động vào nhiệm vụ. Đối với những người quan tâm đến trí tuệ hiện thân, bài viết Xem chi tiết này có thể đọc ngay bây giờ, đặc biệt phù hợp làm tài liệu nhập môn để hiểu sự khác biệt giữa "điều khiển dự đoán" và các phương án phản ứng truyền thống.

Chi phí suy luận AI lần đầu tiên được tính toán rõ ràng: Tỷ lệ sử dụng GPU dưới 52%, tuyệt đối đừng tự xây dựng!

Bài viết trên InfoQ này cố gắng sử dụng mô hình chi phí 5 chiều để so sánh việc tự xây dựng suy luận với API, và lấy tỷ lệ sử dụng GPU 52% làm điểm hòa vốn được suy ra trong bài. Giá trị thực tế của nó không nằm ở việc đưa ra một ngưỡng có thể sao chép, mà ở việc nhắc nhở các đội ngũ đưa tỷ lệ sử dụng, thời gian nhàn rỗi, vận hành và biến động kinh doanh vào hạch toán chi phí; kết luận dưới các phần cứng, mô hình và tải trọng khác nhau vẫn sẽ thay đổi. Nếu bạn đang thảo luận về việc có nên mua card hay di chuyển dịch vụ, khuyến nghị đọc Xem chi tiết trước rồi lấy dữ liệu của mình tính toán lại; nếu không, có thể để dành làm tài liệu tham khảo trước khi đánh giá ngân sách.

Phổ cập kiến thức vạn chữ: Một nghìn "mô hình thế giới" đang được phát hành, rốt cuộc mô hình thế giới là gì?

Bài viết tập hợp các thảo luận của Li Fei-fei, Packy McCormick và những người khác, cố gắng tách "mô hình thế giới" thường được sử dụng thành các khái niệm có thể phán đoán hơn: trình kết xuất (renderer), trình mô phỏng (simulator) và trình lập kế hoạch (planner) không tương đương nhau, và dự đoán tương tác mới là một ranh giới quan trọng trong đó. Nó cũng nhìn lại sự tiến hóa kỹ thuật, thách thức dữ liệu và hướng đi tương lai, giúp độc giả tránh nhầm lẫn giữa tạo video, biểu diễn 3D và hệ thống điều khiển. Đối mặt với các sản phẩm liên quan được phát hành dày đặc gần đây, đáng để đọc Xem chi tiết trước để thiết lập khung khái niệm, rồi mới phán đoán tuyên bố của từng nhà nằm ở tầng nào.

Công cụ tốt hơn lại làm cho việc đánh giá code Copilot trở nên tệ hơn. Dưới đây là cách chúng tôi đã cải thiện thực tế.

Phần tổng kết của GitHub rất phù hợp để phản bác một trực giác: đổi sang các công cụ grep, glob và view được bảo trì tốt hơn không nhất thiết làm cho Agent đánh giá code mạnh hơn. Đội ngũ phát hiện chi phí tăng lên, các vấn đề phát hiện ra lại ít đi, sau đó viết lại chỉ dẫn, để việc đánh giá bắt đầu từ việc thu hẹp phạm vi diff rồi mới đọc ngữ cảnh, cuối cùng giảm chi phí trung bình khoảng 20% trong khi vẫn duy trì chất lượng. Độc giả đang gỡ lỗi đánh giá code hoặc chiến lược gọi công cụ nên xem Xem chi tiết ngay bây giờ; nó cung cấp tư duy phân tách nhiệm vụ có thể di chuyển được.

Ý thức × Loop: Thực tiễn tốt nhất để Loop tự tiến hóa qua các Session

Alibaba Tech quy việc cải thiện Agent xuyên suốt các phiên hội thoại về việc để kinh nghiệm có thể tự động tải: thông qua các tầng như AGENTS.md, MEMORY.md và USER.md để lưu giữ các ràng buộc, sở thích người dùng và kinh nghiệm nhiệm vụ, đồng thời giữ lại các van thủ công không nên giao cho đại lý tự sửa đổi. Bài viết lấy ví dụ khảo sát của công ty FDE, nhấn mạnh các con số có thể truy xuất và phán đoán có ràng buộc, mục tiêu không phải là để vòng lặp chạy vô hạn, mà là giảm bớt việc dạy lại từ đầu mỗi lần. Nếu bạn đang xây dựng tự động hóa lâu dài, có thể đọc Xem chi tiết và chọn ra một kinh nghiệm có thể xác minh để củng cố trước; nếu chỉ muốn xem phát hành mô hình thì có thể đọc sau.

Đọc thêm

Tỷ lệ giới hạn lưu lượng giảm 10 lần: Cách cổng Bailian tái cấu trúc giới hạn lưu lượng mô hình lớn bằng RocketMQ LiteTopic

Alibaba Cloud Developer tổng kết thiết kế của cổng Bailian trong việc thực hiện cách ly người thuê, hạn ngạch khác biệt và định hình lưu lượng dưới tài nguyên GPU hạn chế, đồng thời giải thích lý do chọn RocketMQ LiteTopic. Bài viết cho biết sau khi cải tạo, tỷ lệ giới hạn lưu lượng giảm 10 lần, điểm trọng tâm đáng học hỏi là phương thức quản trị chuyển từ "chống spam" sang chịu trách nhiệm đồng thời cho tài nguyên và trải nghiệm của nhiều người thuê. Xem chi tiết phù hợp cho các đội ngũ kỹ thuật nền tảng và dịch vụ suy luận đọc khi thiết kế chiến lược giới hạn lưu lượng.

AI4S cần những kẻ điên và những kẻ đầy tham vọng | Đối thoại với Odin của Valhalla: "Nếu thần tồn tại, làm sao tôi có thể dung thứ cho việc mình không phải là thần?"Road Podcast

Cuộc đối thoại giữa Crossroads và người sáng lập Valhalla, Odin, nói về trải nghiệm của anh ấy từ phòng thí nghiệm đến khởi nghiệp AI for Science, cũng như tầm nhìn về mô hình thế giới phân tử toàn phương thức và trí tuệ nhân tạo khoa học tổng quát. Nội dung bao gồm cả tài chính, động lực và lựa chọn cá nhân trong khởi nghiệp khoa học, phù hợp với những độc giả muốn hiểu cách người sáng lập thuật lại tầm nhìn nghiên cứu dài hạn. Xem chi tiết có thể mở khi có thời gian nghe trọn vẹn.

Tại sao bây giờ chính là thời điểm để đưa AI trở lại cục bộ

Bàn tròn của AI Engineer cho rằng, khả năng sử dụng của AI cục bộ không chỉ phụ thuộc vào chất lượng mô hình, mà còn phụ thuộc vào việc Agent, truy cập tệp, công cụ dòng lệnh, thiết bị ngoại vi và phần mềm triển khai có thể làm việc cùng nhau hay không. Quyền riêng tư, tính dự đoán được của chi phí và sự tiến bộ của phần cứng biên làm cho việc triển khai cục bộ trở lại thành một lựa chọn cụ thể, thay vì chỉ là một biểu đạt lập trường. Xem chi tiết phù hợp để xem khi đánh giá ranh giới giữa đám mây và thiết bị đầu cuối.

Tổng hợp toàn diện các kỳ lân mới tại Trung Quốc năm 2026: 3 ngày một công ty, AI và robot chiếm một nửa, DeepSeek có định giá cao nhất

Founder Park dựa trên dữ liệu của IT Juzi để tổng hợp các kỳ lân mới trong nửa đầu năm 2026, bài viết quan sát mức độ tập trung của AI, robot và sản xuất tiên tiến từ số lượng, định giá, thành phố và phân bổ ngành. 67 công ty, thị phần thành phố và cấu trúc định giá trong báo cáo có thể được dùng làm một tập mẫu để hiểu bản đồ tài chính khởi nghiệp, nhưng khẩu độ cụ thể vẫn đáng để quay lại dữ liệu gốc để xác nhận. Xem chi tiết phù hợp cho những người quan tâm đến công nghiệp và đầu tư lưu lại đọc.

Tại sao các công ty AI lại mời triết gia vào phòng thí nghiệm?

Viện nghiên cứu Tencent bắt đầu từ thông điệp AI của Vatican và thực tiễn của Anthropic, Google DeepMind, thảo luận về lý do tại sao các phòng thí nghiệm tiên phong lại đưa triết học, lựa chọn giá trị và khả năng giải thích vào hiện trường nghiên cứu. Nó không đơn giản hóa đạo đức thành khẩu hiệu tuyên truyền, mà nhìn nhận các vấn đề như tập trung quyền lực, việc làm và giám sát trong các động lực kỹ thuật và ràng buộc thực tế. Xem chi tiết phù hợp để bổ sung chiều kích phi kỹ thuật khi thảo luận về căn chỉnh hoặc quản trị.

Nhà máy biết mơ: Machinecraft 100 người làm thế nào để tạo ra bộ não doanh nghiệp

Trường hợp của Machinecraft kể về cách một nhà máy 100 người sắp xếp kinh nghiệm trong báo giá, bản vẽ, sắp xếp thanh toán, dòng thời gian và email thành bộ nhớ doanh nghiệp có thể truy xuất, sau đó kết hợp với vector và đồ thị quan hệ để hỗ trợ các tình huống khách hàng khác nhau. Nó không bắt đầu từ việc huấn luyện mô hình mới, mà xử lý tài liệu hiện có và quyền kiểm soát giao tiếp của con người trước. Xem chi tiết phù hợp cho những người muốn đưa thảo luận về bộ nhớ tổ chức ở bài thứ nhất vào quản trị tài liệu cụ thể.

Lộ trình đọc hôm nay

Khi thời gian có hạn, hãy đọc thảo luận về Agent cấp tổ chức của Claude trước, sau đó xem IRT kiểm tra benchmark có đáng tin hay không, cuối cùng mở phần tổng kết thiết kế của YC, đặt các phương pháp ở ba cấp độ quyền hạn, đo lường và lặp lại cạnh nhau để so sánh. Nếu bạn chỉ cần một lời khuyên kỹ thuật trực tiếp hơn, có thể đọc tiếp phần tổng kết về chỉ dẫn đánh giá Copilot của GitHub.

Bạn có đặt ngân sách, bộ nhớ và quyền hạn của Agent vào cùng một bộ kiểm tra không? Khi điểm số của hai mô hình gần bằng nhau, bạn sẽ kiểm tra chất lượng câu hỏi trước hay đổi mô hình trực tiếp? Chào mừng bạn để lại bình luận sau khi đọc theo thứ tự này, và chia sẻ những đánh đổi cụ thể mà bạn gặp phải trong thiết kế hoặc triển khai.

👉 Bản tin sáng gần đây

• Bản tin sáng BestBlogs · 12/07/2026

• Bản tin sáng BestBlogs · 11/07/2026

• Bản tin sáng BestBlogs · 10/07/2026

• Tuần san BestBlogs

BestBlogs là trợ lý đọc tin cá nhân được hỗ trợ bởi AI, giúp bạn khám phá nội dung chất lượng cao thực sự phù hợp với mình, theo dõi các nguồn và chủ đề bạn quan tâm, mỗi ngày tạo ra một "Bản tin sáng của tôi" phù hợp hơn với chính bạn, chào mừng bạn trải nghiệm và theo dõi chúng tôi.

AI AgentĐánh giá mô hìnhThiết kế AIHạ tầng doanh nghiệpIRT
Xem nguyên văn trên X

Bài viết được AI dịch và tổng hợp tự động từ X: Hongming (@hongming731). Liên kết bài gốc ở phía trên. AIHOT.vn luôn dẫn nguồn đầy đủ — nếu bạn thấy điểm cần chỉnh sửa, hãy gửi ý kiến tại trang phản hồi.