Documentation
¶
Overview ¶
Package vectara exposes Vectara's managed RAG service through the Core vector-store capability interfaces. Vectara handles embedding, chunking, and retrieval internally — the store sends raw text to the v2 API and does NOT need an [embedding.Model]. This is unlike every other scope vector store. Documents containing media are rejected before indexing I/O because this adapter persists document text and metadata only.
Requirements: a Vectara account, an API key with corpus-level write + query scope, and a corpus provisioned via the Vectara console or control-plane API. The embedder, retrieval model, and chunking strategy are configured on the corpus itself.
Authentication. API key via the `x-api-key` header.
Construction confirms nothing, unlike its siblings. There is no metric to agree on — Vectara owns embedding and scoring — and the one remaining fact, whether the corpus exists and is enabled, lives behind corpus management, which Vectara scopes to a Personal API key. Indexing and querying are what a serving or serving_and_indexing key is for, so reading the corpus at wiring would make this store demand a more privileged key than its own work needs. A wrong StoreConfig.CorpusKey therefore surfaces on the first request.
Search shape. The store hits Vectara's v2 query endpoint — `POST /v2/corpora/<corpus_key>/query` — with the user's raw query and a `metadata_filter` string derived from the filter visitor. Scores come from Vectara on the scale it documents for this query: -1 to 1, where 1 is a perfect match and -1 has nothing to do with the query. The store maps that onto Core's range, so a Vectara 0.5 reports as 0.75 rather than 0.5 and the negative half keeps its order instead of flattening onto zero. A score outside the scale is reported: Vectara documents a reranked score as unbounded, a reranker is corpus configuration this store does not set, and squeezing such a score onto the bound would hide that behind a plausible number.
Filter visitor produces Vectara's metadata-filter SQL-like syntax — `doc.author = 'Alice'`, `doc.year >= 2020`, `doc.tag IN ('a', 'b')`, `NOT (...)`, ` AND ` / ` OR `. Metadata keys are addressed under the `doc.` prefix by default; pass StoreConfig.MetadataPrefix = `"part"` to filter part-level metadata instead.
Documents are uploaded as `type: "core"` with a single `document_parts` entry holding the raw text — Vectara does its own chunking on the server side.
Delete. Vectara has no bulk filter-delete; the store enumerates matching ids via the list endpoint (paged via `page_key`) and issues per-id DELETEs against `/v2/corpora/<corpus_key>/documents/ <doc_id>`.
A missing `page_key` is the only evidence the listing is complete, so a page holding fewer documents than the requested limit — or none at all — does not end the walk. The full id set is collected before the first DELETE, because a page key belongs to the listing that produced it and deleting mid-walk would resume through a corpus that has already changed. Deletion itself is not atomic: a failure leaves the earlier documents deleted and names the id that failed, and repeating the call finishes the rest.
Null tests emit `IS NULL`, which Vectara documents as checking "whether or not a value is NULL (empty or missing)" — the same pair of states the filter AST reads as nil. HAS is refused because filterable metadata fields are scalar.
Filterable keys. A metadata key is written into the query language as text, and that language cannot quote a field name, so a filter can only name a key that is a plain identifier. An indexed key is a string literal in the filter DSL, so without that limit a caller's key was read as syntax. A document whose metadata key is anything at all still stores and reads back fine; this is only about which keys a filter can name.
Index ¶
Constants ¶
const ( Provider = "Vectara" // DefaultEndpoint is Vectara's public REST endpoint. DefaultEndpoint = "https://api.vectara.io" // DefaultAPIVersion targets the v2 API surface. DefaultAPIVersion = "v2" DefaultMaxResponseBytes = int64(16 * 1024 * 1024) )
Exported identifiers keep provider-owned names and defaults out of caller literals.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type Store ¶
type Store struct {
// contains filtered or unexported fields
}
Store implements vector-store capabilities with Vectara. Vectara handles embedding internally, so the store sends document text without generating vectors locally.
func NewStore ¶
func NewStore(_ context.Context, config StoreConfig) (*Store, error)
NewStore performs no I/O. Vectara owns embedding and scoring, so there is no metric to agree on, and the one thing left to confirm — that the corpus is there and enabled — is readable only through corpus management, which Vectara scopes to a Personal API key. This store indexes and queries, work a serving or serving_and_indexing key is meant for, so reading the corpus at construction would demand a more privileged key than the store's own job needs.
The context is still taken, because every store in this family is constructed the same way and a caller should not have to remember which backend happens to be checkable.
func (*Store) DeleteWhere ¶
func (*Store) Index ¶
func (s *Store) Index(ctx context.Context, request *vectorstore.IndexRequest) (err error)
Index uploads documents to the corpus via Vectara's index API. The service performs its own embedding internally, so no embedding client is required here.
func (*Store) Search ¶
func (s *Store) Search(ctx context.Context, req *vectorstore.SearchRequest) (response *vectorstore.SearchResponse, err error)
Search runs a Vectara semantic search.
type StoreConfig ¶
type StoreConfig struct {
// Endpoint is the Vectara API endpoint. Optional: defaults to
// [DefaultEndpoint].
Endpoint string
// APIKey is the Vectara API key. Required.
APIKey string
// CorpusKey identifies the Vectara corpus. Required.
CorpusKey string
// DocumentBatcher batches documents before upload. Required.
DocumentBatcher vectorstore.Batcher
// MetadataPrefix overrides the metadata accessor prefix used by
// the filter visitor. Optional: defaults to "doc" so filters
// address `doc.<key>` paths.
MetadataPrefix string
// HTTPClient lets callers override transport. Optional:
// defaults to http.DefaultClient.
HTTPClient *http.Client
// MaxResponseBytes bounds every buffered HTTP response. Zero selects
// [DefaultMaxResponseBytes].
MaxResponseBytes int64
}
StoreConfig contains configuration options for the Vectara vector store. Vectara is a managed RAG service that handles embedding, chunking, and retrieval internally — the store sends raw text to the API and does NOT need an [embedding.Model]. This is unlike every other scope vector store.
func (StoreConfig) Validate ¶
func (s StoreConfig) Validate() error
Source Files