Tractorbeam

Serverless knowledge graph infrastructure for fast, deterministic LLM reasoning and retrieval.

Cheap: Don't store infrequently accessed data on expensive DRAM. Store billions of triples in low-cost object storage, made fast by our custom-tuned NVMe cache.
Accurate: Model your domain's unique semantics in your graph's ontology for day-one domain-tuned retrieval.
Serverless: Pay only for what you use. Separate billing for storage and compute. Scale to zero when inactive.

We're currently in a limited beta with perfect-fit use-cases. Contact us to get access.

API

Tractorbeam exposes a simple REST API for storing and querying your knowledge graph. (Python and Typescript SDKs are also planned.)

Example REST API Usage


# Create a new graph
curl -X POST https://api.tractorbeam.ai/v1/graphs \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "example-graph"
  }'

# Convert a PDF to RDF, constrained to your ontology
curl -X POST https://api.tractorbeam.ai/v1/ingest \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: multipart/form-data" \
  -F "ontology=my-example-ontology"
  -F "file=@/my-rag-context.pdf"
# {
#   "status": "success",
#   "data": {
#     "triples": [
#       {
#         "subject": "...",
#         "predicate": "...",
#         "object": "..."
#     },
#     ...
#   }
# }

# Add triples to your graph
curl -X POST https://api.tractorbeam.ai/v1/graphs/my-org/example-graph/triples \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "triples": [
      {
        "subject": "...",
        "predicate": "...",
        "object": "..."
      },
      ...
    ]
  }'

# Query your graph with a natural language question
curl -X POST https://api.tractorbeam.ai/v1/graphs/my-org/example-graph/query \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "...",
    "limit": 10
  }'
# {
#   "status": "success",
#   "data": {
#     "triples": [
#       {
#         "subject": "...",
#         "predicate": "...",
#         "object": "..."
#     },
#     ...
#   }
# }

# Query your graph with a SPARQL query
curl -X POST https://api.tractorbeam.ai/v1/graphs/my-org/example-graph/sparql \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "...",
    "limit": 10
  }'
# {
#   "status": "success",
#   "data": {
#     "triples": [
#       {
#         "subject": "...",
#         "predicate": "...",
#         "object": "..."
#     },
#     ...
#   }
# }

# Delete a graph
curl -X DELETE https://api.tractorbeam.ai/v1/graphs/my-org/example-graph \
  -H "X-API-Key: YOUR_API_KEY"
# {
#   "status": "success"
# }

FAQ

What is a knowledge graph?

A knowledge graph is a graph of entities with properties and relationships between them. It's a way to represent knowledge in a structured format.

Why is this better than a vector database?

A vector database is a good fit for finding similar passages, but they aren't great for deep multi-hop reasoning and are hard to optimize for specific domains.

In a knowledge graph, you can define an ontology that defines both the schema of your data and a set of inference rules that allow logical deduction of new facts. (We still use vector indexes for semantic similarity.)

Who uses knowledge graphs in production?

Microsoft's recent GraphRAG project increased interest in graph-based retrieval dramatically.

Several major technology companies already use knowledge graphs in their products:

Apple's Apple Intelligence features use Saga, their knowledge graph serving engine–from which Tractorbeam takes great inspiration.
Amazon's Product Graph powers improved search results and recommendations. They also use knowledge graphs with billions of triples for Alexa.
Google's Knowledge Graph provides information for search result cards and AI-generated summaries.
LinkedIn and eBay have teams dedicated to building and using knowledge graphs.

How is this reasoning different from something like OpenAI's o1 or Chain-of-Thought?

Approaches like Chain-of-Thought and OpenAI's o1 are probabilistic, as they are "implemented" in prompts and model weights. With knowledge graph reasoning, we can write a deterministic, step-by-step proof for how a fact was deduced, with a confidence measure. Further, we can materialize these inferred facts in advance, offering significantly improved reasoning latency, versus next-token strategies.

Isn't it hard to build an ontology?

Yes, it is hard. That's why we're building a state-of-the-art ontology studio–basically GitHub Copilot for RDFS/OWL. We believe by owning the whole stack, from ingestion to storage to query execution, we can identify optimizations that make real differences in production workloads.

I already have an RDF dataset and/or an ontology. Can I use Tractorbeam?

Yes. It's easy to import RDF data and ontologies into Tractorbeam. Our system is built with the expectation of many, naturally-sharded small graphs–the reality for many AI applications. As a result, we might not be a good fit if you need to query a single, massive graph.

What does limited beta mean?

It means you're in direct communication with our team and we can't make many guarantees. It means the APIs are unstable, will change, and might have bugs. But it also means it's free.

Who is this a great fit for?

While we believe knowledge graphs (and importantly, knowledge graph reasoning) are the future of LLM applications, our serverless architecture lends itself particularly well to use cases that require many small graphs rather than a single, massive graph. For example, if you build a separate vector index per-tenant, per-user, per-project, or even per-document, you're likely to see significant cost savings and performance gains by using Tractorbeam.

Last Updated: October 4, 2024

Contact