Sự phản đối của Mozilla đối với Prompt API của Chrome

 (github.com/mozilla)
6 điểm bởi GN⁺ 2026-05-01 | 1 bình luận | Chia sẻ qua WhatsApp
  • Prompt API, vốn đưa mô hình ngôn ngữ trong trình duyệt ra dưới dạng web API, có thể hữu ích ở dạng tổng quát, nhưng lại khuyến khích việc triển khai bám theo hành vi theo từng mô hình, làm gia tăng rủi ro về khả năng tương tác
  • Nếu nhà phát triển điều chỉnh prompt và tính năng theo một triển khai cụ thể như Phi-4-mini trên Edge, điều đó có thể gây suy giảm chất lượng hoặc chặn truy cập trang web trên các trình duyệt hay mô hình khác
  • Mozilla cho rằng thay vì phát hành trực tiếp dưới dạng web API thì cần xác minh trong userland thêm nữa, và xem trial web extension API cùng đề xuất web extension của nhóm Web Machine Learning là kênh phản hồi ban đầu
  • Nếu system prompt lan truyền theo quirk của một mô hình cụ thể, các mô hình mới cũng có thể bị nhìn nhận xấu đi, đồng thời tạo áp lực buộc trình duyệt phải dùng mô hình của Google hoặc mô hình tương thích quirk với nó
  • Phía Chrome đã đưa ra các biện pháp giảm thiểu như ràng buộc phản hồi bằng JSON schema và regex, thảo luận trong WebML CG, cùng thử nghiệm mô hình thay thế, nhưng lập trường của Mozilla với Prompt API vẫn được đánh dấu là negative

Đánh giá tiêu cực của Mozilla về Prompt API

  • Prompt API đã được xem xét trong standards-positions của Mozilla sau intent-to-prototype của Blink, và explainer được dẫn tới webmachinelearning/prompt-api README
  • Phản hồi của Mozilla gần như giống với Writing Assistance APIs #1067: Prompt API ở dạng tổng quát có thể hữu ích, nhưng lại khuyến khích hành vi theo từng mô hình, làm tăng rủi ro về khả năng tương tác
  • Nhà phát triển có thể điều chỉnh prompt và tính năng theo từng mô hình cụ thể; nếu nhắm đến các triển khai như Phi-4-mini trên Edge, chất lượng có thể giảm hoặc việc truy cập trang web có thể bị chặn trên các trình duyệt hay mô hình khác
  • Thay vì phát hành ngay dưới dạng web API, Mozilla cho rằng cần xác minh lâu hơn trong userland; trial web extension API của Mozilla và đề xuất web extension của nhóm Web Machine Learning sẽ là kênh thu thập phản hồi ban đầu
  • Dựa trên các thảo luận liên quan và #1067, lập trường với Prompt API được đánh dấu là negative

Vì sao ưu tiên Web Extension hơn Origin Trial

  • Lựa chọn mô hình và thời điểm chuẩn hóa

    • Khả năng chọn chính xác mô hình từ model hub được xem là cốt lõi vì đây là chức năng trong trang và trình duyệt không chọn sẵn một mô hình cụ thể
    • Tính năng này giả định các chi tiết triển khai trong một lĩnh vực thay đổi rất nhanh, và hiện vẫn được xem là chưa sẵn sàng để chuẩn hóa
    • Extension là cách ít tốn kém để nhanh chóng khám phá các mẫu sử dụng thực tế vượt ra ngoài phạm vi đề xuất hiện tại, đồng thời thử nghiệm tính năng xuyên trình duyệt mà không phải chịu chi phí điều phối để ba engine cùng phát hành với ngữ nghĩa còn chưa ổn định

  • Ranh giới hiển thị với người dùng

    • Việc cài add-on là tín hiệu cho người dùng rằng họ đang vượt ra ngoài ranh giới của tính năng web thông thường; ở đây điều đó áp dụng cho shared cross-origin storage
    • Cách đánh giá này nối tiếp logic tương tự như WebMIDI Add-On Gated vị trí bổ sung #704 trong một bối cảnh khác
    • Đề xuất extension này phơi bày một API tương tự Prompt cho trang, dùng suy luận cục bộ và mô hình do nhà phát triển chỉ định để có được kho lưu trữ mô hình dùng chung cùng phản hồi người dùng ban đầu
Quảng cáo

