Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Address M.E.AI API feedback#5860

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
stephentoub merged 1 commit intodotnet:mainfromstephentoub:apireviewchanges
Feb 10, 2025

Conversation

@stephentoub
Copy link
Member

@stephentoubstephentoub commentedFeb 7, 2025
edited by dotnet-policy-servicebot
Loading

  • Remove DataContent.ContainsData. While ContainsData could be used to avoid lazily-instantiating aReadOnlyMemory<byte> from a data URI, in all cases examined ContainsData was being used to guard accessing Data, in which case Data.HasValue is sufficient.
  • Make ToolMode optional. We'd previously said that an implementation could use null to imply None if it wanted, but with this being optional we'd want null to be the same as auto, so I added in an explicit null options. That matches as well with what various other client libs do.
  • Remove IChatClient/IEmbeddingGenerator.Metadata. GetService can be used instead, reducing what an implementer must implement and what's exposed to a consumer.
  • Add Complete{Streaming}Async for a single message. We have such accelerators in other places but not here, and it provides a natural grow-up from string to ChatMessage toIList<ChatMessage>.
  • Change UsageDetails.XxTokenCount properties from int? to long?. The AdditionalCounts is already based on longs, and in theory the token counts could exceed int, especially in a situation where UsageData is being used to sum many other call data.
  • Rename GenerateEmbeddingVectorAsync's TEmbedding to TEmbeddingElement. Everywhere else TEmbedding is used where it represents an Embedding, but here it represents a numerical element in an embedding vector.
  • Remove setters on FunctionCall/ResultContent for required ctor parameters. Having those setters goes against .NET design guidelines.
  • Remove FunctionResultContent.Name. It's unnecessary and is actually causing us to do more work in places.
Microsoft Reviewers:Open in CodeFlow

- Remove DataContent.ContainsData. While ContainsData could be used to avoid lazily-instantiating a `ReadOnlyMemory<byte>` from a data URI, in all cases examined ContainsData was being used to guard accessing Data, in which case Data.HasValue is sufficient.- Make ToolMode optional. We'd previously said that an implementation could use null to imply None if it wanted, but with this being optional we'd want null to be the same as auto, so I added in an explicit null options. That matches as well with what various other client libs do.- Remove IChatClient/IEmbeddingGenerator.Metadata. GetService can be used instead, reducing what an implementer must implement and what's exposed to a consumer.- Add Complete{Streaming}Async for a single message. We have such accelerators in other places but not here, and it provides a natural grow-up from string to ChatMessage to `IList<ChatMessage>`.- Change UsageDetails.XxTokenCount properties from int? to long?. The AdditionalCounts is already based on longs, and in theory the token counts could exceed int, especially in a situation where UsageData is being used to sum many other call data.- Rename GenerateEmbeddingVectorAsync's TEmbedding to TEmbeddingElement. Everywhere else TEmbedding is used where it represents an Embedding, but here it represents a numerical element in an embedding vector.- Remove setters on FunctionCall/ResultContent for required ctor parameters. Having those setters goes against .NET design guidelines.- Remove FunctionResultContent.Name. It's unnecessary and is actually causing us to do more work in places.
@dotnet-comment-bot
Copy link
Collaborator

‼️Found issues‼️

ProjectCoverage TypeExpectedActual
Microsoft.Extensions.Caching.HybridLine8682.77 🔻
Microsoft.Extensions.AI.OllamaLine8078.2 🔻
Microsoft.Gen.MetadataExtractorLine9857.35 🔻
Microsoft.Gen.MetadataExtractorBranch9862.5 🔻

🎉Good job! The coverage increased 🎉
UpdateMinCodeCoverage in the project files.

ProjectExpectedActual
Microsoft.Extensions.AI8889
Microsoft.Extensions.AI.Abstractions8385
Microsoft.Extensions.AI.AzureAIInference9192

Full code coverage report:https://dev.azure.com/dnceng-public/public/_build/results?buildId=944835&view=codecoverage-tab

Copy link
Member

@SteveSandersonMSSteveSandersonMS left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Great. Removal ofMetadata is particularly nice - much cleaner to use the existing service location mechanism instead of having a parallel one.

@stephentoubstephentoub merged commita0688e0 intodotnet:mainFeb 10, 2025
6 checks passed
/// <returns>The response messages generated by the client.</returns>
publicstaticTask<ChatCompletion>CompleteAsync(
thisIChatClientclient,
ChatMessagechatMessage,
Copy link
Member

@eiriktsarpaliseiriktsarpalisFeb 10, 2025
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

This new set of extensions can only be used in cases where the chat history consists of only that one message. How common is such a scenario? Could it lead callers into incorrectly assuming that they'reappending a chat message to a log that is being encapsulated by the client?

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

This new set of extensions can only be used in cases where the chat history consists of only that one message. How common is such a scenario?

It's pretty common, for at least:

  • Getting started scenarios, where you want to send a single input
  • Non-chat scenarios, where you're sending input to have the LLM give you back a response as part of the logic of you're program.
  • IChatClient implementations where the state is stored server-side, ala assistants

It's no different from the existing string-based overloads that are helpful in similar circumstances but that are limited to TextContent; these overloads allow you to customize beyond that.

}

/// <inheritdoc />
publicChatClientMetadataMetadata{get;}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Even if no longer part of IChatClient, it seems useful enough to surface as a property on the implementing class.

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I'd rather we expose it as an extension property once those are possible.

@stephentoubstephentoub deleted the apireviewchanges branchFebruary 10, 2025 13:30
@jeffhandleyjeffhandley added the area-aiMicrosoft.Extensions.AI libraries labelMar 7, 2025
@github-actionsgithub-actionsbot locked and limited conversation to collaboratorsApr 6, 2025
Sign up for freeto subscribe to this conversation on GitHub. Already have an account?Sign in.

Reviewers

@eiriktsarpaliseiriktsarpaliseiriktsarpalis left review comments

@SteveSandersonMSSteveSandersonMSSteveSandersonMS approved these changes

@jeffhandleyjeffhandleyAwaiting requested review from jeffhandley

@MackinnonBuckMackinnonBuckAwaiting requested review from MackinnonBuck

Assignees

@stephentoubstephentoub

Labels

area-aiMicrosoft.Extensions.AI libraries

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

5 participants

@stephentoub@dotnet-comment-bot@SteveSandersonMS@eiriktsarpalis@jeffhandley

[8]ページ先頭

©2009-2025 Movatter.jp