"Prompt engineering" and "LLM experience" appear on a lot of resumes now, which means the words carry less signal every month. What still reads as credible is specificity: what you built, what you measured, and where the system's limits were. A hiring manager screening AI work is mostly trying to separate people who wired up an API from people who understand why the system behaves the way it does.
Describing RAG without hand-waving
Retrieval-augmented generation is easy to name and hard to do well. The interesting parts — the parts worth putting on a resume — are the decisions:
- Chunking: how you split documents, what chunk size and overlap you settled on, and why.
- Retrieval: dense vector search, keyword/BM25, or hybrid — and how you decided.
- Context assembly: how many chunks you passed, how you reranked, and how you handled the token budget.
- Grounding: whether the model cited its sources and how you reduced answers that weren't supported by retrieved context.
A bullet like "added a reranking step and citation checking to cut unsupported answers on an internal QA bot" is concrete. "Built a RAG pipeline" is not.
Embeddings and vector search, precisely
Vector search is another phrase that hides a lot of detail. If you worked with embeddings, name the real choices: which embedding model, what dimensionality, which store (pgvector, FAISS, Pinecone, or similar), and the distance metric. Describe the index type if it mattered for latency — a flat index and an approximate one behave very differently at scale. If you evaluated retrieval quality with something like recall@k on a labeled set, that single detail signals you did more than call an API.
Evaluation is what separates the credible resumes
Most LLM work fails quietly, so how you evaluated it is the strongest thing you can show. Be specific about the harness:
- An eval set you built, and how you labeled it.
- Metrics — exact-match, an LLM-as-judge rubric, retrieval recall, faithfulness — and their honest weaknesses.
- Regression testing so a prompt change didn't silently break existing cases.
- Guardrails: input/output validation, refusal handling, and what you did about prompt injection when the input was untrusted.
If you can say "I caught a regression because the eval suite flagged it," that is a real engineering story.
Cost and latency tradeoffs
Production LLM work lives inside a budget. Model choice, prompt length, caching, batching, and streaming are all levers, and describing a tradeoff you made — "moved a classification step to a smaller model after evals showed no quality loss, cutting per-request cost" — reads as someone who has actually shipped.
Aligning to the posting without overclaiming
There's a real difference between applied LLM engineering and research. Most postings labeled "AI" want the former: someone who can build reliable systems on top of existing models. If you haven't trained or fine-tuned models, don't imply you have — claim the applied work you did and go deep on it. Overclaiming research depth is the fastest way to lose a technical interviewer.
Lining up the posting against your collected evidence — the pipelines you built, the evals you ran, the numbers you measured — shows which requirements you can genuinely support and which are gaps to name honestly. FilterProof is built around that comparison, so the application package reflects work you can defend rather than the current vocabulary.