# Embedding／Reranker比較辞典

CURRENT_STATUS: UNKNOWN
OBSERVATION: SPEC_ONLY
FRESHNESS: UNKNOWN
PAGE_TYPE: decision
CANONICAL_URL: /tools/ea-082-embedding-reranker
CLAIM_IDS: none
EVIDENCE_IDS: EVD-EA-082-URL-645BEF382EC7, EVD-EA-082-URL-0E927322F8E3, EVD-EA-082-URL-F436C82EE202, EVD-EA-082-URL-013EC5547569, EVD-EA-082-URL-A6139FE39DBB, EVD-EA-082-URL-C7663B7292AB, EA-082-R11-RESEARCH, EA-082-R11-WEB-READBACK
UNKNOWN_IDS: EA-082-UNKNOWN-01, EA-082-UNKNOWN-CURRENTNESS
OPS_IDS: none

## Summary
"Embedding models and rerankers are versioned retrieval components, not invisible properties of the LLM. Their quality depends on corpus, task, chunking, filters, index configuration and evaluation target. Public benchmark results are useful for candidate selection but do not establish tenant-specific retrieval quality. Model or index changes should therefore be handled as auditable migrations with corpus-specific evaluation and rollback."

## Current judgment
1. **Embedding and reranking are different stages.** Dense embedding normally provides efficient candidate generation; a cross-encoder/reranker can score query-document pairs with richer interaction at greater per-candidate cost. The Sentence Transformers retrieve-and-rerank pattern is an implementation example, not a universal requirement.
2. **Embedding vectors are model artifacts, not timeless data.** Model ID/revision, task mode, dimensionality, normalization and preprocessing must be pinned. Replacing an embedding model can change the vector space even when dimensionality remains compatible; old and new vectors must not be assumed mutually comparable without migration testing.
3. **Provider task semantics matter.** Vertex embedding documentation exposes task-oriented request semantics; therefore query/document representation should preserve which task mode produced each vector. A generic `embedding_model=...` field is insufficient where provider APIs distinguish retrieval roles or task types.
4. **Reranker scores are model-relative relevance signals.** They are not probabilities of truth, authorization, safety or business correctness. A higher rerank score cannot override ACL/policy gates.
5. **Benchmark rank is not deployment proof.** BEIR and MTEB demonstrate that retrieval/embedding quality is multi-dataset and multi-task. A leaderboard aggregate cannot establish performance for a tenant corpus, language mix, chunking policy, ACL topology, freshness requirement or domain-specific relevance definition.
6. **Retrieval evaluation must be staged.** Candidate recall@K should be measured before reranking; reranking metrics should then be measured on the candidate set. Otherwise a strong reranker can hide candidate-generation misses in aggregate reporting, while a reranker cannot recover documents absent from the candidate pool.
7. **Index migration is an operational event.** A model/dimension/preprocessing change requires re-embedding, index rebuild or dual-index migration, shadow evaluation and rollback planning. It should not be treated as a prompt-only change.

## Scope
Enterprise AI Core / retrieval / implementation / interoperability / benchmark / governance / provider mapping.

## Confirmed
- **Embedding and reranking are different stages.** Dense embedding normally provides efficient candidate generation; a cross-encoder/reranker can score query-document pairs with richer interaction at greater per-candidate cost. The Sentence Transformers retrieve-and-rerank pattern is an implementation example, not a universal requirement.
- **Embedding vectors are model artifacts, not timeless data.** Model ID/revision, task mode, dimensionality, normalization and preprocessing must be pinned. Replacing an embedding model can change the vector space even when dimensionality remains compatible; old and new vectors must not be assumed mutually comparable without migration testing.
- **Provider task semantics matter.** Vertex embedding documentation exposes task-oriented request semantics; therefore query/document representation should preserve which task mode produced each vector. A generic `embedding_model=...` field is insufficient where provider APIs distinguish retrieval roles or task types.
- **Reranker scores are model-relative relevance signals.** They are not probabilities of truth, authorization, safety or business correctness. A higher rerank score cannot override ACL/policy gates.
- **Benchmark rank is not deployment proof.** BEIR and MTEB demonstrate that retrieval/embedding quality is multi-dataset and multi-task. A leaderboard aggregate cannot establish performance for a tenant corpus, language mix, chunking policy, ACL topology, freshness requirement or domain-specific relevance definition.
- **Retrieval evaluation must be staged.** Candidate recall@K should be measured before reranking; reranking metrics should then be measured on the candidate set. Otherwise a strong reranker can hide candidate-generation misses in aggregate reporting, while a reranker cannot recover documents absent from the candidate pool.
- **Index migration is an operational event.** A model/dimension/preprocessing change requires re-embedding, index rebuild or dual-index migration, shadow evaluation and rollback planning. It should not be treated as a prompt-only change.

