WEBVTT NOTE Sentence-level transcript of https://www.youtube.com/watch?v=-x5GEVnkuRw NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/-x5GEVnkuRw.html. A cue ends where the next begins, or 2 s after its last word. s1 00:00:00.000 --> 00:00:00.920 Hey, hey, welcome. s2 00:00:00.920 --> 00:00:02.040 My name is Cedric Clyburn. s3 00:00:02.040 --> 00:00:11.080 I'm an open source engineer here at Red Hat, and I think we can all agree that context is the most important aspect to building an AI application or an agent, right? s4 00:00:11.080 --> 00:00:15.800 It's the reason that harnesses have become so popular in order to manage the LLM's context. s5 00:00:15.800 --> 00:00:25.080 But, the thing is, no matter what model or agent that you're using, there is so much data that we're not able to use properly because it's in unstructured formats. s6 00:00:25.080 --> 00:00:35.080 I'm talking everything from PDFs to presentations to contracts and technical docs, even meeting notes, scanned documents, diagrams, tables, images, and more. s7 00:00:35.080 --> 00:00:38.640 And uh sorry, I know that's a lot, but you understand what I mean, right? s8 00:00:38.640 --> 00:00:43.280 All this data needs to be transformed into something that an LLM can actually understand. s9 00:00:43.280 --> 00:00:53.840 And that's why by the end of this session, you'll understand how to extract structure between raw enterprise documents and use it to power better downstream AI systems like rag and agent. s10 00:00:53.840 --> 00:00:55.680 So, let's get started. s11 00:00:55.680 --> 00:01:02.880 Now, I think Jensen from Nvidia made this point super clear at his keynote that unstructured data is becoming this new context layer for AI. s12 00:01:02.880 --> 00:01:12.720 And the reality though, for many teams, and I know this personally working at Red Hat, that PDFs and data are spread across dozens of different systems. s13 00:01:12.720 --> 00:01:14.560 So, we've got a lot to cover today. s14 00:01:14.560 --> 00:01:23.840 As you might know, a large majority of the world's data is unstructured, and so no matter what model you're using, if you're working with data like PDFs and unstructured types of formats, s15 00:01:23.840 --> 00:01:25.920 this is a bit tricky to work with. s16 00:01:25.920 --> 00:01:33.040 Because there are solutions out there, but they might be proprietary or require you to send your private data to someone else's server. s17 00:01:33.040 --> 00:01:42.760 And for not just text, how do we take documents and their graphs or tables and images to formats that LLMs can understand like markdown or JSON? s18 00:01:42.760 --> 00:01:49.920 And I'm going to show you how in the session today because we're going to be using an open source tool, part of the Linux Foundation, that is called Docling, s19 00:01:49.920 --> 00:01:53.320 and learn about extraction, parsing, chunking, and much more. s20 00:01:53.320 --> 00:01:56.640 And I've got some live demos for you, so we're going to have some fun. s21 00:01:56.640 --> 00:02:04.440 And just in case you'd like it, we have the session slides here on the right and a little overview of the specifics I'll be showing you in today's session. s22 00:02:04.440 --> 00:02:06.960 But, without further ado, let's get started. s23 00:02:06.960 --> 00:02:10.520 So, why is there a need for advanced document processing? s24 00:02:10.520 --> 00:02:22.280 As I briefly mentioned before, you might have a lot of technical documentation or meeting minutes or different types of documents and invoices that you need to use and maybe rag or different type of applications s25 00:02:22.280 --> 00:02:26.360 where the uh context is provided to an LLM. s26 00:02:26.360 --> 00:02:38.920 So, whether it's rag or retrieval augmented generation to answer questions based on this data, or you're using this to fine-tune a new specialized model, well, data is this key ingredient behind those applications. s27 00:02:38.920 --> 00:02:50.160 And it doesn't matter if you're using, you know, NVIDIA acceleration or an open-source or proprietary model, that data and the way you process it is the key determining factor s28 00:02:50.160 --> 00:02:55.880 in whether your answer is going to be correct or incorrect for the user or customer at the end of the day. s29 00:02:55.880 --> 00:02:58.640 And that's what's most important. s30 00:02:58.640 --> 00:02:59.880 And how important is it? s31 00:02:59.880 --> 00:03:13.560 Well, I have this viral tweet from earlier where 20 scientific papers now feature a new nonsensical term that doesn't exist because AI misinterpreted a very old article that was scanned and taken to a PDF, s32 00:03:13.560 --> 00:03:17.400 merging two different words from two different columns in this PDF. s33 00:03:17.400 --> 00:03:28.360 And because researchers are using these models in order to help them write, now we have different types of scientific papers that all feature this word and are even being cited by other people. s34 00:03:28.360 --> 00:03:38.320 And so, that's how important it is to make sure that the data that we're processing is processed in a way that's accurate and not hallucinated and able to be used confidently s35 00:03:38.320 --> 00:03:41.880 in our applications that we're delivering to users and customers. s36 00:03:41.880 --> 00:03:43.720 So, it's quite important. s37 00:03:43.720 --> 00:03:54.680 Now, if we were to use a tool like Docling that I can run on my own machine, you could see that these two words are quite far away from each other and shouldn't have been combined in the first place. s38 00:03:54.680 --> 00:03:58.720 But, that's how we're going to learn about extracting this text here in a second. s39 00:03:58.720 --> 00:04:08.560 Now, if we were to try a simple PDF parser for a PDF like this that includes um a table here, it has an image, there's captions, and there's regular sections of text, s40 00:04:08.560 --> 00:04:11.959 well, we might get an answer like this here on the right in markdown. s41 00:04:11.959 --> 00:04:22.360 You know, this might be very fast and cheap to run even on CPU, but the issue is is that a lot of this text has been truncated, has been merged, s42 00:04:22.360 --> 00:04:25.200 and isn't decipherable even by me as a human. s43 00:04:25.200 --> 00:04:31.840 And if I sent this to a model, I don't think I could trust that the model could extract specifics from, say for example, this table. s44 00:04:31.840 --> 00:04:43.120 Because the table has been kind of just spit out linearly, and this information isn't fit for most use cases where I need to ask questions or have an agent do validation s45 00:04:43.120 --> 00:04:46.080 and extraction on this source data. s46 00:04:46.080 --> 00:04:48.000 So, this isn't going to cut it, right? s47 00:04:48.000 --> 00:04:52.800 There's undesired page headers, we don't understand the table, and where's the content from the image, right? s48 00:04:52.800 --> 00:04:54.400 It's not even there. s49 00:04:54.400 --> 00:04:59.200 When we're using frontier models, this is um kind of not bad, right? s50 00:04:59.200 --> 00:05:00.520 But, it's quite expensive. s51 00:05:00.520 --> 00:05:13.080 If I'm sending this to a model that's maybe $30 per million output tokens, you can see how this can get quite expensive as I scale this up to dozens or hundreds or, in a lot of cases, thousands of PDFs that organizations s52 00:05:13.080 --> 00:05:16.400 have to work through to use an AI application. s53 00:05:16.400 --> 00:05:27.560 And the difference is between maybe a 5.1 of a model that was depreciated in the 5.2 version of a model make it tricky to have structured output that's consistent every single time. s54 00:05:27.560 --> 00:05:37.840 And so, while it might be good quality and I can see that most of this looks accurate in the exported markdown, we might be susceptible to hallucinations because models are non-deterministic, s55 00:05:37.840 --> 00:05:40.000 and this is really tricky at scale. s56 00:05:40.000 --> 00:05:42.520 And so, what is the middle ground? s57 00:05:42.520 --> 00:05:44.280 Well, that's where Docling comes in. s58 00:05:44.280 --> 00:05:56.280 It's a fast and cheap, and most importantly, local CLI and library that I can use to take various types of input sources and convert this to markdown, JSON, and a Pydantic s59 00:05:56.280 --> 00:06:08.160 data type that I can use in my applications and that I can scale up if I have thousands of different types of formats that need to be used or translated to something like markdown. s60 00:06:08.160 --> 00:06:16.280 And so we rendered this as HTML, but you can see here we've got this export of the specific table that we had here previously. s61 00:06:16.280 --> 00:06:21.160 Because as a PDF, this data type is spread out and it's proprietary. s62 00:06:21.160 --> 00:06:26.520 So, it's hard to extract this type of data from the source PDF here. s63 00:06:26.520 --> 00:06:41.560 And I'll show you how Docling does it by using a combination of OCR and specific vision models that extract the format and allow me to do things like structure output if I only, say for example, want a specific column to be outputted s64 00:06:41.560 --> 00:06:42.840 from a content source. s65 00:06:42.840 --> 00:06:43.960 So, it's really cool. s66 00:06:43.960 --> 00:06:45.720 And I've been using it at Red Hat. s67 00:06:45.720 --> 00:06:52.000 My team uses it because we have thousands of PDFs that we need to work with, specifically from product documentation. s68 00:06:52.000 --> 00:06:56.000 But also, we have content like images that we want to extract using vision models. s69 00:06:56.000 --> 00:07:10.080 And what Docling does with a pip install Docling is allow me to convert single documents or websites or anything else to markdown or whatever file type I want and be able to work with the page layout so I don't lose the consistency s70 00:07:10.080 --> 00:07:13.160 in the structure of the source document. s71 00:07:13.160 --> 00:07:23.760 And there's a lot of other integrations and for situations where maybe you need to run this locally or you don't want to pay for a service or you have an air-gapped environment. s72 00:07:23.760 --> 00:07:28.680 So, you're able to do this using this open-source project that is part of the Linux Foundation. s73 00:07:28.680 --> 00:07:36.280 So, before I show you the quick demo that I want to highlight the project, I want to talk a little bit about scale and cost. s74 00:07:36.280 --> 00:07:46.680 As I just mentioned it there earlier, but there is a public use case I want to show you from Leandro at Hugging Face where he compared a source of common crawl PDFs s75 00:07:46.680 --> 00:07:57.800 and where he did a little bit of pre-work on them and actually extracted the structure using OCR and using DocLing in order to remove certain parts and clean this up for the fine PDFs s76 00:07:57.800 --> 00:08:09.600 export which is thousands of tokens from PDFs around the web that you could use for training a model etc. But the two comparisons he did using GPU and using CPU for DocLing s77 00:08:09.600 --> 00:08:19.160 allowed him to do this at 50 times of a cost savings compared to VLMs and OCR naively. s78 00:08:19.160 --> 00:08:27.080 And so this is what's really cool is that you can really scale this up and he did this on CPU and not needing GPU which is really cool. s79 00:08:27.080 --> 00:08:29.440 And it's not just document conversion, right? s80 00:08:29.440 --> 00:08:34.560 This example was getting things ready from PDFs, but let's say we have images, right? s81 00:08:34.560 --> 00:08:40.599 This image with vision language model was able to be described and annotated, right? s82 00:08:40.599 --> 00:08:53.600 From this specific image right here, now we have all of this really important context that can be used in a rag application as an example, but also just for the end user to be able to understand what's happening in this image. s83 00:08:53.600 --> 00:09:03.320 And say for example, the SME doesn't work there anymore at the organization, now we have a way to understand what this is with the help of an LLM whether proprietary s84 00:09:03.320 --> 00:09:04.440 or local. s85 00:09:04.440 --> 00:09:10.000 And then finally, it's not just document conversion and annotation, but also structured output. s86 00:09:10.000 --> 00:09:19.720 Say for example, I have this invoice and I need to extract specifically the bill number, the total invoice price, the name of the sender, we're able to get that in a format s87 00:09:19.720 --> 00:09:21.120 that is structured. s88 00:09:21.120 --> 00:09:25.160 So I don't have to worry about, "Hey, it's going to pull in like the headings and titles." s89 00:09:25.160 --> 00:09:36.720 No, I just want the, you know, total invoice price and the bill number and I can get that in a format that's pydantic, but also just super simple if I'm just trying to get a a things out of a huge document. s90 00:09:36.720 --> 00:09:38.120 So let's hop over to the demo. s91 00:09:38.120 --> 00:09:39.760 Let me show you what I'm talking about. s92 00:09:39.760 --> 00:09:44.200 And by the way, we're going to be using this Docling workshop repository for the demos today. s93 00:09:44.200 --> 00:09:45.360 So, feel free to check it out. s94 00:09:45.360 --> 00:09:53.000 In this first example, we're going to be using Docling to convert a popular file type like a PDF because remember that data is the foundation for all AI systems. s95 00:09:53.000 --> 00:09:58.760 And in order to leverage that data, we have to properly ingest different file formats with accuracy. s96 00:09:58.760 --> 00:10:05.400 And without doing that, we can lose information or information can become unreadable from tables and diagrams and images. s97 00:10:05.400 --> 00:10:12.280 So, with Docling, what we're able to do with a simple pip install down here is start processing some of these different file types. s98 00:10:12.280 --> 00:10:13.560 So, I'll show you how we do that. s99 00:10:13.560 --> 00:10:20.200 First off, we're going to be importing essential components like the document converter as well as some other dependencies. s100 00:10:20.200 --> 00:10:28.240 And I'll show you the simplest way, which is to just start out with a PDF that we have online, which is Docling's own research paper. s101 00:10:28.240 --> 00:10:31.200 And here you can see we have different titles and subtitles. s102 00:10:31.200 --> 00:10:34.920 We have components such as images and captions that we have here. s103 00:10:34.920 --> 00:10:44.480 And at the bottom of this PDF, we also have something like a table here that we need to extract as well as images that might be helpful for our AI application or agent. s104 00:10:44.480 --> 00:10:53.880 So, let me come back to the notebook here and I'll show you how we do this simple conversion by using the Docling's document converter and exporting this to markdown. s105 00:10:53.880 --> 00:11:03.920 So, here you can see is a rough example of how fast this can be for a eight-page PDF to be able to export this in a way that an LLM can start using, right? s106 00:11:03.920 --> 00:11:06.839 But at the same time, this is a Pydantic data type. s107 00:11:06.839 --> 00:11:16.920 So, you can see we can explore this PDF and the number of pages and tables and see what is on which page of this PDF and export this into a variety of different formats s108 00:11:16.920 --> 00:11:20.200 like markdown, HTML, dictionary, and much more. s109 00:11:20.200 --> 00:11:25.520 But the real value here is not just with basic text and columns, but working with tables. s110 00:11:25.520 --> 00:11:30.120 So, this PDF here has a variety of different tables that we want to be able to extract. s111 00:11:30.120 --> 00:11:42.360 And so, by doing a converter for this specific document, we can then extract these tables here and be able to export this to a data frame so we can render this out in our Jupiter notebook here. s112 00:11:42.360 --> 00:11:53.120 So as I run this cell, you can see that we've exported eight different tables from that source PDF and we can list these but also be able to get these in a format ready to use in a rag application s113 00:11:53.120 --> 00:11:55.520 or just to query with our LLM. s114 00:11:55.520 --> 00:12:04.200 So we've taken a look at how to pull text and tables from a PDF, but what about visualizing and extracting images from that source document as well? s115 00:12:04.200 --> 00:12:13.600 Now, for this specific example, what we'll do is set up a PDF pipeline that will allow us to scale up the images and push this into a document converter. s116 00:12:13.600 --> 00:12:22.440 So now when I go to inspect the images and picture content in the cells, we can see this nicely mapped out where we have the picture, so the source image, s117 00:12:22.440 --> 00:12:33.920 the caption of that, and all of the embedded text elements that we could use in some type of retrieval augmented generation application to ask questions about, "Hey, what's happening in these different photos s118 00:12:33.920 --> 00:12:35.520 in our source PDF?" s119 00:12:35.520 --> 00:12:43.720 I think what would help here is also to be able to visualize the document layout by using the bounding boxes provided by the layout visualizer here. s120 00:12:43.720 --> 00:12:52.480 So here what we're going to do is visualize all of the different elements and components that can be extracted from, say for example, that source PDF. s121 00:12:52.480 --> 00:13:00.920 So section headers or text or subtitles or different components such as that photo that we just pulled and extracted from the PDF. s122 00:13:00.920 --> 00:13:13.600 So this is one of the models that Doc Lee provides which can be used for situations where you might have personal identifiable information from a customer that you want to remove from a source document type before you extract that into your application. s123 00:13:13.600 --> 00:13:23.839 We can also use vision language models in order to enrich the source images and diagrams that might be in these document types using something like O llama or a third-party LLM. s124 00:13:23.839 --> 00:13:34.760 So what we're going to do here is set up a PDF pipeline that's going to use a local running Granite model and say, "Hey, give us a detailed description of what's happening in this image." s125 00:13:34.760 --> 00:13:45.600 And with that document converter, we're going to go ahead and display that enriched document by calling the OpenAI endpoint with Ollama that we have running locally at the completions endpoint. s126 00:13:45.600 --> 00:13:51.520 And so here we have an annotated caption of what's happening with that DocQuery pipeline image that we were taking a look at earlier. s127 00:13:51.520 --> 00:13:57.800 Where originally we were just pulling the caption, but now we can use a vision language model to describe what's happening in these photos. s128 00:13:57.800 --> 00:14:07.080 And with all this additional information, this can help us to build a really solid RAG pipeline to where we can do questioning and answering over our source data. s129 00:14:07.080 --> 00:14:13.360 And for this example, I want to show you what's known as chunkless RAG or agentic RAG using DocQuery. s130 00:14:13.360 --> 00:14:23.240 And now by starting off with our document outline, so processing a PDF with DocQuery like we just did, we can allow an LLM to be able to pick the most relevant s131 00:14:23.240 --> 00:14:33.960 part of the document that is related to the user's question and pull that full text from the DocQuery document itself to try to answer that question for the user. s132 00:14:33.960 --> 00:14:35.920 And this can run in a agentic loop. s133 00:14:35.920 --> 00:14:48.120 And what's really important here is that we're doing RAG but without having to use a chunker or embedding model or vector database, etc., etc. So the index ends up being the markdown outline of the document. s134 00:14:48.120 --> 00:14:59.400 Now when the user asks a question, the entire retrieval index typically would be thousands of vectors in a database where we would do semantic similarity to make sure, "Hey, these sections are similar to the user's question." s135 00:14:59.400 --> 00:15:06.520 But for us, what we're going to do is be able to see a markdown outline of the document with each section summary outline. s136 00:15:06.520 --> 00:15:15.760 So if the LLM is looking for something about getting started with DocQuery, well it can just pull from this reference of text to say that DocQuery can be installed from PyPI. s137 00:15:15.760 --> 00:15:17.760 And that's the entire retrieval index. s138 00:15:17.760 --> 00:15:22.080 So let's say we have a query, "What are the main AI models used in DocQuery?" s139 00:15:22.080 --> 00:15:29.240 Well we're setting up a rag agent here to be able to iterate on that specific question about five times. s140 00:15:29.240 --> 00:15:39.040 So, we see that there are 20 sections available when the user is asked the question, and we're going to search for that specific part of text that talks about the AI models s141 00:15:39.040 --> 00:15:43.280 and be able to determine, "Hey, is this relevant to answering the question?" s142 00:15:43.280 --> 00:15:53.720 And you can see here the final answer in one iteration was pulled from that source material without having to go in the vector database but instead search that docling document structure s143 00:15:53.720 --> 00:15:55.280 for the specific text. s144 00:15:55.280 --> 00:16:02.360 So, it's a quite interesting way to be able to answer users' questions through this chunklist retrieval augmented generation pattern. s145 00:16:02.360 --> 00:16:19.120 And while this first example might have been simple, what we can do is also pull the IBM 2025 annual report into the context here, which has 418 sections, so it's much larger, and ask the question like, "Hey, what was Red Hat's revenue growth in 2025, s146 00:16:19.120 --> 00:16:22.880 and how did to an overall software segment?" s147 00:16:22.880 --> 00:16:29.800 And so, here we're going to be iterating multiple times to figure out, "Hey, is this section relevant to the user's question?" s148 00:16:29.800 --> 00:16:32.480 And if not, we need to pull in more information. s149 00:16:32.480 --> 00:16:37.800 And so, that is how chunkless rag can work in a situation where you're using a tool like docling. s150 00:16:37.800 --> 00:16:43.000 But what happens when we have hundreds or hundreds of thousands of PDFs that we want to have processed? s151 00:16:43.000 --> 00:16:49.440 Well, this is where we can deploy docling as a REST API service using something that's known as docling serve. s152 00:16:49.440 --> 00:16:55.400 This allows us to scale things up and to run this as a microservice as a container or through Kubernetes. s153 00:16:55.400 --> 00:17:05.520 So, when we set things up here, we're going to do a pip install docling serve, and we're going to be able to serve this from a CLI with docling serve on a specific port, s154 00:17:05.520 --> 00:17:15.199 or once we have that server started, be able to send things to that specific endpoint with different types of options and arguments like, "Hey, do we want OCR? s155 00:17:15.199 --> 00:17:16.600 Do we want a specific back end? s156 00:17:16.600 --> 00:17:18.839 Or do we want images annotated? s157 00:17:18.839 --> 00:17:27.480 And so, that's how we can scale things up and allow this API endpoint to be able to handle hundreds or thousands of different document types at a time. s158 00:17:27.480 --> 00:17:32.720 And let's say, for example, that you're trying to build an AI agent, you can also use the Docling MCP server. s159 00:17:32.720 --> 00:17:47.000 So, this allows us to automate things with our AI agent and give it the capabilities that Docling has through that model context protocol and allow us to standardize the communication between, say, for example, Claude Coder Continue s160 00:17:47.000 --> 00:17:55.800 in our developer CLI to the MCP server, which can handle the document processing for us without us having to know all of those different arguments and commands. s161 00:17:55.800 --> 00:17:57.280 So, it makes it quite easy. s162 00:17:57.280 --> 00:18:05.640 And the example I show here is by using one of the Claude models on my own Mac itself and connecting this to my VS Code instance. s163 00:18:05.640 --> 00:18:07.960 So, let's understand the tools that are available. s164 00:18:07.960 --> 00:18:17.320 For the MCP server, we have conversion tools, generation tools, say, for example, if I want to process a specific part of a PDF, and manipulation tools. s165 00:18:17.320 --> 00:18:23.480 And this is all provided to the LLM and the agent that we're going to be using with the MCP server. s166 00:18:23.480 --> 00:18:31.360 So, here I'm just checking that my local MLX server to run an LLM that's running, and it looks like we've got Quinn 3.6 here. s167 00:18:31.360 --> 00:18:37.840 And we're going to verify that the Docling MCP server is also running, which would be done using UVX here. s168 00:18:37.840 --> 00:18:41.920 And so, we'll do that in this cell here to make sure that the MCP server is available. s169 00:18:41.920 --> 00:18:49.360 Now, in Claude Coder or Codex or another type of AI application, we're going to install the extension. s170 00:18:49.360 --> 00:18:54.160 So, for us, this means adding an MCP server in the config.yaml. s171 00:18:54.160 --> 00:19:03.120 And now, at this point, we can use a model and an MCP server to do things such as, "Hey, convert this document and give me a summary." s172 00:19:03.120 --> 00:19:10.280 Or, create a document with a section of action items and pull in a list from another PDF and export that as markdown. s173 00:19:10.280 --> 00:19:24.800 So, we can use all of those Docling components through the MCP server in order to agentically process and parse these documents using an AI agent like Cursor or Claude Code or one of the many open-source s174 00:19:24.800 --> 00:19:26.160 options that are out there. s175 00:19:26.160 --> 00:19:28.600 Now, let's head back to the slides and wrap things up. s176 00:19:28.600 --> 00:19:29.640 So, let's put it all together. s177 00:19:29.640 --> 00:19:39.840 With Docling, we've seen that we can take a PDF into format like Markdown or JSON with a fully local operation from our own machine without even needing a GPU. s178 00:19:39.840 --> 00:19:43.080 It's fast, it's cheap, and most importantly, it's open-source. s179 00:19:43.080 --> 00:19:45.120 So, I encourage you to check it all out. s180 00:19:45.120 --> 00:19:58.840 Behind the scenes, there's different pipelines that use a combination of OCR and layout analysis to structure everything together, put it together as a Pydantic Docling document that then you can use to export to different types of formats, s181 00:19:58.840 --> 00:20:03.360 create data sets, chunk that using the Hybrid Chunkier, and do so much more. s182 00:20:03.360 --> 00:20:07.680 It integrates with a lot of different rag frameworks and agentic systems and harnesses. s183 00:20:07.680 --> 00:20:08.880 So, feel free to try it out. s184 00:20:08.880 --> 00:20:12.440 And I want to give a big thank you to the AI engineering team for having me on. s185 00:20:12.440 --> 00:20:22.440 This is something that I'm really passionate about with processing documents, but also doing this in an open-source way because, you know, we're here at Red Hat and we love open-source. s186 00:20:22.440 --> 00:20:25.720 So, feel free to check out the slides, connect with me on LinkedIn. s187 00:20:25.720 --> 00:20:31.400 I appreciate the opportunity, enjoy the conference, and keep up with the AI engineering ecosystem. s188 00:20:31.400 --> 00:20:37.040 Things are looking super bright right now for the open-source world and for AI engineers in general. s189 00:20:37.040 --> 00:20:41.120 So, see you next time and thanks for watching.