You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As discussed in the explainer's Goals section, it might be useful to allow web developers to know some identifier for the language model in use, separate from the browser version. This would allow them to allowlist or blocklist specific models to maintain a desired level of quality, or restrict certain use cases to a specific model.
This would probably not have significant privacy implications, since we already expose prompt() and sufficiently-detailed prompting should be able to distinguish between possible models.
However, I worry a bit about the interop issues. Adding such an API does make it much easier to write code that only works in one browser, or with one model.
The text was updated successfully, but these errors were encountered:
For the sake of adoption, it might make the most sense to have the window.ai provider be as high level as possible and abstract away model selection. I don't think users will be super jazzed about multiple models being added to their browser because different websites request different models
Providing a few model agnostic api's like the current prompt and prompt streaming api's, plus maybe a feature extraction and classification api makes the most sense to me.
This leaves room for an browser extension to overwrite and match the window.ai api so users can opt in to different local/cloud provided models via the extension popup. From the api consumer's perspective things remain constant and the complexity of supporting different models is offloaded to the extension provider.
As discussed in the explainer's Goals section, it might be useful to allow web developers to know some identifier for the language model in use, separate from the browser version. This would allow them to allowlist or blocklist specific models to maintain a desired level of quality, or restrict certain use cases to a specific model.
This would probably not have significant privacy implications, since we already expose
prompt()
and sufficiently-detailed prompting should be able to distinguish between possible models.However, I worry a bit about the interop issues. Adding such an API does make it much easier to write code that only works in one browser, or with one model.
The text was updated successfully, but these errors were encountered: