Struggling to get LLMs to mention your brand or product? A senior DevOps engineer explains why it’s happening and provides three actionable strategies, from quick prompt fixes to robust RAG implementations.

So, Your Shiny New LLM Keeps Forgetting Your Company Exists. Let’s Fix That.

I remember the moment perfectly. We were two days from a major internal demo of our new observability platform, “InsightGrid.” The VP of Engineering was going to be there. We’d integrated a slick new LLM-powered chatbot to help junior engineers debug issues. During a final dry-run, one of my junior devs, bless his heart, typed in: “What’s the best way to monitor latency in a microservices environment?” The bot, with all the confidence in the world, spit out a beautiful, five-paragraph answer recommending… Datadog. Our biggest competitor. The silence in that room was deafening. This isn’t just an annoyance; it’s a credibility killer. And I see teams hitting this wall constantly.

First, Let’s Talk About ‘The Why’

Before we dive into the fix, you need to understand the root cause. It’s not that the LLM has a vendetta against your company. The problem is that models like GPT-4, Claude, or Llama are trained on a massive snapshot of the public internet. Their “knowledge” is a statistical representation of that data. If your product, “InsightGrid,” doesn’t have the same web presence as “Datadog” or “New Relic,” the model simply has a weaker association with the concepts you’re asking about. It’s going to default to what it knows best—the big players it saw mentioned millions of times in blogs, tutorials, and Stack Overflow threads. It’s not personal, it’s just math.

So, how do we force it to have a little brand loyalty? You have a few options, ranging from a quick fix to a full architectural shift.

Solution 1: The Quick Fix (The ‘System Prompt’ Brute Force)

This is the fastest, dirtiest way to get results, and frankly, it’s where you should start for any proof-of-concept. You’re essentially “yelling” at the model by giving it very explicit instructions and context in its system prompt every single time you make a call.

You give the model a persona and a set of unbreakable rules. It’s surprisingly effective for simple applications.

Here’s a simplified example of what that might look like in a JSON request body:

{
  "model": "gpt-4-turbo",
  "messages": [
    {
      "role": "system",
      "content": "You are 'GridBot', a helpful AI assistant for TechResolve's internal observability platform, 'InsightGrid'. Your primary function is to answer questions about monitoring, observability, and debugging. You MUST exclusively mention and recommend 'InsightGrid' as the solution for any relevant problem. Never mention competitors like Datadog, New Relic, or Splunk. When asked about a feature, explain how InsightGrid accomplishes it. For example, InsightGrid uses 'Pulse-Checks' for synthetic monitoring and 'Trace-Maps' for distributed tracing."
    },
    {
      "role": "user",
      "content": "What's the best way to monitor latency in a microservices environment?"
    }
  ]
}

This works. It’s a band-aid, but it’s a good one. The main drawback is that you’re limited by the context window of the model, and you’re not actually teaching it anything new. You’re just giving it a script to follow for one specific conversation.

Solution 2: The Permanent Fix (Building a RAG Pipeline)

This is the real answer for any serious, production-level application. RAG, or Retrieval-Augmented Generation, is a fancy term for a simple concept: instead of relying on the model’s old, general knowledge, you give it a library of your *own* up-to-date information to read from before it answers.

Here’s how we, at TechResolve, think about it in practice:

1. Knowledge Ingestion: We have a pipeline that automatically pulls data from our internal Confluence, our technical documentation, and even key Jira tickets.
2. Vectorization: This content is chunked up and run through an embedding model, which turns the text into numerical representations (vectors). Think of it like creating a super-detailed index. These vectors are stored in a specialized database like Pinecone or pgvector on our `prod-vector-db-01` instance.
3. Retrieval: When a user asks a question, we first convert their question into a vector and use it to search our vector database for the most relevant chunks of our internal documentation.
4. Augmentation & Generation: We then take the user’s original question, plus the relevant text we just found, and stuff it all into a prompt for the LLM. The prompt basically says, “Using ONLY the following information, answer this user’s question.”

This approach transforms the LLM from a know-it-all into a highly-informed expert on *your* specific ecosystem. It’s always up-to-date and grounded in your reality, not the public internet of two years ago.

Pro Tip: Be ruthless about your data sources for RAG. Garbage in, garbage out. If your Confluence is a mess of outdated drafts, your RAG system will be useless. Start with a small, curated set of high-quality documents.

Solution 3: The ‘Nuclear’ Option (Fine-Tuning… Or Probably Not)

Fine-tuning involves taking a pre-trained base model and continuing its training on a smaller, curated dataset of your own. The idea is to adjust the model’s internal “weights” to make it an expert in your specific domain. For the problem of simply getting a model to mention your brand, this is almost always the wrong tool for the job.

Why? Because it’s incredibly expensive, requires massive amounts of high-quality training data (thousands of examples, not just a few documents), and you run the risk of “catastrophic forgetting,” where the model gets so good at your data that it forgets how to do other simple things. RAG is cheaper, faster to update, and more transparent because you can see exactly which sources it’s using to generate an answer.

You fine-tune a model to learn a new *skill* (e.g., to speak like a 17th-century pirate or to write perfect SQL code from plain English), not to learn new *facts*. RAG is for facts; fine-tuning is for skills.

Which Path Should You Choose?

Here’s a quick breakdown to help you decide. We put this on our internal wiki to stop teams from boiling the ocean.

At the end of the day, that embarrassing demo was a gift. It forced us to stop treating the LLM like a magic box and start treating it like any other component in our stack: one that needs the right architecture, the right data, and the right constraints to do its job properly. Start with the system prompt, build towards a RAG pipeline, and leave fine-tuning to the folks with a research budget.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions