DEV Community: pante5ter

How to stop your RAG assistant from hallucinating (a practical guide)

pante5ter — Sat, 30 May 2026 18:32:23 +0000

A RAG (retrieval-augmented generation) assistant is supposed to answer from your documents, not from the model's imagination. But teams keep shipping bots that confidently invent prices, policies, and features that don't exist. The hallucination usually isn't the model "being creative" — it's a retrieval and prompting problem you can fix. Here's the checklist I actually use.

Hallucination is usually a retrieval failure, not a model failure

If the right chunk never makes it into the context, the model fills the gap by guessing. So before blaming the LLM, ask: did retrieval even return the correct passage? Most "the AI lied" bugs are really "we fed it the wrong context" bugs. Fix retrieval first; it's where the biggest wins are.

Chunk for meaning, not for byte count

Splitting documents every N characters cuts sentences in half and scatters one answer across chunks.

Split on semantic boundaries — headings, sections, list items — not arbitrary lengths.
Keep chunks focused: one idea per chunk retrieves far more accurately than a wall of mixed topics.
Add a little overlap so context isn't lost at the seams.
Attach metadata (source, title, date) to every chunk — you'll need it for filtering and citations.

Retrieve better than plain vector search

Pure embedding search misses exact terms (product codes, names, numbers).

Use hybrid search: combine semantic (vector) with keyword (BM25) so both meaning and exact matches are covered.
Add a reranker to reorder the top candidates before they hit the prompt — it consistently lifts answer quality.
Tune how many chunks you pass. Too few starves the model; too many buries the answer in noise.

Make "I don't know" a first-class answer

This single instruction prevents most embarrassing hallucinations: tell the model to answer only from the provided context, and to say it doesn't know when the context doesn't contain the answer.

If the answer is not in the provided context, say you don't have that information — do not guess.

A bot that admits a gap is trustworthy. A bot that confidently makes something up costs you a customer.

Demand citations and ground every claim

Have the model cite the source chunk for each statement. Two benefits: users can verify, and you can automatically flag answers where the cited text doesn't actually support the claim. If it can't cite, it shouldn't assert.

Evaluate, don't vibe-check

You can't improve what you don't measure.

Build a small test set of real questions with known correct answers.
Track groundedness (is the answer supported by retrieved context?) and retrieval hit rate (did the right chunk show up?).
Re-run it on every change to chunking, embeddings, or prompts so you catch regressions before users do.

A reliable default stack

Clean, semantically chunked docs with metadata → hybrid retrieval + reranker → a strict "answer only from context, cite sources, admit unknowns" prompt → an eval set guarding the whole thing. Boring, measurable, and it stops the confident nonsense.

Done right, a RAG assistant becomes the thing customers trust for accurate answers 24/7 instead of a liability. I build RAG assistants and AI automation that stay grounded in real data as a freelancer — you can see examples at vengstudio.online. Questions about retrieval or grounding? Drop them in the comments.

Building a Telegram bot that takes payments: what actually matters

pante5ter — Sat, 30 May 2026 18:31:04 +0000

"Just add payments to the bot" sounds like a one-liner. In practice, the happy path is the easy 20% — the other 80% is the edge cases that decide whether you actually get paid and keep customers. Here's what actually matters when a Telegram bot handles money, learned from shipping a few of them.

Two very different ways to charge

There are two models, and picking the wrong one causes most of the pain:

Telegram's native payments (sendInvoice + a provider token like Stripe). The whole flow stays inside Telegram, the UX is excellent, and you get a clean successful_payment update. Great for digital goods and simple checkouts.
External payment link / your own gateway. You generate a link, the user pays on a web page, and your backend gets a webhook. More flexible (subscriptions, local providers, complex carts) but you own more of the plumbing.

For most "sell a product or a subscription" bots, native payments are the right default. Reach for external only when the provider or business model forces it.

The pre-checkout step is not optional

With native payments, Telegram sends a pre_checkout_query and you have ~10 seconds to answer it. If you don't answerPreCheckoutQuery(ok=true) in time, the payment fails — even though the user did nothing wrong.

This is where you do final validation: is the item still in stock, is the price still valid, is the user allowed to buy. Approve only if everything checks out. Skipping real validation here is how people sell things they can't deliver.