## UNKNOWN
- EA-082-UNKNOWN-01: exact 2026-09-16 release/tag/commit for MTEB and Sentence Transformers; current exact commercial reranker model IDs/regions/pricing/limits across providers; provider-specific embedding backward-compatibility guarantees; tenant-specific relevance/ACL performance. These remain unclosed rather than inferred.


STOP_CONDITION for this packet: satisfied when the update Work has (a) re-pinned current commercial model/API availability, (b) attached tenant-safe candidate-recall + rerank evaluation, (c) documented index migration/rollback, and (d) verified authorization placement. Until then, only the architecture/evaluation claims above should be treated as stable Core guidance.

---
- EA-082-UNKNOWN-CURRENTNESS: 外部根拠の再確認日がcanonical body/control-planeで確定していないため、currentnessはUNKNOWNとして保持する。日付を推測補完しない。

## Evidence
- EVD-EA-082-URL-645BEF382EC7 (RESEARCH): | official product docs | Embeddings | OpenAI | — https://platform.openai.com/docs/guides/embeddings
- EVD-EA-082-URL-0E927322F8E3 (RESEARCH): | official product docs | Get text embeddings | Google Cloud Vertex AI | — https://cloud.google.com/vertex-ai/generative-ai/docs/embeddings/get-text-embeddings
- EVD-EA-082-URL-F436C82EE202 (RESEARCH): | official product docs | Rerank | Cohere | — https://docs.cohere.com/docs/rerank-overview
- EVD-EA-082-URL-013EC5547569 (RESEARCH): | author-maintained implementation docs | Retrieve & Re-Rank | Sentence Transformers | — https://www.sbert.net/examples/sentence_transformer/applications/retrieve_rerank/README.html
- EVD-EA-082-URL-A6139FE39DBB (RESEARCH): | primary paper / benchmark | BEIR: A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models | Thakur et al. | — https://arxiv.org/abs/2104.08663
- EVD-EA-082-URL-C7663B7292AB (RESEARCH): | benchmark / author-maintained project | MTEB: Massive Text Embedding Benchmark | Muennighoff et al. / MTEB project | — https://github.com/embeddings-benchmark/mteb
- EA-082-R11-RESEARCH (RESEARCH): EA-082 監査済みresearch / canonical revision binding
- EA-082-R11-WEB-READBACK (IMPL): EA-082 Web body identity / canonical readback

## Failure / limits
A high MTEB/BEIR score does not prove tenant-corpus quality; benchmark-to-product extrapolation is prohibited.
## Failure / limits
Dense retrieval can miss exact identifiers, rare names, numbers or lexical constraints; hybrid lexical+dense retrieval remains a workload-dependent alternative rather than a guaranteed improvement.
## Failure / limits
Reranking only reorders candidates it receives; candidate-generation false negatives are unrecoverable downstream unless another retrieval path contributes them.
## Failure / limits
ANN index settings can trade recall for latency/cost independently of embedding-model quality.
## Failure / limits
Chunking, document deduplication, metadata filters and ACL filtering can dominate end-to-end retrieval quality even when the embedding model itself is unchanged.
## Failure / limits
Score distributions can shift across model revisions, languages and corpora; fixed score thresholds require recalibration.
## Failure / limits
Query/document role inversion or incorrect provider task_type can create silent quality degradation without API failure.
## Failure / limits
Multilingual benchmark strength does not prove parity for a specific low-resource language/domain.
## Practice
Provider/account/region/model availability and retirement status.
## Practice
API/model revision and allowed input types/lengths.
## Practice
Embedding dimension and any supported dimension-reduction parameter.
## Practice
Task/query/document mode semantics.
## Practice
Reranker candidate/document limits and request-size limits.
## Practice
Vector-store support for dimension, metric, filtering and index type.
## Practice
Data residency/retention/training terms for externally hosted embedding/reranking APIs.
## Practice
Cost/throughput quotas for bulk re-embedding and online reranking.
## Practice
**PROPOSAL — `RETRIEVAL MODEL ARTIFACT CONTRACT`**
Persist at minimum: corpus snapshot/hash; document/chunk ID; source ACL/security label; chunker/version/config; normalization/preprocessing; embedding provider/model/revision; task role/type; dimension; vector normalization; distance metric; vector-store/index type and ANN parameters; index build/version; query embedding config; candidate retriever(s); top-K; metadata/ACL filter stage; reranker provider/model/revision; reranker top-N; raw retrieval/rerank scores; final selected evidence IDs; latency/cost; evaluation suite/version; deployment/rollback refs.


