{"slug": "three-mistakes-of-new-ai-teams", "title": "Three mistakes of new AI teams", "summary": "New AI teams often fail by skipping rigorous evaluation, underestimating retrieval complexity, and treating context as mere text chunks rather than rich metadata, according to a consultant who has worked with over a dozen teams. The author, who created Quepid 12 years ago for search evaluation, argues that retrieval quality dictates AI output quality and that teams should spend about 50% of their investment on understanding the problem through evals. He cites a paper from EACL 2026 showing how correct context dramatically improves answer quality, and recommends experimenting with cheap, naive retrieval solutions before building expensive ones.", "body_md": "Your company might be forming an AI team. That AI team starts with excitement. Frequently, though, it collides with reality.\n\nI work in RAG. By now, I’ve had a front-row seat to a dozen plus budding AI teams. As a consultant being brought into expensive disasters on the search side of AI, I’m consciously biased here. Like the cop that only sees the hard, rough side of life in the streets.\n\nA surprising amount of the pain I see on AI teams looks very much like what budding search teams in the 2010s went through. Admittedly this gives me a biased perspective, but perhaps a useful one.\n\n## Evals: We can’t assume we know what ‘good is’\n\nGreat search/AI organizations spend ~50% of their investment on understanding the problem, not solving it. The same goes for AI.\n\nThis means **evals**.\n\nYou want to find opportunities for product improvement? Don’t blindly trust your PMs opinions, eval!\n\nYou know something’s wrong, but can’t find exactly where your agent fails? You need evals.\n\nYou want to train a model on user behavior? Evals become training data.\n\nMy colleagues [Hamel Hussain](https://hamel.dev/) and [Shreya Shankar](https://www.sh-reya.com/) teach an entire [course on AI evaluation](https://maven.com/parlance-labs/evals). They focus on measuring end-to-end product success, not generic metrics. Then they have a methodology for breaking that down and finding the weak points. Maybe its retrieval? Maybe it’s your guardrail? Maybe it’s something else?\n\nI couldn’t even start in search without a basis for evaluation. I created [Quepid 12 years ago](http://quepidapp.com/), because there’s no objective right / wrong answer in conversational systems, search or AI.\n\nI learned to actively NOT trust my instincts. I try to discover with my clients / customers what should happen. Years ago, I did [a project for Advanced Auto Parts](https://opensourceconnections.com/blog/2014/07/24/using-quepid-to-improve-relevancy-of-advance-auto-intranet-search/) internal search. I assumed when employees searched for a product, they just wanted that product to come up. No: what they actually wanted to know was “what will I get an incentive for selling?”.\n\nYour job isn’t just to build things, it’s to be a scientist. Evaluate, hypothesize, test, improve. Don’t lose track of that!\n\n## Retrieval: it’s not a checkbox, it’s the whole thing\n\nYou knew I was going to say this. But how complex this gets - how diverse retrieval can be - becomes a blind spot. Teams just assume there’s one classic RAG architecture to build that applies to everyone.\n\nWe need to recognize that AI teams are search teams. One of the easiest findings out there in research: **retrieval dictates AI quality**.\n\nIn one [such paper](https://aclanthology.org/2026.eacl-srw.17) you can see how dramatic having the right context improves AI quality. They give the LLM the right context, and we see how much answer quality improves.\n\n(Of course, this assumes you have the evals to know the right context!)\n\nSolutions to get the right context vary dramatically.\n\nYou will spend an inordinate amount of time focused on decisions like how to chunk, what technologies should be used to retrieve those chunks, how should they be ranked, how do you give a diverse set of answers.\n\nFor example, the authors of the paper above try different retrieval approaches with varying results:\n\nEach of these solutions are quite different directions. It’s easy to get sunk-cost into one approach in search. Yet there are cheap ways to experiment with naive solutions before jumping to high levels of complexity.\n\nNavigating cheap/easy/dirty to discover what works before building out expensive/robust takes search experience.\n\n## Context doesn’t mean chunks - it means metadata\n\nIn RAG, the classic chunking strategy involves breaking up text into useful passages. We assume, in search, that RAG involves a classic question-answering paradigm: embed passages, embed queries, find the similar results, inject them into agent context.\n\nYet I’d argue, that’s not *really* what RAG is. RAG is about presenting useful information to an agent. Useful to let the agent evaluate its trustworthiness and relevance to the prompt.\n\nIf you built RAG for my blog, which chunk is more useful to the LLM?\n\nWhile I worked at Shopify, I implemented a search relevance solution\n\nOr\n\n```\n## Title: My search relevance work at Shopify\n\n## Popularity\nMedium\n\n## Publication Date\n07-20-2020\n\n“While I worked at Shopify, I implemented a search relevance solution...”\n```\n\nThe latter helps the LLM consider how to use the information. Is it recent? Is it trustworthy? Is further investigation warranted?\n\nRAG is about helping the implicit judge inside the LLM make better decisions. It’s not about arguing how / where to exactly split articles up into paragraphs.\n\nWhen building AI, you need to support the brain inside the LLM. That means representing information with structured metadata that’s important to your domain. Something can be semantically similar to the prompt, but be a horrible response to the user.\n\nIt goes beyond that too. We think of retrieval as only lexical/keyword or embeddings. But representing the right metadata and building tools for agents to select on that metadata can matter more. I think of it even as the third, hidden pillar in retrieval: query understanding and metadata.\n\nDon’t think about “chunks” think “how do I represent a unit of information and its provenance to an LLM.” and “how do I let LLMs navigate that information architecture.”\n\n## The intersection of engineering and data science\n\nLike search, AI teams thrive when they can be multidisciplinary. Can you build scalable systems, but also think in hypotheses? Can you create a retrieval system that scales, but you know targets the weak points in your evals?\n\nI help orgs build their search teams. I have long encouraged getting away from siloed engineering + data science. You need minds that can fit both perspectives into one brain to make minute-to-minute tradeoffs when building. Not data science throwing models over the wall, wait 3 months once built out, only to realize it’s the wrong model, and you need to start over.\n\nThat’s also increasingly how I think about educating AI teams. If you want to get a batteries-included “getting started with AI” perspective, check out [my course with AI expert Hugo Bowne-Anderson](https://maven.com/softwaredoug/build-enterprise-agents). We’re going to actually teach at Building with AI course that doesn’t yadda-yadda over the search part.\n\nWhat else do AI teams miss? Get in touch and let me know!\n\n### Learn to Build Agents + Retrieval from Scratch\n\nTake a course from Doug and AI educator Hugo Bowne-Anderson as they build an agent + retrieval from scratch! [Sign up!](https://maven.com/softwaredoug/build-enterprise-agents)", "url": "https://wpnews.pro/news/three-mistakes-of-new-ai-teams", "canonical_source": "https://softwaredoug.com/blog/2026/08/29/ai-team-mistakes", "published_at": "2026-08-29 14:41:07+00:00", "updated_at": "2026-08-29 14:48:53.544090+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-research", "ai-tools", "ai-products"], "entities": ["Hamel Hussain", "Shreya Shankar", "Quepid", "Advanced Auto Parts", "EACL 2026"], "alternates": {"html": "https://wpnews.pro/news/three-mistakes-of-new-ai-teams", "markdown": "https://wpnews.pro/news/three-mistakes-of-new-ai-teams.md", "text": "https://wpnews.pro/news/three-mistakes-of-new-ai-teams.txt", "jsonld": "https://wpnews.pro/news/three-mistakes-of-new-ai-teams.jsonld"}}