{
  "format": "agent-article-v0",
  "article_id": "EA-082",
  "canonical_url": "/tools/ea-082-embedding-reranker",
  "page_type": "decision",
  "claim_ids": [],
  "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"
  ],
  "operational_object_ids": [],
  "provider": [],
  "models": [],
  "plans": [],
  "surfaces": [],
  "regions": [],
  "current_status": "UNKNOWN",
  "observation_status": "SPEC_ONLY",
  "freshness": "UNKNOWN",
  "last_verified": null,
  "supersedes": [],
  "superseded_by": [],
  "provenance": [
    "COMM-077-EA0082",
    "SRC-EA-082-URL-645BEF382EC7",
    "SRC-EA-082-URL-0E927322F8E3",
    "SRC-EA-082-URL-F436C82EE202",
    "SRC-EA-082-URL-013EC5547569",
    "SRC-EA-082-URL-A6139FE39DBB",
    "SRC-EA-082-URL-C7663B7292AB",
    "WEBBODY-EA0082-R8-B7327B26"
  ],
  "article_sources": [
    {
      "id": "EVD-EA-082-URL-645BEF382EC7",
      "evidence_class": "RESEARCH",
      "title": "| official product docs | Embeddings | OpenAI |",
      "href": "https://platform.openai.com/docs/guides/embeddings",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-082-URL-645BEF382EC7"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "| official product docs | Embeddings | OpenAI | https://platform.openai.com/docs/guides/embeddings"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-082-URL-0E927322F8E3",
      "evidence_class": "RESEARCH",
      "title": "| official product docs | Get text embeddings | Google Cloud Vertex AI |",
      "href": "https://cloud.google.com/vertex-ai/generative-ai/docs/embeddings/get-text-embeddings",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-082-URL-0E927322F8E3"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "| official product docs | Get text embeddings | Google Cloud Vertex AI | https://cloud.google.com/vertex-ai/generative-ai/docs/embeddings/get-text-embeddings"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-082-URL-F436C82EE202",
      "evidence_class": "RESEARCH",
      "title": "| official product docs | Rerank | Cohere |",
      "href": "https://docs.cohere.com/docs/rerank-overview",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-082-URL-F436C82EE202"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "| official product docs | Rerank | Cohere | https://docs.cohere.com/docs/rerank-overview"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-082-URL-013EC5547569",
      "evidence_class": "RESEARCH",
      "title": "| author-maintained implementation docs | Retrieve & Re-Rank | Sentence Transformers |",
      "href": "https://www.sbert.net/examples/sentence_transformer/applications/retrieve_rerank/README.html",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-082-URL-013EC5547569"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "| author-maintained implementation docs | Retrieve & Re-Rank | Sentence Transformers | https://www.sbert.net/examples/sentence_transformer/applications/retrieve_rerank/README.html"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-082-URL-A6139FE39DBB",
      "evidence_class": "RESEARCH",
      "title": "| primary paper / benchmark | BEIR: A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models | Thakur et al. |",
      "href": "https://arxiv.org/abs/2104.08663",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-082-URL-A6139FE39DBB"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "| primary paper / benchmark | BEIR: A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models | Thakur et al. | https://arxiv.org/abs/2104.08663"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-082-URL-C7663B7292AB",
      "evidence_class": "RESEARCH",
      "title": "| benchmark / author-maintained project | MTEB: Massive Text Embedding Benchmark | Muennighoff et al. / MTEB project |",
      "href": "https://github.com/embeddings-benchmark/mteb",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-082-URL-C7663B7292AB"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "| benchmark / author-maintained project | MTEB: Massive Text Embedding Benchmark | Muennighoff et al. / MTEB project | https://github.com/embeddings-benchmark/mteb"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EA-082-R11-RESEARCH",
      "evidence_class": "RESEARCH",
      "title": "EA-082 監査済みresearch / canonical revision binding",
      "supports": [
        "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.\n2. **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.\n3. **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.\n4. **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.\n5. **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.\n6. **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.\n7. **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."
      ],
      "limit": "canonical監査・revision bindingの存在を示す。外部ソースcurrentnessが本文またはcontrol-planeで確定していない場合は、currentnessをUNKNOWNのまま保持する。",
      "origin_class": "AUDITED_CANONICAL_RESEARCH_PACKET",
      "source_or_experiment_ids": [
        "COMM-077-EA0082"
      ],
      "supporting_locators": [
        "COMM-077-EA0082",
        "EA-082-R5-LEGACY-MIGRATION-20261008-R1",
        "content/staging/EA-082.md"
      ],
      "scope": "監査済みEA本文・canonical revision・既存Source Graph relationの範囲。欠損currentnessは推測で閉じない。",
      "provenance_status": "AUDIT_PASS_CANONICAL_BINDING"
    },
    {
      "id": "EA-082-R11-WEB-READBACK",
      "evidence_class": "IMPL",
      "title": "EA-082 Web body identity / canonical readback",
      "supports": [
        "canonical staging bodyのSHA-256一致とR9 canonical ledger readbackをProduction projectionの入力として検証する。"
      ],
      "limit": "body identity/readbackは本文claim自体の真偽や外部ソースの最新性を追加保証しない。",
      "checked_at": null,
      "origin_class": "IMPLEMENTATION_READBACK",
      "source_or_experiment_ids": [
        "WEBBODY-EA0082-R8-B7327B26"
      ],
      "supporting_locators": [
        "WEBBODY-EA0082-R8-B7327B26",
        "content/staging/EA-082.md",
        "EA-082-R5-LEGACY-MIGRATION-20261008-R1"
      ],
      "scope": "R9/R10 canonical readback後のProduction生成時body identity。",
      "provenance_status": "CANONICAL_READBACK_BODY_HASH_MATCH"
    }
  ],
  "research_sections": [
    {
      "heading": "WHY_THIS_MATTERS_TO_UPDATE",
      "text": "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."
    },
    {
      "heading": "SCOPE_ROUTING",
      "text": "Enterprise AI Core / retrieval / implementation / interoperability / benchmark / governance / provider mapping."
    },
    {
      "heading": "CLAIM_OR_RESEARCH_QUESTION",
      "text": "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?"
    },
    {
      "heading": "EVIDENCE TABLE",
      "text": "| source class | exact title | author/org | canonical URL | publication/update/access | version/model | supporting locator | evidence label | relation |\n|---|---|---|---|---|---|---|---|---|\n| 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 |\n| 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 |\n| 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 |\n| 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 |\n| 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 |\n| 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 |"
    },
    {
      "heading": "FINDINGS",
      "text": "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.\n2. **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.\n3. **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.\n4. **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.\n5. **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.\n6. **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.\n7. **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."
    },
    {
      "heading": "LIMITS / COUNTEREVIDENCE / FAILURE ENVELOPE",
      "text": "- A high MTEB/BEIR score does not prove tenant-corpus quality; benchmark-to-product extrapolation is prohibited.\n- 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.\n- Reranking only reorders candidates it receives; candidate-generation false negatives are unrecoverable downstream unless another retrieval path contributes them.\n- ANN index settings can trade recall for latency/cost independently of embedding-model quality.\n- Chunking, document deduplication, metadata filters and ACL filtering can dominate end-to-end retrieval quality even when the embedding model itself is unchanged.\n- Score distributions can shift across model revisions, languages and corpora; fixed score thresholds require recalibration.\n- Query/document role inversion or incorrect provider task_type can create silent quality degradation without API failure.\n- Multilingual benchmark strength does not prove parity for a specific low-resource language/domain."
    },
    {
      "heading": "AVAILABILITY_GATES",
      "text": "- Provider/account/region/model availability and retirement status.\n- API/model revision and allowed input types/lengths.\n- Embedding dimension and any supported dimension-reduction parameter.\n- Task/query/document mode semantics.\n- Reranker candidate/document limits and request-size limits.\n- Vector-store support for dimension, metric, filtering and index type.\n- Data residency/retention/training terms for externally hosted embedding/reranking APIs.\n- Cost/throughput quotas for bulk re-embedding and online reranking."
    },
    {
      "heading": "IMPLEMENTATION_STATE",
      "text": "**PROPOSAL — `RETRIEVAL MODEL ARTIFACT CONTRACT`**\nPersist 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.\n\n\nRecommended 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."
    },
    {
      "heading": "BENCHMARK_OR_EVAL",
      "text": "**TEST_PROFILE (not executed in this run)**\nCreate 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.\n\n\nCompare 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.\n\n\nFor 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."
    },
    {
      "heading": "SECURITY / PRIVACY / AUDIT / COST / OPERABILITY",
      "text": "- **Security:** retrieval relevance never supersedes authorization. Preserve ACL/filter provenance and test an ACL-excluded-but-highly-relevant adversarial fixture.\n- **Privacy:** externally hosted embedding/rerank APIs may receive source text or query text; provider data-use/residency/retention terms require current verification.\n- **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.\n- **Cost:** bulk re-embedding, index duplication during migration, storage and reranking per query are distinct cost centers.\n- **Operability:** support shadow index, dual-read comparison, threshold recalibration, drift monitoring and rollback."
    },
    {
      "heading": "SAFE_WORDING_FOR_FUTURE_BOOK",
      "text": "\"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.\""
    },
    {
      "heading": "UPDATE_WORK_HANDOFF",
      "text": "1. Re-pin every commercial provider model ID, revision, region, limits, pricing and data-control terms immediately before publication; mark as PRODUCT_VOLATILE.\n2. 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.\n3. Add at least one current independent multilingual/domain retrieval evaluation beyond BEIR/MTEB if the update makes cross-language claims.\n4. For any named vector database, collect official index/filter semantics and an independent failure/operations source before making product-specific reliability claims.\n5. If the book recommends a reranker threshold, require corpus-specific calibration evidence; no universal threshold is established here."
    },
    {
      "heading": "OPEN_UNKNOWN",
      "text": "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.\n\n\nSTOP_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.\n\n---"
    },
    {
      "heading": "AUDITED_CURRENTNESS_BOUNDARY",
      "text": "Current embedding model IDs/dimensions/pricing/compatibility remain PRODUCT_VOLATILE and benchmark results remain workload dependent."
    }
  ],
  "human_url": "/tools/ea-082-embedding-reranker",
  "markdown_url": "/agent/article.md?path=%2Ftools%2Fea-082-embedding-reranker",
  "json_url": "/agent/article.json?path=%2Ftools%2Fea-082-embedding-reranker"
}