LLLMWIKI
ArticleMetadataMain page

Question · Updated 2026-07-14

细粒度图文对齐如何兼顾索引效率？

#near-cvpr-2025#multimodal#vision-language#representation-learning#survey-needed

Open question

细粒度图文对齐如何兼顾索引效率？

This question remains open and needs new primary evidence.

Next evidence need

7Candidate sources1Related topics
View evidence paths →

问题

patch/token 级对齐、cross-encoder 精排和多向量 late interaction 能否在真实图库/文档库中带来稳定收益，并把额外存储、候选打分和延迟控制在可接受范围？

为什么还没有解决

FILIP、ALBEF 和 ColPali 使用不同的交互粒度与任务域，不能直接比较；论文中的 benchmark 结果也很少同时报告同规模图库下的索引大小、吞吐、峰值显存和端到端延迟。

什么证据会有帮助

  • 同一 backbone、同一图库和同一候选数下的单向量/多向量/cross-encoder 对照。
  • 关系、属性、局部 OCR/布局等可定位 query 的分层评测。
  • 量化、token 剪枝、候选重排和失败案例可视化。
  • 在视觉信息真正重要与文字占主导的页面上分别评估；MIRACL-VISION 的反方结果要求明确报告 OCR-only 与文本 embedding。

相关页面

Metadata
{
  "id": "question-image-text-retrieval-fine-grained-alignment",
  "type": "question",
  "title": "细粒度图文对齐如何兼顾索引效率？",
  "status": "open",
  "created": "2026-07-14",
  "updated": "2026-07-14",
  "tags": [
    "near-cvpr-2025",
    "multimodal",
    "vision-language",
    "representation-learning",
    "survey-needed"
  ],
  "question_status": "open",
  "priority": "high",
  "related_topics": [
    "topics/image-text-retrieval"
  ],
  "related_entities": [
    "entities/clip",
    "entities/colpali"
  ],
  "candidate_sources": [
    "sources/2026-07-14-filip",
    "sources/2026-07-14-albef",
    "sources/2026-07-14-colpali",
    "sources/2026-07-14-msrm",
    "sources/2026-07-14-cprd",
    "sources/2026-07-14-visrag",
    "sources/2026-07-14-miracl-vision"
  ]
}