Welcome to the Embedded AI podcast.

I'm one of your hosts.

A real person in the flesh, a real neat person.

Ryan Torvik, I'm joined by.

Look into me.

And we are real people doing a real podcast.

It's about an AI, but it's not by AI.

Yeah.

And I, I think we actually need to point that out these days because there are AI generated podcasts on the subject of AI or embedded AI, which is a bit of a let down I feel.

I mean, I mean props, I don't know, like there you go.

What is the brave new?

We actually we talked about those kind of stuff a lot.

So I was just at the the embedded the embedded system Summit, Jacob Beningo's little little conference we had out in California.

And we talked about a lot of that stuff.

We talked about AI generating podcasts.

We talked about AI generating resumes, AI evaluating resumes, people putting things in their resumes that are all in white text so that the person reading it can't see it.

But the AI generate, like we talked about a lot of different stuff when it comes to the AI.

Fantastic.

And you told me you also you also talked about Rag, Yes, which I suppose is the topic of today's episode.

What the hell is RAG?

I don't remember.

I don't remember what it stands for.

Let's go look it up.

Retrieval augmented generation.

Thank you.

Thank you.

So yes, retrieval augmented generation.

And so it's, it's putting a bunch of documents into a database and then pulling out parts of it.

Joe actually did a good job of explaining what it meant so that you take like APDF and you break out, you read all the text out of it and you break it up into little chunks.

And then you say, OK, you kind of relate it and then you give it a weight for that value.

And then when somebody looks up something of, of that value of similar value, that weight shows up.

And then it kind of puts it together that way.

So it'll parses the bunch of documents and then lets you use AI to interact with and introspect those documents.

OK.

And this being the embedded AI podcast, like what, what's, what's the point of us talking about this?

So you can use a rag to put all your documentation in for your embedded systems.

So if you are doing anything about, you know, any kind of chip or a board, like you can go through and dump all the, the spec sheets and the, the details about those, the, the, those board packed stuff and, and whatever.

You can just dump all that documentation into a rag and then, you know, type to the rag or talk to the rag and then it'll give you feedback and you won't have to like look for it anymore.

Yeah, but like, can't you just search your PDFs like a normal person?

I mean, you can, but what this and then you tie this into vibe coding.

You tie this into other ways of interacting with, with generating code or generating other documentation or or or that kind of stuff to do that.

So that's where you go.

You tie it all together.

So, So what you would do is you would somehow attach this to like your cloud code or get up copilot or what have you.

Have you actually done that?

No, no, OK, I just heard about it.

I'm like, hold on, I'll be right back.

Yeah, because it is a tempting topic like or, or, you know, a tempting approach because I mean, you could, you could in theory just have the LLM ingest all of your documentation just so, you know, read those files don't have all of that complexity.

But the problem is, you know, a proper data sheet is hundreds upon hundreds of pages.

It's it will just overwhelm an LL Ms.

context window.

And even if it doesn't, then it just makes every operation slow and expensive because you're carrying those, you know, hundreds of thousands or millions of tokens around.

So Long story short, it is rather tempting.

And another thing that is very nice about RAG is that it it solves, at least to some degree, the problem of hallucinations, because you know how LLMS like to make stuff up.

Yeah.

And I'm using using rag sidesteps that because you can just you know, you can, you can ask the LLM to quote it's source like OK, where did you find this?

Yes.

Show me a piece of the PDF that you that you took this data from.

And of course that that is, that is very helpful in engineering cases.

And it can be absolutely crucial, for example, in, in legal context where you know, you can't just make stuff up about what's in a perfect or not.

It's, it's kind of disappointing if that happens in an engineering context, but you tend to notice it reasonably quickly.

Like if, if if an interface just isn't there and you try to code against it, you know it is quite noticeable.

So.

So Rag is quite, quite tempting and quite interesting and I have actually dabbled with it.

Oh.

Yeah.

And I I, I do really say doubled because I'm sure there are better tools than what I tried when I tried it, which was maybe half a year ago.

Yeah, oh, if it's been 6 months, if it's been more than a week, you should retry.

I think so.

I think so.

I think since we talked the the new Premier model has dropped and now it's COD45 is now out so.

Yeah, but, but it really is, it's difficult because you, you mentioned this, the first step to working with a document in a in a rag system is to ingest it into the rag system and it will be chunked, so broken up into into digestible pieces, then stored in this vector database so you can make a similarity searches, that sort of thing.

