Clarify LanguageModelResponseSchema interface

[michaelwasserman]

I'm confused about the utility and use of the LanguageModelResponseSchema interface.
Can the explainer add some clarity about this interface?

1. Is it mainly intended to validate that objects passed in its ctor are valid JSON schema, not just JSON objects, nor other incompatible objects (i.e. before passing the object to prompt). How will callers verify their schema is valid? Does the LanguageModelResponseSchema ctor throw an exception, or should it have some validation method or validity property?
2. The explainer alludes to reusability; elaborating would be helpful. Maybe show an example of re-use/copying, especially if it highlights utility over just deep-copying the underlying object that would be passed into the ctor.
3. Maybe the interface is useful for other schema formats that might be added in the future? i.e. RegExp shortcut for structured outputs #91 for regex
4. Anything else I'm missing?

[domenic]

The main intention here is to centralize the preprocessing of the schema up front. If I understand correctly, this includes both validation (which you mention), but also transforming the schema from a JS object into something more native to the language model's representation. @sushraja-msft can give more details.

In other words, my understanding is that this:

function getBooleanFromSession(session, question) {
  return session.prompt(question, { responseJSONSchema: { type: "boolean" } });
}

will be slightly slower than this:

const booleanSchema = new LanguageModelResponseSchema({ type: "boolean" });
function getBooleanFromSession(session, question) {
  return session.prompt(question, { responseJSONSchema: booleanSchema });
}

because the first version requires processing the schema object into something suitable for the language model, whereas the latter version does that once and then reuses the result each time.

With regards to other schema formats, #91 discusses how that would impact the API. I think we would not use LanguageModelResponseSchema for that, and indeed might want to rename LanguageModelResponseSchema to LanguageModelResponseJSONSchema to be clear.

[clarkduvall]

In my testing creating the schema object takes something like 1-5ms, so may not be worth having an API around to avoid this cost (on the impl side we can also do things like LRU cache for schemas that should catch this case anyway). I tend to think we may want to get rid of LanguageModelResponseSchema altogether, and just pass the schema as a raw JS object. We can always add LanguageModelResponseSchema later if needed right?

[domenic]

Yeah, I'm supportive of that. Since it sounds like that's what our colleagues at Microsoft have implemented so far anyway, I'll post a PR to get rid of it shortly, unless @sushraja-msft or others have objections.