AI in Procurement | Understanding generative AI: Practical use cases for buyers with Dr Klaus Iffländer

Fabian Heinrich (00:01)
Hello dear listeners to another episode of Procurement Unplugged with Dr AI, Dr Klaus Iffländer, where we take a closer look at artificial intelligence this season. We listened to and looked at a few things in the first episode last week. The main question was: is the AI hype real? To what extent can I use it in my own company?

And how can I also skim myself off somewhere? In today's episode, we really want to delve into the topic of purchasing in more detail. So how can I apply this in purchasing? What topics are there in terms of expertise? People are always talking about all these great models. And of course this also involves all these buzzwords that you hear.

Basic model, RAG, vector database, database, GenAI and so on. Our Dr KI will shed some light on this and tell us exactly what can be used when and how, what works when and how, and how we can use it in our day-to-day purchasing processes and what we can do with it. Yes.

Klaus, that's all the preamble from me. Welcome again to the second episode here with us.

Dr. Klaus Iffländer (01:39)
Yes, thank you, thank you very much. Exactly, you've already moderated it. Perfect. Today we're talking about how to incorporate company-specific expertise and company context into such an AI model. And I think that's an important topic because, on the one hand, that's the AI models or their support much more useful, i.e. much more helpful for everyday working life. And on the other hand, it's always a topic where there is a lot of uncertainty among people because they ask themselves:

This is proprietary company knowledge, secret data so to speak. What can I actually give out of it or is it even safe to use it with an AI model? And I hope that when we talk about the topics now, i.e. RAG and vector database and LLM training, that these things will perhaps become a little clearer as to what is actually possible in terms of benefits and where it might also be dangerous to disclose data and where not.

But Fabian, perhaps you could first explain what kind of expertise is involved in the purchasing area.

Fabian Heinrich (02:53)
Yes, I talked a lot about use cases in the first episode. Of course, we want to look at these again here in particular to see which use cases have business benefits and generate ROI and savings in purchasing, which may already be working today or tomorrow, and which use cases may then also be used for training or other technologies.

In this context, there is also a lot of talk about vertical AI. Perhaps I can explain this again for everyone or for myself. I mean, these so-called basic models, what's the deal with this supervision and why do I have to train them further now? What can they do? We heard in the first episode that they can pass the Bavarian Abitur with a 2.0, for example. So what good are all these basic models?

Can I perhaps use them without a software solution provider? How do I have to train them? Or do I perhaps not need to train them at all? That might be interesting to clarify at the very beginning.

Dr. Klaus Iffländer (04:05)
Yes, definitely. So what do you know as the freely available tools such as Chat GPT or Anthropic Claude or what else is there? Google Gemini or these open source models from Meta, i.e. Llama. These are the so-called basic models. In other words, everything that is freely available. They are either free to use, like Chat GPT, for example.

Or in the case of Meta-Llama, you can even download the model weights and start them yourself if you have the appropriate hardware. These are the basic models. They are called base models because they are always trained on public information. everything that is now available in large... published in media publications or what you would find on Wikipedia. That's the kind of information that these models know. So they were trained or created with it, so to speak. That means they have very broad, very extensive knowledge.

And you are amazed at how specific it is at the same time. Because everything on Wikipedia is sometimes described there in great detail. But nobody knows all the Wikipedia pages by heart. And these basic models do. So they know the areas in which they were trained very well. And these basic models are very generously and broadly trained. And the Abitur, which you mentioned, is just such an exam.

It's also called a general higher education entrance qualification because it covers a very broad range of knowledge and that's what the students are tested on. And that's why it makes perfect sense that such a basic model, such an Abitur examination, could also pass well, because it's about several areas, i.e. maths, German, English and all kinds of school subjects, in which you are tested on having a very broad knowledge and also understanding these relationships and thinking through problems so that you can then solve these tasks or produce texts or, I don't know, have some kind of location and local knowledge in geography. Exactly, that's why basic models can solve these things very well.

On the other hand, basic models cannot solve certain things because they simply cannot know them. Namely specific, i.e. proprietary, company-specific workflows or company-specific knowledge. Because if, for example, I have a machine in the company to produce something, and this machine was built especially for my company and set up there, then it's probably not on Wikipedia or anywhere else how this machine is constructed and how to operate it, but this is precisely knowledge that only exists within a company or this company.

This is why such a basic model has no chance of gaining access to this knowledge. And that's why it can't answer any questions about it. It's certain things that you wouldn't find in Google, in the search engine.

Fabian Heinrich (07:42)
So I finally have two options here in purchasing. On the one hand, I can say that perhaps there are some topics that already work with the basic model, yes, or I can contact solution providers who offer me an improved version of the basic model, or there is a solution provider, or I can train the basic model myself using my specialist knowledge. Is this then vertical AI or vertical AI?

