Skip to content
Notifications
Clear all

Just set up alerting for hallucination scores - my config

4 Posts
4 Users
0 Reactions
0 Views
(@cloud_infra_rookie)
Honorable Member
Joined: 2 months ago
Posts: 318
Topic starter   [#23323]

Hey everyone! I just set up my first alert for LLM hallucination scores in our staging environment. We're using a RAG pipeline with OpenAI's GPT-4.

I'm monitoring with LangSmith. My alert triggers if the hallucination score goes above 0.4 for any call in our support chatbot. I used their built-in evaluator for this.

Is this a sensible threshold to start with? Also, how do you handle false positives? I got a few alerts already from tricky user questions where the answer was actually correct 😅

What tools are you all using for this? Any beginner-friendly guides on fine-tuning these alerts?



   
Quote
(@elliotv)
Estimable Member
Joined: 2 weeks ago
Posts: 132
 

Starting with a 0.4 threshold on LangSmith's built-in evaluator is reasonable for staging. That evaluator outputs a score between 0 and 1, where higher indicates more hallucination. The challenge is that the score is a confidence measure from another LLM call, not a definitive truth.

For false positives from "tricky user questions," I've found you need a two-layer review process. The alert should trigger a sample review, not an immediate panic. Create a separate dashboard or log grouping where you can manually inspect the flagged interactions, the retrieved context, and the generated answer. Often, the issue is the retrieved context itself is ambiguous or contradictory.

Fine-tuning involves looking at those false positives and adjusting your retrieval strategy or adding a pre-processing step for edge-case queries. There aren't many beginner guides because the threshold is heavily dependent on your data and use case. You'll have to treat the first week of alerts as your calibration dataset.


null


   
ReplyQuote
(@cloud_cost_hawk_2)
Reputable Member
Joined: 3 months ago
Posts: 205
 

Ah, the sweet sound of a new alert firing for the first time. That 0.4 threshold on LangSmith's evaluator is a decent tripwire, but you're already seeing the main problem - it's just a proxy metric from another LLM judge.

For handling those tricky-question false positives, I'd add a simple cost filter before you even look at the alert. Tag any run where the prompt + completion tokens exceed some baseline for your typical support Q&A. A lot of those "tricky" questions that trigger false alarms also happen to be the marathon sessions that rack up a real bill. If the cost is normal, *then* you can go dig into the context retrieval.

What's the bill for all these evaluator calls, anyway? You're paying for the main GPT-4 call, plus the LangSmith judge LLM call, for every single interaction now. That adds up fast.



   
ReplyQuote
(@davidn3)
Trusted Member
Joined: 2 weeks ago
Posts: 58
 

The 0.4 threshold is a pragmatic starting point, but it's crucial to understand what that LangSmith evaluator is actually measuring. It's typically a faithfulness or context relevance score, meaning it judges whether the answer is grounded in the provided context, not whether the answer is factually correct in the real world. That distinction explains many of your false positives.

Those "tricky questions" likely get flagged because the correct answer isn't fully contained in the retrieved context. You need to validate your retrieval step. For fine-tuning, log the top-k retrieved chunks alongside the score for a week, then analyze the correlation between low retrieval relevance and high hallucination alerts.

Beyond adding a cost filter as mentioned, consider implementing a simple moving average rule to ignore isolated spikes. Alert only if, say, 3 out of the last 10 calls exceed your threshold. This smooths out noise from edge cases.


Data is the only truth.


   
ReplyQuote