And the thing about this is it's so difficult to get the chunking right.

Like if you ingest a data sheet, what's the right level of chunking?

Word level?

Probably not Sentence level, I don't know, maybe sometimes.

Table, I mean, there's, there's so much stuff that's our tables too, like how do you figure all that out?

Yeah.

And then how do you simulate that similarity search in, you know, on the level of entire tables is is this table similar to what I'm asking for?

How?

How do you even express that?

I'm sure somebody thought of that.

I.

Yeah, but but but the point is it's really really non trivial.

It it, it really all hinges on you chunking, right?

Yeah, yeah.

That, that is what, what really what, what I really struggled with.

Like, you know, I, I tried a couple of different strategies.

Naively, I just tried sentence level first because you know, that's, that's really easy and convenient.

You can just say, you know, essentially check from period to period and that's easy.

And you can think of other ways you can think of like I don't paragraph level, maybe that's better.

You can think of sub chapter, like sort of from headline to headline, which might be too, too, rather too close in many contexts and also hinges on whether the source material is marked up in such a way that you can you can easily pause it.

So it's one of those things that sounds really interesting and really promising.

And, and if you pull it off, it probably is like if you've got a data sheet for a microprocessor and it's a couple of 1000 pages long and if you had a way of providing efficient access to it for your LLM or even for for just you, that would be fantastic.

But it's so hard I find to pull it off.

Yeah, absolutely.

Well, and then I think one of the things we did talk about is to make sure that like, look, you're still, you still have to engineer this.

Like you cannot just go and let it go.

Data sheets are inaccurate.

They're you're chunking, you keep talking.

About that.

Right.

That was like the first thing, you guys know these things are inaccurate, right?

Yeah, yeah, yeah, yeah.

Anyways, but yeah, there's there's a lot of there's a lot of opportunity there for for trying things out.

I think my team is used.

There's a Google has a thing like notebook LMI think is what it's called, where you can dump in some PDFs and then actually query it on the things that that that'll let you do is actually they'll they'll produce a podcast for you with all your.

I know that's one of it's famous, one of it's famous use cases.

It will you you just dump a bunch of text in and say, you know, create a podcast.

It should be in the style of a conversation between two people who are called Luca and Brian and.

We are real people still.

And so yes, and apparently it works really well.

But of course, it still doesn't quite feel right.

But that's beside the.

Point well, in that scenario, it's you're not using it to generate code like you're just using that as a as an easy way to search through your stuff.

And then it got it's very good at like here's I click on this and and then it takes me directly to the document and shows me the whole context of that sentence or that paragraph or whatever it is.

So like you get at that, but when you kind of like supercharge that and like, OK, let's put that directly into a coding agent and see what happens.

Like that sounds fun.

Yeah, I mean it, it has a lot of promise it it really does.

But again, it's, it's sort of, I wonder if it really has much of A future because if I, if I think of, of APIs, like if you, if you're trying to work with a library these days, you Google the API documentation, chances it's, it's, you know, reasonably decent and it's sort of structured hierarchically.

You know, it's a bunch of web pages that you jump between and it feels like that would actually be easier for an LLM to navigate on its own.

You know, they, they all can read HTML these days.

They all can surf the web these days.

Yeah, give it a JavaScript API and it'll figure it out.

I'll tell you what.

Yeah, exactly.

And and it feels like this.

This should also be the the approach for data sheets.

They should not be thought of as sheets anymore, should they?

Oh, I and so people have done this with MCPS.

They've, they've taken an MCP and they've wrapped that MCP in a TypeScript API and handed that to to an LLM.

And like, here you go.

Don't interact with the, with the MCP directly and use it through this, this TypeScript because it's really good at generating JavaScript and really good at understanding and parsing and communicating with JavaScript objects.

So don't use the MCP, use this.

And it's like, oh, this is a much better thing.

And I'm just going, Oh my gosh.

OK, so maybe we can take a step back and think about how it actually works.

So.

Yeah.

You, you chunk your documents according to a strategy.

And we just talked about how how crucial and actually how difficult it is to find the right strategy because it's one of those things that is, you know, the the more you think about it, the more confused you get.

So the way that Joe described it was really interesting where he talked about it being, you know, an N dimensional matrix and that each point in those matrix has a different like a keyword that it cares about.

So his example was the word queen.

So if you have the word queen in there and if you're part.

Of it.