Treat money events as untrusted until verified

Two rules that save you from fraud and angry customers:

Verify webhook signatures. Anyone can POST to your webhook URL. If you act on an unsigned "payment succeeded" call, you'll ship goods for payments that never happened. Always verify the provider's signature before trusting the event.
Make payment handling idempotent. Networks retry. You will receive the same successful_payment / webhook twice. Store a unique payment ID and ignore duplicates, or you'll deliver (or refund) twice.

The database is the source of truth, not the chat

A Telegram message can be missed, edited, or arrive out of order. Don't drive business logic off the conversation state alone. Persist every order with an explicit status — pending → paid → fulfilled → refunded — and let the bot read from that. When a user writes "where's my order?", you answer from the database, not from memory.

Plan for refunds and failures from day one

The unglamorous parts customers judge you on:

A clear message when a payment fails (and an easy retry), not silence.
A defined refund path — Telegram supports refunds for native payments; wire it up before you need it.
An admin view: who paid, what's unfulfilled, what errored. A bot that takes money but gives the owner no visibility is a support nightmare.

A sane minimum architecture

Bot (webhook mode, not long polling for production) → a small backend that validates and writes to a database → payment provider webhooks landing on a separate, signature-verified endpoint. Keep secrets in env vars, log every money event, and alert on failed payments. That's it — boring on purpose, because boring is what you want around money.

None of this is hard individually; the value is doing all of it so nothing silently breaks once real money flows. I build Telegram bots with payments, databases and admin panels as a freelancer — you can see examples at vengstudio.online. Happy to answer implementation questions in the comments.

How I get Next.js sites to load almost instantly — a practical checklist

pante5ter — Sat, 30 May 2026 16:40:15 +0000

Speed isn't a vanity metric. On real projects, shaving load time directly moves conversion and Google rankings — Core Web Vitals are a ranking signal, and users bounce before a slow page even paints. Here's the checklist I actually run through on Next.js builds, in the order that gives the biggest wins first.

1. Ship less JavaScript to the client

The single biggest lever. Most "slow React site" problems are really "we hydrated 400KB of JS the user never needed" problems.

Keep components as Server Components by default (App Router). Only add 'use client' where you genuinely need state or browser APIs.
Push 'use client' down the tree, not up. A whole page doesn't need to be client just because one button is interactive.
next/dynamic for anything heavy and below-the-fold (charts, editors, 3D, modals):

const GalaxyScene = dynamic(
  () => import('@/components/GalaxyScene').then((m) => m.GalaxyScene),
  { ssr: false, loading: () => null },
);

2. Stop layout shift before it starts

CLS is the easiest Vital to wreck and the easiest to fix.

Always give next/image explicit width/height (or fill + a sized container).
Reserve space for anything async — ads, embeds, banners.
Load fonts with next/font so the swap doesn't reflow text:

import { Inter } from 'next/font/google';
const inter = Inter({ subsets: ['latin'], display: 'swap' });

3. Treat images like the heaviest thing on the page (they are)

Use next/image — it gives you AVIF/WebP, correct sizing, and lazy loading for free.
Mark the hero image priority so it isn't lazy-loaded; lazy-load everything else.
Serve dimensions that match the rendered size. A 4000px photo in a 400px slot is wasted bytes.

4. Render on the server, cache aggressively

Prefer static rendering / ISR for anything that isn't per-request personalized. A pre-rendered page paints almost instantly.
Use fetch caching and revalidate instead of refetching on every hit.
Move third-party scripts to next/script with strategy="lazyOnload" so analytics and chat widgets don't block your main thread.

5. Measure on a throttled mobile, not your laptop

Your machine on fiber lies to you. Run Lighthouse in mobile mode with CPU throttling, and watch the field data in Search Console (CrUX) — that's what Google actually ranks on, not your local numbers.

A useful habit: set a performance budget (e.g. < 150KB JS on first load) and let CI fail the build if a PR blows past it. It stops slow creep before it ships.

None of this is exotic. It's just doing the boring things consistently — and the payoff is a site that feels instant, ranks better, and converts more.

I build Next.js sites, Telegram bots and AI automation as a freelancer — if you want a fast, SEO-ready site, you can see my work at vengstudio.online. Happy to answer Next.js performance questions in the comments.