Recommended execution order: authorization-aware corpus selection/filtering -> candidate retrieval (dense/lexical/hybrid as designed) -> candidate-set logging -> reranking -> evidence selection -> generation. Whether ACL filtering must occur pre-retrieval, during retrieval or post-retrieval is system-specific, but unauthorized content must not become an LLM-visible evidence path.
## Practice
**TEST_PROFILE (not executed in this run)**
Create a tenant-safe fixture with: exact-ID lookup; paraphrase; acronym; rare proper noun; numeric constraint; multilingual query; long document; near duplicate; conflicting versions; ACL-excluded relevant document; freshness-sensitive item; hard negative; no-answer query.


Compare at least: lexical baseline; dense-only; hybrid if supported; dense + reranker; current production stack vs candidate migration stack. Measure separately: candidate recall@K, MRR/nDCG@K, reranker delta, end-to-end answer evidence recall, unauthorized-retrieval rate, stale-evidence rate, duplicate rate, no-answer abstention, latency p50/p95, embedding/index build cost, online query/rerank cost. Keep model-level and pipeline-level metrics separate.


For migrations, dual-index the same frozen corpus, run shadow queries, compare overlap and relevance judgments, then test rollback. Do not mix old/new vectors in one logical similarity space unless the provider/implementation explicitly guarantees compatibility and this is independently validated.
## Practice
**Security:** retrieval relevance never supersedes authorization. Preserve ACL/filter provenance and test an ACL-excluded-but-highly-relevant adversarial fixture.
## Practice
**Privacy:** externally hosted embedding/rerank APIs may receive source text or query text; provider data-use/residency/retention terms require current verification.
## Practice
**Audit:** log corpus/index/model/chunker/reranker versions with selected evidence IDs so an answer can be replayed against the retrieval stack that produced it.
## Practice
**Cost:** bulk re-embedding, index duplication during migration, storage and reranking per query are distinct cost centers.
## Practice
**Operability:** support shadow index, dual-read comparison, threshold recalibration, drift monitoring and rollback.
## Practice
Re-pin every commercial provider model ID, revision, region, limits, pricing and data-control terms immediately before publication; mark as PRODUCT_VOLATILE.
## Practice
Decide whether this material extends the existing permission-aware retrieval Core or becomes a dedicated retrieval-model subsection; do not duplicate ACL material already established elsewhere.
## Practice
Add at least one current independent multilingual/domain retrieval evaluation beyond BEIR/MTEB if the update makes cross-language claims.
## Practice
For any named vector database, collect official index/filter semantics and an independent failure/operations source before making product-specific reliability claims.
## Practice
If the book recommends a reranker threshold, require corpus-specific calibration evidence; no universal threshold is established here.
## Practice
Current embedding model IDs/dimensions/pricing/compatibility remain PRODUCT_VOLATILE and benchmark results remain workload dependent.
## WHY_THIS_MATTERS_TO_UPDATE
Enterprise retrieval quality is not determined by the LLM alone. Candidate generation, embedding space, chunk representation, query/document task semantics, metadata/ACL filtering, reranking, score calibration and index/model migration create independent failure surfaces. The update should therefore treat embedding and reranking as versioned retrieval infrastructure rather than an invisible implementation detail of RAG.

## SCOPE_ROUTING
Enterprise AI Core / retrieval / implementation / interoperability / benchmark / governance / provider mapping.

## CLAIM_OR_RESEARCH_QUESTION
What must be pinned, evaluated and audited when an enterprise system uses embedding models and rerankers, and what claims remain unsafe when benchmark or provider documentation is the only evidence?

