You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Feature Request]: Optionally write chunk content to the payload in QdrantWriteConfig #40476
The other RAG writers do persist the content: BigQueryVectorWriterConfig writes a content column (item.content_string) and the Milvus writer has with_content_spec(). With Qdrant, a search over a collection written by Beam returns vectors and metadata but not the text, so the retrieved chunks cannot be used for generation without a second lookup against the original source.
Proposal
Add an optional field to QdrantWriteConfig:
content_payload_key: Optional[str] =None
Default None keeps today's behavior exactly (no change for existing users).
When set, the converter stores item.content_string under that key in the payload, alongside the metadata. A collision with an existing metadata key should raise a clear ValueError rather than silently overwrite.
Unit tests for the converter plus an update to the existing testcontainers round-trip test.
Questions for maintainers
Was omitting the content intentional (e.g. to keep payloads small)? The existing tests assert payload == item.metadata, so I want to make sure this is not a deliberate design decision before changing it.
Is an opt-in content_payload_key the right shape, or would you prefer a different name/default (e.g. always writing to a "content" key)?
Context
I plan to follow up with a Qdrant search enrichment handler (the earlier attempt in #35686 went stale), and the retrieved text is needed for that to be useful end to end. I would like to send this smaller change first, and I'm happy to take it on if the direction looks good.
It adds an optional content_payload_key to QdrantWriteConfig. When it is set, the converter stores EmbeddableItem.content_string under that key in the point payload next to the metadata. The default is None, which writes only the metadata as today, so existing pipelines are unaffected. A key that collides with a metadata key raises ValueError instead of overwriting it, and an empty key is rejected at construction time.
@MichaelGruschke, since you wrote the Qdrant writer in #38142, could I ask you two things before this goes further?
Was leaving the content out of the payload deliberate (for example to keep payloads small)? The existing tests assert payload == item.metadata, so I want to be sure I'm not undoing a design decision.
Is an opt-in content_payload_key the right shape, or would you prefer a different name or default, such as always writing to a fixed "content" key?
If you have time, a review of #40502 would be much appreciated. I'm happy to change the name or the default based on your answers.
Activity
pangwangshu commentedon Oct 9, 2026
.take-issue
pangwangshu commentedon Oct 10, 2026
I've opened #40502 for this.
It adds an optional
content_payload_keytoQdrantWriteConfig. When it is set, the converter storesEmbeddableItem.content_stringunder that key in the point payload next to the metadata. The default isNone, which writes only the metadata as today, so existing pipelines are unaffected. A key that collides with a metadata key raisesValueErrorinstead of overwriting it, and an empty key is rejected at construction time.@MichaelGruschke, since you wrote the Qdrant writer in #38142, could I ask you two things before this goes further?
payload == item.metadata, so I want to be sure I'm not undoing a design decision.content_payload_keythe right shape, or would you prefer a different name or default, such as always writing to a fixed"content"key?If you have time, a review of #40502 would be much appreciated. I'm happy to change the name or the default based on your answers.
MichaelGruschke commentedon Oct 11, 2026
MichaelGruschke commentedon Oct 11, 2026
In hindsight, it would be better to write metadata as a nested field and have content top level if applicable. Breaking change though.