Amazon Kendra 踩坑记录：企业级搜索部署的实际体感
最核心的痛点在于，Kendra 不是简单的关键词匹配，它走的是语义搜索。比如你搜“怎么报销差旅费”，它能把标题是《员工福利手册》但内容包含报销流程的文档给拎出来。但在实操中，如果你对索引配置不精细，检索结果的噪声会非常大。
部署时的关键配置与踩坑细节
在配置 Data Source 时，很多人会直接点默认，结果发现索引速度慢得离谱且结果不准。这里分享一个我实测后的配置建议：
一、关于文档解析的坑
Kendra 对 PDF 的解析能力很强，但如果你的文档包含大量扫描件（非可编辑文本），必须开启 OCR 功能。但我发现开启 OCR 后，索引单个 10MB 文件的处理时间从几秒钟延长到了 30 秒以上。如果文档量级在万篇以上，这个时间成本必须预留出来。
二、权限同步的逻辑陷阱
这是最容易翻车的地方。如果你连接 S3 桶，Kendra 默认会尝试同步 ACL（访问控制列表）。如果你的 S3 对象权限配置不规范，会导致前端搜索结果为空，或者出现权限越权。建议在测试阶段先将 Permissioning 设置为 None，确认能搜到内容后，再针对具体用户组配置具体的权限映射。
三、实测性能数据
我测试了一组包含 500 份技术文档（平均每份 5 页）的知识库，实测响应表现如下：
- 索引构建时间： 约 12 分钟（包含元数据提取）。
- 检索响应延迟： 语义搜索请求的端到端响应时间在 450ms 到 800ms 之间，波动较大，取决于查询词的复杂度。
- 准确率： 针对长尾问题的 Top 3 召回率大约在 70% 左右，但一旦涉及极专业的行业缩写，如果没有配置自定义词典（Custom Thesaurus），召回率会掉到 30% 以下。
针对特定场景的配置示例
为了提高检索精度，我通过配置自定义词典解决了专业术语识别问题。如果你在企业内部有大量缩写，必须手动映射，否则 AI 根本理解不了。
[
{
"term": "K8s",
"synonyms": ["Kubernetes", "容器编排", "集群管理"]
},
{
"term": "RAG",
"synonyms": ["检索增强生成", "Retrieval Augmented Generation"]
}
]将上述 JSON 导入到 Kendra 的 Custom Thesaurus 中后，搜“K8s”能精准命中所有包含“Kubernetes”的文档，这比单纯依赖模型自带的语义理解要稳得多。
现在的处境与选择
现在一个比较尴尬的点是，Kendra 对新客户的准入门槛在变，甚至有些服务在逐步调整方向。如果你现在是从零开始搭建企业知识库，除了关注 Kendra，其实可以对比一下通过 Bedrock 配合 OpenSearch Serverless 搭建的方案。
Kendra 的优势在于它把文档解析、索引构建、语义检索全给包圆了，你不需要写复杂的 Embedding 逻辑。但代价是成本极高，且灵活性不如自建工作流。对于追求快速上线、不差钱、且文档格式极其混乱的企业来说，它依然是目前最省心的方案。