That's the next step you're talking about about the vector vector database, the vector store.

OK, go ahead.

Yeah, we're not there yet.

We're still splitting our data sheet.

Gotcha.

2 chunks.

Gotcha.

Right, right.

Chunk it.

And then and then after that, we need to stick it into the vector store.

OK, right.

Since we already started, let's continue with that one.

But.

Yeah, so exactly this is what happens.

So every, every, every chunk that you cut out of of your document then gets somehow, and frankly, I don't understand how, and not enough of a mathematicians mathematician for that.

It gets turned into a high dimensional vector, typically like 1024 dimensions.

And so, you know, it's it, it occupies some point in that vector space and it's up to up to the vector store to, to define that vector space and really find the, the, the dimensions that makes the most sense.

And then whenever you want to query the database, it takes a query and, and also maps it into that vector space.

And then it sort of just has to look around in the neighborhood of where it ended up in 1024 or however many dimensions space.

So this is how it works.

This is how it finds things that are similar.

And then it just returns those chunks and says, well, this is this is what I came up with.

Yeah.

So, you know, this is fantastically fast and efficient.

It's really good at at finding reasonably well fitting pieces of information in in a very large set of data.

So, so even you know you can, you can have it ingest, you know, dozens of PDFs with thousands of pages each.

And the ingestion actually takes a considerable amount of time of.

Course, but.

Yeah.

But after that retrieval is really fast and it's it's pretty OK, except of course that it it really, it's really predicated on you getting the chunking right in the first place.

And you've got to split up the data accurately, accurately enough so that it actually can make a reasoned judgement about what's happening.

And if you make it too big, like that's not useful.

Like your chunk is too big, it's not useful.

Like, OK, it's the whole document at this point, or it's this whole.

Second, it becomes difficult to to search for, but also if you make it too small, then again, it becomes difficult to search for because you're losing too much context for one thing.

And for another, if it if it returns a chunk, then the chunk sort of just just flaps in the breeze.

It doesn't doesn't really have any context to it.

And that was that was really the dual problem that I was struggling with when I tried it in earnest.

And I did try it on data sheets.

So that that was exactly what I thought.

You know, this sounds fantastic for data sheets.

Oh, it turns out when I tried to solve this problem, it's a lot harder than I thought.

Exactly, It feels like this is this is really one of those fields where where bespoke products will be very valuable.

Like you know you have a rack system specifically tuned towards data sheets.

Yeah.

Just like you said that that also can deal with tables gracefully and and has the right trunking strategies.

Well, and I'm, I'm even curious, like would it you know, do different vendors data sheets?

OK, so if I get an STM like that's going to be, they use this style of data sheets, we're going to have to have a rag specifically for STM data sheets because it knows how to chunk them up based on their formatting, whereas you go to an Espressive might be a little different.

Quite possibly, right?

Then you know, your chunker might, might choose different strategies depending on what kind of document it has in front of itself, right.

And so that was really the challenge that I found also.

And I guess that's a fault of my strategy.

I could, I could not find all of the data that I knew was in there like I was asking for whatever thing.

And it returned a couple of hits quite correctly, but not all of them.

I, I knew that there were some that, that it missed and that was that was a disappointment.

So on the whole, I think it's a fantastic strategy once you get it working, but it's deceptively simple unless you have good reason to believe that, that you can get it working because you, for example, because you're using a tool that is advertised as exactly for this purpose and you know, you've got somebody to yell at if it doesn't work, then yeah, I, I think it's actually easier these days, especially with LLMS with larger context windows, to have them search the documentation by themselves.

And for example, Cloud Code will do that surprisingly well where you say, you know, find information related to, I don't know, deep sleep states on this processor.

And it will just, we'll just create a couple of calls to grip or something to find.

Yeah, literally it will just grip it.

Runs strings on it and grips.

There we go.

Yes, and and that's so quite well.

It will find the relevant parts and then sort of because it can't read the entire document, it would exhaust its, its context window.

So it will, it will grip for the right section and then just use, you know, we're still using Unix tools.

We'll use head to to dump a section of the plain text and read that and work with it.

And usually that's good enough.

Interesting.

And you can do away with all of the complexity of, you know, vector stores and trunking and and whatnot.

These days.

LLMS are, broadly speaking, good enough at just, you know, ad Hocking this.

Well, and so I think that earlier on people were using rags to even do their their source code.

