dotnet ai ml skill - #27
Conversation
There was a problem hiding this comment.
Pull request overview
This PR introduces a comprehensive new skill for .NET AI and Machine Learning development that addresses non-determinism in AI/ML code generation by providing clear technology selection guidance and implementation guardrails.
Changes:
- Adds
dotnet-ai-mlskill with detailed decision trees for selecting between ML.NET, Microsoft.Extensions.AI, Microsoft Agent Framework, GitHub Copilot SDK, ONNX Runtime, and LLamaSharp - Implements library layering rules to prevent mixing abstraction layers (a major source of non-deterministic agent behavior)
- Provides comprehensive evaluation scenarios covering ML.NET classification, LLM integration, technology rejection patterns, agentic workflows with guardrails, and RAG pipelines
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| src/dotnet/skills/dotnet-ai-ml/SKILL.md | Comprehensive 357-line skill document defining technology selection decision trees, library layering rules, guardrails for classic ML/LLM/agent/RAG implementations, and anti-patterns to reject |
| src/dotnet/tests/dotnet-ai-ml/eval.yaml | Five evaluation scenarios with 180-second timeouts testing both positive patterns (correct technology usage) and negative patterns (rejecting inappropriate LLM usage for tabular data) |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
artl93
left a comment
There was a problem hiding this comment.
Some suggestions for your consideration.
|
thank you for the feedback, it should now be addressed. here is the updated evaluation
|
Add SKILL.md with guidance for .NET AI/ML library selection and eval.yaml with validation scenarios. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
|
||
| Evaluate the developer's task against this decision tree and select the appropriate technology. State which branch applies and why. | ||
|
|
||
| | Task type | Technology | Rationale | |
There was a problem hiding this comment.
No mention of semantic kernel, whether to recommend use, or not.
There was a problem hiding this comment.
it is left out as this is a list of recommended choices
There was a problem hiding this comment.
should we explicitly reject SK as an option?
There was a problem hiding this comment.
will do. in rereading it fits well with the example of Accord.NET as well. also asked co-pilot and it agreed that it would be good to explicitly add
| | Ingesting, chunking, and loading documents into a vector store | **Microsoft.Extensions.AI.DataIngestion** (preview) + MEVD | Handles document parsing, text chunking, embedding generation, and upserting into a vector database; pairs with Microsoft.Extensions.VectorData.Abstractions | | ||
| | Both structured ML predictions AND natural language reasoning | **Hybrid**: ML.NET for predictions + LLM for reasoning layer | Keep loosely coupled; ML.NET handles deterministic scoring, LLM adds explanation | | ||
|
|
||
| **Critical rule:** Do NOT use an LLM for tasks that ML.NET handles well (classification on tabular data, regression, clustering). LLMs are slower, more expensive, and non-deterministic for these tasks. |
There was a problem hiding this comment.
is there also a rule that when using an LLM, extract anything that can be a script (eg., tabulation, math, stats) into code/script as it's both cheaper, more accurate and faster than LLM reasoning. maybe that's out of scope?
There was a problem hiding this comment.
interesting, this was geared towards augmenting code and the SDK choice as opposed to a workflow
There was a problem hiding this comment.
I'm curious if @luisquintanilla has an opinio here. LLMs have been promoted (nont by us) for one-shot classification. I was really torn on this one.
There was a problem hiding this comment.
would definitely be good to get Luis to review before merge.
There was a problem hiding this comment.
What is the goal for this skill? This skill appears to provide guidance with various technologies that may have different patterns, practices, use-cases. While they are intended to compose together to build solutions, having them all in one place might confuse the coding assistant. It might be better to split up into separate skills and this skill can serve as a meta-skill that references to those respective skills.
There was a problem hiding this comment.
maybe. experimentally this has added a lot of value as it is highly opinionated and helps to lead to more determinism when choosing between all our options. behind the choice of what SDK to choose, the models seems very effective. so beyond choosing a good starting point, I am not sure what the other split skills would do.
| } | ||
| ``` | ||
|
|
||
| 4. **Tool schemas**: Define explicit tool/function schemas with descriptions. Never rely on implicit tool discovery. |
There was a problem hiding this comment.
and skills? don't know how these are surfaced
There was a problem hiding this comment.
I think tool is synonymous with skill in this context. from the agent pov, skills are tools
|
rerun eval, maybe with increased timeout for the RAG one that's failing? |
|
thanks for the feedback. I am rerunning the eval with the updates |
|
thanks for the feedback, updated
|
|
|
||
| Evaluate the developer's task against this decision tree and select the appropriate technology. State which branch applies and why. | ||
|
|
||
| | Task type | Technology | Rationale | |
There was a problem hiding this comment.
should we explicitly reject SK as an option?
| | Ingesting, chunking, and loading documents into a vector store | **Microsoft.Extensions.AI.DataIngestion** (preview) + MEVD | Handles document parsing, text chunking, embedding generation, and upserting into a vector database; pairs with Microsoft.Extensions.VectorData.Abstractions | | ||
| | Both structured ML predictions AND natural language reasoning | **Hybrid**: ML.NET for predictions + LLM for reasoning layer | Keep loosely coupled; ML.NET handles deterministic scoring, LLM adds explanation | | ||
|
|
||
| **Critical rule:** Do NOT use an LLM for tasks that ML.NET handles well (classification on tabular data, regression, clustering). LLMs are slower, more expensive, and non-deterministic for these tasks. |
There was a problem hiding this comment.
I'm curious if @luisquintanilla has an opinio here. LLMs have been promoted (nont by us) for one-shot classification. I was really torn on this one.
| @@ -0,0 +1,341 @@ | |||
| --- | |||
| name: dotnet-ai-ml | |||
| description: "Guides technology selection and implementation of AI and ML features in .NET 8+ applications using ML.NET, Microsoft.Extensions.AI, Microsoft Agent Framework, GitHub Copilot SDK, ONNX Runtime, and LLamaSharp. Covers the full spectrum from classic ML through modern LLM orchestration to local inference. Use when adding classification, regression, clustering, anomaly detection, recommendation, LLM integration (text generation, summarization, reasoning), RAG pipelines with vector search, agentic workflows with tool calling, Copilot extensions, or custom model inference via ONNX Runtime to a .NET project. DO NOT USE FOR projects targeting .NET Framework (requires .NET 8+), the task is pure data engineering or ETL with no ML/AI component, or the project needs a custom deep learning training loop (use Python with PyTorch/TensorFlow, then export to ONNX for .NET inference)." | |||
There was a problem hiding this comment.
| description: "Guides technology selection and implementation of AI and ML features in .NET 8+ applications using ML.NET, Microsoft.Extensions.AI, Microsoft Agent Framework, GitHub Copilot SDK, ONNX Runtime, and LLamaSharp. Covers the full spectrum from classic ML through modern LLM orchestration to local inference. Use when adding classification, regression, clustering, anomaly detection, recommendation, LLM integration (text generation, summarization, reasoning), RAG pipelines with vector search, agentic workflows with tool calling, Copilot extensions, or custom model inference via ONNX Runtime to a .NET project. DO NOT USE FOR projects targeting .NET Framework (requires .NET 8+), the task is pure data engineering or ETL with no ML/AI component, or the project needs a custom deep learning training loop (use Python with PyTorch/TensorFlow, then export to ONNX for .NET inference)." | |
| description: "Guides technology selection and implementation of AI and ML features in .NET 8+ applications using ML.NET, Microsoft.Extensions.AI (MEAI), Microsoft Agent Framework, GitHub Copilot SDK, ONNX Runtime, and LLamaSharp. Covers the full spectrum from classic ML through modern LLM orchestration to local inference. Use when adding classification, regression, clustering, anomaly detection, recommendation, LLM integration (text generation, summarization, reasoning), RAG pipelines with vector search, agentic workflows with tool calling, Copilot extensions, or custom model inference via ONNX Runtime to a .NET project. DO NOT USE FOR projects targeting .NET Framework (requires .NET 8+), the task is pure data engineering or ETL with no ML/AI component, or the project needs a custom deep learning training loop (use Python with PyTorch/TensorFlow, then export to ONNX for .NET inference)." |
There was a problem hiding this comment.
users might say MEAI (idk)
| .Use(new RetryingChatClient(maxRetries: 3))); | ||
| ``` | ||
|
|
||
| 4. **Cost control**: Always estimate and log token usage. Choose the smallest model tier that meets quality requirements (e.g., `gpt-4o-mini` before `gpt-4o`). |
There was a problem hiding this comment.
do we need to suggest how to log token usage? AFAIK our libraries already fire the right events, not sure the app needs to do anything but IDK
There was a problem hiding this comment.
seems like MaxOutputTokens may be the key thing - mentioned already above
There was a problem hiding this comment.
I've spoken with @stephentoub about this (not recently), and while this was a big ask 2 years ago, it's not so much a thing people focus on now.
There was a problem hiding this comment.
I'm not sure what "this" is here. People still definitely compute token counts, in order to ensure they're not hitting token limits or hurting model performance or if they want to estimate or limit costs, but they have most of what they need to do that, and I see folks being ok with approximations more than absolute-to-the-token correct answers.
|
should we wrap this in a |
|
Tracking in #225 |
while exploring .NET application types, the model found a high level of non-determinism when considering classic and agentic AI SDKs.