Turning Appliance Manuals into Knowledge — Building the RAG Database

Introduction

A whole-house rental comes stocked with a washer-dryer, a dishwasher, an oven, a coffee maker, a barbecue grill — household appliances, sure, but not always obvious ones to operate. The manuals are in the room, but hunting for the right passage in a 100-page PDF is nobody's idea of a good time.

This article covers how we turned those manuals into knowledge the AI can search and answer from. It leans technical, but the underlying idea is close to slipping bookmarks into a book.

Making a PDF searchable

Why you can't just hand it over

"Why not just give the whole PDF to the AI?" It's a fair question. But a manual runs to tens of thousands of characters, which is more than you can pass in one go — and that's before you multiply it by several appliances.

So we split the documents into small pieces ahead of time and pass the AI only the parts relevant to the question.

Step three — turning meaning into numbers — is the heart of the search. Once a passage's meaning is expressed as a few hundred numbers, you can find text that means nearly the same thing even when the words differ, the way "cleaning the drum" and "washer tub maintenance" describe the same job.

Chunking quality decides search quality

We tuned the chunk size repeatedly. Too small and the context gets cut off; too large and irrelevant material rides along. We landed on roughly 700 characters as a target, while respecting heading boundaries.

The hardest problem in chunking was step-by-step instructions getting sliced in half.

We also excluded tables of contents, indexes, and warranty pages from the search. A table of contents is just a list of headings, so it matches almost any question — partially, and unhelpfully.

Flagging anything safety-related

Chunks containing words like "warning," "fire," or "burn" get flagged as safety-related content. The point is to instruct the model that flagged material must always be included in an answer, never trimmed away.

Even when a guest asks for "just the quick version," the caution stays if the step carries a burn risk. Safety information is simply not eligible for summarizing.

Where to store it

Keeping it inside the database we already had

There are dedicated services for storing the numeric representations of meaning (vectors). For this build, though, we used an extension to the PostgreSQL database we were already running: pgvector.

The big win was being able to keep "which appliance this describes" and "which page of which PDF" in the same place as the meaning data. One fewer service to manage matters more than it sounds like when you're running a small operation.

Pulling the neighboring chunks too

Handing over only the chunk that matched can produce an answer that starts awkwardly in the middle of a procedure. So we retrieve the matched chunk plus the one before it and the one after it.

Being shown only "3. Bake for 10 minutes" from a recipe isn't much help; with the steps on either side, the whole flow makes sense.

Storing in Japanese, translating at answer time

The assistant handles four languages, but we store exactly one copy of the knowledge, in Japanese. A question in English searches the Japanese source material and gets answered in English.

We considered translating and storing a copy per language, but that means quadrupling the work every time an appliance changes, and translation drift creeps in. Keeping one source of truth is easier to maintain over the long haul.

Ingestion is a careful, manual job

Choosing not to build an admin screen

We deliberately did not build an admin screen for ingesting appliance manuals. A script you run is the only path into the knowledge base.

Appliances get swapped out a few times a year, at most. Building an admin UI for that — and maintaining the PDF parsing behind it — doesn't pay for itself. Carefully checking character encoding issues and chunking on each run produces better quality anyway.

Making reruns produce identical results

The ingestion script is built so that running it repeatedly on the same appliance always yields the same result. Each run deletes the existing data first, then registers everything fresh.

Because there's no chance of leftovers from a previous run mixing in, you can freely tweak the chunking rules and re-ingest as often as you like.

Fixing garbled characters on the data side

Some PDFs extract with certain characters garbled. Fixing that by editing the original PDF would mean losing the authoritative copy of the document.

So we built a substitution table applied during ingestion instead. Leave the original untouched; correct it on the way in. That way you can always go back and check what the source material actually said.

Wrapping up

Three things mattered most in building the RAG database.

1. Chunking quality decides search quality — respect headings and make sure procedures don't get cut in half
2. Keep it inside the database you already have — at small scale, not adding a dedicated service is easier to manage
3. Keep the source in one language — translate at answer time and avoid maintaining duplicate knowledge