[task]: Decide the initial chunking and retrieval strategy

[qiuethan]

Area

service, docs-system

What needs to happen

The RAG epic (#125) needs explicit chunk-size/overlap and search-strategy choices before contributors implement them. This timeboxed spike unblocks the pure chunker (#218) and informs indexing integration (#175).

Definition of done

• A recommended chunk size and overlap, with supporting reasoning, are recorded in services/documentation-system/docs/ARCHITECTURE.md.
• A hybrid keyword/vector versus pure-vector recommendation for the current corpus size, with reasoning, is recorded in the same document.
• Both recommendations are evaluated against real catalogued Google content, with the tested document shapes and limitations stated.
• The decisions are carried into [task]: Split document text into deterministic chunks with source offsets #218 and [task]: Index document chunks and maintain their lifecycle #175's design notes.
• Any throwaway harness is removed or deliberately promoted into [task]: Measure retrieval quality against a fixed question set #178 rather than left as unowned tooling.

Scope and implementation notes

Epic / downstream: #125; #218 consumes the chunking decision and #175 consumes its output. The deliverable is a documented decision, not a deployment.

Corpus boundary: Start with Google Docs available through the existing connector, including short/structured and long/loosely structured documents where available. Do not claim results generalize to future GitHub content without evidence. Notion (#85) is canceled, not a required experiment.

Planning: Agree a small timebox before starting; model selection remains in #173. Use approved content for experiments without committing or logging private document text.

Out of scope: Implementing #218/#175, choosing the embedding model, or building a permanent evaluation suite beyond an explicitly adopted #178 prototype. Decisions must live in the architecture document, not only a comment thread.

Working convention

Part of #125. GitHub Relationships record existing prerequisites. Keep this task independently reviewable and follow AGENTS.md and the affected service's CONTRIBUTING.md for implementation, meaningful offline tests, and matching documentation. Misty issues may carry several area labels; zones apply to PRs.