.Net: Support markdown semantic functions

[onionhammer]

It would be great if skills could be defined as a group of markdown files with frontmatter (YAML) for defining the configuration, i.e.

instead of

• WriterSkill/
  • Acronym/
  • skprompt.txt
  • config.json
  • EmailTo/
  • skprompt.txt
  • config.json

You could have

• WriterSkill
  • Acronym.md
  • EmailTo.md

Where Acronym.md has

---
schema: 1
type: completion
description: Generate an acronym for the given concept or phrase
completion: 
  max_tokens: 100
  temperature: 0.5
  top_p: 0.0
  presence_penalty: 0.0
  frequency_penalty: 0.0
---
Generate a suitable acronym pair for the concept. Creativity is encouraged, including obscure references. 
The uppercase letters in the acronym expansion must agree with the letters of the acronym

Q: A technology for detecting moving objects, their distance and velocity using radio waves.  
A: R.A.D.A.R: RAdio Detection And Ranging. 

Q: A weapon that uses high voltage electricity to incapacitate the target
A. T.A.S.E.R:  Thomas A. Swift’s Electric Rifle

Q: Equipment that lets a diver breathe underwater 
A: S.C.U.B.A: Self Contained Underwater Breathing Apparatus.

Q: Reminder not to complicated subject matter.
A. K.I.S.S: Keep It Simple Stupid 

Q: A national organization for investment in space travel, rockets, space ships, space exploration
A. N.A.S.A: National Aeronautics Space Administration

Q: Agreement that governs trade among North American countries.
A: N.A.F.T.A: North American Free Trade Agreement. 

Q: Organization to protect the freedom and security of its member countries in North America and Europe.
A: N.A.T.O: North Atlantic Treaty Organization.  

Q:{{$input}}

This would help reduce the number of files and folders a developer has to sift through, making the name of the file significant (rather than every function being named "skprompt.txt")

[dluc]

@onionhammer we looked into something similar using the DIB format discussed here https://github.com/dotnet/interactive/issues/467 but we opted for TXT for a few reasons:

• simplicity: prompts are "functions written in natural language". Config settings would make the syntax more complex, distracting from the logic expressed in simple text.
• consistency: prompts can be copy&paste'd from TXT to inline code.
• performance: the default template parser doesn't need to look for configuration settings.

That said, it's possible to implement custom parsers and we could consider hosting alternative formats.

[onionhammer]

we could consider hosting alternative formats.

Why was this closed as completed?

[onionhammer]

@dluc Why was this closed as completed? Did you mean to close it as not planned? If so then why say you'd consider hosting alternative formats?

[onionhammer]

For any future folks, I wrote a quick proof of concept. The argument about "performance" above is pretty silly, reading from 1 file is always going to be faster than reading from 2 files, the only difference is YAML deserialization vs JSON deserialization, which should be negligible. This could be easily tuned to be more performant, but 99% of the time will be spent reading the file into memory from secondary storage.

Also, some things had to be duplicated, since this library makes some things internal-only

https://gist.github.com/onionhammer/c019b04a7c4f058cd57183f0df738905

[shawncal]

@markwallace-microsoft

[shawncal]

@onionhammer This is a good idea - I like that semantic functions stored markdown would also be visible and nicely rendered in github, etc.

We're working on evaluating a couple new prompt formats, and this is a good one to add to the list. @markwallace-microsoft

[onionhammer]

Thanks, hoping support is added in

[matthewbolanos]

We're starting with the YAML format that is being defined by Azure AI Studio. Afterwards, we can add markdown support.

[onionhammer]

We're starting with the YAML format that is being defined by Azure AI Studio. Afterwards, we can add markdown support.

This relies on YAML so I guess that makes sense.

[markwallace-microsoft]

All .Net issues prior to 1-Dec-2023 are being closed. Please re-open, if this issue is still relevant to the .Net Semantic Kernel 1.x release. In the future all issues that are inactive for more than 90 days will be labelled as 'stale' and closed 14 days later.

[onionhammer]

@markwallace-microsoft if this is not complete, dont mark it as closed as complete.

Please reopen.