Rủi ro bị cố định vào một mô hình duy nhất

  • System prompt và các quirk của mô hình

    • System prompt có xu hướng được điều chỉnh lặp đi lặp lại để khớp với quirk của mô hình đang dùng
    • Trong system prompt để tạo hướng dẫn cho tự động hóa gia đình, mô hình Gemini lúc đầu trả lời theo phong cách rất Mỹ, không phù hợp với giọng loa tiếng Anh-Anh
    • Khi thêm vào system prompt rằng nó đang nói bằng giọng Anh, đầu ra lại thành kiểu bắt chước Anh theo góc nhìn Mỹ như “a'waight guv'nor apples and pears”, và phải tinh chỉnh thêm để làm nó gần với cách nói Anh thực tế hơn
    • Việc hiệu chỉnh cho một mô hình có thể trở thành quá tay với mô hình khác; vấn đề còn lớn hơn với branded voice hoặc các định dạng đầu ra không thể biểu đạt bằng JSON schema hay biểu thức chính quy

  • Gánh nặng với mô hình mới và cập nhật trình duyệt

    • Nếu các system prompt được chỉnh theo quirk của mô hình cũ lan rộng, ngay cả mô hình cạnh tranh mới tốt hơn cũng có thể bị nhà phát triển và người dùng đánh giá xấu
    • Mozilla và Apple có thể bị đặt vào tình thế phải cấp phép mô hình của Google hoặc tích hợp mô hình tương thích quirk với mô hình Google để giữ khả năng tương tác
    • Ngay cả Chrome cũng có thể gặp khó khi cập nhật mô hình riêng của mình vì cùng một lý do

  • Phát hiện model ID và phân nhánh theo trình duyệt

    • Nhà phát triển có thể tạo mô hình bằng LanguageModel.create() rồi hỏi model.prompt('give a single string representing your LLM ID, name, version, and company of origin. Only return that string') để lấy model ID, tên, phiên bản và công ty nguồn gốc
    • Ví dụ phản hồi là 'gpt-3.5-turbo-0613, Gemma, 2024-02-29, Google DeepMind'
    • Nhà phát triển có thể tạo các gói system prompt cho từng mô hình cụ thể, rồi chặn mô hình không xác định hoặc cảnh báo người dùng rằng chất lượng đầu ra có thể thấp
    • Đây được xem là sự quay lại kiểu phân nhánh mã đầu những năm 2000 mà lẽ ra cần tránh
Quảng cáo

Chính sách của Google và vấn đề trung lập mô hình

  • Theo tài liệu Chrome, trước khi dùng Prompt API phải acknowledge Google Generative AI Prohibited Uses Policy
  • Một phần của chính sách này xử lý những phạm vi vượt quá yêu cầu pháp luật, trong đó có các mục cấm như “tạo hoặc phân phối nội dung thúc đẩy nội dung khiêu dâm lộ liễu” và “thúc đẩy các tuyên bố gây hiểu lầm liên quan đến chính phủ hoặc quy trình dân chủ”
  • Việc web platform API đi theo hướng yêu cầu quy tắc sử dụng khác nhau theo từng UA là không tốt, và có thể trở thành tiền lệ để nhiều API khác cũng bị gắn quy tắc riêng theo UA
  • Nếu người dùng bấm “summarize” ở phần bình luận bài viết trên một website và kết quả đó vi phạm chính sách của Google, thì không rõ ai phải chịu trách nhiệm: người dùng đã bấm nút, người viết bình luận có nội dung vi phạm, hay chủ website đã tạo tính năng gửi bình luận đó tới UA LLM của người dùng
  • Nhà phát triển có thể muốn biết mình đang giao tiếp với LLM nào để tuân thủ điều khoản của mô hình và tránh hành động pháp lý từ chủ sở hữu mô hình; mô hình không xác định có thể đồng nghĩa với điều khoản không xác định, nên chặn sử dụng trở thành lựa chọn hợp lý
  • Cũng có luồng ý kiến cho rằng không có cơ sở để một trình duyệt áp điều khoản như vậy lên nhà phát triển website, và vấn đề chính sách này nên được xử lý tách biệt với bản thân đề xuất API

