I agree that you want to have the flexibility for what you use to build your LLM application. For example, if you want direct API level access to building and searching through your RAG layer, calling your LLM models, and other business logic, you should. There's a lot of opportunities to fine-tune each of these layers. However, you are still left with having thousands of combinations that you can experiment with, ex. which prompt template x rag context x LLM model gives me the best results. And you need a framework that helps you manage these thousands of experiments. That is where I'm trying to position this framework, which is it helps you scale the need for being able to try thousands of different configuration of your LLM application, so you can improve your LLM application performance, while providing as much flexibility for what components you use to actually build your LLM application.
With our framework, if you want flexibility for
> You know exactly what goes into the prompt, how it’s parsed, what params are used or when they are changed
We provide this for you. We just give you a process that lets you try and evaluate different configurations of your LLM application layer at scale.
With our framework, if you want flexibility for
> You know exactly what goes into the prompt, how it’s parsed, what params are used or when they are changed
We provide this for you. We just give you a process that lets you try and evaluate different configurations of your LLM application layer at scale.