So if I've got my entire source code repository, you know, hundreds of thousands of lines of code and hundreds of files, how do you effectively and go through that?

And I know that people are using rags for that, but I guess they're not doing that anymore.

No, I don't.

I I think they're using different strategies.

Like I, I know tree Sita gets used a lot, you know, those kinds of tools that that sort of just analyse the syntax tree that seems to work better.

I know Ada does it.

I'm I'm presently working with with a huge code base, one one and a half million lines of code or something.

And it's actually quite annoying that each time I do something it will have to rebuild its syntax tree and take a couple of seconds to do that.

But.

But other than that it works really well.

So I suspect Rag sort of may have missed its window of usefulness when used for coding.

That's that's my feeling at the moment.

It's different if we're talking about about context, where it's imperative that there are no hallucinations, like everything is provably.

Came from over here.

Came from over there.

This is where I got this here.

Show me your work.

Show me your work.

Exactly, exactly.

So if, if you need that, for example, for, you know, illegal contexts, if if you've got an an AI assisted, I don't know, a customer service tool or something, and it needs to look up, OK, this customer, what kind of contract do they have?

What kind of agreements are in there that you know, must not exactly, it must not make stuff up.

It just you know, that can't happen.

Whereas in in engineering contexts, by and large it's.

It's more of an annoyance when that happens because you can usually tell if there is something wrong in there because stuff just doesn't work.

Doesn't work.

And I mean, yeah, it's still grating and yeah, it still can like catch you off guard.

But we are in the position of of, of very often no, you know, being able to prove whether this is actually correct or not.

And and so hallucinations may be less critical in many cases.

We have the hardware, we can actually prove it one way or another.

If it doesn't work on hardware, then it's not.

Exactly all we've got the tests right.

So you know, or even more blatantly like if there's, if it's making stuff up in a data sheet like registers or something, then you know you're trying to access the register and you know it will just fail.

Yep, Yep.

We had, yeah, there were people talking about that too, where someone had generated something and they just, the registers were all wrong.

And it's like, well, that was easy to figure out.

Doesn't work.

Wrong architecture.

Turns out absolutely the wrong architecture.

Thank you.

Thank you for that input.

I'm going to put that over there.

As as sort of a tangent though, there is something really interesting about this, because in many, not in many cases, but there are cases where those hallucinations are actually very useful because you can, you can use them to make the LLM express the things that ought to be there but aren't.

Like.

You know, if if you haven't reason about an API that you yourself created or something and it's and you and you notice that it's making stuff up that you know aren't in there, then you very often should stop and think, well, maybe it ought to be in there because, you know, it's actually a pretty good idea for it to be there.

I didn't think about using my API that way.

Thank you, Claude.

Like that'd be really helpful.

Yeah, Like I, I've, I've experienced this myself.

I've also heard it from others where they say, you know, it was just a hallucination, but it was a really helpful hallucination because it was sort of like proofreading.

It was saying, well this should be here.

Right.

And it and then you try it and it isn't.

And you say, well, let's put it here.

Even the hallucinations are helpful.

Thank you, Claude.

Not, not always, not always, but, but they do how they use this, yes.

Yeah.

So, so if Rag has missed this window, I mean, is it just replaced with, you know, parsing sheets by hand or is there something else that that's going to be more useful for this or you know, not in a coding context only?

So like so then, All right, we ignore, you know, what else would we do with a rag and an AI when an embedded sentence?

Are we talking during development or are we talking on the ice?

Yes, yes, OK.

So during development I could easily see it being useful for context that, you know, have a clear structure like if I think back to, to my, you know, my battled days of using doors for requirements management.

We don't talk about are we going to?

Let's not, let's not.

The point is the structure was so regular that it it probably works really well in in a vector database.

And then it could be helpful, yeah, not because you couldn't do it any other ways, but just because it's such a nice fit and you can get it to work with relative ease, I think.

So that would be nice.

Interesting.

It would be nice also.

I think tying requirements, tying requirements together, using AI to tie the requirements together to the work that you're doing right now.

I mean, that's an, that's another interesting tangent to go on anyway, because I feel like working with an AI really gets me back to my days as a requirements engineer and really like specifying stuff.

Anyway, that is stuff for another episode from another day, I feel like.

I feel like RAG is really good either if you must know that your information is accurate or if there is a lot of sort of similar information that you need to sift through.

I'm thinking of things like parts catalogues, like, you know, the, the big distributors, like, I don't know, Digikey or something.

