Giving it your knowledge

The pitch for attaching your own files is irresistible: upload everything, and the assistant knows everything. The reality is that a carelessly loaded assistant answers worse than one with no files at all, and the reason is worth understanding, because it governs every decision in this lesson and most of lesson 10.

What actually happens to your files

When you attach a document, it is not memorised. It is cut into pieces — a few hundred words each — and stored so that pieces can be found later by meaning. When someone asks a question, the system retrieves the handful of pieces that look most relevant and shows them to the model alongside the question. The model then answers using those pieces.

What happens to an uploaded document: cut into pieces, matched by meaning, and only the top few reach the model
What happens to an uploaded document: cut into pieces, matched by meaning, and only the top few reach the model

Two consequences follow immediately, and they explain nearly every complaint people have about document chatbots.

Only a few pieces make it in. The model sees perhaps three to ten fragments, not your document. A question whose answer requires synthesising across forty pages will be answered from four of them — confidently. This is why "summarise this whole handbook" gives a poor result while "what does the handbook say about notice periods" gives a good one.

Matching is by meaning, not by keyword — and it can miss. If the retrieval step pulls the wrong pieces, the model answers from the wrong pieces and has no way of knowing. Its confidence is unchanged. Any complaint of the form "it made something up from our own documents" is almost always this: retrieval missed, and the model filled in from general knowledge.

The hygiene rules that follow

Fewer, cleaner files beat more files. A 200-page PDF of scanned site notes competes with itself: dozens of pieces look equally relevant to any question, and the good one loses. Twelve well-named, single-topic documents outperform it decisively. Rohit attached four exemplary briefs, not four hundred.

Structure survives, formatting does not. Headings and clear section names help enormously, because a piece that begins "Notice period — clause 4.2" carries its own context. Tables mostly survive; multi-column PDF layouts often do not; scanned images without a text layer contain nothing at all as far as the system is concerned. Check one before you trust a hundred: open the PDF and try to select the text with your cursor. If you cannot, neither can the assistant.

Say what each file is. One line at the top of each document — "Studio Kalpa standard brief, residential, 2024 revision" — dramatically improves retrieval, because it puts identifying words into every piece cut from that file.

Date anything that expires. The system has no notion that the 2022 rate card was superseded. Both versions will be retrieved with equal enthusiasm, and the model will average them into something that was never true. Either delete the old one or put the year in the first line and add an instruction to prefer the most recent.

Attach examples, not archives. This is the highest-leverage rule in the lesson. For a task like brief-writing, three excellent examples of the output teach the assistant more than a thousand pages of raw material — because what you actually want transferred is the pattern, and a pattern is learned from clean instances, not from a warehouse.

What not to upload, ever

Anything you would not be comfortable having quoted back to a colleague who uses this assistant. Attached knowledge is available to every user of the assistant, and it does not respect the folder permissions the file had where it came from. A salary sheet in a shared assistant's knowledge is a salary sheet published to everyone with the link.

The same caution applies to client-confidential material, anything under an NDA, and personal data about identifiable people. Lesson 12 covers the full policy; the rule for right now is: the knowledge base inherits no permissions. Whatever goes in is visible, in effect, to whoever can use the assistant.

Rohit's catalogue problem, deferred

Studio Kalpa's eleven years of specifications are the wrong job for this block. It is thousands of documents, it needs to be searched rather than patterned, and it changes weekly. Attaching it to a Project would produce exactly the diluted mush this lesson warns about. That problem needs a knowledge base built for retrieval, which is lesson 10, and Rohit will get there.

Knowing which block a problem belongs to is the skill this course is really teaching. The brief writer needed five files. The catalogue needs a different tool entirely. Using the first for the second is the most common expensive mistake in no-code AI.

Do this today: open the assistant you built and attach exactly three files — good examples of the output you want, each with a one-line description at the top. Then ask it the question you most want it to answer, and check whether the answer actually came from your files or from the model's general knowledge. Asking "which of my documents did that come from?" usually settles it.

← Previous