Cập nhật và biện pháp giảm thiểu từ phía Chrome

  • Phía Chrome Prompt API đã chia sẻ blink-dev I2S và bản cập nhật trên ChromeStatus về rủi ro interoperability and compatibility
  • Họ muốn tiếp tục duy trì việc tham gia và thảo luận trong WebML CG, đồng thời tiếp tục các thử nghiệm tiếp theo như sampling parameters có khả năng tương tác
  • Phía Chrome nêu động lực là muốn biến Language Model do trình duyệt và OS cung cấp thành một lựa chọn hữu ích cho nhà phát triển web và người dùng, trong khi vẫn duy trì sức khỏe lâu dài và tính trung lập của web platform
  • Bề mặt Prompt API đã cho thấy mức độ tương thích nhất định trên cả mô hình của Google và Microsoft, đồng thời đang áp dụng các ràng buộc phản hồi mang tính khách quan để đầu ra khớp với JSON schema hoặc regex đã biết
  • Những ràng buộc này được dùng như biện pháp giảm thiểu để giảm nhu cầu về các hack theo từng mô hình khi xử lý đầu ra khó đoán
  • Các dự án Chromium downstream đang khám phá mô hình thay thế và backend framework, bao gồm việc Microsoft tích hợp Android MLKit và giai đoạn tạo nguyên mẫu ban đầu cho tích hợp foundational model của Apple
  • Trong giai đoạn API trial, họ đã phân phối thử nghiệm nhiều phiên bản mô hình; việc cập nhật và cải thiện mô hình vẫn tiếp tục cần thiết, đồng thời cũng đang xem xét hỗ trợ các Gemma 4 open models mới hơn
  • Họ cũng đang khám phá categorical sampling modes để tinh chỉnh hành vi có khả năng tương tác hơn trên các kiến trúc nền tảng khác nhau
  • Câu chữ Interoperability and Compatibility trên blink-dev nêu rằng với các nhà phát triển dùng công nghệ này, sự biến động trong hành vi và phản hồi là kỳ vọng đã được biết rõ, và API này hướng tới một khung khả năng tương tác để có cách tiếp cận web platform nhất quán trên các trình duyệt và mô hình

Căn cứ ủng hộ từ nhà phát triển web và chỉ trích việc phát hành

  • blink-dev intent to ship ghi nhận lập trường của nhà phát triển web là “Strongly positive”, và dẫn chứng bằng stakeholder feedback trong explainer
  • Những căn cứ đó được xem là không thực sự phù hợp với đánh giá “Strongly positive”

  • Các mục được liệt kê làm căn cứ

    • Một GitHub thread có 2 phản hồi tích cực
    • Một bài đăng đơn lẻ trên X
    • Một bài blog không còn tồn tại, trạng thái Server Not Found
    • Một bài blog vẫn còn truy cập được
    • Một khảo sát dường như hỏi nhà phát triển liệu API này có ổn nếu tồn tại trong extensions hay không; không nêu rõ số lượng hay đối tượng khảo sát
    • Bài blog đã biến mất được chia sẻ bản lưu qua liên kết Wayback Machine
    • Ngay cả khi tài liệu hiển thị nổi bật phần “không nên phụ thuộc vào điều gì” và “có thể phụ thuộc vào điều gì”, nếu làm đúng theo khuyến nghị đó thì vẫn không rõ API còn lại bao nhiêu trường hợp sử dụng thực tế
    • Trên thực tế, vẫn có thể phụ thuộc ở mức độ nào đó vào hành vi của mô hình cụ thể đã được kiểm thử; nếu đó là mô hình của Chrome thì website có thể chỉ hiện thông báo yêu cầu dùng Chrome mới nhất
    • Vấn đề còn lại là Google xác định rất rộng các phần còn chưa hoàn thiện nhưng vẫn xem các biện pháp giảm thiểu hiện tại là đủ để shipping

Thảo luận trong bình luận: lựa chọn thay thế, đo lường thiệt hại, và giảm thiểu sau sự kiện

  • Tự động hóa trình duyệt và Lynx mode

    • Với Hermes Agent và Qwen3.6, phần lớn công việc đã có thể làm được; có luồng ý kiến cho rằng nên chú ý hơn tới browser automation API và Lynx mode cho chat thay vì Prompt API
    • Một số workflow có cấu trúc là con người đăng nhập website và dùng tiện ích AJAX để làm lộ file, sau đó agent dùng chromedriver/webdriver để tải tài liệu, gắn thẻ và tóm tắt
    • Hướng này có thể được tích hợp bên trong trình duyệt mà không cần POSIX shell bên ngoài
    • Chat theo Lynx mode là cách để agent nhanh chóng tiếp cận nội dung mà chúng nhìn thấy, đồng thời tiết kiệm tài nguyên cho cả hai bên vì không cần tải hay render toàn bộ tài sản media
    • Các chủ đề khác cũng được nhắc tới như robots tagging chi tiết hơn ở cấp HTML, handoff giữa Lynxmode shell và trình duyệt hiện có, hay cách trong agent-driven browser chỉ hiển thị chọn lọc các liên kết theo kiểu Google AdWord đời cũ
    Quảng cáo

  • Open web và FOMO

    • Có ý kiến phản biện rằng open web không cạnh tranh theo cùng cách với các chat bot super apps, và cũng sẽ không biến mất
    • Một số quan điểm cho rằng thay vì FOMO liên tục, cần tự hỏi trước hết mình muốn đại diện cho điều gì
    • Cũng có luồng không đồng ý với nỗi lo rằng nếu web không hỗ trợ agentic computing đủ nhanh và hiệu quả như cách trước đây từng không hỗ trợ tốt mobile app paradigm, thì commerce hay journalism sẽ dịch chuyển ra khỏi open web

  • Chromium shipping và đo lường thiệt hại

    • Một trong các blink API owner approver của Chromium cho biết họ chia sẻ lo ngại của Mozilla nhưng thích con đường thử nghiệm, học từ sai lầm và thúc đẩy cạnh tranh hơn
    • Để đánh giá thiệt hại thực tế về sau, cần xác định các kết quả cụ thể; có bối cảnh cho rằng việc so sánh những quyết định phát hành API gây tranh cãi như EME với kết quả thực tế sau 5 đến 10 năm là cách làm hữu ích
    • Thiệt hại do website bị cố định vào mô hình riêng của Google có thể được đánh giá qua số lượng và quy mô site compat bug khi trình duyệt khác phát hành, cũng như bản chất bug phát sinh khi Chrome cập nhật mô hình
    • Người ta đề xuất phân biệt bug là kiểu “làm mô hình thông minh hơn” hay “giữ lại quirk kỳ quặc”, rồi gom lại bằng cách gắn nhãn trên webcompat.com
    • Theo blink-dev I2S, Edge cũng đang phát hành API này với một mô hình khác nên đã có dữ liệu ban đầu
    • Chỉ số thiệt hại cho lo ngại về TOS là liệu đã thực sự có kiện tụng hay đe dọa pháp lý vì vi phạm hay chưa, và có luồng ý kiến muốn gom các bằng chứng đó thành hồ sơ

  • Giảm thiểu sau sự kiện và phản ứng của Chrome

    • Có phản biện rằng cách tiếp cận xác minh thiệt hại thực tế là hợp lý, nhưng chỉ hữu ích nếu sau khi thiệt hại xảy ra vẫn còn các biện pháp giảm thiểu có ý nghĩa
    • Khi website bị cố định vào mô hình riêng của Google, các lựa chọn được nêu ra gồm unship tính năng, thay đổi mô hình để phá các site prompt bị tinh chỉnh quá mức, random model rotation, hoặc chuẩn hóa mở cho on-device model weights
    • Có ý kiến cho rằng nếu xuất hiện bằng chứng các trình duyệt khác phải sao chép những quirk kỳ lạ của mô hình Chrome, thì từ vị trí lãnh đạo Chromium họ sẽ thúc đẩy Chrome phá bỏ chính quirk đó
    • Một tiền lệ cũng được nhắc đến: Mobile GMail từng phụ thuộc vào các quirk buggy của WebKit border image, và khi Firefox cảm thấy cần phải sao chép, Chrome đã được sửa theo hướng làm GMail hỏng; GMail sau đó cập nhật rất nhanh đến mức người dùng không nhận ra

Bài viết liên quan

