Amazon Kendra 不再向新客户开放。要了解与类似的功能 Amazon Kendra，请浏览亚马逊基岩知识库。[了解更多](https://docs.aws.amazon.com/kendra/latest/dg/kendra-availability-change.html)。 本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # Amazon Kendra   可用性变更 ## 概述 经过仔细考虑，我们决定 Amazon Kendra 进入维护模式，自 2026 年 6 月 30 日起生效。截至该日期，该服务没有新的功能或能力开发，并且自2026年7月30日起，该服务不再向新客户开放。 在维护模式下，该服务 AWS 将得到全面支持，并将继续为现有客户提供错误修复和安全更新，但是将不再考虑新功能请求。 我们建议客户迁移其 Kendra 应用程序并在 Amazon Bedrock 管理知识库 (BMKB) 上实施任何新的搜索应用程序，以获得与 Kendra 相似的功能，并为生成式 AI 和代理人工智能用例提供更高级的功能。Bedrock Managed Knowledge Base 是一个完全托管的 RAG 解决方案，具有内置连接器、智能解析、带混合搜索的托管向量存储，以及生成响应（使用检索和生成 API）和跨多个知识库进行多步推理的能力（使用代理检索 API）。BMKB 还使您能够调整分块策略和嵌入模型以针对您的特定应用程序进行优化，还可以选择生成响应的基础模型。这种全新的功能和灵活性带来了可预测的成本，具体取决于摄取的知识库的规模、执行的查询数量和 LLM 的使用情况。 ## 迁移指南 对于大多数企业搜索和 RAG 工作负载，只要进行一些仔细的规划，就可以实现从 Amazon Kendra 亚马逊基岩管理知识库 (BMKB) 的迁移。并非所有 Kendra 功能都可直接在 Bedrock 管理知识库中获得，但许多功能可以通过变通办法实现。本指南为现有 Kendra 客户提供了全面的分步迁移路径，帮助他们将其应用程序过渡到 BMKB，包括架构映射、API 转换、代码示例、功能差距分析和推荐的变通方法。 ### 亚马逊 Bedrock 托管知识库功能 BMKB 端到端地管理整个 RAG 管道。它支持嵌入模型，包括亚马逊 Titan 文本嵌入 V2、Cohere Embed English v3、Cohere Embed 多语言 v3、Cohere Embed v4 和亚马逊 Nova 多模态嵌入——所有模型都固定在 1024 维度上，使用 float32 向量。托管向量存储完全由 Bedrock 运营，无需预置或管理 OpenSearch Aurora 或其他矢量数据库。分块策略包括默认（固定大小约为 300 个令牌）、 Fixed-size （可配置的最大令牌和重叠百分比）、分层（具有关卡配置的父子）和无分块；托管知识库不支持语义分块。 BMKB 目前支持七个数据源连接器：亚马逊 S3、Confluence、微软、网络爬虫 SharePoint、谷歌云端硬盘 OneDrive、微软和自定义连接器。该服务始终执行混合搜索（关键字加语义），不提供纯语义搜索模式。 **两者之间的架构比较 Amazon Kendra 和 Bedrock 管理知识库** | 功能 | Kendra | 基岩管理知识库 | | --- | --- | --- | | 原生连接器 | 32 个以上的连接器 | 7 个连接器 | | 嵌入 | 内部管理 | Customer-selectable （泰坦 V2、Cohere、Nova） | | 矢量存储 | 内部管理 | 由 Bedrock 完全管理 | | 搜索类型 | 关键字、语义或混合词 | 混合（关键字 \+ 语义） | | RAG 支持 | 需要外部 LLM 集成 | 原生 RetrieveAndGenerate API | | 代理检索 | 不可用 | 原生多重迭代检索 | | 最大结果 | 100 个段落（检索 API） | 100 个结果（检索 API） | ## 迁移步骤 ### 亚马逊 Bedrock 托管知识库设置 #### 步骤 1：配置 IAM 角色 创建一个 IAM 角色以授予 Bedrock 访问您的数据源和调用嵌入模型的权限。信任策略必须允许 bedrock.amazonaws.com 代入该角色，并且权限策略必须包括对您的 S3 存储桶和所选嵌入模型的访问权限。 IAM 配置（Python 代码）： ``` import boto3 import json iam = boto3.client('iam') trust_policy = { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": {"Service": "bedrock.amazonaws.com"}, "Action": "sts:AssumeRole" }] } iam.create_role( RoleName="BedrockKBRole", AssumeRolePolicyDocument=json.dumps(trust_policy), Description="Role for Bedrock Managed Knowledge Base" ) permissions_policy = { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:GetObject", "s3:ListBucket"], "Resource": [ "arn:aws:s3:::your-bucket-name", "arn:aws:s3:::your-bucket-name/*" ] }, { "Effect": "Allow", "Action": ["bedrock:InvokeModel"], "Resource": ["arn:aws:bedrock:*::foundation-model/amazon.titan-embed-text-v2:0"] } ] } iam.put_role_policy( RoleName="BedrockKBRole", PolicyName="BedrockKBPermissions", PolicyDocument=json.dumps(permissions_policy) ) ``` #### 步骤 2：创建托管知识库 使用类型为 MANAGED CreateKnowledgeBase 的 API 来创建知识库： ``` import boto3 bedrock_agent = boto3.client("bedrock-agent", region_name="us-east-1") response = bedrock_agent.create_knowledge_base( name="my-managed-kb", description="Migrated from Kendra index", roleArn="arn:aws:iam::123456789012:role/BedrockKBRole", knowledgeBaseConfiguration={ "type": "MANAGED", "managedKnowledgeBaseConfiguration": { "embeddingModelArn": "arn:aws:bedrock:us-east-1::foundation-model/amazon.titan-embed-text-v2:0", "embeddingModelConfiguration": { "bedrockEmbeddingModelConfiguration": { "embeddingDataType": "FLOAT32" } } } } ) kb_id = response["knowledgeBase"]["knowledgeBaseId"] print(f"Created knowledge base: {kb_id}") ``` #### 步骤 3：配置数据源 使用托管连接器配置创建 S3 数据源： ``` response = bedrock_agent.create_data_source( knowledgeBaseId=kb_id, name="my-s3-data-source", description="Product documentation from S3", dataSourceConfiguration={ "type": "MANAGED_KNOWLEDGE_BASE_CONNECTOR", "managedKnowledgeBaseConnectorConfiguration": { "connectorParameters": { "type": "S3", "version": "1", "connectionConfiguration": { "bucketName": "your-bucket-name", "bucketOwnerAccountId": "123456789012" }, "filterConfiguration": { "inclusionPrefixes": ["documents/"] } } } }, vectorIngestionConfiguration={ "parsingConfiguration": { "parsingStrategy": "SMART_PARSING" } } ) data_source_id = response["dataSource"]["dataSourceId"] print(f"Created data source: {data_source_id}") ``` **注意** CreateDataSource 托管知识库是异步的。数据源状态从 “正在创建” 转换为 “可用”，通常在 2-5 分钟内。在状态为 “可用” 之前，请勿继续摄取。 #### 第 4 步：启动并监控摄取 触发文档摄取和轮询以完成操作： ``` import time ingestion_response = bedrock_agent.start_ingestion_job( knowledgeBaseId=kb_id, dataSourceId=data_source_id, description="Initial ingestion" ) ingestion_job_id = ingestion_response["ingestionJob"]["ingestionJobId"] print(f"Started ingestion job: {ingestion_job_id}") while True: job_response = bedrock_agent.get_ingestion_job( knowledgeBaseId=kb_id, dataSourceId=data_source_id, ingestionJobId=ingestion_job_id ) job = job_response["ingestionJob"] status = job["status"] stats = job.get("statistics", {}) print(f"Status: {status} | Scanned: {stats.get('numberOfDocumentsScanned', 0)} | " f"Indexed: {stats.get('numberOfNewDocumentsIndexed', 0)} | " f"Failed: {stats.get('numberOfDocumentsFailed', 0)}") if status == "COMPLETE": print("Ingestion complete!") break elif status in ("FAILED", "STOPPED"): print(f"Ingestion {status}: {job.get('failureReasons', [])}") break time.sleep(30) ``` ## API 迁移映射和代码示例 ### API 操作映射 **从 Kendra 到 BMKB 的 API 操作映射** | 操作 | 肯德拉 API | BMKB API | 客户端 | | --- | --- | --- | --- | | 创建 index/KB | kendra.create\_index () | 基岩代理.create\_knowledge\_base () | 肯德拉 → 基岩特工 | | 添加数据源 | kendra.create\_data\_source（类型= “S3”） | bedrock-agent.create\_data\_source () | 肯德拉 → 基岩特工 | | Sync/ingest 文档 | kendra.start\_data\_source\_sync\_job () | bedrock-agent.start\_ingestion\_job () | 肯德拉 → 基岩特工 | | 批量添加文档 | kendra.batch\_put\_document () | 不直接支持（使用 S3 上传 \+ 提取） | 肯德拉 → S3 \+ 基岩代理 | | 检索段落 | kendra.retrieve (=...) QueryText | bedrock-agent-runtime.retrieve () | 肯德拉 → 基岩代理运行时 | | 使用过滤器搜索 | AttributeFilter: {"EqualsTo": {...}} | 过滤器：{“等于”：{...}} | 相同的模式，不同的语法 | | RAG 生成 | N/A （需要外部 LLM） | bedrock-agent-runtime.retrieve\_and\_generate () | 新能力 | ### 迁移检索 API 之前（肯德拉）： ``` kendra_client = boto3.client("kendra") response = kendra_client.retrieve( IndexId="your-kendra-index-id", QueryText="How do I configure VPC endpoints?", AttributeFilter={ "EqualsTo": { "Key": "_category", "Value": {"StringValue": "networking"} } }, PageSize=10 ) for item in response["ResultItems"]: print(item["DocumentTitle"]) print(item["Content"]) ``` 之后（BMKB）： ``` bedrock_runtime = boto3.client("bedrock-agent-runtime", region_name="us-east-1") response = bedrock_runtime.retrieve( knowledgeBaseId="your-kb-id", retrievalQuery={ "text": "How do I configure VPC endpoints?" }, retrievalConfiguration={ "managedSearchConfiguration": { "numberOfResults": 10, "filter": { "equals": { "key": "category", "value": "networking" } } } } ) for result in response["retrievalResults"]: print(f"Score: {result['score']}") print(f"Content: {result['content']['text']}") print(f"Source: {result['location']['s3Location']['uri']}") ``` 主要区别在于：查询文本从顶级参数移动到嵌套检索Query.text 字段；在托管中 AttributeFilter 变为筛选器SearchConfiguration；结果包括相关性分数字段。 ### 用 RetrieveAndGenerate 于 RAG BMKB 提供了原生 RAG 功能，无需在检索后单独调用 LLM： ``` response = bedrock_runtime.retrieve_and_generate( input={ "text": "Explain how to configure VPC endpoints for S3 access" }, retrieveAndGenerateConfiguration={ "type": "KNOWLEDGE_BASE", "knowledgeBaseConfiguration": { "knowledgeBaseId": "your-kb-id", "modelArn": "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-sonnet-20240229-v1:0", "retrievalConfiguration": { "managedSearchConfiguration": { "numberOfResults": 5 } } } } ) # Generated answer with citations print(response["output"]["text"]) # Source citations for citation in response.get("citations", []): for ref in citation.get("retrievedReferences", []): print(f"Source: {ref['location']['s3Location']['uri']}") ``` 此 API 返回生成的自然语言响应以及指向源文档的引文，提供 Kendra 本机未提供的内置 RAG。 ### 元数据过滤器语法翻译 **元数据过滤器运算符映射** | 肯德拉 AttributeFilter | BMKB 过滤器 | 注意 | | --- | --- | --- | | EqualsTo | equals | 直接映射 | | ContainsAll | 输入（部分） | BMKB 使用套装成员资格 | | ContainsAny | in | 直接映射 | | GreaterThan | greaterThan | 直接映射 | | LessThan | lessThan | 直接映射 | | GreaterThanOrEquals | 更大 ThanOrEquals | 直接映射 | | LessThanOrEquals | 更少 ThanOrEquals | 直接映射 | | NotFilter | notIn/noteQuals | 使用适当的否定词 | | AndAllFilters | andAll | 直接映射 | | OrAllFilters | orAll | 直接映射 | **注意** BMKB 不支持托管知识库的 startsWith 或 stringContains 运算符。如果您的 Kendra 应用程序在过滤器中使用通配符或子字符串匹配，则需要重构元数据架构，改为使用完全匹配或集成员资格模式。 ## 功能差距和变通方法 并非所有 Kendra 功能都在 BMKB 中可用。查询建议、分面搜索、自定义同义词、拼写检查、增量学习和文档丰富是需要在 BMKB 中变通的功能。本节讨论这些变通方法。 **查询建议（自动完成）** Kendra 提供的 GetQuerySuggestions API 可根据索引文档词汇返回自动填充建议。BMKB 目前不提供此功能。 **解决办法：使用带有内置建议器功能的亚马逊 OpenSearch 服务**实现自定义自动填充层，或使用 LLM-based 查询完成服务。在检索之前，您还可以利用 Bedrock Agents 重新制定部分查询。一种实用的方法是维护从文档语料库中提取的常见查询术语的单独 OpenSearch 索引，并在调用 BMKB 检索之前从前端调用其建议 API。 **分面搜索 ** Kendra 通过查询 API 中的 Facets 参数支持文档属性构面，每个方面最多显示 10 个分面值以及文档数量。BMKB 的架构不支持分面搜索。 **解决办法：使用元数据筛选**模拟分面导航。在.metadata.json 边车文件中使用结构化元数据属性（部门、作者、文档类型、日期范围）标记文档。根据已知的元数据架构在应用程序界面中显示筛选器选项，并在查询时应用相应的过滤器运算符。虽然这不提供动态刻面数，但它使用户能够按类别缩小结果范围： ``` # Simulating faceted search with metadata filters response = bedrock_runtime.retrieve( knowledgeBaseId="your-kb-id", retrievalQuery={"text": "security best practices"}, retrievalConfiguration={ "managedSearchConfiguration": { "numberOfResults": 10, "filter": { "andAll": [ {"equals": {"key": "department", "value": "engineering"}}, {"equals": {"key": "doc_type", "value": "policy"}} ] } } } ) ``` **自定义同义词 ** Kendra 允许创建特定业务术语的自定义映射，这些术语映射到其他术语，以便通过同义词库文件匹配搜索结果。BMKB 目前不支持自定义同义词。 **解决方法：在 BMKB 查询前面**构建轻量级同义词扩展服务： + 维护现有的 Kendra 同义词库文件（或中的同义词词典） DynamoDB/S3 + 在调用 BMKB 检索或 RetrieveAndGenerate API 之前，通过附加匹配的同义词来扩展用户的查询 + 示例：如果用户查询 “DNS 问题”，则您的应用程序会在发送到 BMKB 之前将其重写为 “DNS Route53 问题” 这特别有效，因为 BMKB 始终使用混合搜索（关键字 \+ 语义），因此在查询文本中添加同义词将在关键字和语义维度上都匹配。 **拼写检查 ** Kendra通过索引文档词汇表提供自动拼写更正. SpellCorrectionConfiguration BMKB 目前不支持拼写检查。 **解决办法：在向 BMKB 发送查询之前**添加预处理层。使用调用拼写更正库（例如 SymSpell 或 TextBlob）或调用 LLM 进行查询更正的 L AWS ambda 函数： ``` import boto3 lambda_client = boto3.client("lambda") def correct_and_retrieve(query_text, kb_id): # Step 1: Spell-correct the query using a Lambda function correction_response = lambda_client.invoke( FunctionName="spell-correction-function", Payload=json.dumps({"query": query_text}) ) corrected_query = json.loads(correction_response["Payload"].read())["corrected"] # Step 2: Query BMKB with corrected text bedrock_runtime = boto3.client("bedrock-agent-runtime") return bedrock_runtime.retrieve( knowledgeBaseId=kb_id, retrievalQuery={"text": corrected_query}, retrievalConfiguration={"managedSearchConfiguration": {"numberOfResults": 5}} ) ``` **增量学习 ** Kendra 支持点击信号和相关性反馈 SubmitFeedback 的 API，以随着时间的推移提高排名。BMKB 不提供此功能。 **解决方法：**使用 BMKB 的重新排名模型来提高查询时的相关性。建立一个自定义反馈回路，将用户点击和评分信号存储在外部数据存储（例如 DynamoDB）中，并使用这些信号来调整元数据提升权重或重新排列参数。为了进行长期改进，可以考虑根据收集的相关性反馈定期微调您的嵌入模型。 **自定义文档充实 ** Kendra 支持提取前和提取后的 Lambda 挂钩，可在摄取期间操作文档内容和元数据。BMKB 使用智能解析进行文档处理，但不提供等效的 Lambda 挂钩。 **解决办法：使用 AWS 步进函数或 Lambda ** 实现预处理管道，在将文档放入 S3 中进行 BMKB 提取之前对其进行转换。该管道可以在文档到达 BMKB 数据源存储桶之前执行内容提取、元数据丰富、个人身份信息编辑或格式转换。 ## 数据源迁移策略 ### 连接器覆盖差距 Kendra 支持 32 个本机连接器，而 BMKB 支持 7 个。对于 BMKB 不直接支持的数据源，推荐的方法是将内容导出到 Amazon S3 并在 BMKB 中配置 S3 数据源。 **不支持的连接器的迁移模式：**创建自动管道（使用 AWS Lambda、Step Functions 或 Amazon S EventBridge cheduler），该管道通过其 API 定期从源系统提取内容，使用适当的元数据 JSON 边车文件将文档写入到 S3 存储桶，并触发 BMKB 摄取任务。这复制了 Kendra 连接器的定期同步行为。 ### 元数据迁移 必须将 Kendra 文档属性转换为 BMKB 元数据格式。在 Kendra 中，属性在索引级别定义，并在摄取期间附加到文档中。在 BMKB 中，元数据是通过与源文档一起存储在 S3 中的.metadata.json 边车文件定义的，每个文件的最大大小为 10 KB。每个属性都必须键入为字符串、数字或布尔值。 ### 分块策略选择 从 Kendra（内部处理分块）迁移时，必须明确为 BMKB 选择分块策略。对于大多数迁移方案，具有 200 个代币和 30% 重叠的 Fixed-size策略提供了一个很好的起点。如果您的文档具有清晰的分层结构（章节、章节、小节），请考虑采用分层分块来改善对大背景和特定细节的检索。 ## 测试和验证 要评估性能，请同时运行 Kendra 和 BMKB。向这两个服务发送相同的查询，并使用以下维度比较结果：相关性质量（由 NDCG 或 MRR 对照黄金测试集衡量）、延迟（p50、p95、p99 响应时间）、吞吐量（负载下每秒的查询次数）和完整性（检索到的预期文档的百分比）。 创建评估检索质量的测试工具： ``` def compare_retrieval(query, kendra_index_id, bmkb_kb_id): # Query Kendra kendra_results = kendra_client.retrieve( IndexId=kendra_index_id, QueryText=query, PageSize=10 ) # Query BMKB bmkb_results = bedrock_runtime.retrieve( knowledgeBaseId=bmkb_kb_id, retrievalQuery={"text": query}, retrievalConfiguration={ "managedSearchConfiguration": {"numberOfResults": 10} } ) # Compare overlap in top-10 results kendra_docs = {r["DocumentId"] for r in kendra_results["ResultItems"]} bmkb_docs = {r["location"]["s3Location"]["uri"] for r in bmkb_results["retrievalResults"]} overlap = len(kendra_docs.intersection(bmkb_docs)) print(f"Query: {query}") print(f"Result overlap: {overlap}/10 documents in common") return overlap ``` 在将生产流量切换到 BMKB 之前，请验证以下几点：所有数据源均已摄取且处于最新状态，没有失效的文档；元数据过滤器为所有应用程序筛选模式生成预期结果；访问控制变通办法正确限制未经授权的访问；相关性基准达到或超过 Kendra 基准质量；应用程序错误处理正确处理 BMKB 响应格式；监控和警报配置为 BMKB API 错误和延迟。 ## Summary 从 Amazon Kendra Bedrock 托管知识库迁移主要需要做两项工作：将数据源重新摄入到 BMKB 中，以及重写应用程序代码以使用 BMKB API。虽然 BMKB 引入了包括 RetrieveAndGenerate 代理检索在内的强大 RAG-native 功能，但使用分面、查询建议、自定义同义词和增量学习等企业搜索功能的客户将需要实施本指南中描述的变通方法。 如[有任何其他问题，请联系客](https://console.aws.amazon.com/support)AWS 服。