397b553528
`lancedb.databases` maps a name to a location, mutually exclusive with `uri`. `search(sources=[…])` selects which to search, `sources=None` searches all of them and `sources=[]` searches none; `SearchResult.source` carries the configured name, so a path or URI never leaves the configuration. A database named in config keeps its name even when it is the only one configured; only a legacy single `uri` leaves `source` unset. Databases open on first use, not at entry. Which are searched is a per-query choice, so a set of 25 queried a few at a time opens a few, and a database nobody asked for can neither fail a query nor be opened for nothing. A named database that fails to open raises `SourceUnavailableError` naming it, raised outside the handler so the original is not attached at all. A local failure spells out the absolute path and an object-store failure can carry the bucket; `from None` would only stop that being printed, leaving it on `__context__` for anything that walks the chain. A legacy `uri` client has no name to report instead, so its error passes through unchanged. Candidates are fetched concurrently, then fused before anything is ranked. A configured reranker scores the union, which is what makes ranking across databases tractable: it compares query against document and does not care where a candidate came from. Without one, reciprocal rank fusion over the per-database rankings, since scores from separate indexes are not comparable. Enrichment then runs on the survivors through the database each came from, concurrently, so it costs what a single-database search costs. The over-fetch decision and the reranker belong to the federating client alone. Deciding per database would have each consult its own, and a local reranker loads model weights per instance. It is built only for a text query, and closed once by the client that owns it. A location without a scheme is opened as a local path rather than through `lancedb.uri`. Routing it through `uri` had `ConnectionMode` classify it as object storage, which opens a missing database instead of reporting it. With several databases configured, `store` and the repositories are left unset: they have no unambiguous meaning across a set, and picking one silently would be worse than the error. |
||
|---|---|---|
| .. | ||
| haiku/rag | ||
| LICENSE | ||
| pyproject.toml | ||
| README.md | ||
haiku.rag-slim
Opinionated agentic RAG powered by LanceDB, Pydantic AI, and Docling - Core package with minimal dependencies.
haiku.rag-slim is the core package for users who want to install only the dependencies they need. Document processing (docling), and reranker support are all optional extras.
For most users, we recommend installing haiku.rag instead, which includes all features out of the box.
Installation
Python 3.12 or newer required
Minimal Installation
uv pip install haiku.rag-slim
Core functionality with OpenAI/Ollama support, MCP server, and Logfire observability. Document processing (docling) is optional.
With Document Processing
uv pip install haiku.rag-slim[docling]
Adds support for 40+ file formats including PDF, DOCX, HTML, and more.
Available Extras
docling, tui, voyageai, cohere, zeroentropy, cross-encoder, jina,
s3, ingester, and one per model provider: anthropic, google, groq,
mistral, bedrock, vertexai. Ollama and any OpenAI-compatible endpoint need
no extra.
What each provides, and which ones the full haiku.rag package already
includes: Installation.
# Common combinations
uv pip install 'haiku.rag-slim[docling,anthropic,cross-encoder]'
uv pip install 'haiku.rag-slim[docling,groq]'
Usage
See the main haiku.rag repository for:
- Quick start guide
- CLI examples
- Python API usage
- MCP server setup
Documentation
Full documentation: https://ggozad.github.io/haiku.rag/
- Installation - Provider setup
- Configuration - YAML configuration
- CLI - Command reference
- Python API - Complete API docs