Why You Might Not Need an LLM to Leverage AI for Your Business

googleads_generic_blank

I've spent a lot of time lately explaining to clients how AI works and why they may not need or want a Large Language Model, or LLM, in the mix. There's so much confusion about the technology – and to most of the world, LLMs are synonymous with AI.

But there’s a lot more to AI than just LLMs. And LLMs are often a costly and potentially unnecessary feature. In many situations, an embedding model is more than enough.

What is an Embedding Model?

An embedding model is not an LLM. It's a small neural network that quickly converts text into a numerical representation, known as encoding or tokenization. The encoded data is then processed through the embedding model to create a series of decimals called a dense vector. These vectors are how "meaning" and relation are determined.

How Embedding Models Work

Consider an obvious use case: an AI-assisted search tool for a business website. Many assume that the LLM handles this stuff. You feed it your data, and it responds with relevant information.

In reality, the important work for preparing your data is handled without an LLM at all. It’s done with an embedding model. This far faster and cheaper process is the foundation for LLMs that sit on top of it.

Here's an oversimplified breakdown of how information is prepared for use with AI technologies:

  1. Extract the text if necessary (e.g., from a PDF or Word document) or fetch the content
  2. "Chunk" the raw text: This is a process that intelligently splits long text into smaller passages while also tagging each chunk with relevant data, such as the source document ID, the page number, URL, section, etc.
  3. Generate the "embedding": Each chunk from Step 2 is sent to an embedding model to create vectors
  4. Store the vectors from Step 3 in a vector database

Congratulations, you’ve just created “AI” data, no LLM required.

With a vector database of your data prepared, you can now serve extremely fast and relevant search results to your customers. Their search query is passed through the same embedding model, which converts their text into a vector on the fly. That vector is then used to fetch results from your database that are closest to the search query. The result is a ranked list of passages from your documents (aka chunks), with metadata telling you exactly which file and page they came from. You know… search results, but smarter.

This is called semantic search. Unlike just matching keywords, semantic search improves accuracy by focusing on the meaning and context behind the query. You can output these search results directly and just give your user the answer. Combining this technique with keyword matching gives you a very useful search product.

This method, without using an LLM, is orders of magnitude less expensive and resource-intensive. It’s also restricted to just the “facts” from the actual data you’ve provided. No misinterpretation or hallucination is possible.

In many cases, this is a much more preferable method, especially where precision is important – like in legal, healthcare, manufacturing, and scientific spaces.

Embedding Models vs. LLMs: What’s the Difference?

While the underlying concepts are similar, how each type of model operates is much different. An embedding model is small (80 - 500MB) and can process a full chunk or passage of content in a single pass in milliseconds on a CPU. It’s a snapshot of information encoded without any real-world context.

LLMs are massive in comparison, with the largest models requiring hundreds of Gigabytes of memory to operate. Unlike the single-pass operation of an embedding model, an LLM processes each token (roughly a word) in a recursive loop. It takes your input, produces a probability distribution over every possible next word, picks one, appends it to the sequence, then feeds the entire extended sequence back through the network to produce the next word, and repeats. Each iteration, the model reprocesses everything that came before along with it. These models are loaded and trained with essentially all of humanity's knowledge to “accurately” predict the next word and allow for “reasoning.”

So when an LLM writes a 200-word response, it has effectively run the model 200+ times in sequence. Each pass looks structurally similar to what an embedding model does in a single pass: read the context, compute attention across all tokens, and produce a vector representation. But instead of outputting that vector as the final answer, the LLM uses it to predict the next token and then loops.

This is why LLMs require powerful GPUs to provide responses in a reasonable amount of time.

Do You Need an LLM With Your Embedding Model?

Without an LLM, you have a great search engine. Ask a question, get the relevant information with citations, and read and interpret them yourself. With an LLM, you gain a conversational assistant. It can read the results for you, create summaries of the information, compare things across documents, leverage context and knowledge from the broader world, and answer you in natural language.

That extra capability comes at a huge computational and monetary cost, however. Whether that cost is worth it comes down to your use case. To me, for something like an intelligent site search, I’d rather be given the answers directly without a computer telling me how great my search was first.

The Bottom Line

It’s important to understand that you don’t always need an LLM to leverage the progress in AI for your business. Knowing the difference can unlock much greater opportunity through dramatically lower costs, highly accurate responses, and greater control and security of your data.

Looking for guidance on how to make AI work for you? Schedule a free 30-minute consultation.

Leave a Reply

Your email address will not be published. Required fields are marked *

Meet the Author

mmombrea-headshot
CTO / Partner

Matthew Mombrea

Matt is our Chief Technology Officer and one of the founders of our agency. He started Cypress North in 2010 with Greg Finn, and now leads our Buffalo office. As the head of our development team, Matt oversees all of our technical strategy and software and systems design efforts.

With more than 19 years of software engineering experience, Matt has the knowledge and expertise to help our clients find solutions that will solve their problems and help them reach their goals. He is dedicated to doing things the right way and finding the right custom solution for each client, all while accounting for long-term maintainability and technical debt.

Matt is a Buffalo native and graduated from St. Bonaventure University, where he studied computer science.

When he’s not at work, Matt enjoys spending time with his kids and his dog. He also likes to golf, snowboard, and roast coffee.