diff options
| -rw-r--r-- | gemfeed/DRAFT-x-rag-observability-hackathon.html | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/gemfeed/DRAFT-x-rag-observability-hackathon.html b/gemfeed/DRAFT-x-rag-observability-hackathon.html index ec081953..3230c89b 100644 --- a/gemfeed/DRAFT-x-rag-observability-hackathon.html +++ b/gemfeed/DRAFT-x-rag-observability-hackathon.html @@ -852,7 +852,7 @@ $ curl -s -G "http://localhost:3200/api/search" \ <ul> <li><span class='inlinecode'>Search latency</span>: 99th percentile search response time under 3 seconds</li> <li><span class='inlinecode'>Uptime</span>: 99.9% availability of the search API endpoint</li> -<li><span class='inlinecode'>Response quality</span>: Percentage of searches returning relevant results (though this is harder to measure automatically and might require user feedback or evaluation frameworks)</li> +<li><span class='inlinecode'>Response quality</span>: How good was the search? There are some metrics which could be used...</li> </ul><br /> <span>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.</span><br /> <br /> |