From f5297292d46010188758f8e0eae45f767c14769b Mon Sep 17 00:00:00 2001 From: Paul Buetow Date: Wed, 24 Dec 2025 00:56:19 +0200 Subject: Update content for md --- gemfeed/DRAFT-x-rag-observability-hackathon.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gemfeed/DRAFT-x-rag-observability-hackathon.md b/gemfeed/DRAFT-x-rag-observability-hackathon.md index 1e0d158d..3614103b 100644 --- a/gemfeed/DRAFT-x-rag-observability-hackathon.md +++ b/gemfeed/DRAFT-x-rag-observability-hackathon.md @@ -824,7 +824,7 @@ For X-RAG specifically, potential SLOs might include: * `Search latency`: 99th percentile search response time under 3 seconds * `Uptime`: 99.9% availability of the search API endpoint -* `Response quality`: Percentage of searches returning relevant results (though this is harder to measure automatically and might require user feedback or evaluation frameworks) +* `Response quality`: How good was the search? There are some metrics which could be used... SLAs (Service Level Agreements) are often confused with SLOs, but they're different. An SLA is a contractual commitment to customers—a legally binding promise with consequences (refunds, credits, penalties) if you fail to meet it. SLOs are internal engineering targets; SLAs are external business promises. Typically, SLAs are less strict than SLOs: if your internal target is 99.9% availability (SLO), your customer contract might promise 99.5% (SLA), giving you a buffer before you owe anyone money. -- cgit v1.2.3