WEBVTT 00:00.240 --> 00:04.400 Guard object serves as the central interface for guardrails. 00:04.440 --> 00:05.480 AI framework. 00:05.720 --> 00:13.320 When initialized, its seeds with a rail specification that outlines the rules and standards the AI's 00:13.360 --> 00:14.800 output must meet. 00:16.280 --> 00:19.720 The guard object is employed to operate the guardrails. 00:19.920 --> 00:20.920 AI engine. 00:21.400 --> 00:29.360 Managing the input prompts, wrapping around LLM calls, and maintaining a log of call history for reference 00:29.360 --> 00:30.440 and analysis. 00:32.720 --> 00:39.720 With this context in mind, let's delve into the flow of using a guard for output validation. 00:41.200 --> 00:47.920 The first step will be creating a guard object. 00:47.920 --> 00:51.520 You can start by defining the output to validate. 00:53.760 --> 01:03.240 There are three options that can be chosen based on the requirements rail specification or using a Pydantic 01:03.240 --> 01:08.470 model for data validation or a simple string validation. 01:11.510 --> 01:18.710 The next step would be preparing the lm callable function with the necessary prompt and instruction 01:18.710 --> 01:23.150 that needs to be validated. 01:23.310 --> 01:29.750 Finally, after selecting the output type prompts an instruction that needs to be validated. 01:30.430 --> 01:34.030 Initialize the guard with the relevant specifications. 01:36.710 --> 01:45.270 Once the guard object is initialized, the next step would be invoking the guard object. 01:47.110 --> 01:50.790 This step involves the guard performing following actions. 01:53.030 --> 01:59.390 Here, the guard calls the large language model API with the provided prompts and instructions. 02:01.470 --> 02:07.950 The LM processes the request and returns the output. 02:08.030 --> 02:11.150 The guard validates Lmm's output against the chosen 02:14.820 --> 02:20.900 Simultaneously, details of the operations are logged for record keeping and potential debugging. 02:25.780 --> 02:33.020 The outcome of validation could be valid or invalid if the output is valid. 02:33.180 --> 02:38.780 It's ready for use if the output is not valid. 02:38.940 --> 02:44.220 The guard checks a specified on fail action, which can be one of the following. 02:46.460 --> 02:58.380 Risk in which the guard object requests the LM to generate the output again, or filter or fix, which 02:58.380 --> 03:01.020 means automatically correct the output. 03:03.100 --> 03:10.260 Refrain or to not perform any operation or no OP, that means no operation. 03:11.700 --> 03:17.740 Likely similar to refrain indicating no action will be taken. 03:17.780 --> 03:21.680 Finally, depending on the validation On and on. 03:21.680 --> 03:22.920 Fail actions. 03:23.160 --> 03:25.920 The resulting output is returned. 03:31.920 --> 03:39.760 Guard framework includes two essential flows calling and validating, with built in mechanisms for error 03:39.760 --> 03:41.600 handling and retries. 03:42.560 --> 03:45.680 Creating a resilient I application process. 03:49.000 --> 03:50.760 Let's look at the call flow. 03:52.080 --> 03:58.000 The first step in leveraging the guardrails I is to wrap your LLM with guardrails. 04:00.560 --> 04:04.200 Validating its output against a Rel specification. 04:05.200 --> 04:12.080 This is done by instantiating a guard and calling it with your desired LLM function. 04:14.200 --> 04:21.560 This method returns a tuple containing both the raw output from the LLM and validated output. 04:22.640 --> 04:29.790 Ensuring you have the data you need in both in its original Format and the refined format. 04:31.750 --> 04:37.590 This approach ensures that every call to your LLM is screened through guardrails. 04:38.390 --> 04:48.430 Validating the output in real time and ensuring it adheres to your standards. 04:49.470 --> 04:51.910 The second flow is validate flow. 04:52.590 --> 04:59.750 For scenarios where you prefer direct control over the LLM, or wish to apply guardrails as a Post-processor. 04:59.790 --> 05:05.310 Guard validate offers a flexible solution. 05:05.310 --> 05:09.470 It applies the rail specification to the Llms output. 05:11.710 --> 05:12.750 After the fact. 05:13.830 --> 05:21.270 You can even specify the number of risks, allowing guardrails to automatically adjust queries to LLM 05:21.470 --> 05:27.470 for better output, or set it to zero to keep it purely as a validation step. 05:32.270 --> 05:39.540 The guard object gracefully handles the errors, so understanding that errors are part of any API interaction. 05:40.180 --> 05:48.620 Guardrails has implemented a robust error handling and retry mechanism when. 05:48.660 --> 05:51.700 Encountering errors like API connection error. 05:52.020 --> 05:52.980 API error. 05:53.260 --> 05:53.980 Try again. 05:53.980 --> 05:57.740 Timeout rate limit error or service unavailable error. 05:59.020 --> 06:04.140 Guardrails automatically retries the request using exponential backoff. 06:05.500 --> 06:13.820 This process continues until a maximum wait time is reached, ensuring that temporary issues don't halt 06:13.820 --> 06:16.380 your application's functionality. 06:17.780 --> 06:26.740 In cases where an error falls outside of the predefined retrieval errors, guardrails raises an exception 06:26.940 --> 06:29.100 designed to aid in troubleshooting. 06:29.940 --> 06:33.820 This ensures that developers are informed of the root cause. 06:34.500 --> 06:41.140 Facilitating a quicker resolution to any issues encountered.