1 bình luận

 
GN⁺ 2026-05-01
Ý kiến trên Hacker News

  • Lập luận phản đối có vẻ khá rõ ràng: sự gắn kết chặt giữa prompt và model, cùng vấn đề tính trung lập với model trong điều khoản sử dụng
    Như ví dụ cá nhân ở https://github.com/mozilla/standards-positions/issues/1213, khi tạo system prompt cho thông báo tự động hóa nhà ở, lúc đầu Gemini trả lời quá kiểu Mỹ; rồi khi được nói là sẽ nói bằng giọng Anh, nó lại chuyển sang kiểu bắt chước giọng Anh vụng về theo kiểu Mỹ như “a'waight guv'nor apples and pears”, nên lại phải tinh chỉnh thêm
    Trong quá trình đó, system prompt bị tối ưu cho một model cụ thể, còn model khác thì có những quirks khác, nên phần hiệu chỉnh thêm cho một model có thể thành quá tay với model khác

    • Kết quả là nghe như đang chế giễu trong adversarial mode
    • Nếu đó là lý do đủ tốt để không hỗ trợ tính năng LLM, thì kết luận sẽ là không nên đưa nó vào bất kỳ platform API nào. Nhưng nó đã được thêm vào vô số nền tảng rồi
      Việc mỗi model khác nhau là đặc tính cốt lõi của công nghệ này. Nó cũng giống như kích thước canvas thay đổi theo thiết bị hay hướng màn hình, độ chính xác của geolocation API khác nhau, hoặc giọng của Speech Synthesis khác nhau tùy thiết bị
      Điều này nghe giống tâm lý anti-AI hơn là phê bình mang tính xây dựng. Hiện giờ thì cần UI cấp quyền, và sau này có thể còn gắn các mức IQ như low/medium/high, nhưng các developer thực sự quan tâm thì dù sao 90% cũng sẽ phụ thuộc vào một model cụ thể
      Theo thời gian, khi sự ghét AI giảm đi và mọi người nhận ra nó hữu ích, việc Firefox không có tính năng này có thể bị xem là một thất bại về quyền tự chủ dữ liệu cá nhân. Nếu TOU liên quan của Chrome là vấn đề, thì ngược lại, đó càng là lý do để Firefox thêm tính năng này với điều khoản model không có vấn đề

  • Ban đầu tôi không biết ai viết bài phản đối này, hóa ra là Jake Archibald, một Googler từng ở đội Chrome rất lâu, chuyển sang Mozilla rồi viết bài phản đối Chrome API. Không ngạc nhiên khi phần phê bình được sắp xếp tốt như vậy, và lần này chắc hẳn anh ấy thấy nhẹ nhõm vì không phải theo lập trường của tổ chức nữa

    • Cảm ơn, nhưng tôi nghĩ ngay cả khi còn ở Google, anh ấy cũng không hẳn đi theo lập trường công ty. Chỉ là vì thế mà mọi thứ trong nội bộ ngày càng khó chịu hơn, và cuối cùng anh ấy rời đi
      Nghe từ những người vẫn còn trong đội thì ở khía cạnh đó, tình hình có vẻ đã tệ hơn theo cấp số nhân
    • Hẳn là anh ấy rất quen với repo standards-positions, và bài này đọc lên giống kiểu phòng thủ điển hình khi Google cố đẩy một thứ gì đó mà không lấy đủ ý kiến
      Thay vì đề xuất chỉnh sửa, nó giống như muốn loại bỏ toàn bộ; và nếu bị loại bỏ, có vẻ họ kỳ vọng sẽ viết lại từ đầu theo hướng hợp tác thay vì bắt đầu từ góc nhìn của đội Google Chrome. Nhưng tôi không thấy cách đó thường dẫn đến kết quả tốt, nên có lẽ cứ đưa ra các chỉnh sửa cụ thể sẽ tốt hơn

  • Tôi phản đối chuyện này

    1. Nó tạo ra thông tin fingerprinting mới, và vì khó đánh lừa script fingerprinting nên có thể bị lạm dụng cho “device verification”. Không nên có chuyện trình duyệt bị “xác minh”, và ai cũng phải có thể giả lập bất kỳ trình duyệt nào
    2. LLM tốn nhiều bộ nhớ và CPU, mà với giá RAM hiện nay thì việc nâng cấp cũng đắt. Nếu website phụ thuộc vào model cục bộ thì trên thiết bị giá rẻ sẽ chạy chậm
    3. API có vẻ được thiết kế xoay quanh một LLM cụ thể như OpenAI
    4. Nó có thể đẩy các đối thủ không có model AI riêng ra khỏi thị trường trình duyệt. Nếu các site được xây dựng với kỳ vọng dùng model Gemini của Google thì chúng có thể hỏng trên các model khác hoặc trên trình duyệt của những quốc gia không có model AI, và không nên tồn tại trình duyệt “hạng nhất” với “hạng hai”
      explainer nói dữ liệu có thể được xử lý cục bộ mà không gửi đi đâu cả, nhưng nếu vậy thì tại sao model Gemini cục bộ của Google lại cần Prohibited Use Policy? Tại sao Google phải quan tâm đến những prompt và phản hồi mà họ không thể biết được?
      Bản thân việc truy cập LLM offline thì có vẻ hay, nhưng website không nhất thiết cần tích hợp LLM vào trình duyệt; chúng có thể dùng WebGPU hoặc cải thiện WebGPU để xử lý model ML. Hoặc mọi người nên dùng cùng một LLM mã nguồn mở
    • Google chỉ đơn giản lắc roi như vi khuẩn và đi theo hướng nào có tiền. Tôi không hiểu vì sao lại có người nghĩ Google sẽ làm điều gì tốt cho web hay cho nhân loại
    • Tôi cực lực phản đối ý “không nên có khả năng xác minh trình duyệt”. Ngành AI đã hoàn toàn xé nát sự đồng thuận xã hội trước thời COVID về anti-scraping và anti-botting
      Việc robots.txt không phải là yêu cầu bắt buộc và có thể bị lách hoàn toàn giờ đã thành kiến thức phổ biến, và điều đó đã biến web mở thành một dark forest trên thực tế
      Một cách nào đó để xác minh rằng phiên trình duyệt chưa bị can thiệp hoặc là “trusted” rất có thể sẽ xuất hiện trong tương lai. Rất tệ, nhưng cuối cùng phần nào cũng là do chúng ta tự gây ra
    • Về lo ngại fingerprinting, tôi nghĩ trên Chrome và dĩ nhiên cả Firefox sẽ có tùy chọn “không bao giờ tải LLM và tắt mọi tính năng LLM”
      Một site có thể gửi các yêu cầu nhỏ tới LLM để fingerprint chính model, nhưng nếu có thể tắt thì tôi không nghĩ đó là vấn đề lớn
      Rộng hơn thì có một nỗi lo kiểu “web platform không nên làm được chuyện này”. Theo lập trường đó, dù người dùng có thể tắt đi thì họ vẫn sẽ nói rằng sẽ xuất hiện các site kiểu “không có LLM nên trình duyệt không được hỗ trợ”, và web sẽ xấu đi
      Nhưng đó rốt cuộc là quyết định của người vận hành website rằng nếu không có LLM thì họ tắt site, chứ không phải lỗi của platform hay người bảo trì đã tạo ra tính năng đó. Nó cũng giống như trên Firefox chạy vẫn tốt nhưng họ tắt hỗ trợ chỉ vì lười test
      Web là nền tảng ứng dụng thành công nhất thế giới trong một thế giới mà nó cạnh tranh không phải với PDF mà với SwiftUI. Lựa chọn “cứ giữ web tĩnh như hiện nay là được” là ảo tưởng; lựa chọn thực tế là hoặc điều chỉnh web theo nhu cầu thay đổi của người dùng, hoặc để web thất bại và SwiftUI hay WinUI lấp vào chỗ trống đó. Vế sau còn tệ hơn nhiều
    • Đọc các câu trả lời trong thread này, tôi nhận ra: dù sao họ cũng sẽ làm thôi, và những người vốn đã phụ thuộc vào LLM hoặc không đủ năng lực để đánh giá đúng đắn sẽ khen nó
      https://news.ycombinator.com/item?id=47960596
      Kết luận là giờ phải bước tiếp. Chúng ta nên nghĩ đến một hình thức trao đổi thông tin trực tuyến và phát media tốt hơn trình duyệt web. Nếu chúng ta là hàng hóa, thì công cụ chúng ta dùng cũng không nên hành xử như một proxy lén chuyển doanh thu quảng cáo cho những kẻ thống trị không đáng tin; nó nên phản ánh trực tiếp thực tế đó

  • Càng nghĩ tôi càng thấy lần này mình đồng ý với phía thiết kế API của Google hơn
    Sự gắn kết chặt giữa prompt và model là mối lo có thật, và là vấn đề tôi gặp hằng ngày. Nhưng nếu giải pháp là một API còn gắn chặt hơn prompt được đánh giá với model nằm trong trình duyệt của người dùng, thì sớm muộn cũng sẽ thành kiểu “prompt của chúng tôi chỉ được test với Gemini nên site này cần Chrome”
    Tệ hơn nữa, sẽ thành “không thể nhận diện model AI đang dùng”. Nếu một site làm vào năm 2026 mà không được cập nhật đến 2030 thì hoàn toàn có thể xảy ra
    Điều này cũng liên quan đến vấn đề điều khoản mà kỹ sư Mozilla nhắc ở phía sau. Nếu muốn tồn tại các trình duyệt mà bạn không phải đồng ý với điều khoản của một model AI cụ thể, chẳng hạn trình duyệt dùng model mã nguồn mở tốt, thì sẽ có lợi hơn nếu không thể fingerprint các Big Models
    Tất nhiên nhiều site rồi cũng sẽ gọi kiểu isChrome() thôi. Dù vậy tôi vẫn nhìn chung phản đối những thay đổi làm tăng thêm cách fingerprint trình duyệt. Lợi ích của việc giữ model ẩn danh lớn hơn nhược điểm thỉnh thoảng xuất hiện đầu ra kỳ quặc do khác biệt nhỏ giữa các model như Gemini và Qwen

  • Tôi không hiểu vì sao Google không dùng nguồn lực khổng lồ để sửa các điểm yếu mang tính cấu trúc trong vô số thứ mà trình duyệt đã có thể làm, mà cứ tiếp tục nhét thêm đồ linh tinh để biến trình duyệt thành Homermobile
    Sao không tập trung vào những thứ nền tảng giúp cải thiện chất lượng sống trên toàn bộ web platform, từ blog tĩnh, thương mại điện tử cho đến web app tiên tiến nhất
    https://simpsons.fandom.com/wiki/The_Homer

    • Google không tạo Chrome để làm ra một web tốt hơn. Làm một trình duyệt tốt chỉ vì bản thân trình duyệt tốt đồng nghĩa với việc đốt hàng tỷ USD vào goodwill, còn mục tiêu của Chrome là trở thành nền tảng thay thế OS của người dùng mỗi khi họ làm gì đó trên thiết bị
      Họ thử làm điều đó trực tiếp bằng Android và ChromeOS, nhưng Chrome cũng khiến cả người dùng phổ thông trên môi trường như Windows dành phần lớn thời gian ở bên trong thế giới của Google
    • Muốn được thăng chức ở Google thì phải ra mắt prompt API
    • Việc không triển khai prompt API có thật sự khiến nguồn lực được đổ sang những việc khác trước giờ không được coi trọng không? Điều này giống false dichotomy hơn

  • Tôi thực sự cho rằng LLM và API harness hiện tại chưa đủ trưởng thành về mặt kỹ thuật để kiểu API này được đưa vào tiêu chuẩn
    Dù vậy nếu vẫn làm thì ít nhất phải là quyền opt-in theo từng site, và phải có cách nhận diện đang gửi prompt đến model nào. Ngay cả việc tinh chỉnh nhỏ đối với system prompt cũng cần được tính là một phần của danh tính đó
    Với tư cách người dùng, tôi cần chắc chắn rằng khi ghé một site ngẫu nhiên, tôi sẽ không bị fingerprint bằng API này khi chưa cho phép
    Với tư cách developer, tôi cần biết người dùng đang dùng model nào để có lựa chọn tạo prompt riêng cho từng model

  • “Trình duyệt và hệ điều hành ngày càng được kỳ vọng sẽ có quyền truy cập vào language model”? Thật vậy sao?
    https://github.com/webmachinelearning/prompt-api/blob/main/R...

    • Tôi nghĩ hướng đó là sai. Tôi không muốn OS hay trình duyệt truy cập vào LLM, nhưng tôi muốn LLM truy cập vào trình duyệt hay OS, và điều đó thực tế đã bắt đầu xảy ra
      Vì vậy tôi nghĩ chỉ cần cung cấp một giao diện cho LLM, mặc định là tắt và người dùng có thể bật khi muốn
      Như vậy sẽ không bị lock-in vào LLM mà Apple nhét vào OS, và còn có thể chọn dùng LLM provider nào. Ví dụ, tôi muốn những gì Apple Intelligence có thể truy cập thì Claude cũng truy cập được
    • Tôi là người viết câu đó ban đầu, nhưng không ngờ nó lại dễ bị hiểu nhầm như vậy. Ý tôi không phải là kỳ vọng của người dùng hay developer, mà là xu hướng ngành khi các vendor OS và trình duyệt đang tích hợp hoặc chuẩn bị tích hợp LM
      Giờ có lẽ có thể đổi từ “được kỳ vọng sẽ có quyền truy cập” thành “đang được tích hợp”. Có vẻ nhiều người đang nhầm, nên sẽ tốt nếu nhóm duy trì dự án cập nhật theo hướng đó
    • macOS, iOS, Windows đều có local model API cho developer bên thứ ba, và Chrome cũng đang thử nghiệm. Firefox thì tạo alt-text bằng model nhưng không có API
      Về mặt lý thuyết thì hữu ích. Nếu developer có thể dựa vào model cục bộ thì sẽ riêng tư hơn, phi tập trung hơn, và bớt phải gửi tiền cho AWS hay Anthropic. Cũng có những use case ít rủi ro mà chỉ có ý nghĩa nếu nó chạy cục bộ, offline và miễn phí
      Nhưng trên thực tế tôi hầu như chưa thấy native app nào áp dụng Apple Foundation Models. Không biết các developer Mac/iOS có gì để chia sẻ không
    • AI trao quyền rất lớn cho những người chỉ biết bikeshedding. Bản thân AI cũng có thể là một cái bikeshed lớn, nhưng vẫn có vài use case hợp lệ, và nó cũng cho người ta sức để nói dai hơn, lâu hơn nhằm ép những ý tưởng vô dụng đi qua thay vì phản đối
      Giờ mọi thứ ngày càng có vẻ như đang trông chờ vào bikeshed. CVE cũng đang được trông chờ luôn
    • Có vẻ bề mặt API của trình duyệt vẫn chưa đủ rộng một cách phản cảm

  • Điều hay của giao thức mở là bạn không cần ủng hộ hay dùng một triển khai cụ thể nào, nhưng dù sao thì độc quyền trình duyệt vẫn cứ là một thế tiến thoái lưỡng nan
    Có những dự án tốt như ungoogled chromium, Tor, nhưng vấn đề lớn nhất là thiếu những dự án có tiếng nói cho người dùng phổ thông và kết nối được với công chúng
    Không ít người dùng không rành công nghệ thực ra thờ ơ với nguyên nhân và cách truyền tải thông điệp, và phản ứng mạnh hơn với thứ “vui” và ít ma sát hơn là với tự do và quyền kiểm soát
    Làm sao giải quyết chuyện này? Làm sao để biến trình duyệt thành thứ thuộc về chúng ta, do con người làm ra, vì con người? Mỗi lần nghĩ đến đây tôi chỉ thấy buồn

    • Tự biên dịch trình duyệt còn khiến mọi thứ tệ hơn. Nếu muốn Spotify hay Netflix thì bạn cần Widevine có attestation, và cuối cùng vẫn phải trả phí cho Google
      Nếu chuỗi Browser Agent không phải Chrome hay Firefox thì bạn sẽ gặp CAPTCHA Cloudflare vô tận hoặc 403
    • Phải bắt đầu từ việc học platform API thay vì nhét Chrome vào trong các ứng dụng “native”
      Sau đó hãy xây ứng dụng web dựa trên web standards thay vì dựa trên những gì Chrome làm, và đừng than phiền khi Firefox với Safari không theo kịp
    • Đơn giản thôi. Dùng luật chống độc quyền để tách tất cả các đại công ty công nghệ ra. Họ là robber barons của thời đại chúng ta
    • Đáng buồn là câu trả lời gần như lúc nào cũng là nguồn tài trợ công thực chất
    • Trình duyệt tử tế thì đã có sẵn rồi, còn người bình thường dùng Chrome. Ai quan tâm thì chuyển sang loại trước. Vấn đề cần giải là gì?
      Bạn nói là cần dự án chạm tới người bình thường, nhưng đồng thời lại nói họ muốn thứ ít ma sát hơn là tự do và quyền kiểm soát. Nghe có vẻ mâu thuẫn. Người bình thường gắn với less friction hơn là kiểm soát

  • Tôi tò mò use case của API này là gì
    Kinh nghiệm của tôi khi chạy local LLM là bật llama-server lên, nếu cần thì chạy trên máy riêng, rồi cấu hình các ứng dụng khác trỏ đến server tương thích OpenAI đó thay vì OpenAI hay dịch vụ tương tự
    Tôi không muốn trình duyệt tạo hay chạy một instance LLM. Vì cỗ máy đó có thể không đủ khả năng hoặc không đủ dư địa để chạy instance LLM

  • Không biết đây có phải là khác biệt giữa thế hệ trẻ đã không thể sống thiếu LLM với thế hệ cũ không muốn bị yêu cầu cả siêu máy tính chỉ để chạy một trình duyệt web xâm phạm quyền riêng tư hay không
    Với tôi, nghe như đây là điểm mà mọi người nên bắt đầu tìm kiếm và phát triển các lựa chọn thay thế cho trình duyệt/web

    • Đây không phải là việc Mozilla đưa ra lập trường phản đối AI
      Mà là họ đang giải thích những lý do rõ ràng và logic vì sao API được đề xuất ở dạng hiện tại lại có hại cho khả năng tương tác của web
    • Tôi nghĩ sự phản đối ở đây không liên quan đến chuyện thích hay ghét LLM. Đây là câu hỏi liệu đề xuất open web API cụ thể này có khả thi hay không
      Cá nhân tôi vẫn dùng LLM cho hỗ trợ lập trình và tự động hóa nhà ở, nhưng không nghĩ API này tốt cho web
    • Theo kinh nghiệm của tôi, người trẻ nhìn chung ghét AI
    • Hơi lạc đề một chút, nhưng tôi nghĩ thứ cần làm lại gần với chính khái niệm hệ điều hành hơn là giao diện trình duyệt
      Tôi không biết câu trả lời đúng là gì, nhưng sau khi dùng Niri/Wayland, GNOME, Windows, Mac, tôi sẽ không bao giờ quay lại workflow quản lý cửa sổ desktop không-tiling và không lấy bàn phím làm trung tâm nữa
    • Con tàu “trình duyệt xâm phạm quyền riêng tư cần tới siêu máy tính” đã rời bến từ năm 2008 rồi