## EVIDENCE TABLE
| source class | exact title | author/org | canonical URL | publication/update/access | version/model | supporting locator | evidence label | relation |
|---|---|---|---|---|---|---|---|---|
| official product docs | Embeddings | OpenAI | https://platform.openai.com/docs/guides/embeddings | accessed 2026-09-16 | text-embedding-3-small / text-embedding-3-large | model/dimension and embedding usage guidance | VERIFIED_SPEC / PRODUCT_VOLATILE | support/context |
| official product docs | Get text embeddings | Google Cloud Vertex AI | https://cloud.google.com/vertex-ai/generative-ai/docs/embeddings/get-text-embeddings | accessed 2026-09-16 | current Vertex text embedding models | task_type / dimensionality / request semantics | VERIFIED_SPEC / PRODUCT_VOLATILE | support/limit |
| official product docs | Rerank | Cohere | https://docs.cohere.com/docs/rerank-overview | accessed 2026-09-16 | current Rerank family; exact production model must be re-pinned | query+documents reranking semantics | VERIFIED_SPEC / PRODUCT_VOLATILE | support/context |
| author-maintained implementation docs | Retrieve & Re-Rank | Sentence Transformers | https://www.sbert.net/examples/sentence_transformer/applications/retrieve_rerank/README.html | accessed 2026-09-16 | bi-encoder + CrossEncoder pattern; package release not pinned in this run | retrieval candidate generation followed by CrossEncoder reranking | OSS_PRACTICE | support/context |
| primary paper / benchmark | BEIR: A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models | Thakur et al. | https://arxiv.org/abs/2104.08663 | 2021; accessed 2026-09-16 | BEIR | heterogeneous zero-shot IR evaluation across datasets/tasks | RESEARCH | support/limit |
| benchmark / author-maintained project | MTEB: Massive Text Embedding Benchmark | Muennighoff et al. / MTEB project | https://github.com/embeddings-benchmark/mteb | accessed 2026-09-16 | current benchmark repo; exact commit not pinned | multi-task embedding evaluation; leaderboard/model-card ecosystem | RESEARCH / OSS_PRACTICE | support/limit |

## FINDINGS
1. **Embedding and reranking are different stages.** Dense embedding normally provides efficient candidate generation; a cross-encoder/reranker can score query-document pairs with richer interaction at greater per-candidate cost. The Sentence Transformers retrieve-and-rerank pattern is an implementation example, not a universal requirement.
2. **Embedding vectors are model artifacts, not timeless data.** Model ID/revision, task mode, dimensionality, normalization and preprocessing must be pinned. Replacing an embedding model can change the vector space even when dimensionality remains compatible; old and new vectors must not be assumed mutually comparable without migration testing.
3. **Provider task semantics matter.** Vertex embedding documentation exposes task-oriented request semantics; therefore query/document representation should preserve which task mode produced each vector. A generic `embedding_model=...` field is insufficient where provider APIs distinguish retrieval roles or task types.
4. **Reranker scores are model-relative relevance signals.** They are not probabilities of truth, authorization, safety or business correctness. A higher rerank score cannot override ACL/policy gates.
5. **Benchmark rank is not deployment proof.** BEIR and MTEB demonstrate that retrieval/embedding quality is multi-dataset and multi-task. A leaderboard aggregate cannot establish performance for a tenant corpus, language mix, chunking policy, ACL topology, freshness requirement or domain-specific relevance definition.
6. **Retrieval evaluation must be staged.** Candidate recall@K should be measured before reranking; reranking metrics should then be measured on the candidate set. Otherwise a strong reranker can hide candidate-generation misses in aggregate reporting, while a reranker cannot recover documents absent from the candidate pool.
7. **Index migration is an operational event.** A model/dimension/preprocessing change requires re-embedding, index rebuild or dual-index migration, shadow evaluation and rollback planning. It should not be treated as a prompt-only change.

## LIMITS / COUNTEREVIDENCE / FAILURE ENVELOPE
- A high MTEB/BEIR score does not prove tenant-corpus quality; benchmark-to-product extrapolation is prohibited.
- Dense retrieval can miss exact identifiers, rare names, numbers or lexical constraints; hybrid lexical+dense retrieval remains a workload-dependent alternative rather than a guaranteed improvement.
- Reranking only reorders candidates it receives; candidate-generation false negatives are unrecoverable downstream unless another retrieval path contributes them.
- ANN index settings can trade recall for latency/cost independently of embedding-model quality.
- Chunking, document deduplication, metadata filters and ACL filtering can dominate end-to-end retrieval quality even when the embedding model itself is unchanged.
- Score distributions can shift across model revisions, languages and corpora; fixed score thresholds require recalibration.
- Query/document role inversion or incorrect provider task_type can create silent quality degradation without API failure.
- Multilingual benchmark strength does not prove parity for a specific low-resource language/domain.

## AVAILABILITY_GATES
- Provider/account/region/model availability and retirement status.
- API/model revision and allowed input types/lengths.
- Embedding dimension and any supported dimension-reduction parameter.
- Task/query/document mode semantics.
- Reranker candidate/document limits and request-size limits.
- Vector-store support for dimension, metric, filtering and index type.
- Data residency/retention/training terms for externally hosted embedding/reranking APIs.
- Cost/throughput quotas for bulk re-embedding and online reranking.