Dr. Klaus Iffländer (08:12)
Exactly.

So there are different approaches and possibilities as to exactly how to organise this. But in principle, that's exactly what it is. You integrate yourself into a function, for example the purchasing function, where function-specific knowledge is built up. So in the most concrete case, it's from the company, i.e. very, very specific information. Or then a bit more generally, how does purchasing work, how do purchasing processes work, what are all the tasks, that's just knowledge about this function.

‍Fabian Heinrich (08:45)
This is ultimately the reason why it makes sense to use the Co-Pilot with HubSpot or Salesforce and not your own Chat GPT. Or why it makes sense to use the Co-Pilot for purchasing solutions such as Mercanis and not the Chat GPT, because these models are already trained accordingly with the specialised data.

Dr. Klaus Iffländer (09:07)
Yes, exactly, or what Microsoft has done with the GitHub Co-Pilot, which has been trained on a lot of programme code, i.e. source code, and as a result this model is also very good at providing new suggestions for programming work.

Fabian Heinrich (09:24)
Yes, I mean, the listeners are probably already very excited, as am I myself. It's always all about use cases, yes. And there are thousands of use cases in procurement. I mean, I've been in procurement myself for many years. For example, now somehow from supplier evaluation to supplier search and selection to order processing. An important topic is always Contract comparison, NDA comparison, document comparison, purchasing policy comparison or even topics such as optimising supplier performance.

So if we now look at this multitude of use cases in purchasing in a very structured way, no matter how pre-trained or not, but now, for example with purchasing software, such as Mercanis, where could I get started tomorrow and have a huge impact tomorrow? Because it works almost immediately with very little pre-training.

Dr. Klaus Iffländer (10:35)
Yes, so with little pre-training actually always where a lot of data is already available. In other words, where you can put a lot of context and knowledge into the model. So if, in the simplest case, we imagine something like Chat GPT, I would copy this into the chat window, say, here's my data or these are my documents that I have now and I need to add these and these ... extract things from there and compare them so that they can be compared in a table, for example. You can definitely start with things like this.

Fabian Heinrich (11:11)
So for me, applications in purchasing are always a case of somehow comparing NDAs, where are the differences or comparing general terms and conditions, where are the differences, reading out contracts, that's all where you say, ok, if a solution provider offers this now, it works, you can use it tomorrow, so to speak, because it requires little preliminary training in the model and the solution provider can then build on the basic model very well.

Dr. Klaus Iffländer (11:41)
Yes, I think documents like this are a good choice because you often don't need much background knowledge. So if you imagine a database, for example, that consists of tables with rows and columns, you always have to know exactly what this table represents. And in such documents, such continuous text as contract documents or NDAs.

It's very explicit there. There's a heading that says, here's this and this in the next paragraph. Then there are the sentences and the language model is able to process the information without further ado. It doesn't need a lot of pre-training, it can process it directly. And because you mentioned NDAs, for example, i.e. non-disclosure agreements, you could make use cases like, imagine you have a standard like this, Company NDA, which is your reference.

So perhaps it was drawn up with the company's own lawyer and that is always the reference, so to speak. However, a supplier may have a different reference NDA and simply signs it. Then you could compare it and see, whether it is stricter or covers exactly the same thing as your own NDA or perhaps more lax and where you might need to make improvements.

So, language models can definitely extract such information. They understand what an NDA is, they understand the specific paragraphs that are dealt with in it and are also able to compare them with each other. So it's very suitable for things like this.

Fabian Heinrich (13:19)
In other words, speaking for myself now or for the buyers, wherever standardised formats or documents are involved, I can set a standard, such as a general terms and conditions or an NDA, I don't actually need to bring any data from myself, except for the inverted commas ‘sample document’ and can then get started tomorrow, because the whole topic is already relatively well-trained.

Dr. Klaus Iffländer (13:47)
Exactly, because it's all about language, so of course these documents are formulated a bit legally, but they are still written in natural language. So it's not code or a database table. And that's why language models are also able to process this out of the box, so to speak.

Fabian Heinrich (14:06)
I mean, another big issue, as I know best myself, having founded Scoutbee, is always this search for suppliers. Many of our customers also ask us, if you enter GPT in the chat, then the results are always a bit mediocre, now for such an AI co-pilot or now such a model that you simply map the whole thing in a solution like Mercanis. How would it behave there?

Dr. Klaus Iffländer (14:34)
Yes, it's a bit more complicated than that. Of course, you can now task a language model like this with simply finding new suppliers. And it can certainly also use search engines, just like we can, and interpret the results. I don't think that's the big hurdle, but the difficult part is actually making sense of it and integrating it into the corporate context. So if we imagine something like suppliers for a standard product, for example, if I have a packaging, i.e. cardboard packaging, then it would be interesting to find suppliers that are close by so that I don't have to travel such long distances to keep the logistics efficient.

And a typical case would be that the language model is then used, for example or somehow make it clear where the company's own location is or where the material is to be delivered. And that goes in the direction of retrieval augmented generation, because in the simplest case I would ask the language model:

‘Use the search engine of my choice and find new suppliers.’ And the second step would be to do even more research to find out even more information about these companies. But in order to be able to assess these delivery routes, for example, I have to somehow tell the model where my own company is. And that would be one of those... This is the kind of information that I would put in the prompt, i.e. in this enquiry.

Fabian Heinrich (16:15)
And if we now move away from logistics, as a category buyer I always want suppliers that are as good as mine, or have the same characteristics or are perhaps even better than my current supplier, better in terms of quality, perhaps better in terms of price. Can I then also work with this data so that I can somehow process all the characteristics of my current supplier data base in an anonymised way and thus get better requests or how does that work?

Dr. Klaus Iffländer (16:50)
Yes, in principle yes. Of course, a lot depends on whether you have this data. And I assume that this data will certainly be collected for your own existing suppliers, it will be available. Because historical delivery reliability or something like that is the first thing you track afterwards. But of course you don't have a history available for new suppliers.

So the best you can do is work together with the supplier, to find out such things. But this could definitely be analysed for existing suppliers. You could ask the language model: ‘Look at my current suppliers and analyse the delivery reliability’ or costs or any other performance metrics. And first summarise them so that you have an overview and then look for new suppliers based on this.

So that in the next step you can work with these potential suppliers to achieve better performance. So that's how I would approach it. You also have to look at how the process then continues...

Fabian Heinrich (18:00)
This could also be a use case in the area of risk management, if I have somehow set up my Siblaidchen, that somehow my semiconductor suppliers are all located in Taiwan and I now say that the political risk with Taiwan is too high, that I then say to the model: ‘Hey, these are my suppliers today that I have commissioned in Taiwan, are there similar suppliers in the EU or in South America?’. That would then work.

Dr. Klaus Iffländer (18:29)
Exactly, so language models can definitely carry out such research because it's not incredibly difficult for most suppliers to find out where the location is. And then to put this information back into context with the political risks of certain countries and locations. So language models can definitely establish such correlations.

Fabian Heinrich (18:50)
That would be a major benefit of Vertical AI, to say that these connections can now be established accordingly in the context of the supplier base, in the context of the topic of procurement.

Dr. Klaus Iffländer (19:04)
Exactly, you could achieve this with various training methods. Or you could use this Retrieval Augmented Generation, for example, which is now on everyone's lips because it's such a... use-genuine training device

Fabian Heinrich (19:16)
Before we go any further into this, I mean, there are perhaps cases at the other end of the spectrum that might not work at all, or perhaps they will work with the Augmented Generation retriever. So I always think of supplier development. It's a huge topic, if I work better with my suppliers, then maybe I'll get better quality, why can I develop them somehow? There is also the whole topic of action management in the area of supplier development.

We also talk about supplier lifecycle management. For me, this is of course very strategic or, I would say, very human-based. So these are all human relationships. In these areas, generative AI and these large language models could also help somehow, or is this a topic where you say we don't even need to start, there is somehow nothing pre-trained, the data requirements are virtually infinite.

And is it better to rely on human relationships?

Dr. Klaus Iffländer (20:23)
Well, generally speaking, in a professional company you shouldn't rely much on human factors to begin with. But I think LLMs can only help to a very limited extent. So I think the recommendations would be very generic. Well, you would, for example, ask the language model the question: ‘How can I improve performance?’ in order to advance such a development.

If you ask the question, the answers will be just as generic. The LLM would probably try to work with you to find out where the performance problems lie and how they can be improved. But without knowing the supplier and your specific relationship with them, the language model cannot provide you with any concrete suggestions. Of course, it can try to suggest shortening logistics routes, reducing delivery times or dealing with the price again to bring the costs down. But these are very generic measures, which would also be your and my first idea.

Fabian Heinrich (21:30)
Mmh.

No, well, I mean, to summarise the last 10-15 minutes again, the use cases are always in great demand, then I would say that we have now somehow seen these three stages. On the one hand, we have these topics where basic models are almost completely trained, where I need little or no data at all, that whenever it comes to standardised templates, when it comes to documents, invoices, NDAs, AGB, I simply have to store my standard or tell the model what my standard is and then of course I can get the analyses and deviations and can actually get started tomorrow.

