Skip to main content

Search your knowledge from an automation

Find the passages of your documents and indexed websites that match a question with the knowledge.search step, use them in a later step, and know what a search may read.

3 min read

Use a knowledge.search step when an automation needs what your organization already knows, such as a policy, a product sheet or a page of your help centre, without an agent step. It searches your documents, your indexed websites, or both, and returns the passages that match the query best, best first. It changes nothing, so it never asks for an approval. A test run answers with a mock.

Search, then use the passages

yaml
nodes:
  - id: related
    type: knowledge.search
    input:
      query: '{{ input.question }}'
      corpus: documents
      limit: 3
  - id: answer
    type: llm
    model: openai/gpt-4o-mini
    prompt: 'Answer {{ input.question }} from these passages only, and say so when they do not answer it: {{ nodes.related.output.hits }}'

The search step in the editor: its query reads the run's question, and it hands its hits to a later step.
InputWhat it holds
queryWhat to search for, in words, up to 2,000 characters.
limitHow many passages to return: 1 to 20, 5 by default.
corpusdocuments, web for your indexed websites, or all for both, the default.
folderOnly documents in this folder and the folders below it, such as /Policies/.

The step returns { hits }, best first. No hit means nothing matched, and the step still succeeds. Each hit holds:

FieldWhat it holds
textThe passage, with its document's heading.
titleThe document's or the page's title, or null.
sourcedocuments or web.
documentIdThe document the passage belongs to.
projectIdThe project the document is filed under. A document every member shares has none.
urlThe page a web passage came from.
scoreThe rank the hits are ordered by.
similarityHow close the passage's meaning is to the query, closer to 1 when closer, when the meaning search found it.

A search keeps every hit it ranks, however weak. To leave weak matches out, compare similarity in a later step.

A live run in Website relaunch: the step read the run's question, searched the documents and returned three hits.

What a search reads

A search reads what its run may read, never what the author of the step can see:

  • A run in a project reads that project's documents and the documents every member shares.
  • A run of an automation bound to projects, started for the whole organization, reads those projects' documents and the shared ones.
  • An automation bound to no project reads only the documents every member shares.

It never reads a team library the run isn't given, nor the uploads and mail of a conversation. Embedding the query counts toward the usage limits that bind the run, and is booked under the automation's name, as an llm step's call is.

When a search fails

The run page says why a search step failed and how to fix it.

FailureWhat happened
Knowledge search isn't set upThe organization has no embedding model. An administrator chooses one in Settings › Data residency.
Knowledge search failedThe provider of the embedding model refused or failed the call. A failure on the provider's side doesn't count toward pausing a schedule; a refused account or key does.
A usage limit stopped the stepA limit that binds the run has no room left. It counts as a limit, not as a failure that repeats, so no schedule pauses.