semantic-kernel
semantic-kernel copied to clipboard
SQL DB Agent/Connector/Skills
What is the best approach to using Semantic Kernel to access SQL databases?
This blog post by LangChain about LLMs and SQL has some interesting ideas: https://blog.langchain.dev/llms-and-sql/
It discusses:
- Ways to a include a description of the database schema and data in the input prompts.
- How to limit output size to fit in max token limits
- How to handle errors.
Is the best approach a combination of a SQL DB connector + skills customized with DB schema + data?
What about the error handling? Is that another skill? Or is that some kind of agent or part of the planner's job?
This is interesting. I think for precision, error handling and other related stuff, it might be more convenient to call a native skill
that handles database read and write whenever necessary in a semantic skill
Hi @samleegithub this is a really interesting article. I am on the same page as @tynguyen. I would consider creating a SQL DB connector, a set of native skills that interact with this connector, perform error handling, and process large batches of data. Then more targeted semantic skills can call these native skills.
We mostly follow this pattern for the Connectors.Sqlite SqliteMemoryStore (though here, the schema is mostly defined at the connector level).
I am investigating approaches to this issue
Curious any update on this issue or any workaround/options if one wants to query the SQL DB as part of building the prompt?
@samleegithub not sure if have seen this blog post > https://devblogs.microsoft.com/semantic-kernel/use-natural-language-to-execute-sql-queries/ we discuss and share our approach. Hopefully this helps with your question. Closing this issue but if you have further questions feel free to post on here.
@nacharya1 Thanks for sharing this blog post. I hadn't seen it before.
Is there a way to leverage this to turn into a plugin?
We are currently working on a big investment on memory and storage: https://github.com/microsoft/semantic-memory
Currently, the strategy is to incorporate SQL access as part of this. Active discussion are underway on how this intersects with plug-in architecture.