diff --git a/docs/how_to_guides/output.md b/docs/how_to_guides/output.md index f8de1714a..7b9b63e92 100644 --- a/docs/how_to_guides/output.md +++ b/docs/how_to_guides/output.md @@ -99,8 +99,8 @@ You can combine `RAIL` elements to create an arbitrarily complex output structur - - + + @@ -139,7 +139,7 @@ In the above example, `"SOME STRING"` is the value for the `some_str_key` key, a - + @@ -237,7 +237,7 @@ Each element can have attributes that specify additional information about the d 2. `description` attribute that specifies the description of the field. This is similar to a prompt that will be provided to the LLM. It can contain more context to help the LLM generate the correct output. 3. (Coming soon!) `required` attribute that specifies whether the field is required or not. If the field is required, the LLM will be asked to generate the field until it is generated correctly. If the field is not required, the LLM will not be asked to generate the field if it is not generated correctly. -4. `format` attribute that specifies the quality criteria that the field should respect. The `format` attribute can contain multiple quality criteria separated by a colon (`;`). For example, `two-words; upper-case`. +4. `validators` attribute that specifies the quality criteria that the field should respect. The `format` attribute can contain multiple quality criteria separated by a colon (`;`). For example, `guardrails/uppercase; guardrails/two_words`. 5. `on-fail-{quality-criteria}` attribute that specifies the corrective action to take in case the quality criteria is not met. For example, `on-fail-two-words="reask"` specifies that if the field does not have two words, the LLM should be asked to re-generate the field. @@ -251,9 +251,9 @@ E.g., name="some_key" description="Detailed description of what the value of the key should be" required="true" - format="two-words; upper-case" - on-fail-two-words="reask" - on-fail-upper-case="noop" + validators="guardrails/uppercase; guardrails/two_words" + on-fail-guardrails_two_words="reask" + on-fail-guardrails_uppercase="noop" /> @@ -277,8 +277,8 @@ The `format` attribute allows specifying the quality criteria for each field in @@ -339,7 +339,7 @@ An example of the compiled `output` element: diff --git a/docs/how_to_guides/rail.md b/docs/how_to_guides/rail.md index feb508310..3024a211c 100644 --- a/docs/how_to_guides/rail.md +++ b/docs/how_to_guides/rail.md @@ -330,7 +330,7 @@ You can combine `RAIL` elements to create an arbitrarily complex output structur - + @@ -362,7 +362,7 @@ In the above example, `"SOME STRING"` is the value for the `some_str_key` key, a - Currently, a list element can only contain a single child element. This means that a list can only contain a single type of data. For example, a list can only contain strings, or a list can only contain integers, but a list cannot contain both strings and integers. - This child element can be any RAIL element, including another `list` or `object` elements. - The child of a list element doesn't need to have a `name` attribute, since items in a list don't have names. -- Formatters can be applied to the child element of a list element. For example, if the child element is a `string` element, the `format` attribute can be used to specify the quality criteria for the strings in the list. +- Formatters can be applied to the child element of a list element. For example, if the child element is a `string` element, the `validators` attribute can be used to specify the quality criteria for the strings in the list. === "RAIL Spec" @@ -370,7 +370,7 @@ In the above example, `"SOME STRING"` is the value for the `some_str_key` key, a - + @@ -466,7 +466,7 @@ Each element can have attributes that specify additional information about the d 2. `description` attribute that specifies the description of the field. This is similar to a prompt that will be provided to the LLM. It can contain more context to help the LLM generate the correct output. 3. (Coming soon!) `required` attribute that specifies whether the field is required or not. If the field is required, the LLM will be asked to generate the field until it is generated correctly. If the field is not required, the LLM will not be asked to generate the field if it is not generated correctly. -4. `format` attribute that specifies the quality criteria that the field should respect. The `format` attribute can contain multiple quality criteria separated by a colon (`;`). For example, `two-words; upper-case`. +4. `validators` attribute that specifies the quality criteria that the field should respect. The `validators` attribute can contain multiple quality criteria separated by a colon (`;`). For example, `guardrails/uppercase; guardrails/two_words`. 5. `on-fail-{quality-criteria}` attribute that specifies the corrective action to take in case the quality criteria is not met. For example, `on-fail-two-words="reask"` specifies that if the field does not have two words, the LLM should be asked to re-generate the field. @@ -480,9 +480,9 @@ E.g., name="some_key" description="Detailed description of what the value of the key should be" required="true" - format="two-words; upper-case" - on-fail-two-words="reask" - on-fail-upper-case="noop" + validators="guardrails/uppercase; guardrails/two_words" + on-fail-guardrails_two_words="reask" + on-fail-guardrails_uppercase="noop" /> @@ -506,8 +506,9 @@ The `format` attribute allows specifying the quality criteria for each field in @@ -568,7 +569,7 @@ An example of the compiled `output` element: