mikekistler
commented
1 year ago Notes from API Review meeting 10/31/23
- May be some "flexibility" in support time frame for OpenAI GA releases
- Casing conventions aren't consistent between OpenAI and Azure extensions - confusing?
- More important, Azure extensions may not be sufficiently distinguished in client libraries
- API Stewardship board guidance is generally "Be consistent within the service"
- We should optimize for dev experience and not MS Engineering team convenience
- Enclose all Azure extensions in an object (at the highest applicable level)
- Want to piggyback on existing messages rather than adding messages
- But when we can't, we want to mimic the message format
- If we can't add an extension within the same route, should this even be part of Azure OpenAI ?
- Let's try to avoid new endpoints. Can we make this a guiding principle ?
- Consider: use an "azure_" prefix rather than introducing an
azure_extensions_contextcontainer- We should avoid extra levels of nesting when possible.
Need to consider this feedback and develop a concrete proposal -- hopefully by the end of this week.
New API Review meeting has been requested.
Service Name: Azure OpenAI Service - Azure OpenAI Service Review Created By: Travis Wilson Review Date: 10/31/2023 01:00 PM PT Onboarding Record: https://dev.azure.com/azure-sdk/Release/_workitems/edit/17714 PR: Hero Scenarios Link: Not Provided Core Concepts Doc Link: Not Provided
Description: We'll discuss the 'Azure OpenAI extensions' schema update proposals outlined and discussed in the stakeholder-circulated draft document: https://microsoft.sharepoint.com/:w:/t/AzureOpenAIDeveloperExperience/ER-8Rb_5TSZAlUPbHZSeEuMBFFIP6f8S6wkMgDFM436W1Q?e=bm6to3
Most listed attendees are optional; I've added quite a few people to ensure stakeholders are kept in the loop, and for the same reason please don't hesitate to forward.
The proposed changes are intended to be implemented in advance of and as part of the next GA service API release (tentatively targeting February 2024) and aim to establish commonly-defined containers for request/response data uniquely added by Azure OpenAI capabilities that extend the base capabilities available on the progenitor OpenAI service while also codifying a generalized set of principles for where and how to add more.
In other, more straightforward words: this proposes rules that would restrict Azure extensions schema additions to only appear in new, dedicated schema containers, e.g. moving BYOD's 'dataSources' down one level, into a dedicated (name pending) 'azure_extensions_context' object rooted to the request body.
Conversation will likely be focused around the above document and examples therein, but I'll aim to have a preliminary APIView available prior to the call, too.
Detailed meeting information and documents provided can be accessed here For more information that will help prepare you for this review, the requirements, and office hours, visit the documentation here