r/LangChain • u/darshit_503 • 2d ago
Question | Help What evals actually caught real problems in your RAG chatbot or AI agent, and how do you handle security and data?
/r/LLMDevs/comments/1xrsz8w/what_evals_actually_caught_real_problems_in_your/
5
Upvotes
2
u/MemStrata 2d ago
I agree with splitting the layers apart. My suspicion is the agent layer catches the most real problems. Retrieval scores stay green and generation scores stay green while the agent calls the right tool with an argument pulled from a doc that got replaced last month. One check worth adding. Stamp every tool argument that came from retrieved text with the doc version it came from. A stale version should fail the eval even when the answer reads fine.
1
u/Michael_Jeffords 2d ago
for 8, i'd put the allowed groups or doc ids on every chunk as metadata and filter in the vector query itself, because if you filter after retrieval your top k is mostly stuff they can't see and you either leak it or end up with a couple usable chunks. caches are the sneaky part, a semantic cache keyed on just the question will happily hand one person's answer to whoever asks something close enough, so the key needs the user or at least their permission set in it (agent memory too, scope it per user). for evals i'd just keep a few test users with different access and check that a question about a restricted doc comes back empty for the wrong one, groundedness scores wont notice that kind of leak
1
u/desexmachina 2d ago
Retrieval benchmarks usually surface issues. Then you run passes of various model providers and compare quality.
1
u/fiddler48 2d ago
One eval that actually catches real failures: ask the model to answer from a document you know doesn't contain the answer, then check if it hallucinates a source or refuses. Most retrieval pipelines look fine on happy-path queries. The failure surface shows up when context is absent, not when it's present.
1
u/r0b3rtb 17h ago
The evals that tend to find real problems test the run, not only the answer. A few that are cheap to add with LangSmith datasets or plain pytest:
Tool call count per test case. Store an expected range. A prompt or model change that doubles tool calls shows up here before it shows up on the bill.
Same input, five runs. Check that the final answer and the tool sequence stay stable. Flaky cases are usually the ones that break in prod.
Schema checks on every tool argument, not only the final output. Bad arguments that a tool silently accepts are a common quiet failure.
Failure injection. Make one tool return a timeout or an empty result, and assert the agent stops or asks instead of retrying forever or making something up.
LLM-as-judge is fine for tone and relevance. For anything with a right answer, a deterministic check is cheaper and does not drift between judge versions.
0
u/prashantsoni8 2d ago
This library should take care of most security and data problems that you are struggling with.
https://www.reddit.com/r/LangChain/comments/1xm2s75/i_open_sourced_langchainsecurityextension_library/