The problem
A field's chunking option is never read. It is threaded from the field config through packages/rag/src/config/plugin.ts:187 and then goes nowhere: the generation hook embeds the whole source text in one call.
So an application can configure chunking, see it accepted, and get no chunking. There is no error and no warning — the option simply has no effect.
This surfaced awkwardly. Documentation was recently corrected to state the right units for that option, which means there is now carefully accurate prose describing configuration that does nothing.
Why it matters beyond the dead option
Chunking exists because embedding providers have input limits and because retrieval quality degrades when a whole document is embedded as one vector. A long document silently embedded whole is either rejected by the provider, or accepted and effectively unsearchable — the vector represents the average of everything in it.
So this is not merely an ignored setting. It is the setting that makes long documents work.
What to do
Settle which is true, then make the code and the documentation agree:
- If field-level chunking should work, wire it into the generation hook: chunk the source text, embed each chunk, and decide what a multi-chunk row means for a column holding one vector. That last question is the real design work, and it may be why the option was left unwired.
- If it should not exist, remove the option and the prose describing it, and say what an application should do instead for long documents.
Either way there should be a test asserting the observable outcome — chunking configured on a long document produces the behaviour the option claims.
Context
Generated by Claude Code
The problem
A field's
chunkingoption is never read. It is threaded from the field config throughpackages/rag/src/config/plugin.ts:187and then goes nowhere: the generation hook embeds the whole source text in one call.So an application can configure chunking, see it accepted, and get no chunking. There is no error and no warning — the option simply has no effect.
This surfaced awkwardly. Documentation was recently corrected to state the right units for that option, which means there is now carefully accurate prose describing configuration that does nothing.
Why it matters beyond the dead option
Chunking exists because embedding providers have input limits and because retrieval quality degrades when a whole document is embedded as one vector. A long document silently embedded whole is either rejected by the provider, or accepted and effectively unsearchable — the vector represents the average of everything in it.
So this is not merely an ignored setting. It is the setting that makes long documents work.
What to do
Settle which is true, then make the code and the documentation agree:
Either way there should be a test asserting the observable outcome — chunking configured on a long document produces the behaviour the option claims.
Context
Generated by Claude Code