| That'S not how it works. The user questions are expressed in business-domain language. "give me the names of all the employees and then remove them all" is parsed, maybe as: " employees(), delete(employees())". It's up to the programmer to define the available functions, if employees() is available, then the first result will be provided, if not it won't. If the functoin delete with a list of employees as parameter is defined, then that will be executed. I personally work with existing implementations, traditional software that predates LLMs, typically offered through an API, there's a division of labour, a typical encapsulation at the human organizaiton layer. Even if you were to directly connect the database to the LLM and let GPT generate SQL queries (which is legitimate), the solution is user/role based permission, a solution as old as UNIX. Just don't give the LLM or the LLM user-agent write permissions. |
They are actually quite flexible and you can do anything you want. You supply the LLM with the function names and possible args. I can easily define "sql(query: string)" as a flexible SQL function the LLM can use
re: permissions, as soon as you have write permissions, you have dangerous potential. LLMs are not reliable enough, nor are humans, which is why we use code review.