The second topic would be this partial pre-training with mean and data requirements. I can compensate for the medium and data requirements if I work together with vertical AI, i.e. with solution providers who are anchored in the subject area and then develop these basic models for me, had already pre-trained accordingly. So there was the example of supplier scouting, supplier search for new suppliers and the third point was then the topic of where it might not work after all, where you can then perhaps use the time freed up from the first two newscales to then strategically play on these topics.

That could also be a solution, that you I can use the time saved strategically for issues such as the betrayed development. Yes, Klaus, you've mentioned the magic word RAG or LAG several times now and you wanted to explain it, because that seems to be the big issue, how I get to this vertical AI and how this AI then ultimately leads to the development of a new AI.

The only thing that spits out the right things for me in my context, in my specialist area of purchasing, is what's in the co-pilot's Mercanis. So maybe you can give a few more explanations and you won't be able to explain what the magic word RAG is all about.

Dr. Klaus Iffländer (23:52)
Exactly, the name almost explains it. Retrieval means picking something up or simply getting something, usually from a database. And what happens with retrieval augmented generation is simply that the answer or the understanding and answer that LLM provides is enriched with its own data, i.e. with what comes out of the previous retrieval.

In practice, you have to imagine that the LLM does not answer generically, i.e. it does not simply give an answer based on an enquiry, but that the enquiry or the entire thought process, so to speak, when creating the answer, is already enriched with the company's own data. So imagine you have a customer service agent and the customer wants to know, when will my order arrive? Then you can extract the customer number from this conversation and find the order number and then you can ask the LLM more specific questions.

When will the delivery for this order number arrive? It is not simply the enquiry, when will my order arrive, as it has now been formulated, but at the same time information is retrieved from the database in the background and then the delivery date for this specific order is queried, for example. And only then does the the second step is the generation of the response, which is already enriched with this information.

So when the response is created, the model already knows who the customer is, which order it is and when it will be delivered and can then say that this delivery will be made to such and such a fourth party. So that's how retrieval augmented generation works.

This is, of course, a relatively simple example, but in many of the use cases we've already discussed, it works in much the same way. You can retrieve data about suppliers, such as their performance, and use that information to generate responses—whether by summarising it, rephrasing it, or presenting it in a way that helps you prepare more effectively for supplier negotiations in annual reviews. These are just some of the things that can be achieved with this approach.

Fabian Heinrich (26:25)
One question I still have—when you read up on this topic, you often come across vector databases. Is that the next stage of development? How does it all fit together? After all, vector databases have been around for decades. Could you perhaps close the loop on that?

Dr. Klaus Iffländer (26:45)
JYes, you could look at it that way. The example I just gave, involving a customer service agent, deals with just one piece of information—perhaps a single order number or a delivery date. But often, you need to process much larger datasets to generate meaningful responses. For example, if you wanted to analyse the performance of all your suppliers in a specific category over the past quarter.

Incorporating this level of data into a prompt—i.e. the query sent to the LLM—becomes problematic because LLMs have a limited context window. They can only process a certain amount of information before older data is essentially "forgotten" and removed from the conversation. Once that happens, the LLM can no longer refer back to that information.

If your dataset exceeds the model’s context window, vector databases offer a highly effective technical solution. They allow you to store vast amounts of data, particularly text-based data, which is then transformed into numerical representations. There are various methods for doing this, but ultimately, large text datasets are converted into a numerical format that language models can efficiently access.

This means an LLM can search within the vector database for specific text passages. Imagine you uploaded all your supplier contracts into a vector database. Unlike traditional databases, vector databases are particularly efficient at retrieving specific text segments. This enables you to use them in two key ways: 1 - Teaching the LLM about specific contexts and making certain information accessible. 2- Querying the LLM for relevant data.

For example, you could ask, "When does my contract with Supplier XY expire? When do I need to terminate it, and how can I extend it?" The LLM would then retrieve the relevant information from the vector database and even cite the exact contract clause. This ability to efficiently locate and reference textual information makes vector databases highly relevant to LLMs. They effectively overcome the context window limitation and are particularly well suited for processing language-based documents.

Fabian Heinrich (29:36)
That’s fascinating, Klaus. We’ve essentially gone on a full journey—from the basic foundation models (which, as you joked, could pass the Bavarian A-levels) to real-world procurement applications, including the concept of Vertical AI and how it applies to procurement expertise.

You've also helped clarify the buzzword RAG (Retrieval Augmented Generation) and how it can be enhanced with vector databases. As always, it's been a pleasure speaking with you—this conversation has been incredibly insightful.

You’ve also teased the next episode a bit—you mentioned agents several times. Next time, we’ll be talking about AI agents—not the spy kind, but actual AI-powered agents. We’re looking forward to it and hope you’ll join us again next week!