-
Notifications
You must be signed in to change notification settings - Fork 11
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Caveats on how to ask, and what to watch on the answer [Multi line output] #12
Comments
I tried to handle this kind of situation with the python port, it is not extensive parsing, but it should support GPT explaining the commands to some extent and then ask if you want to execute the explained command without the excess text. It is currently limited to this: Line 41 in 1b7977e
|
Task vs question
Good call. Updated in 929eef7 EnvironmentsFYI Clipea is designed to give you command you can run in the current environment, rather than provide general command line help, so adding "mac" or "ubuntu" may not work as expected. This is due to the system prompt: https://github.com/dave1010/clipea/blob/main/clipea/system-prompt.txt It can be customised if you put your own prompt in here: You could try something like
Multi line outputIt should definitely be clearer to the user in these cases. Perhaps it should have a terse output if the response is just 1 command but then format it differently (colours too?) when there is more than 1 line of output. |
It seems that GPT-3.5 isn't always consistent with its output, and Llama-2-13B has the same issue of extra output.
Sequential runs using GPT-3.5, note the usage of mac/ubuntu and how the prompt is formatted as a question vs task changes the output:
Perhaps the README should encourage the user to use "task" vs "question", because this is a command line interface and not a question line interface. That would help minimize near-correct but I suppose inherently broken answers. If the prompt is a question, LLMs like to explain.
Doing some minimal parsing of the output might be useful, so that the explanation doesn't get sent in as the command. Because the explanation could include dangerous stuff, and from the output format it's not at all obvious, what gets sent as a command, if it's a multi-line answer. Would it be too harsh to just pass if it was a multi-line answer, to avoid bad mistakes?
I can contrive an example, in which the explanation begins:
In this case, is it "rm -rf" that gets sent to the shell, or is it the word "instead", or both?
The text was updated successfully, but these errors were encountered: