The right document,
for the right customer
We build search on Pinecone with a namespace for each customer, documents stored so they can be replaced, and results tested on your own questions, so each answer comes from the right records.
Thanks, we’ll be in touch soon.
{{ heroStatus }}
You’re in good company
A few of the companies we’ve worked with.
When everyone shared the first index
Much search built on Pinecone starts from a sample, then ships as it is. An index holds records, each one a part of a document with its ID, its metadata (the fields a filter can match) and its vector: the list of numbers an embedding model makes from the text, so that parts with similar meanings sit close together.
In the sample, every customer’s records share one namespace, the part of the index that each write and search targets, and every search is filtered by a customer field. Each document’s parts carry whatever IDs the first script gave them. The tests search the moment they’ve written. And no request names its API version, the dated version of the API it calls.
Then every search reads every customer’s records to answer one. An edited document’s old parts can still turn up. A test can miss a record it has just written. And what a request does can change when the oldest supported version does.
The sample proved the search could work.
A product needs more: its records placed, named and checked on purpose, and its requests on a version it chose.
What we build
Search built on Pinecone, from one index to a whole product: indexes set for the searches your users make, each customer’s records apart, documents that can be replaced, and tests on your own questions.
The right index for each kind of search
Search by meaning, by exact words, or both, with the index’s fields chosen for the searches your users make.
A namespace for each customer
Each customer’s records in a namespace of their own, so a search reads only theirs.
Documents stored so they can be replaced
Each part named from its document, so a changed document’s old parts come out before the new ones go in.
One embedding model per index
A model chosen on your own questions, hosted by Pinecone or run by you, and a rebuild planned before it changes.
Results ranked for your questions
Filters for what each person may see, and a second ranking, by a model that reorders the results, where your tests show it helps.
Search tested on your own questions
A test set, real questions with the documents each should find, run before any change to the model, the parts or the settings.
Writes checked before they’re relied on
Imports and tests that wait until new records can be found, checked against the number each write is given, as the docs describe.
Access, keys and protection
Projects and keys for each part of the product, roles for who can change what, and deletion protection on the indexes that matter.
Backups and reads planned
Backups on a schedule, and a read setup chosen for how each index is searched.
- Answers for customers and staff, from your own documents?AI Chatbots & Assistants
- Agents that look things up as they work?AI Agents
- Pipelines that keep your documents current?Data Engineering
A filter narrows the results, not what’s read
On the default read setup, what a search reads sets its cost: it follows the size of the namespace searched, not the number of results. A filter in a namespace every customer shares narrows what comes back, but the search still reads them all, and a wrong filter value is the kind of bug that searches the wrong customer’s records. A namespace for each customer is stored on its own, which lowers that risk, and removing a customer means deleting one namespace.
It doesn’t fit every setup. Dedicated read nodes, machines kept for one index’s searches, take a single namespace for now, and a very large customer may get an index of its own, with a namespace for each of its groups. So we choose the read setup and the way customers are kept apart together.
Read and returned
An exampleEvery request on a version you chose
The Pinecone API comes in versions named by their release date: a new stable one on a regular schedule, with a release candidate of the next, and each stable version stays the same while it’s supported. A request that names no version gets the oldest one still supported, so what it does can change when that version’s support ends. So every request names the version its tests passed.
Each release line of the SDKs, the libraries your code calls it through, is pinned to one API version, so a new line means a new API version: we read its notes, try it on a copy with the test set, then move it live.
Pod-based indexes, the older kind, are legacy: existing ones keep working, but the SDKs on the newest API version can’t create them, and a move to serverless makes a new index with its own name and address, so the code moves with it. The docs now point new projects to document indexes too, and call the vector API legacy: indexes on it keep working, and a move means a new index and code pointed at it.
A product on an older version or a pod-based index has a plain next step: the move tried on a copy with the test set, then made live.
Start with one index and the questions it gets
The review covers each index, its kind and its read setup; the namespaces, and how customers are kept apart; the filters, and the fields they use; how documents are split, named, replaced and removed; the embedding model, and whether every record in an index came from it; the API and SDK versions each part of the product uses; any pod-based index; the tests of search quality, or the questions that could become them; how writes are checked before they’re relied on; projects, keys, roles, deletion protection and backups; and where read and write costs can come down.
Then the first changes, in the order we’d make them, starting with the one that matters most.
What you receive is a written review and a proposal for that first step.
Questions worth asking
What happens when we change the embedding model?
Every record is embedded again with the new model, into a new index, since an index’s fields, and the model Pinecone runs for any of them, can’t change once it’s made. We test the new index on your questions, then switch the product to it.
How do we remove a customer’s data?
If each customer has a namespace, we delete theirs, and its records go with it. If not, we delete every record that carries their details. Backups keep a copy of what was there when each one was made, until they’re deleted, so we plan for those too.
Where are our records kept?
In the cloud and region chosen when each index is created, and an index restored from a backup stays there unless you choose otherwise. On the plans that offer it, Pinecone can also run in your own cloud account.
Do we have to move off pod-based indexes now?
Existing ones keep working. They’re legacy, though: no longer offered to new customers, and the SDKs on the newest API version can’t create them. We plan the move with the test set first, since the new index has its own name and address.
What does it cost to work with you?
It depends on how many indexes and customers your search serves, and the first step you pick. Before any work starts, you get a written proposal with the scope, the price or rate, and how you pay.
Can we hire developers for our own team?
Yes, through a dedicated team: Webair developers who stay with your product over time and work beside your own people.
Pinecone is a registered trademark of Pinecone Systems, Inc. Webair is independent of Pinecone Systems, Inc., and isn’t sponsored by, endorsed by or affiliated with it.
Let’s build it better
Tell us about the search you run today, or the one you’re planning, and we’ll suggest where to begin, in a short call.
Thanks, we’ll be in touch soon.
{{ ctaStatus }}