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

 (github.com/mozilla)
2 điểm bởi GN⁺ 3 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Prompt API, vốn phơi bày mô hình ngôn ngữ trong trình duyệt 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 các triển khai bám theo hành vi riêng của từng mô hình, làm 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 cho phù hợp với một triển khai cụ thể như Phi-4-mini trên Edge, điều đó có thể gây 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 thẳng dưới dạng web API, cần kiểm chứng trong userland lâu hơn; trial web extension API và đề xuất web extension của nhóm Web Machine Learning được dùng làm kênh phản hồi ban đầu
  • Nếu system prompt lan rộng theo các 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 tiêu cực, và trình duyệt có thể chịu áp lực phải dùng mô hình của Google hoặc mô hình tương thích với các quirk đó
  • 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·regex, thảo luận trong WebML CG, và thử nghiệm các 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 liên kết 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 riêng 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 một mô hình cụ thể; nếu nhắm vào các triển khai như Phi-4-mini của Edge, chất lượng trên trình duyệt hoặc mô hình khác có thể giảm, thậm chí trang web có thể bị chặn truy cập
  • Thay vì phát hành trực tiếp dưới dạng web API, Mozilla cho rằng nên kiểm chứng trong userland lâu hơn, và trial web extension API của Mozilla cùng đề 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ề 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 nên tự chọn một mô hình cụ thể
    • Chức 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 đượ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 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 bước ra ngoài ranh giới của một 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 tiếp nối logic tương tự với 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 cho trang một API tương tự Prompt, sử 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 ban đầu từ người dùng

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

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

    • System prompt có xu hướng được điều chỉnh lặp đi lặp lại để phù hợp với quirk của mô hình đang dùng
    • Trong một system prompt dùng để tạo hướng dẫn cho tự động hóa nhà thông minh, mô hình Gemini ban đầu trả lời rất kiểu 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, kết quả lại thành kiểu bắt chước Anh theo kiểu Mỹ như “a'waight guv'nor apples and pears”, nên còn phải tinh chỉnh thêm để hạ xuống gần với tiếng Anh-Anh tự nhiên hơn
    • Việc hiệu chỉnh cho một mô hình có thể trở thành hiệu chỉnh quá mức với mô hình khác, và vấn đề càng lớn hơn ở các dạng đầu ra như voice có thương hiệu hoặc định dạng không thể biểu đạt bằng JSON schema hay regex

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

    • Nếu các system prompt được chỉnh theo quirks 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ể trông tệ trong mắt nhà phát triển và người dùng
    • Mozilla và Apple có thể rơi vào tình huống phải cấp phép mô hình của Google, hoặc dùng mô hình tương thích quirk với mô hình Google, để duy trì khả năng tương tác
    • Vì lý do tương tự, ngay cả Chrome cũng có thể gặp khó khăn khi cập nhật mô hình của chính mình

  • 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 xuất xứ
    • Ví dụ trả về là 'gpt-3.5-turbo-0613, Gemma, 2024-02-29, Google DeepMind'
    • Nhà phát triển có thể tạo các bộ system prompt riêng cho từng mô hình cụ thể, rồi chặn mô hình không xác định hoặc thông báo với người dùng rằng chất lượng đầu ra có thể thấp
    • Điều này bị xem là sự quay trở lại kiểu code branching đầu những năm 2000 mà nên tránh

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

  • Theo tài liệu của 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 bao trùm phạm vi vượt quá luật pháp, trong đó cấm “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 tiến trình dân chủ”
  • Việc web platform API đi theo hướng yêu cầu quy tắc sử dụng 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 gắn quy tắc theo UA
  • Nếu người dùng nhấn “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 là đối tượng chịu trách nhiệm: người dùng bấm nút, người viết bình luận tạo ra nội dung vi phạm, hay chủ website xây dựng 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 rủi ro pháp lý từ chủ sở hữu mô hình; một mô hình không xác định cũng có thể đồng nghĩa với điều khoản không xác định, nên chặn sử dụng là lựa chọn hợp lý
  • Cũng có luồng ý kiến cho rằng một trình duyệt không có cơ sở để áp các đ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à phần cập nhật liên quan tới rủi ro interoperability and compatibility trên ChromeStatus
  • Họ muốn tiếp tục duy trì sự 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ó thể tương tác
  • Phía Chrome cho biết động lực của họ là giữ gìn sức khỏe lâu dài và tính trung lập của web platform, đồng thời biến Language Model do trình duyệt và OS cung cấp thành lựa chọn hữu ích cho nhà phát triển web và người dùng
  • Bề mặt Prompt API đã cho thấy mức độ tương thích nhất định với cả mô hình của Google và Microsoft, và họ đang áp dụng các ràng buộc phản hồi 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 nhằm giảm nhu cầu dùng các hack riêng theo từng mô hình để 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 khác, bao gồm việc Microsoft tích hợp Android MLKit và nguyên mẫu ban đầu cho tích hợp foundational model của Apple
  • Trong giai đoạn API trial, họ đã phát hành 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, đồng thời cũng đang khám phá hỗ trợ cho 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 tốt hơn trên các kiến trúc nền tảng khác nhau
  • Phần mô tả Interoperability and Compatibility trên Blink-dev nêu rằng với nhà phát triển dùng công nghệ này, sự biến động của 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 framework tương tác để có cách tiếp cận web platform nhất quán xuyên các trình duyệt và mô hình

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

  • blink-dev intent to ship đánh dấu lập trường của nhà phát triển web là “Strongly positive”, và liên kết stakeholder feedback trong explainer làm căn cứ
  • Căn cứ này đượ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 tồn tại
    • Một khảo sát dường như hỏi nhà phát triển liệu API này có thể tồn tại trong extensions hay không, nhưng không nêu rõ số liệu hay đối tượng khảo sát
    • Bài blog đã biến mất được chia sẻ bản lưu qua Wayback Machine
    • Dù tài liệu có nhấn mạnh lớn những gì “không nên phụ thuộc vào” và những gì “có thể phụ thuộc vào”, thì nếu làm đúng theo khuyến nghị đó, không rõ API còn giữ lại được 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ử, và nếu đó là mô hình của Chrome thì website có thể hiện thông báo yêu cầu dùng bản Chrome mới nhất
    • Google đã nhận diện rất rộng khu vực 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, và đây vẫn là điểm gây vấn đề

