|
|
|
|
|
by grncdr
1232 days ago
|
|
I've noticed when prompting ChatGPT for code that it occasionally invents libraries that don't exist at all, or adds it own input if something about a prompt is strongly connected to its latent knowledge. For example, I asked it to write a program that would select one of my favourite dinner ideas at random, providing a list of options in my prompt. It added 4 more recipes I'd never heard of and some playful commentary about Ruby in the comments (and a working program). As I'm a complete novice when it comes to LLMs, I'm really curious how you go about building these safeguards/constraints around knowledge you want the model to prioritize? Is it simply a matter of fine-tuning the model with explicit instructions on how to handle certain topics? Can you simply train it with assertions like "Ignore everything you know about comparing the Angular and React javascript frameworks. Read this document we wrote to compare them instead."? |
|
The constraints can be put in place through a bunch of different things. The prompt engineering is a big thing, instruction-tuned models can be pretty good at following very restrictive instructions. You do end up sacrificing some creativity in your answers by adding a lot of restrictions but it generally works quite well as a safeguard layer. A lot of the cool LLM applications are, first and foremost, proper prompting. Setting a low temperature is also key, as the higher likelihood suggestions _generally_ (but not always) are less made-up. ChatGPT makes this a bit harder as you have no control over the model parameters (temperature is OpenAI-set) and cannot control the original prompt, meaning you can't fully be in charge of the instructions it gets, so any mitigation to avoid hallucinations will have its limits.
After that yeah, the context documents you provide are pretty important in grounding it. It ties back in with the prompt, but you can more or less drill it into a low-temperature instruction-fine tuned model that if it can't find the answer within a set of documents you provide it, it should simply not answer. Again, you lose out in some contexts (it's a bad feeling on the user's end to not get an answer) but you also ensure that your model isn't live-freewheeling about a new framework called Reagular...