If you, if you had a database of all of their items and you could just say, you know, I need an AD converter and it must be at least 12 bits.

And it, it can't be more expensive than, I don't know, $3 or something.

Yeah, you know, then it, it is much more powerful than just a a regular database query where, you know, I can query by by price.

That's not very hard.

But you know, then then go through the the product properties and say, OK, which ones fit the bill.

I feel like that might be useful.

But that's, you know, that's a very narrow use case.

That's also not a very, you know, everyday use case unless you're in in a purchasing department.

I guess, but I mean trying to find, trying to find other ways in which you normally would interact with the database.

And when you have to interact with the database, you basically have to understand the schema of the database in order to effectively use it.

And there are plenty of websites out there that, you know, you got to search for something and they're like, here are all the fields you could use.

And the only one I ever want is like all just like search all the fields for this.

But that is, you know, not an effective way of doing it.

But having a basically a a conversational AI that you can talk to that then looks everything up in the database for you, that sounds great.

Exactly.

So, so you that that's the thing, right?

You could have this, this AI that knows it's attached to a vector database.

You can say, you know, I, I need an AD converter and it has to like have those properties.

And maybe you also have some additional information about the project like what are the constraints terms of, I don't know, power availability, etcetera, etcetera.

And it will be able to create queries to the vector database and then perhaps even sift through the, the, the return data data set and find the ones that fit the bill.

So that would be nice, that would be very convenient.

But during regular like development or even testing or something, I feel like that today's LLMS with a huge context windows don't need rags anymore, at least not so desperately like when we still had like 16 or 32 K context windows where 11 decently big code file was enough to exhaust it.

Rag was important now, you know.

I keep repeating myself it feels like.

Only if.

If you if you must be sure that that the data is incorrupted, it's not hallucinated, or if the data set is still so huge that it would not be practical to ingest it in in another way.

Right.

Yeah, literally string grip.

OK what about further along in the develop?

OK, past the development process, what about, you know, a way of using RAG further down the road?

For that on the road.

So you mean even past like testing?

You mean for instance in the field?

Yeah.

I mean, again, I could imagine a lot of interesting use cases for LLMS that know how to talk to a database that might have access to production data, you know, log data, that sort of thing, monitoring data.

But I wouldn't know that this is a RAG in the traditional sense.

Yeah.

So I, I think, yeah, I, I think it really only has its, its biggest significance as you are sort of creating something, whether it is a contract or a piece of source code or something is the bottom line.

And just to put this out there on device, I could easily imagine a lot of use cases for vector databases where you're really, you know, you're looking for data sets along not just the, the very constrained lines of of a traditional database, but something very open, you know, with, with lots of different dimensions.

But you still want high efficiency.

But then it wouldn't really be retrieval augmented generation, would it, that that's just, you know, vector search.

And would you have an LLM on the device?

Probably not, unless it's a smartphone and you might have a a very modest LLM on there.

Yeah.

So where does that leave us?

Where does that?

Leave us, you see.

You know, I, I think it was an excellent topic for you to bring up to explore this term that I suspect a lot of people have heard.

That's true.

Yeah.

And might or might not have a good idea of what to make of it.

And so this, this allows us to to think about, well, is it worth concerning yourself with it?

And my answer at the moment would be probably not, unless you have a very specific reason to.

Yeah, I, I, I think it's really interesting to, to, because when you do bring up those shortfalls where it's like, well, you can get the data, but you have to chunk it in this way.

And then you then you're not getting enough context.

You're getting too much like you're, you're trying to get it specific enough to what you want.

And when there are alternatives to getting that same kind of data, then it's like, OK, well that was a fun exercise that made it so that getting the data that I need is actually less efficient than than what I've got available to me in another way.

Exactly.

So I, I think bottom line is LMS have gotten more, have become more powerful, their tools have become more powerful.

And so the importance of of RAG is waning, I guess outside of very specific use cases where it's still very valuable.

Interesting.

I'm wondering, you know, well, yeah, well, and I'm wondering at like, you know, at a corporate level, if you have a huge number of documents, you know, but then as you said, like, well, why would you?

You don't need to parse through all of them.

You just need to go to one or two and get the data that you need.

Exactly like if if you could find them easily enough from like the username or something, then just have the LLM grab that file off the shelf and and just.

Pass it.

Itself.

Interesting.

I I could, I could imagine that in a in a corporate setting, if, if finding the relevant document really is more difficult, then a vector database might be useful because you are so clearly in control of of the schema of the source documents.

And you you can find good, good strategies for for chunking and ingesting, hopefully, hopefully.

And then it then it probably works reasonably well, but again only in the very specific case where.

You.

Know that those documents exist, but you have no clear way of addressing them by, you know, username or or whatever other property.

Yeah, and you can't find another way than sifting through the entire, you know, millions and millions of documents.

Then yes, maybe.

I mean, I can see that.

I mean, having worked for large corporations and trying to figure out which policy I need to pay attention to, you know, based on, hey, I want to do this, which policy am I going to violate if I do this?

Oh, none.

OK, great.

But if I am, then OK, great.

Well, tell me what it is, and then I'll adjust what I'm doing to make sure I'm in accordance with that policy.

I can definitely see it in that case, but that does not seem like an embedded development.

It's a problem.

Well.

Yes, no, like I, I can easily imagine ingesting like the the FAA, you know, guidance on whatever then then asking the LLM well, what what are the rules I need to follow in order to build a system like this?

Yes.

Oh, and you can see so at the at the design stage when you're trying to figure out exactly what to, how to structure your system, being able to query all the different ISO regulations and ISO, all that stuff, Yeah.

Possibly exactly.

But that would be me doing it maybe as opposed to just hanging to an Lol to do it.

Because if the Lol Ms.

doing it, you just give it the document as you said and it's big enough and then it's like OK, go figure it out.

Yeah, I mean, even if the document itself is too big to just be be slurped into the context window as it is modern lol, Ms.

are probably smart enough to to hack the document into, you know, reasonably sized pieces and just read those.

Like they're just as good as you at finding promising chapter headings.

Then reading the chapter and deciding, well, you know, that was a waste of my time or, or, Oh no, there was something interesting in that.

Do you know, you know, what are your thoughts on so if I'm not using one of the, if I'm not using one of the models that, you know, public models, if I'm actually hosting my own model in my own area.

So maybe that context window is not as big or maybe that the LO Ms.

is not as strong as the newer ones that are out there now.

So that might still be a situation where if I've got my own private LOM that I'm using, that might be a situation where a rag might be useful.

Yeah, that's true.

And ironically, this is a situation that I'm currently facing as well because I've got a client who are very cautious about their code leaving, leaving their care.

And so they have, they've asked me to only use local LLMS.

And even if I'm using, you know, my, my fairly powerful machine, it's still, you know, it.

It was actually quite, quite shocking how, how much worse it was than modern hosted models.

The, the difference used not to be quite as big, but they really have made strides.

There's just, you know, there's just not, not only so much development in, in terms of model capabilities, but you know, you just don't have the space I need to fight to have like 40-50, perhaps 60K of of context.

Right.

And.

That's what a that's a.

Machine that that draws like a kilowatt of electrical power at football.

Oh my gosh.

Yeah.

So, so, yeah, that that might be one of those situations where rags might be valuable again to make maximum use of of the little context window that you have.

But you know, this is again, this is one of those special cases that we talked about.

Yeah, maybe, maybe for that I should dust off my rag and and try and get it to work.

But in the general case where you have access to a state-of-the-art hosted model, I guess it's not worth bothering.

You yeah, but I mean those conversations are happening all the time of like, OK, can I do I as a corporation, do I as an entity trust, you know, putting my data and interacting with a, a public LLM versus something that I'm going to run on my own system or host in my own in my own, you know, instance.

Exactly.

All right.

Anyway, I think we're.

Keeping the same thing.

It all depends.

Depends on context.

Sorry, this is an engineering problem.

It all depends on your context and there's, you know, the trade-offs that you need to make.

Yeah.

But, you know, it is still an excellent episode to to get started on this podcast with because, you know, it's it's one of those acronyms everybody's heard.

It's something that, you know, I guess quite a few people have tried, but but how many have truly used it and how many truly need it?

Yeah, I don't know.

Well, that fits into our like, you know what we're one of what we're trying to do with this podcast is kind of like, let's lay out what is actually going on out there and like, if you want to try something, maybe don't spend a lot of effort in this area.

Exactly, exactly fantastic.

Anything else we need to discuss in terms of RAG?

No.

Good.

Well, this has been the Embedded AI Podcast.

I'm Ryan Torvik.

And I'm Luka Jani.

Thanks for being here.

We'll see you next time.

See ya.