![]() |
|
when RAG was overkill - Printable Version +- Inference (https://www.datasculpting.ai/inference) +-- Forum: Training & Customization (https://www.datasculpting.ai/inference/forumdisplay.php?fid=13) +--- Forum: Distillation (https://www.datasculpting.ai/inference/forumdisplay.php?fid=55) +--- Thread: when RAG was overkill (/showthread.php?tid=1127) Pages:
1
2
|
Re: when RAG was overkill - turboarch95 - 10-18-2026 I'd approach it in a boring order. On GB200, the easiest win is often to back off the aggressive settings and see whether the problem survives. A lot of these threads end up being one bad config plus a pile of conclusions drawn from it. Re: when RAG was overkill - mangohouse - 10-19-2026 I'd approach it in a boring order. Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at batch size. Once you know the plain path works, then add the faster path back in piece by piece. Re: when RAG was overkill - cobalttinker - 10-19-2026 A couple things I'd check first. If you're on Ollama, I'd confirm the version first and then reduce variables until the behavior is obvious. Once you know the plain path works, then add the faster path back in piece by piece. Re: when RAG was overkill - emberrunner - 10-19-2026 My first guess would be this: Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at structured output. Once you know the plain path works, then add the faster path back in piece by piece. Re: when RAG was overkill - thetaember38 - 10-19-2026 Need a little more detail here. Are you testing this on 4090 or something else? Re: when RAG was overkill - rocmriley - 10-19-2026 I think the bottleneck is somewhere else. The reported numbers can look compelling, but in ordinary usage I didn't see the same benefit. Not saying you're wrong, just that I wouldn't lock that in as the lesson yet. |