Large-paper embedding observation · V1
Embedding Studies
- papers
- 326
- PDFs
- 104
- characters
- ~8.5M
- Xeon CPU embedding models
- 22
- GPU workstation embedding models
- 55
How a paper becomes chunks
Fixed-token
Naive baseline
Constant-size sliding window (256 / 512 / 1024 tokens). No structural awareness. Reference baseline.
Overlap
Sliding window + overlap
Fixed token windows with 25-50% overlap between adjacent chunks. Reduces boundary loss at the cost of duplication.
Section-aware
Respect document structure
Split at section boundaries (abstract, introduction, methods, results, discussion). Chunks correspond to semantic units.
TeX-aware
Handle source TeX
Parse TeX commands; preserve equations as atomic chunks; strip rendering directives. The most demanding strategy.
What each model is tested on
- Known-title retrieval — given a paper title, return the paper
- Abstract-to-paper — given an abstract paragraph, return the source paper
- Method query — given a method description, return papers using that method
- Figure/table caption retrieval — given a caption, return the source paper
- Cross-paper related-work — given a paper, return related papers
- Code/dataset link recovery — given a paper, return its referenced code or dataset
- Cloud-model query generation — generate retrieval queries from raw text
Vectors on disk, metadata in Postgres
Explicit policy. Full embedding vectors live on disk as content-addressed manifests (SHA-256 of the chunk text plus the embedding-model name as the key). Postgres stores only the lightweight provenance and scoring layer — which chunk, which model, what retrieval task, what score, where on disk to find the vector. This keeps the database fast and small while preserving full reproducibility.