Overview
This model is meant to enhance adherence to provided context (e.g., for RAG applications) and reduce hallucinations, inspired by airoboros context-obedient question answer format.
license: cc-by-4.0
Contextual DPO
Overview
The format for a contextual prompt is as follows:
BEGININPUT
BEGINCONTEXT
[key0: value0]
[key1: value1]
... other metdata ...
ENDCONTEXT
[insert your text blocks here]
ENDINPUT
[add as many other blocks, in the exact same format]
BEGININSTRUCTION
[insert your instruction(s). The model was tuned with single questions, paragraph format, lists, etc.]
ENDINSTRUCTION
I know it's a bit verbose and annoying, but after much trial and error, using these explicit delimiters helps the model understand where to find the responses and how to associate specific sources with it.
BEGININPUT - denotes a new input block
BEGINCONTEXT - denotes the block of context (metadata key/value pairs) to associate with the current input block
ENDCONTEXT - denotes the end of the metadata block for the current input
[text] - Insert whatever text you want for the input block, as many paragraphs as can fit in the context.
ENDINPUT - denotes the end of the current input block
[repeat as many input blocks in this format as you want]
BEGININSTRUCTION - denotes the start of the list (or one) instruction(s) to respond to for all of the input blocks above.
[instruction(s)]
ENDINSTRUCTION - denotes the end of instruction set
Here's a trivial, but important example to prove the point:
BEGININPUT
BEGINCONTEXT
date: 2021-01-01
url: https://web.site/123
ENDCONTEXT
In a shocking turn of events, blueberries are now green, but will be sticking with the same name.
ENDINPUT
BEGININSTRUCTION
What color are bluberries? Source?
ENDINSTRUCTION
And the expected response:
Blueberries are now green.
Source:
date: 2021-01-01
url: https://web.site/123
References in response
As shown in the example, the dataset includes many examples of including source details in the response, when the question asks for source/citation/references.
Why do this? Well, the R in RAG seems to be the weakest link in the chain.
Retrieval accuracy, depending on many factors including the overall dataset size, can be quite low.
This accuracy increases when retrieving more documents, but then you have the issue of actually using
the retrieved documents in prompts. If you use one prompt per document (or document chunk), you know
exactly which document the answer came from, so there's no issue. If, however, you include multiple
chunks in a single prompt, it's useful to include the specific reference chunk(s) used to generate the
response, rather than naively including references to all of the chunks included in the prompt.
For example, suppose I have two documents:
url: http://foo.bar/1
Strawberries are tasty.
url: http://bar.foo/2
The cat is blue.
If the question being asked is What color is the cat?, I would only expect the 2nd document to be referenced in the response, as the other link is irrelevant.
