接口介绍
本接口（/deepsearch/v1/deep_search）提供端到端的 DeepSearch 检索服务，其完整流程包括：查询预处理、相似性检索、模型重排序（Rerank）以及基于 LLM 的评估与迭代。
说明：
DeepSearch 每秒最多能处理10,000个 token，涵盖了 Embedding（向量化）、LLM（大语言模型生成）和 Rerank（重排序）三个核心组件的消耗。
Method 与 URL
POST https://{服务访问地址}/deepsearch/v1/deep_search使用示例
Authorization：配置 DeepSearch 访问密钥。
x-tdai-service-id：配置 DeepSearch ID。
curl -i -k -X POST \\-H 'Content-Type: application/json' \\-H 'Authorization: Bearer *****************************************' \\-H "x-tdai-service-id: tdai-dps-9f3w****" \\https://deepsearch.tdai.tencentyun.com/deepsearch/v1/deep_search \\-d '{"database": "dps_test_db","collection": "dps_test_coll","search": {"query": "怎么配置向量数据库的数据自动删除","query_preprocessing": {"method": "sub_query_split"},"retrieval_config": {"mode": "dense","limit": 3,"retrieval_params": {"ef": 200}},"rerank": {"rerank_model": "bge-reranker-large"},"evaluate_config": {"max_iterations": 3},"limit": 3,"return_execution_details": true}}'
请求参数
参数（一级） | 参数（二级） | 参数（三级） | 是否必选 | 参数含义 | 配置方法及要求 |
database | - | - | 是 | 指定 DeepSearch 检索所关联的向量数据库名称。 | 在控制台关联的向量数据库。 |
collection | - | - | 是 | 指定 DeepSearch 检索的向量数据库的集合名称。 | 所关联向量数据库中已经创建好的向量集合。 |
search | query | - | 是 | 用户传入的自然语言问题。 | 数据类型：String。 |
| query_preprocessing | method | 否 | 指定输入问题的预处理方法。 | 当前仅支持指定为 sub_query_split，表示系统会使用 LLM 将复杂的主查询语句拆解为多个更易回答的子问题，并行检索后再合并结果，以提高复杂问题的检索效果。 |
| retrieval_config | embedding_model | 否 | 指定用于检索的向量化模型。 说明： 如果创建集合时已经绑定了模型，则以集合配置为准，此处的指定会被忽略。 | 您需根据业务的语言类型、数据维度要求等综合选择合适的模型。取值如下所示： bge-large-zh-v1.5：适用中文，1024维，推荐使用。 bge-base-zh-v1.5：适用中文，768维。 bge-large-zh：适用中文，1024维。 bge-base-zh：适用中文，768维。 m3e-base：适用中文，768维。 e5-large-v2：适用英文，1024维。 text2vec-large-chinese：适用中文，1024维。 multilingual-e5-base：适用于多种语言类型，768维。 BAAI/bge-m3：适用于多种语言类型，1024维。 |
| | text_field | 否 | 指定向量数据库集合中所检索的文本字段。 | 以向量数据库集合中配置的文本字段为准。 |
| | mode | 否 | 指定检索模式。 | 支持如下检索模式。 dense：单路稠密型向量检索。默认为：dense。 sparse：单路稀疏型向量检索。 hybrid：稠密向量与稀疏向量两路混合检索。 |
| | fusion_mode | 否 | 若 mode 为 hybrid，则需指定混合检索的重排序（rerank）的方式。 | 支持的重排序（rerank）方式如下所示。 weighted：基于稠密向量与稀疏向量的加权组合来进行排序。 dense_weight：指定稠密向量的权重。例如，0.9。 sparse_vector：指定稀疏向量的权重。例如，0.1。 rrf：一种融合稠密向量与稀疏向量各自相关性评分体系的检索结果排序算法。参数 k 是一个平滑因子，主要用于调节低排名文档对最终结果的影响程度。默认值为60。 |
| | params | 否 | 指定向量数据库集合索引类型所对应的检索参数。 | FLAT ：无需指定参数。 HNSW 类型：需配置参数 ef，指定需要访问向量的数目。取值范围[1,32768]，默认为10。 IVF 系列：需设置参数 nprobe ，指定所需查询的单位数量。取值范围[1,nlist]，其中 nlist 在创建 Collection 时已设置。 |
| | limit | 否 | 指定检索向量数据库返回的最大数量。 | 默认值：最终返回数量 Limit 的三倍。 最大值：100。 取值：向量数据库检索返回的数量与最终 DeepSearch 检索返回的数量，二者取较大者作为实际取值。 |
| rerank | rerank_model | 否 | 指定重排序配置模型。 | 当前仅支持 bge-reranker-large 模型，评估检索出来的结果和原始问题的关联程度去做重排序。 |
| evaluate_config | max_iterations | 否 | 指定多轮计算的次数。 | 正整数，最小值为1，最大值为5。 |
| limit | - | 是 | 最终返回的文档数量。 | 正整数，取值范围[1,10]。 |
| filter | - | 否 | 设置检索的过滤条件。 | |
| output_fields | - | 否 | 指定返回结果中应包含哪些字段。 | 返回字段为所检索的向量数据库集合中的的字段。 |
| return_execution_details | - | 否 | 指定是否返回检索过程信息。 | false：不返回检索过程。默认 false。 true：返回检索过程。 |
响应示例
{"code": 0,"message": "operation success","documents": [{"id": "1415908106070560773","score": 0.98535156,"chunk_num": 2,"file_name": "VDB TTL.md","section_num": 2,"text": "## 适用场景\\n\\n某些业务场景下，业务数据的增长很快，并且业务数据的热度随着时间推移会有明显的降低，可以使用 TTL 将热度降低的数据在特定的过期时间时自动清理。例如：在电子商务平台中，用户搜索和浏览行为产生的向量数据，如点击流和用户偏好向量，通常具有很高的时效性。这些数据在短期内对于个性化推荐至关重要，但随着时间的推移，其相关性会迅速降低。在向量数据库集合中，设置TTL，便会自动删除过时的用户行为数据，确保推荐系统能够基于最新的用户互动提供实时、相关的推荐，从而提升用户体验和业务效率。\\n\\n"},{"id": "1415908106070560772","score": 0.46704102,"chunk_num": 1,"file_name": "VDB TTL.md","section_num": 1,"text": "## 功能介绍\\n\\nTTL（Time to Live，生存周期）功能，指数据项从创建或更新后开始，到自动被系统删除的时间期限。在创建数据库集合时，通过为文档设置TTL，数据库能够自动清理过期的数据，从而优化存储空间的使用，保持数据的时效性，并确保查询结果的准确性，特别是在数据具有时效性要求的场景中，如实时推荐系统等。\\n\\n"},{"id": "1415908205789741090","score": 0.07116699,"chunk_num": 1,"file_name": "VDB备份&恢复技术方案.pdf","section_num": 1,"text": "# 向量数据库备份&恢复技术方案\\n\\n## 使用场景\\n\\n主要有以下两个场景：\\n\\n数据安全是云上数据库产品的生命线，备份回档作为保障数据安全的核心能力，是云上数据库产品的基本功能，提供后也能够为客户误操作导1.\\n\\n致的数据丢失、数据错乱等现象提供兜底。\\n\\n部分客户存在克隆数据到新实例的需求。2.\\n\\n具体到某个场景\\n\\n在数据库出现性能问题或故障时，离线备份提供了一种安全且可控的方式来排查问题。通过将数据库实例迁移到新的节点，可问题排查与性能验证：1.\\n\\n以在不影响生产环境的情况下进行详细的性能分析和故障排查。\\n\\n定期进行离线备份是防止数据丢失的关键措施。"}],"execution_details": {"original_query": "怎么配置向量数据库的数据自动删除","total_iterations": 2,"max_iterations": 3,"iterations": [{"iteration_no": 1,"query_processing": {"method": "sub_query_split","input_query": "怎么配置向量数据库的数据自动删除","sub_queries": [{"query": "向量数据库支持哪些数据自动删除机制","purpose": "识别实体与核心功能"},{"query": "常见向量数据库（如Milvus、Pinecone、Weaviate）如何配置自动删除策略","purpose": "获取具体产品的配置方法"},{"query": "配置向量数据库自动删除策略时的注意事项与最佳实践","purpose": "补充操作细节与限制条件"}],"token_usage": 351},"retrieval": {"mode": "dense","sub_query_results": [{"query": "向量数据库支持哪些数据自动删除机制","retrieved_docs": 3,"top_docs": ["1415908110847873059","1415908107303686148","1415908205789741090"],"top_doc_texts": [" | [TTL](https://cloud.tencent.com/document/product/****) | \\nSDK 功能更新 | Python、GO、Java SDK 支持对 Database、Collection 的存在判断。 | - | \\n\\n\\n\\n","腾讯云向量数据库提供数据备份与回档服务，支持预设备份时间点并周期性执行主动备份，同时允许随时手动触发即时备份操作；所有备份均以高可靠快照形式存储，通过实例克隆功能可实现数据回档，恢复业务状态。\\n\\n> **说明：**\\n> \\n\\n> V2.4 版本起，支持产品化的备份克隆功能，若需要使用该功能，请 [提交工单](https://console.cloud.tencent.com/workorder/category) 升级实例版本。\\n> \\n\\n\\n","# 向量数据库备份&恢复技术方案\\n\\n## 使用场景\\n\\n主要有以下两个场景：\\n\\n数据安全是云上数据库产品的生命线，备份回档作为保障数据安全的核心能力，是云上数据库产品的基本功能，提供后也能够为客户误操作导1.\\n\\n致的数据丢失、数据错乱等现象提供兜底。\\n\\n部分客户存在克隆数据到新实例的需求。2.\\n\\n具体到某个场景\\n\\n在数据库出现性能问题或故障时，离线备份提供了一种安全且可控的方式来排查问题。通过将数据库实例迁移到新的节点，可问题排查与性能验证：1.\\n\\n以在不影响生产环境的情况下进行详细的性能分析和故障排查。\\n\\n定期进行离线备份是防止数据丢失的关键措施。"],"avg_score": 347.1428629557292},{"query": "常见向量数据库（如Milvus、Pinecone、Weaviate）如何配置自动删除策略","retrieved_docs": 3,"top_docs": ["1415908110847873053","1415908205789741090","1415908205789741091"],"top_doc_texts": ["综合体验提升特性 | - 索引参数修改 modifyVectorIndex，可修改原数据表的向量索引参数，降低重新建表并导入数据的成本。注意：这里修改索引参数后会自动发生一次 Rebuild Index。 | - 支持 Count，返回 Collection 所有的文档数量或满足 Filter条件的文档数量。 | - Delete 支持 Limit，单次删除的速度非常快，同时很好地控制对数据库业务影响。如果您的业务中需要删除海量数据，可以循环通过 Limit 删除配合 affectedCount 返回值来达到效果。","# 向量数据库备份&恢复技术方案\\n\\n## 使用场景\\n\\n主要有以下两个场景：\\n\\n数据安全是云上数据库产品的生命线，备份回档作为保障数据安全的核心能力，是云上数据库产品的基本功能，提供后也能够为客户误操作导1.\\n\\n致的数据丢失、数据错乱等现象提供兜底。\\n\\n部分客户存在克隆数据到新实例的需求。2.\\n\\n具体到某个场景\\n\\n在数据库出现性能问题或故障时，离线备份提供了一种安全且可控的方式来排查问题。通过将数据库实例迁移到新的节点，可问题排查与性能验证：1.\\n\\n以在不影响生产环境的情况下进行详细的性能分析和故障排查。\\n\\n定期进行离线备份是防止数据丢失的关键措施。","通过在非工作时间进行备份，可以最大限度地减少对业务的影响，同时确保数据的定期备份与恢复：2.\\n\\n一致性和完整性。定期备份不仅提供了数据恢复的保障，还支持在发生灾难性事件时快速恢复业务运行，确保业务的连续性和数据的完整性。\\n\\n数据库归档：对于不再频繁使用的数据库，或用户欠费的实例，离线备份可以作为一种有效的归档手段。通过备份某个时间点的数据，可以在用户再3.\\n\\n次启用时快速恢复数据库，确保数据的完整性和一致性。\\n\\n"],"avg_score": 340.3140869140625},{"query": "配置向量数据库自动删除策略时的注意事项与最佳实践","retrieved_docs": 3,"top_docs": ["1415908205789741090","1415908205789741091","1415908205793935404"],"top_doc_texts": ["# 向量数据库备份&恢复技术方案\\n\\n## 使用场景\\n\\n主要有以下两个场景：\\n\\n数据安全是云上数据库产品的生命线，备份回档作为保障数据安全的核心能力，是云上数据库产品的基本功能，提供后也能够为客户误操作导1.\\n\\n致的数据丢失、数据错乱等现象提供兜底。\\n\\n部分客户存在克隆数据到新实例的需求。2.\\n\\n具体到某个场景\\n\\n在数据库出现性能问题或故障时，离线备份提供了一种安全且可控的方式来排查问题。通过将数据库实例迁移到新的节点，可问题排查与性能验证：1.\\n\\n以在不影响生产环境的情况下进行详细的性能分析和故障排查。\\n\\n定期进行离线备份是防止数据丢失的关键措施。","通过在非工作时间进行备份，可以最大限度地减少对业务的影响，同时确保数据的定期备份与恢复：2.\\n\\n一致性和完整性。定期备份不仅提供了数据恢复的保障，还支持在发生灾难性事件时快速恢复业务运行，确保业务的连续性和数据的完整性。\\n\\n数据库归档：对于不再频繁使用的数据库，或用户欠费的实例，离线备份可以作为一种有效的归档手段。通过备份某个时间点的数据，可以在用户再3.\\n\\n次启用时快速恢复数据库，确保数据的完整性和一致性。\\n\\n","\\"4 \\n<\\n<\\n \\"logid.index: \\" \\n<\\n<\\n logid.index 5 \\n<\\n<\\n \\", backup_index: \\" \\n<\\n<\\n backup_index;6 node_->leave_recover_mode();7 do_recover_events();8 }9 10 // 备份点之后且时间戳在新实例创建前的日志, 需要跳过11 if (logid.index > backup_index && timestamp < FLAGS_recover_create_timestamp) {12 continue;"],"avg_score": 343.1875406901042}],"total_retrieved_docs": 9,"token_usage": 73},"rerank": {"rerank_model": "bge-reranker-large","input_docs": 6,"output_docs": 3,"top_docs": ["1415908110847873053","1415908107303686148","1415908205789741090"],"top_doc_texts": ["综合体验提升特性 | - 索引参数修改 modifyVectorIndex，可修改原数据表的向量索引参数，降低重新建表并导入数据的成本。注意：这里修改索引参数后会自动发生一次 Rebuild Index。 | - 支持 Count，返回 Collection 所有的文档数量或满足 Filter条件的文档数量。 | - Delete 支持 Limit，单次删除的速度非常快，同时很好地控制对数据库业务影响。如果您的业务中需要删除海量数据，可以循环通过 Limit 删除配合 affectedCount 返回值来达到效果。","腾讯云向量数据库提供数据备份与回档服务，支持预设备份时间点并周期性执行主动备份，同时允许随时手动触发即时备份操作；所有备份均以高可靠快照形式存储，通过实例克隆功能可实现数据回档，恢复业务状态。\\n\\n> **说明：**\\n> \\n\\n> V2.4 版本起，支持产品化的备份克隆功能，若需要使用该功能，请 [提交工单](https://console.cloud.tencent.com/workorder/*****) 升级实例版本。\\n> \\n\\n\\n","# 向量数据库备份&恢复技术方案\\n\\n## 使用场景\\n\\n主要有以下两个场景：\\n\\n数据安全是云上数据库产品的生命线，备份回档作为保障数据安全的核心能力，是云上数据库产品的基本功能，提供后也能够为客户误操作导1.\\n\\n致的数据丢失、数据错乱等现象提供兜底。\\n\\n部分客户存在克隆数据到新实例的需求。2.\\n\\n具体到某个场景\\n\\n在数据库出现性能问题或故障时，离线备份提供了一种安全且可控的方式来排查问题。通过将数据库实例迁移到新的节点，可问题排查与性能验证：1.\\n\\n以在不影响生产环境的情况下进行详细的性能分析和故障排查。\\n\\n定期进行离线备份是防止数据丢失的关键措施。"],"token_usage": 744},"evaluation": {"evaluation_result": {"is_relevant": false,"reason": "结果仅涉及索引修改、删除功能与备份恢复机制，未提及自动删除配置方法","suggestions": {"query_refinement": "需明确向量数据库品牌或添加'自动过期/TTL'等关键词","recommended_queries": [{"query": "向量数据库TTL自动删除配置","purpose": "查找基于时间的数据自动删除功能"},{"query": "Milvus/Weaviate自动数据清理配置","purpose": "针对具体数据库系统查找自动删除方案"},{"query": "向量数据库数据生命周期管理API","purpose": "寻找通过编程接口设置自动删除的方法"}]}},"token_usage": 894}},{"iteration_no": 2,"query_processing": {"method": "sub_query_split","input_query": "怎么配置向量数据库的数据自动删除","sub_queries": [{"query": "向量数据库TTL自动删除配置","purpose": "查找基于时间的数据自动删除功能"},{"query": "Milvus/Weaviate自动数据清理配置","purpose": "针对具体数据库系统查找自动删除方案"},{"query": "向量数据库数据生命周期管理API","purpose": "寻找通过编程接口设置自动删除的方法"}],"token_usage": 0},"retrieval": {"mode": "dense","sub_query_results": [{"query": "向量数据库TTL自动删除配置","retrieved_docs": 3,"top_docs": ["1415908106070560773","1415908106070560772","1415908110847873059"],"top_doc_texts": ["## 适用场景\\n\\n某些业务场景下，业务数据的增长很快，并且业务数据的热度随着时间推移会有明显的降低，可以使用 TTL 将热度降低的数据在特定的过期时间时自动清理。例如：在电子商务平台中，用户搜索和浏览行为产生的向量数据，如点击流和用户偏好向量，通常具有很高的时效性。这些数据在短期内对于个性化推荐至关重要，但随着时间的推移，其相关性会迅速降低。在向量数据库集合中，设置TTL，便会自动删除过时的用户行为数据，确保推荐系统能够基于最新的用户互动提供实时、相关的推荐，从而提升用户体验和业务效率。\\n\\n","## 功能介绍\\n\\nTTL（Time to Live，生存周期）功能，指数据项从创建或更新后开始，到自动被系统删除的时间期限。在创建数据库集合时，通过为文档设置TTL，数据库能够自动清理过期的数据，从而优化存储空间的使用，保持数据的时效性，并确保查询结果的准确性，特别是在数据具有时效性要求的场景中，如实时推荐系统等。\\n\\n"," | [TTL](https://cloud.tencent.com/document/product/*******) | \\nSDK 功能更新 | Python、GO、Java SDK 支持对 Database、Collection 的存在判断。 | - | \\n\\n\\n\\n"],"avg_score": 353.4836018880208},{"query": "Milvus/Weaviate自动数据清理配置","retrieved_docs": 3,"top_docs": ["1415908110847873042","1415908110847873059","1415908205793935427"],"top_doc_texts": ["## 2025年4月\\n\\n**版本信息** | **动态名称** | **动态描述** | **相关文档** \\n:-: | :-: | :-: | :-: \\nV2.4 | 备份回档能力产品化（原后台功能升级） | 用户可通过控制台直观查看实例备份记录及详情。系统在保留自动备份机制的同时，新增手动即时备份触发功能，为关键业务操作提供双重保护。同步推出的实例克隆功能支持通过创建新实例实现数据快速恢复，有效提升数据恢复效率与操作准确性。 | - [备份概述](https://write.woa.com/document/174646208485576704) | - [自动备份](https://write.woa.com/document/************) | - [手动备份](https://write.woa.com/document/************) | - [克隆实例](https://write.woa.com/document/************) | - [查看备份记录](https://write.woa.com/document/************) | \\n"," | [TTL](https://cloud.tencent.com/document/product/************) | \\nSDK 功能更新 | Python、GO、Java SDK 支持对 Database、Collection 的存在判断。 | - | \\n\\n\\n\\n","|recover_from|-recover_from=172.17.**.**:****,172.17.0.**.**:****,172.17.0.**:****|from\\\\to 为 Worker 节点的 ip 值，需一一对应；Worker 节点也需要填写，因为有可能从 localdb 启动，此时需要修改 ip 为对应的新值|\\n||recover_timestamp|-recover_timestamp=1734593270132|从某个备份集恢复||\\n\\n"],"avg_score": 332.4210611979167},{"query": "向量数据库数据生命周期管理API","retrieved_docs": 3,"top_docs": ["1415908106506768384","1415908108004134918","1415908205789741090"],"top_doc_texts": ["腾讯云向量数据库（Tencent Cloud VectorDB）作为一种专门存储和检索向量数据的服务提供给用户， 在高性能、高可用、大规模、低成本、简单易用、稳定可靠等方面体现出显著优势。 \\n\\n","腾讯云向量数据库（Tencent Cloud VectorDB）在建表时，需指定不同字段的索引类型，数据存储时将会按照指定的索引类型进行索引；在检索时，便会依据索引并使用已选择的相似性计算方法进行匹配，快速高效地获取目标数据。腾讯云向量数据库（Tencent Cloud VectorDB）支持主键索引、向量索引和 Filter 索引，各自适用于不同的查询场景。\\n\\n","# 向量数据库备份&恢复技术方案\\n\\n## 使用场景\\n\\n主要有以下两个场景：\\n\\n数据安全是云上数据库产品的生命线，备份回档作为保障数据安全的核心能力，是云上数据库产品的基本功能，提供后也能够为客户误操作导1.\\n\\n致的数据丢失、数据错乱等现象提供兜底。\\n\\n部分客户存在克隆数据到新实例的需求。2.\\n\\n具体到某个场景\\n\\n在数据库出现性能问题或故障时，离线备份提供了一种安全且可控的方式来排查问题。通过将数据库实例迁移到新的节点，可问题排查与性能验证：1.\\n\\n以在不影响生产环境的情况下进行详细的性能分析和故障排查。\\n\\n定期进行离线备份是防止数据丢失的关键措施。"],"avg_score": 348.5239664713542}],"total_retrieved_docs": 9,"token_usage": 43},"rerank": {"rerank_model": "bge-reranker-large","input_docs": 8,"output_docs": 3,"top_docs": ["1415908106070560773","1415908106070560772","1415908205789741090"],"top_doc_texts": ["## 适用场景\\n\\n某些业务场景下，业务数据的增长很快，并且业务数据的热度随着时间推移会有明显的降低，可以使用 TTL 将热度降低的数据在特定的过期时间时自动清理。例如：在电子商务平台中，用户搜索和浏览行为产生的向量数据，如点击流和用户偏好向量，通常具有很高的时效性。这些数据在短期内对于个性化推荐至关重要，但随着时间的推移，其相关性会迅速降低。在向量数据库集合中，设置TTL，便会自动删除过时的用户行为数据，确保推荐系统能够基于最新的用户互动提供实时、相关的推荐，从而提升用户体验和业务效率。\\n\\n","## 功能介绍\\n\\nTTL（Time to Live，生存周期）功能，指数据项从创建或更新后开始，到自动被系统删除的时间期限。在创建数据库集合时，通过为文档设置TTL，数据库能够自动清理过期的数据，从而优化存储空间的使用，保持数据的时效性，并确保查询结果的准确性，特别是在数据具有时效性要求的场景中，如实时推荐系统等。\\n\\n","# 向量数据库备份&恢复技术方案\\n\\n## 使用场景\\n\\n主要有以下两个场景：\\n\\n数据安全是云上数据库产品的生命线，备份回档作为保障数据安全的核心能力，是云上数据库产品的基本功能，提供后也能够为客户误操作导1.\\n\\n致的数据丢失、数据错乱等现象提供兜底。\\n\\n部分客户存在克隆数据到新实例的需求。2.\\n\\n具体到某个场景\\n\\n在数据库出现性能问题或故障时，离线备份提供了一种安全且可控的方式来排查问题。通过将数据库实例迁移到新的节点，可问题排查与性能验证：1.\\n\\n以在不影响生产环境的情况下进行详细的性能分析和故障排查。\\n\\n定期进行离线备份是防止数据丢失的关键措施。"],"token_usage": 1039},"evaluation": {"evaluation_result": {"is_relevant": true,"reason": "提到了TTL配置与自动删除相关机制，但未给出具体配置步骤或代码示例","suggestions": {"query_refinement": "需补充具体数据库类型和配置语法","recommended_queries": [{"query": "Milvus向量数据库TTL配置步骤","purpose": "获取该数据库具体操作指南"},{"query": "Weaviate自动删除数据参数示例","purpose": "补充不同数据库的实现方式"},{"query": "elasticsearch向量索引TTL设置","purpose": "覆盖常见向量数据库方案"}]}},"token_usage": 873}}]},"token_used": {"query_preprocessing_tokens": 351,"embedding_tokens": 116,"rerank_tokens": 1783,"evaluation_tokens": 1767}}
参数（一级） | 参数（二级） | 参数（三级） | 参数含义 |
documents | id | - | 检索到的文档主键 ID。 |
| score | - | 相似性得分，表示该文档与（最终优化后的）查询的匹配程度。 |
| author | - | 文档的其他属性字段。 |
execution_details | original_query | - | 原始查询的问题。 |
| total_iterations | - | 多轮迭代总循环次数。 |
| max_iterations | - | 系统配置的最大允许轮数，防止无限循环。 默认为3轮，最大为5轮。 |
| iterations（迭代详情列表） | iteration_no | 本轮的轮次。 |
| | query_processing (查询处理) | method：预处理方式 input_query：本轮迭代输入的查询内容。 sub_queries：拆分后的子查询列表。每个子查询对象包含 query (问题文本) 和 purpose (拆分目的)。 token_usage：本阶段消耗的 Token 数量。 |
| | retrieval（检索） | mode：检索模式。 dense：单路稠密型向量检索。默认为：dense。 sparse：单路稀疏型向量检索。 hybrid：稠密向量与稀疏向量两路混合检索 sub_query_results：每个子查询的独立检索结果。 query：子查询的输入问题。 retrieved_docs：检索的文档数量。 top_docs：最相关的文档 ID 列表。 avg_score：检索到的文档的平均相关性分数。 total_retrieved_docs：所有子查询检索到的文档总数。 token_usage：本阶段消耗的 Token 数量。 |
| | rerank（重排） | rerank_model：使用的重排模型名称，"bge-reranker-large" 是一个专门用于对检索结果进行精细排序的模型。 input_docs：送入重排模型的文档数量。 output_docs：重排后输出的文档数量。 top_docs：经过重排模型计算后，全局最相关的文档 ID 列表（按相关性从高到低排序）。 token_usage：本阶段消耗的 Token 数量。 |
| | evaluation （评估） | evaluation_result：对本轮迭代结果的评估结论。 is_relevant：评估是否通过。false 表示系统自动判断当前结果不足以很好地回答原始问题。 reason：评估不通过的原因。 suggestions：改进建议。系统根据失败原因生成的优化策略。 token_usage：本阶段消耗的 Token 数量。 |
token_used | query_preprocessing_tokens | - | 在查询处理阶段（如查询改写、拆分）所消耗的 Token。 |
| embedding_tokens | - | 将处理后的查询（Processed Queries）转换为向量表示（Embedding）所消耗的 Token。 |
| rerank_tokens | - | 将检索到的文档输入重排模型进行精细排序所消耗的 Token。通常与输入的文档数量成正比。 |
| evaluation_tokens | - | 检索结果和原始查询输入评估模型进行判断所消耗的 Token。 |
