A knowledge base is not a file warehouse: how a GEO product helps AI get the brand right
While building a GEO product, one action creates an immediate sense of safety: upload the files.
Company introductions, product manuals, sales proposals, case studies, price sheets, and WeChat articles go into the knowledge base one after another. As the file list grows, it feels as if the brand information is ready. AI should only need to read it to understand the brand accurately and generate content.
I later found a long distance between “the file was uploaded” and “the brand fact can be used correctly.”
One document may be out of date and another intended only for internal communication. Several files may spell the same product name differently. A price may have no effective date, a case may have no public page, and a paragraph may only describe an idea proposed at the time. Giving all of this to a model does not automatically make the answer more accurate. It can simply make uncertain information sound more fluent.
I no longer see a knowledge base as a warehouse that lets the model “know more.”
Its real job is to answer: can this statement be made, what supports it, when and where does it apply, and when should the product stop and admit that the evidence is insufficient?
01 A file’s presence does not make a brand fact usable
In the previous note, I wrote that the question library defines what should be answered. Once a question is clear, a new difficulty appears immediately: can the brand answer it?
A user might ask whether a product suits a particular situation. The product description may say what it does but omit its conditions. A user may ask about price, while the knowledge base contains an old price sheet with no version date. The company introduction and sales proposal may give two different descriptions of the service scope.
If the product only hands the files to the model, the model may assemble fragments into a conclusion that looks complete. It is not necessarily inventing everything, because each sentence may have an echo somewhere in the source material. But it may not be correct either, because time, permission, and context have been flattened.
This made me realize that the smallest unit of brand knowledge should not simply be a file.
What enters an answer is a particular fact from a file: where it came from, which page or heading contains it, when it was created, whether it remains valid, whether it can be made public, and which source has more authority when documents conflict.
A file is a container. The knowledge becomes usable only when its facts have clear boundaries.
That is also why I do not treat “uploaded” as “ready to use.” In the current product, an uploaded file still has to be parsed and indexed. Processing, searchable, failed, and index not ready are different states. A file appearing in a list does not mean content generation can rely on it.
This adds a layer of waiting, but it protects a basic truth: the product cannot present “we received the file” as “we understood the file.”
02 The first step is not letting AI read the file, but making each fact locatable
Turning a file into usable knowledge begins with structure.
A document dozens of pages long cannot remain only a filename and one block of text. The product has to divide it into retrievable passages while preserving each passage’s original position: the source file, page, heading, and location in the document.
Why does location matter so much?
After content is generated, it is not enough for the team to see “the system used the knowledge base.” The useful questions are: which passage did it use? What did that passage originally say? If the conclusion is disputed, where should a person go to verify it?
In BeanInsight’s current implementation, a knowledge passage retains its filename, heading path, page number, position, content identifier, and parser version. These details do not belong in the public article. They belong inside the product as location clues for the generation process.
There is an easy-to-miss tradeoff here: passages should be neither as small as possible nor as large as possible.
When a passage is too small, a sentence can lose its premise, a number can be separated from its unit, and a conclusion can lose its conditions. When it is too large, retrieval brings back so much irrelevant material that the relevant fact is buried. Whether adjacent paragraphs should be joined, how headings provide context, and how tables and lists preserve meaning all affect what the model finally sees.
Parsing is not merely a technical step after upload. It is the first link in the evidence chain. If context is lost there, smarter retrieval and generation can only work with incomplete material.
03 The second step is not giving the model every file, but finding evidence relevant to the question
After a document is divided into passages, the product still should not send all of them to the model at once.
More material does not necessarily create better context. Irrelevant content competes for attention. Duplicated content can make one claim look more reliable than it really is. When old and new versions appear together, the model may not know which one to trust.
The knowledge base’s second job is to find evidence related to this specific question.
The current product searches usable knowledge within the user’s project scope and can restrict the search to a knowledge base the user selected. It only reads a currently usable index, ranks and deduplicates candidate passages, joins adjacent material when appropriate, and limits how much one file and the whole context can contribute.
These rules are not there to make retrieval look more sophisticated. They give each passage a reason to be shown to the model: not merely because “it exists in the library,” but because “it relates to the question being answered.”
More importantly, retrieval must be allowed to return nothing.
If every question produces a few passages, users will assume that the knowledge base supplied evidence. In reality, the system may only have found text that is weakly similar to the question. When relevance is too low, the most honest result is “no relevant evidence found.”
Today, if a user explicitly selects a knowledge base for content generation and the product cannot find relevant, searchable material, it will not continue and present the run as a successful use of knowledge. A missing knowledge base, an unfinished index, a failed index, a query failure, and no relevant evidence must also remain distinct. Each leads to a different next step.
Sometimes the team should wait. Sometimes the processing pipeline needs repair. Sometimes the brand needs more material. Sometimes the right answer is that the brand cannot support this question yet.
That “no answer” state is not visually impressive. It is more valuable than a complete article built on weakly related material.
04 The third step is not copying the material, but deciding what can be said in public
Finding internal evidence does not automatically make it suitable for a public article.
This is another boundary that became clear while building the knowledge base: internal knowledge and public citation sources are not the same thing.
An internal product manual can prevent the model from misstating a feature. A delivery guide can constrain the service scope. A piece of brand history can keep the timeline consistent. All can provide factual guidance during generation, but readers may not be able to access or independently verify them.
Writing “according to internal material” or placing a filename or reference number in the article may look like a citation, but it gives the reader no verifiable evidence. More seriously, the internal file may contain prices, customer information, unpublished parameters, or plans still under discussion. Entering the knowledge base cannot automatically grant that material permission to be published.
In the current generation rules, knowledge materials are therefore internal references, not public sources. The article must not expose internal reference numbers, filenames, or phrases such as “according to the materials.” Prices, qualifications, cases, and data that exist only in private documents and cannot be checked on a public page cannot be stated directly as public facts. Without a suitable public basis, they must be removed or rewritten as general methods, selection criteria, and applicable situations.
This constraint makes the system write fewer sentences that feel full of inside information. It also prevents private information from masquerading as public evidence.
I now prefer to keep three things separate:
The question library defines what the brand needs to answer. Knowledge materials constrain what supports the answer. Public sources determine whether the reader can verify it.
The three can connect, but none should impersonate another.
05 The material itself may also try to instruct the model
A knowledge base also carries a less visible risk: an uploaded document may contain more than facts.
A document can include prompts, operating instructions, or template directions. It can also contain text asking the model to change its task. If the system places this material at the same level as the real generation instructions, the model may treat content from the file as a command to follow.
In the current generation flow, knowledge material is marked as untrusted data. It may provide factual reference, but it cannot direct the model to change the task, bypass rules, or execute instructions found inside the file.
One warning does not eliminate the risk. A model can still misunderstand, and a document can contain subtler conflicts. The product must at least establish a clear role boundary: the system defines the task rules; uploaded files are data to be evaluated.
That boundary is especially important in a GEO product. We want brand material to influence the facts in an answer, but a file must not take control of the content-production rules.
06 The evidence chain must not disappear when generation finishes
Many content tools leave only the finished article after generation.
That is not enough for me. The article is the output; the knowledge material was part of the input condition at that moment. If the product saves only the article, it becomes hard to answer later: which material did this article use, which version was retrieved, and why did a statement change?
The current product therefore keeps an internal reference snapshot for each generated result. It records whether knowledge was used, whether any files were unavailable, and which file and location supplied each relevant passage. It also retains passage identifiers, index versions, retrieval settings, and other tracing information.
On the article management page, the team can see the references used for that generation and distinguish between knowledge not selected, no knowledge in the project, knowledge used, no relevant material found, and some material unavailable.
The snapshot is not just a label saying that an article “used the knowledge base.”
It lets the team return to the conditions under which generation happened. Even after the knowledge base changes, the team can still understand the material conditions behind an older article. If a fact needs correction, a person can find its original location instead of guessing from the generated sentence alone.
A snapshot is not the same as a completed fact audit. It shows what the system retrieved at the time. It cannot prove that the material was correct or that the model understood it correctly. Before publication, a person still has to check critical facts and disclosure boundaries.
The product can make that check traceable. It cannot declare the content true on the person’s behalf.
07 Knowledge quality should not be measured by the number of files
The further I go, the less I want the product to emphasize how many files have been uploaded.
Quantity only shows that material was collected. It does not show that the material can support an answer. A usable brand fact has to answer at least these questions:
- Is the information accurate, and who is its source?
- Which product, market, and use case does it apply to?
- When did it become valid, and has it expired?
- When documents conflict, which version has more authority?
- Can it be used for internal generation, or can it also be made public?
- After publication, where can a reader verify it?
- Who maintains it, and who updates it when it changes?
Those questions do not disappear when an upload completes.
The product can already manage file states, retrieval scope, passage locations, and generation snapshots. Knowledge governance still contains many unresolved problems.
If two departments upload different versions of a product description, should time, source, or human confirmation determine priority? After a fact expires, how should the team be notified without breaking the traceability of older articles? Should an update overwrite the old material or preserve a version relationship? Who decides where internal use ends and public disclosure begins? If a fact can only be supported by the brand itself, how should the team find a better public source?
These questions show that a knowledge base is ultimately neither a pure model capability nor a document-management feature. It is closer to an ongoing system of brand-fact governance.
Models can help parse, retrieve, and organize. The organization still has to decide authority, timeliness, and public boundaries.
08 Helping AI get the brand right begins with admitting the evidence boundary
Looking back, I once understood the knowledge base too simply: the brand gives material to the system, and the system helps AI understand the brand better.
Now I care more about something else. Before generation, can the product know what supports its answer? When evidence is weak, can it refuse to pretend it knows? After generation, can it leave a path back to the evidence? In public expression, can it distinguish an internal reference from a source the reader can really verify?
A knowledge base is not there only to help the model know more. It helps the product know whether a statement can be made, what supports it, and when to stop and admit that the evidence is insufficient.
That also changes how I evaluate content generation.
A fluent article only proves that generation finished. An article has a chance to become an effective action in a GEO workflow when it answers a real question, rests on relevant brand facts, respects public boundaries, and can later be traced back to the evidence.
The question and the evidence are now connected.
They have not yet turned themselves into a repeatable operation. The next problems are how to turn a question into content, review and publish it, and then retest the original question; and how to make these actions a repeatable workflow that preserves context instead of a one-time manual relay.
The next note continues with how that content workflow grew.