## IMPLEMENTATION_STATE
**PROPOSAL — `RETRIEVAL MODEL ARTIFACT CONTRACT`**
Persist at minimum: corpus snapshot/hash; document/chunk ID; source ACL/security label; chunker/version/config; normalization/preprocessing; embedding provider/model/revision; task role/type; dimension; vector normalization; distance metric; vector-store/index type and ANN parameters; index build/version; query embedding config; candidate retriever(s); top-K; metadata/ACL filter stage; reranker provider/model/revision; reranker top-N; raw retrieval/rerank scores; final selected evidence IDs; latency/cost; evaluation suite/version; deployment/rollback refs.


Recommended execution order: authorization-aware corpus selection/filtering -> candidate retrieval (dense/lexical/hybrid as designed) -> candidate-set logging -> reranking -> evidence selection -> generation. Whether ACL filtering must occur pre-retrieval, during retrieval or post-retrieval is system-specific, but unauthorized content must not become an LLM-visible evidence path.

## BENCHMARK_OR_EVAL
**TEST_PROFILE (not executed in this run)**
Create a tenant-safe fixture with: exact-ID lookup; paraphrase; acronym; rare proper noun; numeric constraint; multilingual query; long document; near duplicate; conflicting versions; ACL-excluded relevant document; freshness-sensitive item; hard negative; no-answer query.


Compare at least: lexical baseline; dense-only; hybrid if supported; dense + reranker; current production stack vs candidate migration stack. Measure separately: candidate recall@K, MRR/nDCG@K, reranker delta, end-to-end answer evidence recall, unauthorized-retrieval rate, stale-evidence rate, duplicate rate, no-answer abstention, latency p50/p95, embedding/index build cost, online query/rerank cost. Keep model-level and pipeline-level metrics separate.


For migrations, dual-index the same frozen corpus, run shadow queries, compare overlap and relevance judgments, then test rollback. Do not mix old/new vectors in one logical similarity space unless the provider/implementation explicitly guarantees compatibility and this is independently validated.

## SECURITY / PRIVACY / AUDIT / COST / OPERABILITY
- **Security:** retrieval relevance never supersedes authorization. Preserve ACL/filter provenance and test an ACL-excluded-but-highly-relevant adversarial fixture.
- **Privacy:** externally hosted embedding/rerank APIs may receive source text or query text; provider data-use/residency/retention terms require current verification.
- **Audit:** log corpus/index/model/chunker/reranker versions with selected evidence IDs so an answer can be replayed against the retrieval stack that produced it.
- **Cost:** bulk re-embedding, index duplication during migration, storage and reranking per query are distinct cost centers.
- **Operability:** support shadow index, dual-read comparison, threshold recalibration, drift monitoring and rollback.

## SAFE_WORDING_FOR_FUTURE_BOOK
"Embedding models and rerankers are versioned retrieval components, not invisible properties of the LLM. Their quality depends on corpus, task, chunking, filters, index configuration and evaluation target. Public benchmark results are useful for candidate selection but do not establish tenant-specific retrieval quality. Model or index changes should therefore be handled as auditable migrations with corpus-specific evaluation and rollback."

## UPDATE_WORK_HANDOFF
1. Re-pin every commercial provider model ID, revision, region, limits, pricing and data-control terms immediately before publication; mark as PRODUCT_VOLATILE.
2. Decide whether this material extends the existing permission-aware retrieval Core or becomes a dedicated retrieval-model subsection; do not duplicate ACL material already established elsewhere.
3. Add at least one current independent multilingual/domain retrieval evaluation beyond BEIR/MTEB if the update makes cross-language claims.
4. For any named vector database, collect official index/filter semantics and an independent failure/operations source before making product-specific reliability claims.
5. If the book recommends a reranker threshold, require corpus-specific calibration evidence; no universal threshold is established here.

## OPEN_UNKNOWN
exact 2026-09-16 release/tag/commit for MTEB and Sentence Transformers; current exact commercial reranker model IDs/regions/pricing/limits across providers; provider-specific embedding backward-compatibility guarantees; tenant-specific relevance/ACL performance. These remain unclosed rather than inferred.


STOP_CONDITION for this packet: satisfied when the update Work has (a) re-pinned current commercial model/API availability, (b) attached tenant-safe candidate-recall + rerank evaluation, (c) documented index migration/rollback, and (d) verified authorization placement. Until then, only the architecture/evaluation claims above should be treated as stable Core guidance.

---

## AUDITED_CURRENTNESS_BOUNDARY
Current embedding model IDs/dimensions/pricing/compatibility remain PRODUCT_VOLATILE and benchmark results remain workload dependent.

NEXT: /agent/start.json
STOP: This is a knowledge projection, not an execution order.