AI Engineer World's Fair 2024
What It Actually Takes to Deploy GenAI Applications to Enterprises
Read the talk
Deploying Enterprise GenAI Means Building the Feedback Loop
Echo AI’s customer-conversation pipeline shows how broad analysis becomes useful only when teams can inspect outputs, grade them against customer needs, and turn corrections into better models.
From a talk by Arjun Bansal and Trey Doig
Before you start: Familiarity with LLM prompts, fine-tuning, and basic evaluation metrics will help with the research and implementation sections.
Customer understanding breaks down at scale
How much of what customers tell a company does anyone actually examine? Support, sales, and customer success conversations contain more than the routine complaints that reach a dashboard. Trey Doig introduces Echo AI through an iceberg: familiar issues sit above the waterline, while a much larger body of business information remains underneath.
The barrier is the work required to read those conversations. A small company can rely on its support staff and sales team to notice patterns and relay them to decision-makers. As the company succeeds and conversation volume grows, that same process becomes impractical. The organization gains customers while losing touch with what they are saying every day.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From sampling to discovery
The usual response progresses from manual review to increasingly specialized software. Doig uses a sample of roughly 5% of conversations as an illustration of manual review, not a measured industry average. Reviewers check compliance, agent handling, and recurring themes; engineers then pull records across systems to investigate questions retrospectively. Once an issue is understood, the company builds software to track it.
| Approach | What it examines | Main limitation |
|---|---|---|
| Manual review | A small conversation sample | Leaves most interactions unseen |
| Retrospective scripts | Data gathered for an investigation | Starts after a question emerges |
| Purpose-built tracking | Known signals across conversations | Requires knowing what to seek |
| Generative analysis | Conversations for known and emerging themes | Still requires trustworthy interpretation |
By the time the first three approaches identify a problem, the fire may already be burning. Doig presents generative AI as a way to detect the smoke: he claims it enables 100% conversation coverage and can surface issues the company did not already know to search for. Coverage describes how much gets examined; it does not establish whether the analysis is correct.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
One message can expose several problems
Consider the customer message about a router that arrived broken. The immediate extraction is contact intent: why the customer is asking for help. The same message also identifies the product and the condition on delivery, suggesting a possible supply-chain problem. Sentiment adds another dimension, covering both the customer and the representative handling the interaction. These are separate views of the same evidence, rather than a single label attached to the conversation.
Doig then describes Wine Enthusiast, whose high-end wine refrigerators serve customers including retail locations. A new refrigerator model created a manufacturing problem that Echo AI surfaced through customer conversations. Doig reports that the platform identified the defect in real time, before it could continue for weeks. For a business that depends on expensive purchases and repeat customers, the useful output is an operational finding that can prompt action, not merely a negative-sentiment count.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The pipeline starts before the prompt
Echo AI’s processing begins with ordinary integration work:
- Connect to contact systems, ticket systems, and other conversation sources.
- Gather, normalize, clean, and compress the records for LLM prompts.
- Run the conversations through dozens of configurable analysis pipelines.
- Let customers specify what matters, initially writing prompts with Echo AI and eventually maintaining those prompts themselves.
The customer’s requirements therefore shape the analysis throughout its life, rather than appearing only in an initial configuration form.
That collaboration leads directly to the enterprise buyer’s question: can these insights be trusted as much as the judgments of business analysts, customer-experience leaders, or sales executives? Doig says Echo AI aims to show a new customer useful insights within seven days. He describes 95% accuracy as an aspiration supported by sampling and ongoing assessment, without defining a benchmark or scoring protocol. The commercial objective is durable trust that leads to renewals.
Log10 supports the work of establishing that trust. Engineers need to understand what their application generated, but solutions and implementation engineers also need to handle corrections while working directly with customers. A customer saying that an answer is wrong must be able to initiate a concrete inspection-and-feedback process.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
What an accuracy problem looks like in production
Arjun Bansal introduces Log10 as infrastructure for improving application accuracy, with a longer-term goal of systems that improve their own prompts and models. He explicitly describes that goal as something the field has not yet achieved. The immediate problem is more concrete: deploying a prompt without a dependable way to measure its behavior exposes the business to failures that extend beyond an incorrect answer.
The Air Canada chatbot incident illustrates the stakes. A customer received inaccurate advice about retroactive bereavement fares. As the legal account of the decision clarifies, the February 2024 Civil Resolution Tribunal outcome was an award for negligent misrepresentation—not a general ruling that a company must enforce any policy its chatbot invents. Bansal also recounts a dealership chatbot being persuaded to offer a Chevy Tahoe for a dollar; the example establishes an inappropriate offer, not a completed sale.
Other failures are less spectacular but still damaging. A support chatbot suggested playing a game while a frustrated customer waited, missing the emotional context. A retrieval-augmented semantic search system can miss common-sense implications that are not explicit in its retrieved documents. Human review is the deployment gold standard in Bansal’s account, but its time and expense recreate the scaling problem that automated analysis was meant to solve.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The evaluator needs evaluation too
Replacing reviewers with an LLM judge introduces another source of error. Bansal identifies several recurring biases:
- Self-preference: a model favors its own output.
- Position: the first option receives an advantage because it appears first.
- Verbosity: a longer answer looks better regardless of its quality.
- Token diversity: varied wording becomes a proxy for merit.
These biases can make the evaluator respond to presentation rather than the rubric it is supposed to apply.
Log10’s Auto Feedback aims to combine human-review accuracy with the speed and cost of model-based review. In Bansal’s presented comparison, an ordinary judge can concentrate its predictions around one score despite variation in human judgments. Auto Feedback produces predictions that correlate more closely with the actual feedback. The desired property is not simply that the system returns a score, but that its scores track distinctions reviewers care about.
Once that signal is useful, it supports three different workflows: continuous quality monitoring, triage that directs limited human attention to valuable cases, and dataset curation for prompt improvement or fine-tuning. Evaluation becomes an input to improvement, rather than a report generated after deployment.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Build the evaluator around human judgments
The training record contains four things: the application input, its output, the grading rubric, and a human’s feedback. Log10 explores three ways to use those records:
| Method | How human feedback enters the evaluator |
|---|---|
| Few-shot learning | Labeled examples appear in context |
| Fine-tuning | Labeled examples train the evaluator |
| Synthetic bootstrapping, then fine-tuning | Seed labels support synthetic training data |
The third approach tries to reduce the amount of human annotation needed before the evaluator becomes useful.
The companion study, Hybrid Evaluation: Scaling human feedback with custom evaluation models, examines TL;DR summary grading. Its experiments move from aggregate to annotator-specific models, from GPT-3.5 to GPT-4, from few-shot learning to fine-tuning, and then add synthetic bootstrapping. Bansal calls the combined result an improvement in evaluation accuracy. More precisely, the companion study reports a 45% reduction in grading RMSE, from 2.12 to 1.16, on its TL;DR summary-rating experiment. This is reduced error in predicting human scores, not a 45-percentage-point gain in classification accuracy.
The companion study’s bootstrapping experiment expands 50 human-labeled seed examples into 600 synthetic examples and comes within 0.045 absolute-error points of the result using 1,000 human-labeled examples. The practical attraction is a smaller initial annotation requirement for this summary-grading task. Bansal then reports that follow-up work using Mistral 7B and Llama 70B Chat matched GPT-4 and GPT-3.5 fine-tuned evaluation accuracy. The presentation does not specify the exact open-model versions or matching conditions.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Put feedback beside logging and debugging
Log10 packages these evaluators into its Auto Feedback module. The surrounding platform provides logging, debugging, and evaluation, alongside prompt optimization and fine-tune management. Bansal describes a one-line integration between the application and its LLM SDK, with support for OpenAI, Anthropic, Gemini, several open-source SDKs, and application frameworks. That placement connects the quality signal to the requests and responses engineers already need to inspect.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A broken TV and a network of downstream analyses
Back in Echo AI, Doig distinguishes codified analysis requirements from generative discovery. After transcription and cleaning, customers can ask a broad question such as why customers are canceling; the system generates an ontology of cancellation reasons rather than requiring every reason to be specified beforehand.
The demo account uses generated conversations. Doig opens one about a customer’s broken TV and examines its summary. Summarization looks like a simple feature, but Echo AI uses summaries in downstream analysis, so mistakes can affect more than the text displayed to a reviewer. The resulting prompt volume and throughput requirements motivate substantial self-hosting and continual training for different customer domains. Other insights beside the summary come from separate models and pipelines.
Each insight corresponds to a customer question or requirement. That variation makes quality difficult to manage with one generic notion of a good answer. Engineers and solutions engineers use Log10 to inspect the generated prompts behind the visible results, connecting a customer-facing problem to the request that produced it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make a correction easy to capture
Echo AI defines specific criteria for summary quality and uses Auto Feedback to grade each summary against them. In the example, the evaluator deducts one point and provides an explanation. Doig shows how a reviewer can change the point value and accept a human override. The workflow gives the reviewer a starting judgment to inspect rather than an empty scoring form.
At the data-record level, the same operation can preserve the automated judgment while adding the reviewer’s accepted score. This Python function illustrates that separation; calling it constructs a revised record without changing the input record:
python
from copy import deepcopy
from typing import Any
def accept_human_override(
record: dict[str, Any],
score: float,
explanation: str,
) -> dict[str, Any]:
revised = deepcopy(record)
revised["human_feedback"] = {
"score": score,
"explanation": explanation,
"status": "accepted",
}
return revised
The application input, generated summary, rubric, and automated feedback remain available for inspection. The added human feedback records the correction rather than silently replacing the model’s judgment.
Doig also points to a Mistral example as he explains the goal: collect high-fidelity human feedback with little effort from solutions engineers. Automated feedback continues in the background, while human corrections accumulate through normal review work. He says this has changed Echo AI’s process for building fine-tuning datasets.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Inspect a failed summary, not just its score
The next conversation contains an obvious failure: instead of summarizing the interaction, the output reiterates instructions and resembles a system prompt. Doig opens the underlying record and observes that the output has been graded accordingly. The exact cause is not explained aloud, but the demonstration connects the visible failure, its underlying request, and its quality assessment in one investigation.
Doig reports that this process lets Echo AI track hallucinations and observe model drift with data, where it previously depended heavily on people sampling outputs. The operational goal remains customer trust: detect declining quality, understand individual failures, and retain corrections that can inform subsequent improvements.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From feedback to a reported customer gain
Bansal reports a 20 F1-point improvement for one Echo AI use case using Auto Feedback; the accompanying slide links the result to 20 feedback examples and Log10’s Prompt Optimizer. Its chart compares Baseline, dspy, Fine Tune, and Log10. The presentation defers the detailed result to a case study without specifying the task, baseline score, dataset, or F1 averaging convention.
Because customer data cannot be shared in the presentation, Log10 also offers a public summarization and summary-grading application, with a live website and resources for adapting the example to other tasks. The example provides a way to explore the feedback workflow without exposing the conversations used in the customer deployment.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Carry the workflow into the application
The UI is not the only entry point. Bansal says its functionality is available programmatically through Python and other-language SDKs, with flexible feedback types. The Log10 Python client and Log10 Cookbook provide the corresponding integration and example resources. His closing implementation sequence is:
- Create the evaluation task.
- Create feedback for that task.
- Run Auto Feedback locally with a simpler model.
- Fetch feedback from a more complex model hosted in Log10’s cloud.
This local/cloud workflow describes the platform at the time of the recording; current repository documentation does not establish identical hosted-service availability. The limited-time free access to advanced models mentioned at the close was a historical offer. The implementation path ends where the demo began: application outputs become inspectable records, records receive feedback, and that feedback becomes material for improving prompts and models.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Log10's experiments with annotator-specific evaluators, fine-tuning, and synthetic bootstrapping for summary grading.
Python integration examples for LLM logging, feedback collection, and automated evaluation.
Examples and guides for using Log10 in application workflows.
Further reading
Original summarization research repository with human comparisons and summary-quality ratings; the code is archived.
Legal analysis of the tribunal's decision concerning inaccurate chatbot advice about bereavement fares.
Read the complete timestamped transcript
- 0:00
[on-hold music] So Echo AI. So Echo AI is a, uh, uh, bringing this, like, fundamental new technology into the world of customer support and, and customer-facing teams.
- 0:24
Uh, you've probably all seen this metaphor once before. You know just the tip of the iceberg. There's so much that lies underneath, and this is especially true with, with companies that are dealing with exceptionally high volumes of customer interactions.
- 0:36
So whether that be customer support or sales or s- customer success teams, any kind of conversation that you're having with your customers is an opportunity to learn more about your business and what your customers need from it.
- 0:47
So, you know, at the surface, you probably get the signals around the things that are going wrong or the things that are just routine to, to kinda handle. And, and most enterprises have a good idea of the, the approximate kinda set of categories that they, they generally have to deal with on a normal basis.
- 1:04
But there's just so much that lies underneath and it's, it's been virtually unlocked by just pure manpower that's required to look at these conversations. Um, and there's this sort of cycle that happens with these types of companies and, you know, everyone's kinda heard the startup mantra of just be obsessed about your customer, right?
- 1:25
Just do everything you can to listen to the customer, understand them to the, the best possible degree you, um, you're capable of at, at, at your scale. But as you grow and you get bigger and you get more customers, a lot of that becomes this, um, this cycle that, uh, where you just, like, you kinda lose touch
- 1:43
with, with what they're saying, what they're telling you every day. Um, and that only really comes with being successful, right? Uh,
- 1:50
at like a, you know, a, a meaningful or, like, a manageable size of customers, you can typically use, uh, either, you know, staff or your sales team, your customer support team to sort of derive those insights and better, um, you know, navigate your, your company towards, uh, greater revenue growth.
- 2:05
But when you get too big to the point where that's, like, virtually impossible just due to the scale of conversations that you have to deal with, uh, there, there becomes this issue where you're just-- there's so much that is just happening right underneath you without your, your, your knowing.
- 2:18
So the way we think about it, um, and this-- the, the first three columns here are, are effectively what every enterprise, every, every company of scale is trying to do, where they do manual reviews.
- 2:31
So they do these, like, small sample sizes. They try to collect, I don't know, five percent of the conversations. They run through an evaluation of it to check for, you know, maybe certain compliance things, like how well did the agent handle it or perhaps are there any sort of common subjects or, or, um, themes in these conversations.
- 2:49
At the end of the day, you're just sampling and, and it's-- leaves everyone unhappy at the end of the day. They understand that it's not a very, uh, kinda accurate process.
- 2:57
So then you, like, involve engineers and you start building these scripts. You start doing retroactive analysis. You pull this data from all the different systems that your, your customers are interacting with you on and you're, you know, doing these, like, kinda long-form analysis.
- 3:10
And y- you're, you're ultimately, um, that, that, that can typically, like, derive insights that you know that you wanna, uh, track in a, in a forward-moving time. So then you, like, move into this situation where you start building software to, to look for very specific things in every single conversation and everything's just so retroactive.
- 3:29
Like, everything is after the fact. It's already after fires have formed. You, you have no sense of where the smoke is and that's where generative AI-- sorry, generative AI can come in and really transform this process because generative AI unlocks this, this amazing capability of one hundred percent coverage.
- 3:47
So now rather than doing that sampling or just, like, looking for the things that you know to look for, you can use generative AI to surface all the things that you didn't know to look for and look at everything all at once.
- 3:58
So here, here's a great example. This is just a small interaction between some random, uh, you know, agent that's handling a, a chat from one of their customers. And in this one message that comes from the customer, you're able to find things like why is this customer talking to me?
- 4:12
That'd be your intent. Uh, you know, what are the aspects of our business that are, that are really kinda at the root of this? So, you know, routers and it was broken on delivery, so maybe you have a supply chain issue.
- 4:22
You've got the basics, things like sentiment, understanding, like, not only the sentiment of your customers, but also the sentiment of your, your, your representatives, which is, you know, maybe more important.
- 4:31
Um, and then at the end of the day,
- 4:34
with each of these messages, you can effectively extract so much more and so much depth that's ever been available to, to pull from just a single conversation and that's what our, our, our, our platform seeks to provide.
- 4:47
Here's a great example from one of our customers. Uh, uh, we don't have to read this, but, uh, wine enthusiasts, they, they, they shipped a new unit. It was a brand-new, uh, uh, version of their, their...
- 4:56
They, they, they, they sell, like, really high-end wine refrigerators, so, um, their customers are, are spending a lot of money. It's a, it's a very special relationship that they have with their customers.
- 5:05
They want those customers to buy more fridges. A lot of these customers are retail locations. So, uh, one of the, the, the insights we were able to surface for them was a, you know, a, a, a defect in their manufacturing process.
- 5:18
Uh, something that, uh, you know, could have gone on for weeks and weeks and weeks and become a much bigger problem versus what our, our, our platform was able to surface in real time.
- 5:29
So yeah. How, how does this all work? Uh, it all really starts with gathering all of those conversations. This is kinda like non-AI boring stuff. We're, like, connecting to a bunch of different, like, contact systems and ticket systems and so forth.
- 5:41
Uh, we pull all that in and we normalize it. We, we make it super clean, uh, ready to go and compressed to, to pass it into LLM prompts. And then we have dozens of these pipelines that are assessing these conversations in, in, uh, you know, a variety of different ways, all of which are configurable by the user.
- 5:56
So the user, the customer can come in, they can tell us, like, what they care about, what they, what they're looking for, and they'll actually work with us to write these prompts and eventually they write the prompts themselves and manage it over time.
- 6:08
And why this is like ultimately most important is when you are dealing at the accuracy-- uh, sorry, when you're dealing at the like enterprise scale, they're ultimately most concerned around accuracy.
- 6:20
Uh, there's a, there's a, I think, a huge, uh, hesitation right now in the market around accuracy. I can deploy generative AI to try to understand these conversations, but do I really trust the insights?
- 6:31
Is it gonna be better than what my, my business analysts are doing, or my, my CX leaders, my, my, my VP of sales? Does this system, does this technology, is it really capable of giving me insights that I ultimately trust?
- 6:43
So for us, it's important that we establish trust from the very beginning. So when we bring on a customer, within seven days, we try to introduce them to like, "Okay, here are the insights."
- 6:52
And then from there, we work towards a place where we're, you know, sort of a, a-- We like to say ninety-five percent accurate, but, you know, it's a lot of sampling, a lot of figuring out.
- 7:02
But virtually, we wanna create that trust with the customer 'cause that's ultimately what's gonna get them to keep renewing and, and be a customer for a longer period of time.
- 7:12
So Log10 plays a huge part in our ability to do this. So not only have they created a, a huge amount of, of features and capabilities that allow for our engineering team to build faster and to understand, you know, the quality of the code that they're writing, but maybe more importantly, our solutions engineers, our implementation engineers, who
- 7:32
are actually working hand-in-hand with the customer, who is telling us that, like, "This isn't s- this isn't exactly right." Um, and Log10 is, is, is a kind of a go-to tool for p- managing that process, so...
- 7:45
Jump in the back there. Thanks, Trey. Um, so really excited to share with you what we've built at Log10. Uh, so we're basically an infra layer to improve LLM accuracy for your AI applications.
- 7:58
We started with this vision of building self-improving systems, so having LLM applications that can improve prompts and models themselves to ultimately drive accuracy improvements. Obviously, we're not there as a field yet, but that's the vision we're driving towards, and I'm excited to share some of the work we've done along that path.
- 8:21
So today, measuring and improving LLM accuracy is hard. Uh, you've probably had this experience if you've tried to deploy a prompt and kind of try to YOLO accuracy in prod.
- 8:34
Um, and you've probably heard in the news of these, um, instances where there was the Air Canada chatbot, which hallucinated a refund policy, and a judge in Canada f- um, forced them to honor the policy that was made up, so obviously causing some financial problems as well as brand image problems.
- 8:55
Uh, there was the case of the Chevy Tahoe dealership chatbot, which was convinced to sell a truck for a dollar.
- 9:01
Uh, we've run into similar issues where we were having some, uh, issues with a product, and a chatbot told us to, uh, play a game while we wait, uh, kind of missing our emotional state in that moment.
- 9:14
And, uh, there's also issues with semantic search engines where, uh, because they're doing this kind of RAG-based lookup, uh, they sometimes just miss out on common sense, even though it may not be explicitly present in the source documents that they're pulling up.
- 9:28
And so, uh, people have tried to use human review as an alternative to, um, a-as a way to sort of look at the output of the LLMs, and that's ultimately become the gold standard in terms of getting LLM apps into deployment, but it's time-consuming and expensive.
- 9:47
And as an alternative, uh, we've tried to use, uh, AI-based review, so, um, LLMs-as-a-judge, for example. But obviously, this also has a lot of issues with accuracy. Uh, people have found that models tend to prefer their own output.
- 10:03
Uh, they exhibit positional bias, so just the ordering of, um, if you present, uh, an option first, it might just prefer that over the second one, even if the second one's better.
- 10:14
Uh, they have verbosity bias, a bias towards diversity of tokens, and so forth, so, uh, kind of failing in these trivial ways. And so with Log10, we did a bunch of algorithms research work to try to address this issue and ask this question of, could we get the accuracy of human review with the speed and cost advantages
- 10:34
of model-based review? And that's exactly what we've solved for with our auto feedback system. So I think even in the previous talk, you saw a graph kinda like this, where when you use LLMs-as-a-judge, uh, the predicted feedback can often be, uh, just set at one score, regardless of what the ground truth is.
- 10:56
But with our auto feedback system, you get that much nicer, much better correlation between the, uh, predicted feedback and the actual feedback.
- 11:06
And just to kinda motivate what do you do once you have this measure of accuracy, so some of the downstream ways in which you can use the auto feedback is for things like, uh, monitoring, so you get like an ongoing quality signal on how well your LLM application's doing.
- 11:23
It can be used for triaging, so you make the most optimal use of the limited human resources you might have. And it can also be used for curating datasets, high-quality datasets, for things like automated prompt improvement and fine-tuning, which can ultimately improve the accuracy of your LLM application.
- 11:45
Uh, so next I'll say a little bit more about what the system is. Um, so for some of the, uh, experiments we did as part of the research, we came up with these three different ways of building auto feedback models.
- 11:58
Uh, so on the left, we have the ground truth datasets, which consist of the input and output, some kinda grading rubric, which you might give to a human for review, and, uh, their feedback.
- 12:09
And we had three variations where we could build these models with few-shot learning or with some kind of fine-tuning, um, and then finally, uh, creating these models with some bootstrap synthetic data and then fine-tuning the auto feedback model.
- 12:25
And I won't have time to go into all the details. We published, uh, some of this work in a blog post, which is available on our Substack, and there's a QR code there.
- 12:35
But, uh, in summary, uh, for a summary grading task where we use the TLDR dataset, we were able to get a forty-five percent improvement in evaluation accuracy by going from aggregate to, uh, annotator-specific models, uh, going from GPT-3.5 to GPT-4 as the base model, uh, going from few-shot learning to fine-tune models and, uh, with the use of
- 12:59
the bootstrap synthetic data. Uh, our approach was also very sample efficient, so by using the bootstrapping approach, we were able to achieve the accuracy of almost as if we had one thousand, uh, ground truth labeled examples with just using fifty ground truth examples.
- 13:19
So much faster to get started and not needing as much data to get to that high level of accuracy with the evaluation model.
- 13:29
Uh, we also extended this in a follow-up blog post to open source models. So, uh, we were able to match the accuracy of GPT-4 and GPT-3.5 fine-tuned evaluation using Mistral 7B and Llama 70B Chat, and that's in a follow-up blog post, which is accessible on this link.
- 13:52
And so once we were able to show that we're able to get high confidence in the eval models that we were building in this way, uh, we set it up for deployment within this auto feedback module on our platform.
- 14:04
And, uh, just kind of zooming out, we have, as part of the Log10 platform, a fundamental LLM Ops offering, which includes things like logging, debugging, and evaluation, as well as auto-tuning features to do prompt optimizations and manage your fine-tunes.
- 14:20
And we have a seamless one-line integration which sits in between your LLM application, uh, and your, um, LLM SDK. Uh, we have integrations into many of the common LLM SDKs, including OpenAI, Anthropic, uh, Gemini, and a few of the open source ones, and we integrate with frameworks as well.
- 14:40
So next, I'll hand it back to Trey for a demo.
- 14:51
All righty. Let me, uh, just make this slightly bigger.
- 14:58
Well, okay. So, uh, here's, uh, uh, Echo AI. So Echo AI is, uh, like I said earlier, we, we, we connect into all of the different, um, channels that your customer conversations are coming in.
- 15:08
We transcribe them, we clean them, and then we allow you to, uh, basically, like, codify all the different things that you're looking to, uh, kinda analyze these conversation against, uh, as well as offering a product that is purely generative and is, uh, kinda tasked with surfacing those insights in ways that you, um, you, you basically know the
- 15:24
question, like, "Why are my customers canceling?" And then we, uh, generate, uh, like a, you know, uh, an ontology of different reasons for why that's happening. So let me give you an example of how, uh, we are, um, making use of this feedback tool.
- 15:36
So if I, like, jump into one of these... This is a demo account, so, uh, all these conversations are, are generated, so they're kinda silly. But nonetheless, uh, you can see here we've got this, uh, example, uh, phone conversation that comes from a customer.
- 15:48
Their, their TV was broken. Uh, one of the most, you know, simple, uh, I think on the surface, uh, features would be summarization of the transcript. Uh, we actually rely on summarization for, uh, a variety of different downstream, uh, sort of analysis, so it's really important to us to, uh, kinda ensure high levels of accuracy.
- 16:06
Not only that, uh, this is also, um, uh, you know... Because of that, uh, kinda technical reason, we have, like, an, an immense number of prompts and throughput that has to get through LLMs, so we do quite a bit of self-hosting and are constantly training, uh, new models to better handle different, uh, domains of, of our customer
- 16:24
base. So here's an example. Like, you can see that this, this summary came in. It's pretty decent. Uh, all of these other sort of insights that you see here are all being generated by, um, various different models and pipelines, all of which are being created from LLMs.
- 16:39
So, uh, each of these things are, are questions and specific, um, sort of, uh, requirements that the customer is providing us. So it's really hard to stay on top of accuracy and quality as a result.
- 16:51
Basically, every customer is different. Um, so what we've done is we've leveraged Log10 not only for the ability to, um, very-- Sorry. Very quickly, uh, uh, allow our, our engineers and solution engineers to go in and actually understand, like, what was the, the generated prompt for all of this pretty standard stuff, as many of you know.
- 17:10
But m- which maybe, um, kind of more interesting is the ability to automatically generate feedback for these things. So we've, we've created a criteria that analyzes each of the, the summaries that we create against very specific, uh, user-defined, like, uh, were defined by us, uh, criteria for how q- how good of a quality, um, the summarization was.
- 17:29
So in this case, uh, the-- It actually looked pretty good, and there's, there's one, uh, point deducted. You can actually read down here why it deducted that point. But let's say that, like, I wanna provide a kinda human override here.
- 17:42
I could just come in here and change the point value and, uh, accept it. Uh, and why that's useful for us is, like I said, uh, it's, it's critical that we continue, um, a process that allows our solution engineers to...
- 17:55
This is an example, one against Mistral, um, to kinda give us, like, really high fidelity, uh, human-provided feedback in a way that, uh, virtually is, uh, effortless for them to do so, because what we're ultimately trying to do is collect as much of that as possible.
- 18:09
Uh, and Log10 has been, uh, I think, a great tool in not only, uh, making that possible for the solution engineers and our engineers to do, but also automatically doing so behind the scenes.
- 18:18
It's really ch- changed our, um, our processes towards our fine-tuning datasets.
- 18:25
Thanks. Actually, I'll show one more thing, uh, to give an example of, like, how it's, uh, maybe more useful to an engineer. Here's another, uh, conversation where, uh, the summarization failed.
- 18:36
Uh, we, we have just a, uh, reiteration of the instructions. That looks, that looks like the system prompt. Um, no idea why. Let's... We can, we can actually g- kinda go in here and look why.
- 18:47
Okay, well, there's, there's a good reason why. Um, and you can see that it's been graded accordingly, uh, which is, you know, uh, exactly what we would expect. So we, we've been able to track, uh, hallucinations via this process.
- 19:00
We've been able to see model drift, uh, in a meaningful way, in a data-driven way that we previously were unable to do. You know, a lot of it has been, uh, sort of, um, requiring humans to sample these things and give feedback on that.
- 19:11
So this has been a, a huge, uh, tool in our, like, maintenance of, of, of achieving the, the utmost trust that we can, uh, kinda retain with our customers.
- 19:22
Awesome. Thanks. Great. So maybe just in the interest of time, I'll skip forward. So, uh, one of the big, uh, achievements we were able to get was, uh, using this Auto Feedback approach, get a 20 F1 point improvement in accuracy in one of the use cases with Echo AI, and we publish all of the details in a
- 19:44
case study that's accessible there. And, uh, just in terms of getting started, obviously, we cannot share, um, you know, customer data, uh, here, so we created this new summarization app, which kinda, uh, shows an example of a summary grading, uh, application, as well as, um, has a live version of the website that you could check out.
- 20:04
Um, if you wanna, uh, take a picture of those QR codes, um, you can adapt this for your use cases, for your tasks, and try out Auto Feedback yourself.
- 20:15
Uh, we also have an SDK, so everything that was shown in the UI is available programmatically from, uh, Python and SDKs in other languages. Uh, the feedback type is pretty flexible.
- 20:27
Uh, we have a bunch of recipes that you can get from our GitHub, as well as notebooks to get started as well. Um, I'll skip over some of the mechanics, but basically goes over how you create the task, uh, create feedback, run the Auto Feedback locally o- on a simpler model, and then fetch feedback from a more
- 20:49
complex model that runs on our cloud. And maybe just in the interest of time, we'll, uh, I think, Trey, you already covered this, but, um, yeah, invite you to use our platform, and, uh, for a limited time, you can use even the more advanced models on our platform for free.
- 21:07
Thanks a lot.
- 21:08
Thank you. [audience applauding] [upbeat music]