Skip to content

Adds near-real-time knn parameter and vectordb_document index mode to conceptual docs - #7685

Open
kosabogi wants to merge 4 commits into
mainfrom
vector-features-9.5
Open

Adds near-real-time knn parameter and vectordb_document index mode to conceptual docs#7685
kosabogi wants to merge 4 commits into
mainfrom
vector-features-9.5

Conversation

@kosabogi

@kosabogi kosabogi commented Jul 31, 2026

Copy link
Copy Markdown
Member

DO NOT MERGE BEFORE THE 9.5 RELEASE

Summary

This PR adds documentation for the vectordb_document index mode and near-real-time knn parameter that will be introduced in the 9.5 release.

Generative AI disclosure

  1. Did you use a generative AI (GenAI) tool to assist in creating this contribution?
  • Yes
  • No

Cursor agents

@kosabogi
kosabogi requested a review from a team as a code owner July 31, 2026 13:04
@github-actions

Copy link
Copy Markdown
Contributor

Elastic Docs AI PR menu

Check the box to run an AI review for this pull request.

  • Review docs changes (docs-review). Status: not started.

Powered by GitHub Agentic Workflows and docs-actions. For more information, reach out to the docs team.

@github-actions

github-actions Bot commented Jul 31, 2026

Copy link
Copy Markdown
Contributor

🔍 Preview links for changed docs

@github-actions

github-actions Bot commented Jul 31, 2026

Copy link
Copy Markdown
Contributor

✅ Elastic Docs Style Checker (Vale)

No issues found on modified lines!


The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale.

@kosabogi kosabogi changed the title Adds near-real-time and vector-index-mode to docs Adds near-real-time knn parameter and vectordb_document index mode to conceptual docs Jul 31, 2026

@leemthompo leemthompo left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This section duplicates the parameter reference (true/false behavior, defaults, code example). Consider focusing on when and why in the introduction — the reference page already covers the what.

nit: I noticed that the same background process is described three different ways across this section: "prepared for search" , "optimizing" , and "preparing" . I'd suggest naming it once up front and reusing it consistently. I'd lean towards "optimize" as the consistent term.

For example:

Use the `near_real_time` parameter in the top-level `knn` object to control whether approximate kNN search includes vectors that have not yet been optimized for search.

We need to ensure cross-links with the index mode reference page too.

Comment thread solutions/search/vector/knn.md Outdated
Comment thread solutions/search/vector/knn.md Outdated
Comment thread solutions/search/vector/knn.md Outdated
Comment thread solutions/search/vector/knn.md Outdated

### Near-real-time kNN [near-real-time-knn]
```{applies_to}
stack: ga 9.5

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does it merit an explanation why this isn't tagged for serverless?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I know, our convention is to call out deployment types and version availability only when they differ from what is stated at the top of the main page.

Since Serverless is already listed as supported on this page, I don’t think we need to mention it again here. Otherwise, we would probably need to add the same callout in other sections as well.

For example, this section is specifically tagged as Serverless: unavailable, so my understanding is that only exceptions like this need a Serverless tag.

@leemthompo leemthompo Aug 3, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

true! and I've been following this myself, but for some reason my brain thought otherwise when reviewing 😄

not for this PR, but I don't think all docs have been taking the same approach 😢 (I think this is because the reader experience is slightly confusing about the cascading nature from page-level)

@kosabogi

kosabogi commented Aug 3, 2026

Copy link
Copy Markdown
Member Author

This section duplicates the parameter reference (true/false behavior, defaults, code example). Consider focusing on when and why in the introduction — the reference page already covers the what.

nit: I noticed that the same background process is described three different ways across this section: "prepared for search" , "optimizing" , and "preparing" . I'd suggest naming it once up front and reusing it consistently. I'd lean towards "optimize" as the consistent term.

For example:

Use the `near_real_time` parameter in the top-level `knn` object to control whether approximate kNN search includes vectors that have not yet been optimized for search.

We need to ensure cross-links with the index mode reference page too.

Thanks for your review, @leemthompo !
I've updated that section:

  • Used "optimized" consistently for this process
  • Kept the true/false explanations, but focused them more on the why
  • Added cross-links

@leemthompo leemthompo left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants