> ## Content Index > Fetch the complete content index at: https://www.bulkifiedthinking.com/llms.txt > Use this file to discover other available public pages before exploring further. # How Agentforce Finds Answers in Unstructured Data: Vector Databases & RAG - URL: https://www.bulkifiedthinking.com/how-agentforce-finds-answers-in-unstructured-data-vector-databases-rag/ - Published: 2026-09-30T03:02:53.000Z - Updated: 2026-09-30T03:02:53.000Z - Description: How does Agentforce actually find the right information across thousands of files? I look at unstructured data, chunking, vector databases, Data 360 Search Indexes and RAG, and explain how all of it works together before the LLM answers. - Author: Andrii Sukhetskyi - Tags: Agentforce, AI, Architects In the last couple of months, I keep hearing more about Agentforce being able to understand your organization, pick the relevant pieces of information and work with different chunking strategies. The less obvious part is that most of it eventually accumulates into one simple question Agentforce has to answer: How do I find the **relevant** information? You, all technical engineers out there, can criticize me and say that finding information is a matter of a simple keyword search, as long as the data is properly indexed. In reality, it comes down to many other problems: millions of records from different data sources, users using completely different wording, LLM token limits, accuracy getting worse when useful information is buried under piles of useless context, and, of course, unstructured data. Unstructured data is an incredibly interesting one. How can Agentforce (or your custom application) discover a few relevant pieces of information across thousands of files, support tickets, emails and conversations circulating around your organization? You might suggest finding a file by its title, description or summary using SOQL or SOSL, passing the entire thing to an LLM and hoping it finds the right answer somewhere across dozens of pages. Which is, frankly, a terrible idea. No worries, though. That's why we're here. I want to look at what actually happens behind the unstructured scenes and why vector databases, search indexes and RAG make a difference. ## How To Make Unstructured Data Searchable? Unstructured data is information that does not follow a predefined schema in the same way your standard or custom records do. It can be PDFs, Word documents, images, emails, transcripts or support tickets. All of them can contain crucial information for your business. Yet, once you have enough of them, most of that information becomes a dead weight unless you have a good way to find it. Agentforce has the exact same problem. It is not an endless box capable of loading every document in your company, reading everything and figuring out what matters for every request. It needs a reasonable way to retrieve only the information that applies to what the user is asking. For reference, you can absolutely store the content in a regular relational database: ``` id | 001500000001AbcAAY name | contract.pdf content | "Customer may terminate..." ``` However, in this case, the problem is search. Imagine you have thousands of contracts and somebody asks: ```text Can I cancel my contract if the system has been unavailable for two days? ``` The actual contract might say: ```text Customer may terminate the agreement if the service remains unavailable for more than 48 consecutive hours. ``` You might notice a few things right away: - Your user said "cancel". The document says "terminate". - Your user said "system". The document says "service". - Your user said "two days". The document says "48 consecutive hours". A regular keyword search will struggle here because the words are different even though the meaning is identical. That's where [vectors](https://www.ibm.com/think/topics/vector-embedding?ref=bulkifiedthinking.com) come into play. A vector is a long list of numbers representing the meaning and context of a piece of information. Something like this: ``` [0.021, -0.813, 0.441, 0.092, ...] ``` These numbers mean absolutely nothing to us. Mathematically, though, they represent where that particular text sits in a large semantic space, or in simple terms, what does that particular text is all about. πŸ’‘ The original content still matters because this is what we eventually want the LLM to read. The vector is primarily a representation used to find that content. ![](https://storage.ghost.io/c/92/d5/92d55211-2cfe-45c9-b8c4-b7c7b1595cdb/content/images/2026/09/image-1.png) [What Is a Vector Database? An Illustrative Guide](https://www.altexsoft.com/blog/vector-database/?ref=bulkifiedthinking.com) Now, who creates those numbers? This is done by an embedding model. An embedding model is a model specifically designed to convert information into vectors. It is not the same generative LLM that eventually answers your question. Salesforce Data 360, for example, currently supports dedicated embedding models such as E5 Large V2, Multilingual E5 Large and SFR V2 Small for search indexes. So our contract text goes through an embedding model: ```text "Customer may terminate the agreement if the service remains unavailable for more than 48 consecutive hours." ↓ Embedding model ↓ [0.021, -0.813, 0.441, 0.092, ...] ``` Then our user asks: ```text "Can I cancel my contract if the system has been unavailable for two days?" ``` The same type of embedding model converts the question into another vector. ```text User question ↓ Embedding model ↓ [0.019, -0.791, 0.419, 0.103, ...] ``` If the vectors are mathematically close to each other, there is a good chance the meaning is close as well. The search index can therefore find the contract paragraph even though the user did not use the words "terminate", "service" or "48 consecutive hours". Basically, the search engine is using mathematics to find vectors located close to the vector representing the user's question. Those search engines normally use nearest neighbor search techniques and specialized indexes rather than comparing every vector against every other vector one by one. ## What About Large Documents? There is another problem. Converting a 150 page contract into a single vector would not be particularly useful. The contract can talk about salary, termination, confidentiality, benefits, intellectual property and another hundred things. Representing all of it as one semantic point would make our search very imprecise. That's why unstructured content is normally divided into chunks first. ```text Chunk 1: "This agreement begins January 1..." ↓ [0.291, -0.104, ...] Chunk 2: "Customer may terminate the agreement if the service remains unavailable for more than 48 consecutive hours." ↓ [0.021, -0.813, ...] Chunk 3: "Payments are due within 30 days..." ↓ [1.821, -0.011, ...] ``` Now when somebody asks about terminating the contract, we do not retrieve the entire contract. Instead, we retrieve Chunk 2. That makes the information cheaper to process, easier to fit into the model context and, most importantly, removes a lot of information that has absolutely nothing to do with the question. Salesforce does exactly this when building Data 360 search indexes. The content gets chunked and vectorized before it becomes available for semantic retrieval. Chunking, however, can introduce its own problems. Imagine a financial report containing a table like this: ```text Product Revenue Growth AI Platform $42.1M 87.9% Cloud $81.2M 21.4% ``` Now imagine the chunking algorithm splits it like this: ```text Chunk 1: Product Revenue Growth AI Platform $42.1M 87.9% Chunk 2: Cloud $81.2M 21.4% ``` The second chunk no longer contains the column names. Therefore, from the LLMs perspective: What does $81.2M mean? The same problem can happen when a conversation gets split away from the speaker name, when a section loses its title or when related paragraphs end up in completely separate chunks. At that point, the problem is no longer the LLM. You already broke the information before the LLM ever saw it. This is why Salesforce introduced [Data 360 Code Extension](https://developer.salesforce.com/docs/data/data-cloud-code-ext/guide/use-custom-code.html?ref=bulkifiedthinking.com) functions for custom chunking. They allow you to use Python to control how your content gets divided before vectorization and indexing. Sometimes you need chunks based on specific criteria. Sometimes you need more context. Sometimes you need to preserve table headers. Sometimes you want to remove PII before information gets indexed. Code Extension functions give you a place to introduce that logic. You can read more about it [here](https://developer.salesforce.com/blogs/2026/09/pro-code-chunking-of-data-360-search-indexes-for-agentforce?ref=bulkifiedthinking.com). And this is one of those areas where the implementation detail can have a very real business impact. You can use the smartest LLM available and still get a terrible answer if the right information was never retrieved in the first place. ## How Does RAG Fit in Here? We now understand vectors, chunks, search indexes and how relevant information is extracted. But what the hell is RAG and how does it fit in here? [Retrieval-Augmented Generation](https://aws.amazon.com/what-is/retrieval-augmented-generation/?ref=bulkifiedthinking.com) (RAG) is basically the process of finding relevant external information first and then giving that information to the LLM before asking it to generate the answer. Imagine a customer asks: ```text Our service has been unavailable for two days. Can we terminate the contract? ``` Agentforce might already know some structured Salesforce information: ``` Account Contact Product Support Plan Current Cases ``` But the answer could depend on information stored elsewhere: ``` Signed contract Service terms SLA Internal support policy Previous communication ``` Those files contain organization specific knowledge the model was never trained on. Without RAG, you have two bad options: - You give the LLM none of that information and risk it making assumptions. - You send every contract, every support document and every policy to the model and ask it to figure everything out. The second option is, frankly, ridiculous. LLMs cannot reasonably process terabytes of your organization's knowledge every time somebody asks one question. Even when something technically fits into a large context window, filling that context with mostly irrelevant information does not magically make the response better. That's why we need RAG. ```text USER QUESTION "Our service has been unavailable for two days. Can we terminate the contract?" ↓ Retrieve structured customer context Account Product Support Plan Cases + Retrieve relevant company knowledge Contract Chunk 18 SLA Chunk 7 Support Policy Chunk 31 ↓ Build the context for the LLM ↓ Generate the answer ``` At this point, it's important to understand that the LLM does not receive the vectors. It receives the actual text retrieved with the help of those vectors. The vectors have already done their job, they helped us find the right contract section. The LLM can now work with human readable information. RAG also does not mean vector search only. Sometimes an exact keyword is much more useful. Imagine somebody searches for: ``` INC 00048192 ``` There is not much semantic meaning to understand there. You probably want an exact match. This is why Data 360 also supports hybrid search, which combines vector search with keyword search. Salesforce specifically positions hybrid search for situations where semantic meaning and exact terms both matter. An organization can therefore have many different retrieval mechanisms working together. [RAG](https://aws.amazon.com/what-is/retrieval-augmented-generation/?ref=bulkifiedthinking.com) is the broader process that takes the relevant pieces and uses them to ground the model. ## Putting the Agentforce Flow Together Let's finally put everything into one picture. Assume your organization has Salesforce records, PDFs, Knowledge articles, emails, support conversations and some documents coming from an external system. The flow will look like this: ![](https://storage.ghost.io/c/92/d5/92d55211-2cfe-45c9-b8c4-b7c7b1595cdb/content/images/2026/09/agentforce-final-diagram-1.png) There are a few different responsibilities hiding inside this diagram. - **Organization Data** is the actual information your business works with. Salesforce records, PDFs, Knowledge articles, emails, support conversations and anything else you connect to Data 360. - **Data 360** prepares that information for search. For unstructured content, this includes parsing the file, splitting it into chunks and creating vector embeddings for those chunks. - The **Search Index** stores the searchable representation of that information. Depending on the configuration, it can use vector search, keyword search or a combination of both. - The **Retriever** uses that Search Index when Agentforce needs information. It takes the current request, searches the index and returns the most relevant chunks. You can also configure filters and other retrieval rules to control what comes back. - The retrieved chunks are then combined with the **current user request** and any **structured business context** Agentforce already has, such as Account, Case or Product information. - **RAG** is the process of taking all of that retrieved context and adding it to the prompt before the model is called. - The **LLM** receives the prompt together with that context and generates the final answer. I personally love this kind of stuff, when we look beyond the platform and explore what’s actually driving it all behind the scenes. What do you think?