Thảo luận trong phần bình luận: lựa chọn thay thế, đo lường tác hại, và giảm thiểu hậu kỳ

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

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

  • Open web và FOMO

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

  • Việc Chromium phát hành và đo lường tác hại

    • Một trong các blink API owner approver của Chromium cho biết họ chia sẻ các lo ngại của Mozilla, nhưng vẫn ưu tiên con đường thử nghiệm, học từ sai lầm và thúc đẩy cạnh tranh
    • Để đánh giá tác hại thực tế trong tương lai, cần xác định kết quả cụ thể; bối cảnh ở đây là cách từng hữu ích khi so sánh các 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–10 năm
    • Tác hại nếu 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 các trình duyệt khác phát hành, cũng như tính chất bug khi Chrome cập nhật mô hình
    • Có ý kiến nên phân biệt bug là do “làm mô hình thông minh hơn” hay do “bảo toàn quirk kỳ quặc”, rồi gắn nhãn và gom lại trên webcompat.com
    • Theo blink-dev I2S, Edge cũng đang phát hành API này với mô hình khác, nên đã có dữ liệu ban đầu
    • Chỉ số tác hại cho lo ngại về TOS là liệu đã thực sự xuất hiện kiện tụng hay đe dọa pháp lý do vi phạm hay chưa, và nên bắt đầu ghi chép các bằng chứng đó

  • Giảm thiểu hậu kỳ và phản ứng của Chrome

    • Có phản biện rằng cách tiếp cận kiểm chứng tác hại khả dĩ trong thực tế là hợp lý, nhưng chỉ hữu ích nếu sau khi tác 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 dưới dạng câu hỏi gồm unship tính năng, thay đổi mô hình để phá vỡ site prompt bị tinh chỉnh quá mức, random model rotation, hay tiêu chuẩn hóa mở cho trọng số mô hình on-device
    • Có ý kiến 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ỳ quặc trong mô hình của Chrome, thì ở vị trí lãnh đạo Chromium họ sẽ thúc đẩy Chrome phá bỏ chính quirk đó
    • Tiền lệ được nhắc tới là Mobile GMail từng phụ thuộc vào các WebKit border image quirks lỗi; khi Firefox cảm thấy cần phải sao chép, Chrome đã được sửa theo cách làm GMail bị lỗi, và GMail 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⁺ 3 giờ trước
Ý 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