作者: du

  • RAG 中的混合搜索对决!OpenSearch Serverless VS Aurora Serverless

    RAG 中的混合搜索对决!OpenSearch Serverless VS Aurora Serverless

    前言

    今天我要对可作为 Amazon Bedrock Knowledge Bases 向量数据库(搜索引擎)的工具进行对比。

    目前,Bedrock Knowledge Base 中支持混合搜索的向量数据库如下:

    • OpenSearch Serverless
    • OpenSearch Managed Cluster(OpenSearch 托管集群)
    • Aurora Serverless V2(PostgreSQL)
    • MongoDB Atlas

    本次,我将针对其中使用率较高的OpenSearch ServerlessAurora Serverless V2(PostgreSQL) ,对比二者在混合搜索中的精度表现。

    概述

    混合搜索是一种结合向量(语义)搜索关键词(全文)搜索来查找相关文档的搜索方式。这种方式既能通过向量搜索实现基于语义的检索,又能通过关键词搜索,在检索过程中纳入指定关键词的考量。

    OpenSearch Serverless 与 Aurora Serverless V2(PostgreSQL)的对比

    下面我将对本次作为数据存储使用的 OpenSearch Serverless 和 Aurora Serverless V2(PostgreSQL)进行简单对比。

    对比维度OpenSearch ServerlessAurora Serverless V2(PostgreSQL)
    混合搜索(Bedrock Knowledge Bases)支持支持
    中文支持可使用 Kuromoji 等中文形态素分析PostgreSQL 标准全文搜索(目前不支持中文形态素分析)
    向量存储格式支持浮点数 / 二进制两种格式浮点数(基于 pgvector 插件)
    计费单位OCU / 小时(最小 1 个 OCU,含 0.5 计算 OCU+0.5 存储 OCU)ACU / 小时(最小 0.5 个 ACU)
    最小配置计费示例175.22 美元(1 个 OCU:175.2 美元,存储:0.02 美元)87.83 美元(1 个 ACU:87.60 美元,I/O:0.13 美元)

    (参考链接:aws.amazon.comaws.amazon.com

    OpenSearch Serverless 支持中文形态素分析,因此即便使用中文,也能高精度地进行关键词搜索。另一方面,Aurora Serverless V2(PostgreSQL)在最小配置下的费用更具优势,但由于其默认不支持中文形态素分析,因此在中文混合搜索的精度方面存在不确定性。

    精度对比实验

    为对比 OpenSearch Serverless 与 Aurora Serverless V2(PostgreSQL)的精度,本次将开展以下两类实验:

    1. 英文数据集的搜索精度对比
    2. 中文数据集的搜索精度对比

    尤其对于中文数据集,由于 Aurora Serverless V2(PostgreSQL)不支持中文形态素分析,预计 OpenSearch Serverless 在精度上会更具优势。

    1. 实验设置

    以下是本次实验使用的基本设置。首先,Bedrock Knowledge Base 的基础设置如下,仅向量存储工具为两者的差异点。

    嵌入模型(Embedding Model)嵌入类型(Embedding Type)分块策略(Chunking Strategy)
    Titan Text Embeddings V21024 维浮点数向量嵌入分层分块(父块:2000 字符,子块:500 字符,重叠:50 字符)

    精度对比将通过 Bedrock Evaluations 完成。

    (参考链接:docs.aws.amazon.com

    本次对比将采用以下两项指标,指标取值范围均为 0~1,数值越大表示对问题的回答质量越高:

    • Context relevance(上下文相关性):衡量获取的文本与问题在上下文层面的关联程度
    • Context coverage(上下文覆盖率):衡量获取的文本对正确数据中全部信息的覆盖程度

    2. 混合搜索对比(英文数据集)

    1. 数据集

    本次实验使用的数据集如下:Amazon Reviews 2023(2023 年亚马逊评论数据集)

    (参考链接:amazon-reviews-2023.github.io

    该数据集包含约 2.8 万组 “产品 ID – 评论” 数据,示例如下:

    product/productId: B000GKXY4S
    product/title: Crazy Shape Scissor Set
    product/price: unknown
    review/userId: A1QA985ULVCQOB
    review/profileName: Carleen M. Amadio "Lady Dragonfly"
    review/helpfulness: 2/2
    review/score: 5.0
    review/time: 1314057600
    review/summary: Fun for adults too!
    review/text: I really enjoy these scissors for my inspiration books that I am making (like collage, but in books) and using these different textures these give is just wonderful, makes a great statement with the pictures and sayings. Want more, perfect for any need you have even for gifts as well. Pretty cool!
    

    2. 结果(英文)

    对比结果如下,
    数值越高,评估结果越好。

    指标类型OpenSearch无服务器Aurora Serverless V2(PostgreSQL)
    上下文相关性0.060.07
    上下文覆盖0.190.18

    3. 混合搜索对比(中文数据集)

    那么,接下来将对核心中文数据集的(检索)精度展开比较分析。​

    1. OpenSearch(中文分词设置示例)

    由于 OpenSearch Serverless 可使用 Kuromoji 形态素分析(中文分词工具),因此需进行相关配置。

    通过该配置,中文文本能被正确分割,进而有望提升关键词搜索的精度。

    配置示例

    PUT bedrock-knowledge-base-hybrid-index
    {
      "mappings": {
        "properties": {
          "AMAZON_BEDROCK_METADATA": {
            "type": "text",
            "index": false
          },
          "AMAZON_BEDROCK_TEXT_CHUNK": {
            "type": "text",
            "analyzer": "custom_kuromoji_analyzer"
          },
          "bedrock-knowledge-base-default-vector": {
            "type": "knn_vector",
            "dimension": 1024,
            "method": {
              "name": "hnsw",
              "engine": "faiss",
              "space_type": "cosinesimil"
            }
          },
          "id": {
            "type": "text",
            "fields": {
              "keyword": {
                "type": "keyword",
                "ignore_above": 256
              }
            }
          }
        }
      },
      "settings": {
        "index": {
          "knn.algo_param": {
            "ef_search": "512"
          },
          "knn": "true",
          "analysis": {
            "analyzer": {
              "custom_kuromoji_analyzer": {
                "tokenizer": "kuromoji_tokenizer",
                "filter": [
                  "kuromoji_baseform",
                  "ja_stop"
                ],
                "char_filter": [
                  "icu_normalizer"
                ]
              }
            }
          }
        }
      }
    }
    
    

    2. 插入的中文文档

    本次使用的数据集,是让 ChatGPT 输出的,具体如下。
    在混合检索时,我们期望能以 “张居正生平” 作为关键词,检索到相关信息。

    张居正像(现藏于中国国家博物馆)

    时代 明朝中后期(嘉靖、隆庆、万历年间)

    生诞 嘉靖四年五月初三日(1525 年 5 月 24 日)

    死没 万历十年六月二十日(1582 年 7 月 9 日)(58 岁卒)

    改名 无(一直以 “张居正” 为名,字叔大,号太岳)

    字:叔大

    号:太岳

    谥号:文忠(万历朝初赠,后被追夺,天启朝恢复)

    墓所:湖北省荆州市沙市区张居正墓

    官职:吏部左侍郎兼东阁大学士、礼部尚书兼武英殿大学士、少师兼太子太师、吏部尚书、中极殿大学士(内阁首辅)

    主要事迹 1. 推行 “一条鞭法”,将田赋、徭役和杂税合并,按田亩折算银两征收,简化税制,增加财政收入;2. 实施 “考成法”,考核各级官吏政绩,整顿吏治,提高行政效率;3. 重用戚继光、李成梁等将领,加强北方边防,抵御蒙古部落侵扰,稳定边疆局势;4. 主持治理黄河、淮河,任用潘季驯负责河工,疏通河道,减少水患,保障农业生产。

    评估用数据集示例

    • 问题:请告知张居正被任命为吏部尚书的年份
    • 答案:张居正于明万历元年(公元 1573 年) 正式被任命为吏部尚书。

    3. 结果(中文)

    以下是中文数据集的精度对比结果。数值越大,代表评价结果越好。

    Metric typeOpenSearch ServerlessAurora Serverless V2(PostgreSQL)
    Context relevance0.450.43
    Context coverage1.000.93

    如上表所示,尽管优势微弱,但 OpenSearch Serverless 在两项指标上均超过 Aurora Serverless V2(PostgreSQL)。尤其在衡量 “问题回答覆盖度” 的上下文覆盖率(Context coverage)指标上,OpenSearch Serverless 的优势更为明显。

    我们认为,这一差异源于 OpenSearch Serverless 通过 Kuromoji 实现了中文形态素分析支持,进而在混合搜索的关键词搜索精度上形成了优势。

    此外,我们也对比了两者的搜索速度,结果如下:我们连续执行 5 种不同查询,去除最大值与最小值后计算 “截尾平均值”(Trimmed Mean)进行对比。

    OpenSearch Serverless(秒)Aurora Serverless V2(PostgreSQL)(秒)
    0.48 秒0.55 秒

    从搜索速度来看,OpenSearch Serverless 同样具备更快的检索表现。

    总结

    本次实验对比了在 Bedrock 知识库中,分别使用 OpenSearch Serverless 与 Aurora Serverless V2(PostgreSQL)实现混合搜索的效果。结果显示,在中文搜索的精度与速度上,OpenSearch Serverless 均优于 Aurora Serverless V2(PostgreSQL)。

    需要说明的是,本次验证基于 “数据量较少” 的场景,因此两者的差距并不显著;若后续数据量增加,结果可能会发生变化。不过,从整体来看,两款工具在精度与速度上均具备较高性能,建议根据实际使用场景数据量选择合适的工具。

  • 借助 StrandsAgents+AgentCore Memory 实现符合个人偏好的智能体

    借助 StrandsAgents+AgentCore Memory 实现符合个人偏好的智能体

    近年来,随着对话式 AI 的应用不断深入,为每位用户提供个性化体验变得愈发重要。当前所需的智能体,已不再是简单的一问一答模式,而是能够理解 “用户是谁、拥有怎样的关注点与目标” 后再进行响应的智能体。

    在本文中,我们将结合 Strands Agents 与 Bedrock AgentCore,对可记忆并活用用户对话历史的个性化智能体进行实现与验证。

    1. 引言

    首先,我们将对各个构成要素进行简单介绍。

    1.1 什么是 Strands Agents

    Strands Agents 是一套能够灵活设计并构建对话式智能体行为及对话流程的机制。通过组合多个工具,可在对话过程中实现所需的处理(如 API 调用、数据检索、记忆查询等)。

    相关内容也可参考 GitHub 链接:github.com

    1.1.1 Strands Agents 工具

    在 Strands Agents 中,“工具” 指的是智能体所使用的外部功能。本文将重点介绍用于处理对话记忆的 “Agent Core Memory” 工具。

    相关参考链接:github.com

    1.2 什么是 Bedrock AgentCore

    Bedrock AgentCore 是一项托管服务,为智能体的开发与运行提供所需功能。它具备以下功能,可助力智能体的顺畅构建:

    • 提供运行环境
    • 与各类工具联动
    • 认证与授权功能
    • 按用户管理记忆等

    官方参考链接:aws.amazon.com

    1.2.1 AgentCore 记忆功能(AgentCore Memory)

    AgentCore 具备 “Memory(记忆)” 功能,可让智能体拥有短期记忆与长期记忆。

    其中,长期记忆尤为重要,它能够记录通过与用户对话获取的事实信息,并在后续对话中加以活用。例如,通过记忆用户 “擅长 Python”“喜欢旅行” 等偏好与特征,智能体在之后的对话中,就能给出更贴合用户需求的响应与建议。

    需要注意的是,并非所有已记忆的内容都会被调用,系统会动态检索并使用与当前对话相关的信息。

    ChatGPT 也具备记忆功能,能够记住用户的个人信息与偏好,而通过 Bedrock AgentCore,我们可以自行实现同等功能,从而达成自然的个性化体验。

    官方文档参考链接:docs.aws.amazon.com

    2. 验证

    我们将实际创建智能体,验证其能否在保存、检索记忆的同时进行对话。

    由于短期记忆可通过 StrandsAgents 的 ConversationManager 进行管理,因此本次验证将重点关注长期记忆。

    我们已通过 AgentCore 的控制台,创建了启用 “用户偏好” 策略的记忆模块。

    2.1 结构图

    2.2 实现过程

    以下为智能体的实现代码。为了获取与特定用户的对话记录,我们设置了可通过参数接收 “与谁对话” 这一信息的功能。

    class MemoryAgent:
        PROMPT = dedent("""\
            请你扮演一个能为用户提供个性化服务、贴合用户需求的助手。
            请利用与用户过往的交互信息,理解用户想要做的事情。
    
            以下内容仅需在你内部处理,不得告知用户。
            请自然地进行互动。
            - 对于用户的输入内容,不得修改,需全部通过agent_core_memory的record工具进行记录。
            - 在对话过程中,若话题发生变化或开启新话题,请通过agent_core_memory的retrieve工具,从过往交互记录中获取与用户相关的信息。
            以上内容仅需在你内部处理,不得告知用户。
        """)
    
        def __init__(self, actor_id: str, session_id: str):
            model = BedrockModel(
                model_id='us.anthropic.claude-sonnet-4-20250514-v1:0',
                streaming=True,
                additional_request_fields={
                    'thinking': {'type': 'enabled', 'budget_tokens': 4000},
                    'anthropic_beta': ['interleaved-thinking-2025-05-14'],
                },
                region_name='us-west-2',
            )
    
            # 此处准备AgentCore Memory
            # 可指定使用的记忆模块以及长期记忆的整理策略
            provider = AgentCoreMemoryToolProvider(
                memory_id=MEMORY_ID,
                actor_id=actor_id,
                session_id=session_id,
                namespace=f'/strategies/{STRATEGY_ID}/actors/{actor_id}',
                region='us-west-2',
            )
    
            self.agent = Agent(
                model=model,
                system_prompt=self.PROMPT,
                tools=provider.tools,
            )
    
        async def stream(self, prompt):
            async for event in self.agent.stream_async(prompt):
                if text := event.get('event', {}).get('contentBlockDelta', {}).get('delta', {}).get('text', ''):
                    yield text
                for content in event.get('message', {}).get('content', []):
                    if isinstance(content, dict) and (tool_use := content.get('toolUse', '')):
                        logger.info('## 工具使用:%s', tool_use)
    

    2.3 尝试对话

    我平时习惯使用 “Python+Angular” 的组合开发应用。如果智能体生成的应用也采用这种技术组合,我不仅更容易理解,还能直接将其投入实际应用。

    本次验证中,我首先明确告知智能体需用 Python+Angular 实现,随后在不额外说明的情况下让其开发应用,以此检验它是否会主动使用 Angular。若智能体在未明确告知的情况下仍能选择 Angular,就说明它理解了我的偏好,实现了个性化,称得上是贴心的智能体。

    2.3.1 未理解用户偏好的情况

    我们先确认未设置 Strands Agents Tools、不使用记忆功能时的智能体表现。

    首次对话:明确告知所用框架并让智能体实现

    “请用 Python+Angular 开发一个 LLM 聊天 GUI 应用。”

    智能体按照需求,使用 Python+Angular 实现了应用:

    “将为您开发 LLM 聊天应用。我们将以 Python(FastAPI)作为后端,Angular 作为前端进行构建。”(其余省略)

    另起线程:不告知框架,让智能体实现

    若让同一个智能体开发,它有可能从对话历史中推断出需使用 Angular。为避免这种情况,我先停止了智能体应用,重新初始化一个新的智能体,再发出以下请求:“开发一个 RAG 聊天 GUI 应用。”

    由于新智能体未保留之前的对话记忆,不记得上次使用 Angular 作为前端框架的情况。因此,它并未采用我习惯使用的 Angular,而是生成了基于 Streamlit 的代码:

    “将为您开发 RAG 聊天 GUI 应用。我们将使用 Streamlit,构建一个包含文档上传、向量检索、聊天功能的完整应用。”(其余省略)

    2.3.2 已理解用户偏好的情况

    接下来,我们启用 Strands Agents Tools 的 Memory(记忆)工具,通过使用 AgentCore Memory,验证智能体是否能记住过往对话,从而成为具备个性化能力的智能体。

    首次对话:明确告知所用框架并让智能体实现

    “请用 Python+Angular 开发一个 LLM 聊天 GUI 应用。”

    智能体同样按照需求完成了开发:

    “好的,我们来用 Python + Angular 开发 LLM 聊天 GUI 应用!将采用全栈架构,打造一个实用的聊天应用。”(其余省略)

    另起线程:不告知框架,让智能体实现

    此处我们同样先创建一个新的智能体,再发起请求:“开发一个 RAG 聊天 GUI 应用。”

    智能体回复:

    “参考过往的交互记录,发现您对用 Python 和 Angular 开发 LLM 聊天应用很感兴趣!本次我们来开发一个集成了 RAG(检索增强生成)功能的聊天 GUI 应用吧。

    以下为您建议的技术架构:

    技术栈

    • 后端:Python(FastAPI)
    • 前端:Angular
    • RAG:LangChain + 向量数据库(Chroma/FAISS)
    • LLM:OpenAI API 或 Hugging Face

    (其余省略)”

    可见,智能体记住了此前用户使用 Python+Angular 开发 GUI 应用的偏好,因此主动提议采用相同技术架构进行开发。

    这表明 AgentCore Memory 实现了预期功能,能够输出符合用户偏好的响应。

    2.4 查看 Memory的内容

    由于无法从 AWS 控制台直接查看 Memory 的内容,我们通过 AWS 命令行工具(AWSCLI)获取相关数据。

    从获取的结果中可以看出,智能体已将 “对开发 LLM 应用感兴趣”“使用 Python+Angular 开发应用” 识别为用户的偏好。

    $ aws bedrock-agentcore list-memory-records \
        --memory-id $memoryId \
        --namespace /strategies/memory_preference/actors/sy
    {
        "memoryRecordSummaries": [
            {
                "memoryRecordId": "mem-cacf3145-324f-4f30-8e83-dade742bc2e0",
                "content": {
                    "text": "{\"context\":\"对开发LLM(大型语言模型)聊天应用表现出兴趣\",\"preference\":\"对基于LLM的聊天应用感兴趣\",\"categories\":[\"人工智能\",\"技术\",\"应用开发\"]}"
                },
                "memoryStrategyId": "memory_preference",
                "namespaces": ["/strategies/memory_preference/actors/sy"]
            },
            {
                "memoryRecordId": "mem-77a9f50f-8589-4229-874b-2dcac251708f",
                "content": {
                    "text": "{\"context\":\"用户要求使用Python+Angular开发LLM聊天GUI应用\",\"preference\":\"对使用Python和Angular开发应用感兴趣\",\"categories\":[\"编程\",\"软件开发\",\"技术\"]}"
                },
                "memoryStrategyId": "memory_preference",
                "namespaces": ["/strategies/memory_preference/actors/sy"]
            }
        ]
    }
    

    当 Strands Agents 的智能体调用该 Memory 时,可通过向量检索获取匹配度高的内容作为相关记忆。

    以下是第二次运行智能体时,Strands Agents 实际执行的工具调用内容,从中可看出其利用了向量检索的分数来获取相关记忆:

    agent.agent.tool.agent_core_memory(
        action='retrieve',
        query='RAG 聊天 GUI 应用 开发 编程',
    )
    {
        "memoryRecordSummaries": [
            {
                "content": {
                    "text": "{\"context\":\"用户要求使用Python+Angular开发LLM聊天GUI应用\",\"preference\":\"对使用Python和Angular开发应用感兴趣\",\"categories\":[\"编程\",\"软件开发\",\"技术\"]}"
                },
                "namespaces": ["/strategies/memory_preference/actors/sy"],
                "score": 0.49530885
            }
        ]
    }
    

    3. 应用示例

    通过将 Strands Agents Tools 与 AgentCore Memory 相结合,智能体能够记住对话上下文,并根据用户的偏好和目标提供个性化服务。

    此处将介绍几个在实际业务或服务中的应用场景。

    客户支持

    将用户过往的咨询内容及问题处理记录存储在长期记忆中,用户无需每次都从基础情况开始说明。例如,在处理错误问题时,智能体可实现 “上次出现的是XX错误,这次看起来是△△错误呢” 这类理解上下文的支持服务。

    持续学习支持

    作为教育类应用或企业内部培训的辅助工具,智能体可记录学习者的进度及薄弱领域,并据此调整出题内容和讲解方式。用户能获得 “以前你对这个问题不太擅长,这次已经能解出来了呢” 这类反馈,从而得到更具持续性的学习支持。

    个性化推荐系统

    在提供产品推荐或内容建议的应用中,智能体可结合用户的偏好及过往选择进行推荐。例如,旅行方案推荐智能体可实现 “上次您更喜欢安静的温泉胜地,这次为您推荐氛围相似的〇〇地区” 这类响应。

    4. 总结

    通过将 Strands Agents 与 Bedrock AgentCore 的 Memory 功能相结合,能够实现传统对话式 AI 难以做到的 “保持上下文”“结合个人偏好提供服务” 等能力。

    本文通过一个简单的聊天应用,对 AgentCore Memory 的功能进行了验证。

    结果表明,利用 Memory 工具能够为用户提供更自然、更具连贯性的体验。

    未来,还需要应对更复杂的应用场景,例如提升记忆的准确性、实现记忆的删除与修改控制、支持多用户使用等。可以说,让智能体具备 “记忆” 能力,是未来 AI 应用发展中的关键功能之一。

  • 在OSS 的 Open Deep Research 中实现 Deep Research

    在OSS 的 Open Deep Research 中实现 Deep Research

    前言

    这次我想实际运行由 Hugging Face 公开的开源 AI 代理(AI Agent)——Open Deep Research。

    huggingface.co

    1. 概要

    Deep Research 指的是在进行网络搜索的同时,自主收集信息并输出详细报告的服务。目前,带有 “Deep Research” 名称的代表性服务如下。

    服务名称OpenAI Deep ResearchGoogle Gemini Deep ResearchPerplexity Deep ResearchOpen Deep Research
    提供商OpenAIGooglePerplexity AIHugging Face
    价格ChatGPT Pro(月费 200 美元),ChatGPT Plus(月费 20 美元)可有限次数使用Gemini Advanced(月费 20 美元)免费(未注册用户每日限 5 次)免费(开源)
    精度GAIA 基准测试 67%、Humanity’s Last Exam 26.6%(采用 GPT-4 系列 “o3” 模型)无官方基准测试,被评价为可生成高精度医疗、市场调查报告Humanity’s Last Exam 21.1%,检索与解读性能强,但存在部分错误取决于开源模型性能(使用 o1 模型时,GAIA 55%、Humanity’s Last Exam 8.5%)
    特点在 ChatGPT 内运行,结合检索与推理,5-30 分钟生成详细调查报告从 50 余个网站收集信息,支持计划编辑、进度可视化、Google 文档输出通过反复检索与推理,短时间生成全面报告,具备检索对象指定及导出功能仅需开源大语言模型即可运行,适合完全离线部署及隐私保护

    在以上服务中,本次我想重点介绍由 Hugging Face 开发的开源项目 ——Open Deep Research。该服务以复现 OpenAI 的 Deep Research 为目标,与 OpenAI Deep Research 类似,可结合大规模语言模型(LLM)与代理框架进行信息检索和推理。

    huggingface.co

    openai.com

    OpenAI 的 Deep Research 是一款利用网络检索来应对复杂问题的工具,但其代理框架的详细信息未公开。与之相对,Hugging Face 团队开发了这款 “Open Deep Research” 作为开源替代方案,构建了任何人都可使用、改良的系统。

    Open Deep Research 的工作机制

    Open Deep Research 通过以下两种代理协同工作,实现信息检索与推理。

    CodeAgent

    • 接收用户的问题,制定检索计划
    • 将检索任务交给其他代理(SearchAgent)

    SearchAgent

    • 负责实际执行网络检索、收集并整理信息的工作。

    具体流程如下。

    尤其值得注意的是,CodeAgent 向 SearchAgent 下达指令的方式基于以下代码形式,通过这种方式,Agent 能够将更复杂的操作作为指令传递出去。

    Open Deep Research 的请求示例

    search_results = search_agent(task="请在互联网上搜索关于『Open Deep Research』的信息,调查其属于何种组织或具体活动内容。")
    print(search_results)
    

    2. 运行 Open Deep Research

    接下来,我们马上开始实际运行 Open Deep Research。

    准备工作

    需获取以下 3 个 API 密钥:

    此外,本次将使用 o1 模型进行 Deep Research。

    搭建方法

    按照以下步骤搭建环境:

    git clone https://github.com/huggingface/smolagents.git
    cd smolagents/examples/open_deep_research
    
    pip install -r requirements.txt
    pip install smolagents[litellm]
    
    export OPENAI_API_KEY="填入获取的密钥"
    export HF_TOKEN="填入获取的Hugging Face令牌"
    export SERPAPI_API_KEY="填入SERPAPI的密钥"
    

    执行搜索

    使用以下命令执行搜索:

    python run.py --model-id "o1" "请介绍一下Open Deep Research。"
    

    执行过程(中途进展)

    启动搜索后,内部会执行如下处理:

    以下是我为解决该任务将遵循的行动方案: 1. 审视任务“请介绍一下Open Deep Research。”及已知事实。 2. 调用search_agent获取关于“Open Deep Research”的信息。 3. 总结搜索结果中的关键信息,例如背景、目标或重要成果。 4. 使用final_answer呈现调查结果。

    ━━━━━━━━━━━━━━━━━━━━━━━━━ 步骤 1 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

    大语言模型(LLM)的输出信息: ──────────────────────────────

    思考:我需要查找关于 “Open Deep Research” 的信息。我会让 search_agent 用中文进行网络搜索以获取相关信息。

    代码:

    py

    search_results = search_agent(task="请在互联网上搜索关于『Open Deep
    Research』的信息,调查其属于何种组织或具体活动内容。")
    print(search_results)
    

    ─ 执行解析后的代码: ──────────────────────────────search_results = search_agent (task=” 请在互联网上搜索关于『Open DeepResearch』的信息,调查其属于何种组织或具体活动内容。”)

    print(search_results)

    ──────────────────────────────

    可以看出,CodeAgent 通过 Python 代码形式向 SearchAgent 发送请求,SearchAgent 则根据该请求执行搜索操作。

    回答结果

    获取到的回答:以下是关于『Open Deep Research』的概要总结。

    【概要】

    『Open Deep Research』是一个开源项目,旨在运用 AI 技术及网络搜索功能获取大量信息,为摘要撰写、报告生成及研究工作提供支持。GitHub 上存在多个相关仓库,目前该项目正以开源形式推进开发与改进。此外,其官方网站及演示版本等也已公开,任何人都可进行部署与扩展。

    【背景・特点】

    • 其核心特点是基于 OpenAI 最初发布的 “Deep Research”,由社区主导实现了 “开源化”。
    • 具备 AI 代理(AI Agent)检索、分析互联网上的大规模文本数据,并自动生成摘要与报告的功能。
    • 也能看到其采用结合 Firecrawl 等爬虫技术以提升搜索精度的实现方式。

    【应用案例】

    • 预计可用于需高效处理网络上海量信息的场景,例如自动生成研究资料、整理信息等。
    • 由于属于非营利性社区项目,开发者与用户正通过协作扩充、改进功能,推动项目发展。

    【注意事项】

    • 搜索到的信息多汇总于 2025 年前后,该项目可能尚未形成固定的正式企业组织。实际使用时,建议确认 GitHub 仓库及官方网站(如https://opendeepresearch.vercel.app 等)。
    • 关于许可证形式及持续开发状况,也建议提前核查最新信息。

    以上即为关于『Open Deep Research』的主要信息。

    系统已根据最新信息,生成了关于搜索对象的报告。

    与 OpenAI Deep Research 的对比

    向 OpenAI Deep Research 提出相同问题后,得到的结果如下。

    OpenAI Deep Research 的回答结果:

    明白了。我将对 “Open Deep Research” 的概况进行调查,并汇总其目的、活动内容、相关组织及项目等信息。调查完成后会通知您。

    Open Deep Research 概况

    一、概述

    Open Deep Research(开放深度研究)是一个旨在为 OpenAI 开发的高级调查代理(AI Agent)“Deep Research” 提供开源替代方案的项目。该项目以 Hugging Face 联合创始人托马斯・沃尔夫(Thomas Wolf)等人为核心,目标是让任何人都能结合自己偏好的语言模型,在本地环境中使用高级调查代理。具体而言,其公开了 OpenAI 未披露的代理控制部分(即指示网络浏览、工具使用的框架)并自行实现相关功能,肩负着推动封闭性尖端 AI 功能民主化的使命。

    二、主要研究领域与活动内容

    Open Deep Research 的核心焦点是实现与 Deep Research 同等的网络研究功能。针对用户的问题,它能自动从互联网收集、分析信息,进行逻辑推理并生成长篇回答。其特色功能可归纳为以下 3 点:

    • 内容发现:通过网络搜索收集与用户问题相关的信息(自动生成搜索查询,探寻最新信息)。
    • 内容整合:汇总、整合来自多个信息源的内容,提取关键要点。
    • 信息推理:基于收集到的信息进行层层逻辑推理,得出针对问题的结论及详细解释。

    通过上述流程,该项目据称可在数分钟至数十分钟内完成人类需耗时数小时的调查工作,并生成专业级的详细报告。

    从技术层面看,Open Deep Research 通过组合以下要素实现功能:

    1. 搜索引擎:借助外部搜索服务检索相关信息,获取对应页面的 URL(例如 DuckDuckGo API 等)。
    2. 解析器(网页内容提取):从搜索结果的 URL 中提取页面正文,并转换为文本数据的模块。
    3. 大规模语言模型(LLM):基于提取的文本执行摘要生成、问答及推理的 AI 模型(目前主要使用 OpenAI 的 o1 等模型)。
    4. 代理控制逻辑:指示 LLM 使用网络浏览、文件读取等工具,并管理多步骤操作的框架。在 Hugging Face 版本中,该逻辑通过 Python 轻量级代理库 “smolagents” 实现,并结合 OpenAI 的 LLM(o1 模型)API,复现了与 Deep Research 相当的运行效果。

    三、相关组织与项目

    Open Deep Research 是由Hugging Face 公司的研究团队推进的项目。尤其是托马斯・沃尔夫(Hugging Face 联合创始人)、艾美瑞・鲁歇尔(Aymeric Roucher)等人通过 24 小时黑客马拉松式的努力搭建了原型,并公开了成果。该项目受 OpenAI 的 Deep Research(原始封闭代理)启发,以开源社区的协作支持为显著特征。

    目前存在多个具有类似目标的相关项目。例如,Jina AI 公司开发了基于 TypeScript/Node.js 实现的开源代理 “node-DeepResearch”,采用以 Google 的 PaLM 2、Gemini 模型为后端的技术路径。此外,个人开发者开发的复刻版本也陆续出现,据 Hugging Face 报告,dzhngnickscamara等开发者已各自公开了 Deep Research 的开源版本。这些尝试相互促进,为整个代理 AI 领域的发展做出了贡献。

    四、官方网站与信息来源

    Open Deep Research 的官方信息及资源如下:

    • 官方博客文章(Hugging Face 博客):Hugging Face 于 2025 年 2 月 4 日公开的文章《Open-source DeepResearch – Freeing our search agents》(开源 DeepResearch—— 解放我们的搜索代理),详细解读了 Open Deep Research 的背景、实现方式及成果。
    • 演示网站(Hugging Face Spaces):在 Hugging Face 提供的演示页面可试用 Open Deep Research。从浏览器输入问题后,代理会自动执行搜索并给出回答。目前该演示收到了来自全球的大量请求,可能会出现响应等待时间较长的情况。
    • 源代码(GitHub):Open Deep Research 的实现代码已在GitHub公开,可在 Hugging Face 的smolagents仓库内的open_deep_research示例中查看。任何人都可浏览、使用代码,同时也欢迎通过 Issue(问题反馈)和 Pull Request(代码提交)提供反馈与贡献。

    此外,TechCrunch、Ars Technica 等科技媒体也已针对该项目发布详细报道;日语信息方面,Qiita、GIGAZINE 等平台介绍了项目背景及搭建方法。

    五、最新研究成果与发布动态

    Open Deep Research 自公开以来便展现出较高性能,据报道其成果已接近 OpenAI 官方的 Deep Research。具体而言,在测试通用 AI 助手能力的GAIA 基准测试中,Deep Research 官方版本的平均正确率达到67.36% ,而 Open Deep Research 的得分已达到54% 左右。仅用约 1 天时间便复现核心功能,并实现了官方版本约 80% 的性能,这无疑是一项重大成果。Hugging Face 团队表示 “这仅仅是开始,仍有许多需要改进的地方”,并明确表达了将持续推进开发以提升性能的意向。

    此后,Open Deep Research 持续稳步更新。例如,截至 2025 年 3 月,项目已新增 “Visual Flow”(可视化流程)功能,可将代理的探索过程以视觉形式呈现,便于用户理解多阶段深度调查的流程。此外,作为未来计划,团队还将致力于开发可与 OpenAI 发布的浏览器操作代理 “Operator” 相媲美的GUI 操作兼容代理(通过视觉识别画面,使用鼠标、键盘进行操作的代理)。从这些最新动态可以看出,Open Deep Research 项目正与社区协作不断进化,站在拓展开源 AI 代理可能性的最前沿。

    以下是简单的对比。

    对比项目Open Deep ResearchOpenAI Deep Research
    参考网站数量8 个网站17 个网站
    回答所需时间约 2 分钟约 16 分钟
    报告质量反映了搜索结果,但内容较为简洁能触及搜索结果的细节之处

    结果来看,果然还是 OpenAI Deep Research 参考了更多网站,生成的报告内容也更充实。

    不过,Hugging Face 的 Open Deep Research 作为开源项目公开,能够结合任意的大语言模型(LLM),还可以嵌入自家服务中使用,这一点是很有优势的。

    总结

    我实际运行了作为开源项目公开的 Open Deep Research。

    能够通过开源(OSS)搭建 Deep Research 功能,这一点让我觉得很有吸引力。

    在精度方面,随着 Operator 等功能的引入,未来还有很大的改善空间,非常期待后续的更新。

  • 在保证精度的同时大幅降低成本,Elasticsearch 向量搜索选项及效果

    在保证精度的同时大幅降低成本,Elasticsearch 向量搜索选项及效果

    前言

    近年来,在检索增强生成(RAG,Retrieval-Augmented Generation)兴起等背景下,向量搜索的重要性日益凸显。向量搜索是将文本、图像等高维数据嵌入向量空间,基于相似度进行检索的技术。通过该技术,能够实现传统关键词搜索无法捕捉的、基于语义相似性的检索。

    另一方面,可处理向量搜索的产品与服务不断增多,想必有不少人在选择时会感到迷茫。不同服务支持的向量搜索选项也存在差异。尤其在近期,为提升向量搜索性能与资源效率的各类选项纷纷涌现,其中 “向量量化” 与 “二进制向量” 作为有助于降低资源用量、提升检索速度的技术备受关注。

    本文将聚焦向量搜索引擎的有力选择之一 ——Elasticsearch,结合具体配置方法,解析向量量化、二进制向量等选项及其效果。

    Elasticsearch 中的向量搜索

    Elasticsearch 作为全文搜索引擎广为人知,而自 7.x 版本起,它开始支持稠密向量(Dense Vector)类型,向量搜索功能得到强化。稠密向量是用于存储高维向量数据的数据类型。

    Elasticsearch 稠密向量文档:Elasticsearch Dense Vector 文档

    向量搜索的算法

    在 Elasticsearch 中处理稠密向量时,会使用近似最近邻(ANN)搜索算法。目前可使用名为 HNSW 的算法。HNSW(Hierarchical Navigable Small World,分层可导航小世界)是一种高速的近似最近邻搜索算法,采用基于图的数据结构,能高效检索相似向量。

    用于资源削减的选项:向量量化与二进制向量

    向量搜索的性能与资源效率存在权衡关系。Elasticsearch 提供向量量化与二进制向量作为调节这种权衡的选项。

    选项说明优势劣势推荐使用场景
    向量量化将向量各维度用更少的比特数表示的方法。在 Elasticsearch 中,可替代 32 比特的 float 型,实现 8 比特、4 比特、1 比特的量化。大幅降低存储大小与内存用量,还有可能提升查询性能。可能导致精度下降。需降低存储成本与内存用量,追求一定精度与性能平衡的场景。
    二进制向量将向量各维度用 0 或 1 表示的方法。可使用汉明距离等进行高速的相似度计算。大幅减少计算时间及磁盘、内存用量,支持针对二进制向量的高速距离计算(如汉明距离)。与使用 float 型相比精度下降,且需要用于生成二进制向量的专用嵌入(Embedding)模型。可牺牲部分精度以大幅控制存储与内存用量,或需高速检索的场景。

    二进制向量详情

    二进制向量(比特向量)是一种蕴藏着大幅提升向量搜索效率潜力的技术。

    www.elastic.co

    机制

    二进制向量是基于阈值将原始向量(通常为浮点数向量)的各维度转换为 0 或 1 得到的。

    距离计算

    二进制向量间的相似度计算采用汉明距离(比特位不同的位置数量),其速度远快于浮点数向量间的余弦相似度或欧几里得距离计算。

    生成方法

    • 专用嵌入模型:使用可直接输出二进制向量的嵌入模型。
    • 现有嵌入模型 + 二值化:对通过现有嵌入模型得到的浮点数向量,采用阈值处理等方式进行二值化。

    量化 / 二值化的优势与注意事项

    向量量化与二值化是提升稠密向量存储效率与查询性能的有力手段,但在引入时需理解以下优势与注意事项。

    优势:

    1. 降低存储成本:可大幅减小索引大小,降低磁盘存储成本。
    2. 减少内存用量:向量数据更易存入内存,从而减少内存用量,提升 Elasticsearch 集群的稳定性。
    3. 提升查询性能:对量化 / 二值化后的向量进行运算速度更快,有望提升查询性能。

    注意事项:

    1. 精度的权衡:量化 / 二值化通常与精度存在权衡关系,数据压缩程度越高,检索精度下降的可能性越大。
    2. 选择合适的方法:需结合业务需求允许的精度损失与存储效率的平衡,选择合适的量化级别或二进制向量化方法。

    基于 JMTEB 数据的测试

    存在名为 JMTEB(Japanese Massive Text Embedding Benchmark,日语大规模文本嵌入基准)的嵌入精度评估基准。

    github.com

    JMTEB 通过 5 个使用各类日语开放数据的任务对嵌入模型进行评估。本次将利用部分数据集,观察修改量化选项后对磁盘用量及精度的影响程度。

    使用 Cohere 提供的嵌入 API,除了常规的 Float 型嵌入外,还可使用二进制嵌入。在验证中,我们使用 Cohere 的嵌入模型生成以下 3 种向量并注册到 Elasticsearch 中进行比较。

    1. 采用 Elasticsearch 默认设置(8 比特量化)的 float 向量
    2. 在 Elasticsearch 中进行比特量化(bbq)的 float 向量
    3. 利用 Elasticsearch 的 bit 选项注册的二进制向量

    参考:www.elastic.co

    索引大小 / 正确率

    以下展示了启用各选项并导入 Elasticsearch 后,索引的大小以及对数据集中预先定义的正确答案的匹配率。本次使用的数据集中,404 个检索查询均各自定义了 1 个正确文档。正确率指标采用精确率(precision)和归一化折损累积增益(nDCG)两项。

    • precision@1:应匹配的正确文档排在第 1 位的比例
    • nDCG@10:衡量前 10 位结果中应匹配的正确文档排名情况的指标,正确文档排名越靠前,得分越高。
    类型索引大小正确率 (precision@1)nDCG@10
    float 向量9.1MB84.41%0.9108
    量化 (bbq)8.7MB83.66%0.9024
    二进制向量2.6MB81.19%0.8889

    可以看出,直接使用 float 型向量的精度确实更高,但其他方法在减小索引大小的同时,精度仅下降了 1%~3% 左右,并未出现显著下滑。近年来也有通过与重排序(rerank)结合来保证精度的策略,因此本文介绍的选项具有实用价值。当然,精度下降幅度会因数据集不同而存在差异,建议在使用前进行验证,但仍推荐积极尝试这些选项。

    本文到此结束。感谢您读到最后。

  • 基于 Amazon S3 Vectors 的 RAG 性能与精度评估实践

    基于 Amazon S3 Vectors 的 RAG 性能与精度评估实践

    本次想为大家介绍在 2025 年纽约 AWS Summit 上发布的 S3 Vectors,内容将包含其与现有向量存储的对比分析。

    相关参考链接:aws.amazon.com

    什么是 S3 Vectors

    S3 Vectors 是 AWS S3 推出的新功能,本质是一款向量存储服务。由于依托 S3 提供,它与 AWS 此前可用的向量存储(如 OpenSearch Serverless、Aurora 等)不同 —— 无需承担运行成本,仅需根据数据量和 API 请求量支付费用。基于这一特性,在部分使用场景中,可实现大幅成本削减。

    相关参考链接:aws.amazon.com

    1. 与其他向量存储的成本对比

    假设每月使用 1GB 存储容量、执行 30000 次检索,以下为 S3 Vectors 与其他向量存储的成本对比示例。※AWS 区域按美国弗吉尼亚北部计算。

    向量存储名称每月总成本成本明细
    S3 Vectors$2.06存储:$2.00,请求:$0.06
    OpenSearch Serverless$175.221 个 OCU:$175.2,存储:$0.02
    Aurora Serverless v2$87.831 个 ACU:$87.60,存储:$0.10,I/O:$0.13
    Pinecone$0(入门版)/$50(标准版)使用 5 个及以上索引时,必须选择标准版

    由此可见,与其他向量存储相比,S3 Vectors 的成本具有压倒性优势。

    2. 功能层面的限制事项

    S3 Vectors 虽能以低成本使用,但在以下功能上存在限制。

    向量存储名称元数据过滤检索功能块大小(Chunk Size)限制分层分块(Hierarchical Chunking)
    S3 Vectors仅支持完全匹配检索、范围检索500 tokens△(默认设置下不可用)
    OpenSearch Serverless支持部分匹配检索等灵活检索方式无限制○(可用)

    元数据过滤检索功能

    进行元数据过滤检索时,无法像 OpenSearch Serverless 那样实现部分匹配等灵活检索,仅支持完全匹配、范围检索等基础方式。

    相关参考链接:docs.aws.amazon.com

    块大小限制

    可创建的最大块大小限制为 500 tokens。

    相关参考链接:docs.aws.amazon.com

    借助 Bedrock 知识库使用分层分块

    在 Bedrock 知识库的默认设置下,同步时会出现以下错误,导致无法使用分层分块功能:

    Filterable metadata must have at most 2048 bytes (Service: S3Vectors, Status Code: 400, Request ID:XXXXXX)

    若要从 Bedrock 知识库使用分层分块,需先在 S3 Vectors 中创建以下配置的索引:

    aws s3vectors create-index \
      --vector-bucket-name "bucket-name" \
      --index-name "index-name" \
      --data-type "float32" \
      --dimension 256 \
      --distance-metric "cosine" \
      --metadata-configuration '{"nonFilterableMetadataKeys":["AMAZON_BEDROCK_METADATA"]}'
    

    出现该限制的原因是,分层分块的父块所存储的元数据,在默认设置下仅能容纳 2048 字节以内的内容。因此,需通过上述命令,将存储父块的元数据指定为 “不可过滤元数据”。

    相关参考链接:docs.aws.amazon.com

    除上述之外,由于 S3 Vectors 仅支持向量检索,因此自然无法实现 OpenSearch Serverless 等服务所支持的混合检索功能。

    3. S3 Vectors 的最佳实践

    官方文档中介绍了以下最佳实践:

    最佳实践核心要点
    重试处理为避免系统过载,推荐采用带退避策略(Backoff)的重试机制
    通过索引拆分实现扩展按租户或用途分别使用多个索引,可提升系统吞吐量
    元数据设计将仅用于参考的文本等设置为不可过滤元数据,以优化性能
    访问控制可通过索引级别的 IAM 权限控制,灵活设计租户级访问限制等权限管理规则

    参考链接:docs.aws.amazon.com

    其中,在访问控制方面,官方特别推荐使用 IAM 角色进行配置,这一点在实际运维中也颇具参考价值。

    与其他向量存储的速度对比

    接下来,我们针对实际使用中最受关注的检索速度,将 S3 Vectors 与 OpenSearch Serverless 进行对比。本次对比基于 Bedrock 知识库的检索场景,具体检索条件如下:

    • 数据源:包含以下 IPA PDF 在内,共约 800MB、1000 个文件
      • 《面向安全网站运营》
      • 《软件开发数据白皮书 2018-2019》
      • 《软件开发数据白皮书 2018-2019 金融保险业篇》
      • 《软件开发数据白皮书 2018-2019 信息通信业篇》
    • 嵌入模型(Embedding Model):Titan Text Embeddings v2
    • 嵌入类型(Embedding Type):1024 维浮点向量嵌入
    • 分块策略(Chunking Strategy):固定分块
    • 分块大小(Chunk Size):300 tokens

    为覆盖缓存生效的场景,我们共设计了 100 种不同的查询语句作为测试请求。

    查询示例

    • “制造业中新开发项目的工时与工期关系”
    • “制造业改良开发中 FP(功能点)规模与工时的关系”

    对比结果

    向量存储名称平均时间(秒)最大时间(秒)最小时间(秒)
    S3 Vectors0.6881.5990.553
    OpenSearch Serverless0.4330.5070.383

    结果显示,S3 Vectors 的平均检索速度比 OpenSearch Serverless 慢 0.2 秒左右,最大延迟甚至相差 1 秒。不过,结合官方文档中 “检索响应时间需控制在 1 秒以内” 的标准来看,S3 Vectors 基本能满足大多数 RAG 场景的速度要求。

    参考链接:docs.aws.amazon.com

    与其他向量存储的精度对比

    接下来,我们从精度维度进行对比,分别测试 S3 Vectors 的 “仅向量检索” 与 OpenSearch Serverless 的 “混合检索” 效果。

    本次精度验证采用 Bedrock Evaluations 工具完成。

    参考链接:aws.amazon.com

    1. 基于向量检索的精度对比

    首先,仅针对向量检索的精度进行验证。我们沿用上述相同的知识库配置进行测试,采用以下两项指标评估精度:

    • 上下文相关性:衡量检索到的文本与查询问题在上下文层面的关联程度
    • 上下文覆盖率:衡量检索到的文本对正确答案全部信息的覆盖程度

    对比结果

    S3 Vectors 的精度

    OpenSearch Serverless 的精度

    由于两者采用相同的检索方式,因此精度水平基本相当。这表明,在仅使用向量检索的场景下,S3 Vectors 的精度与 OpenSearch Serverless 等现有向量存储相比并无明显差距。

    2. 与混合检索的精度对比

    接下来,我们使用包含产品 ID 等信息的数据集,对比 S3 Vectors 的向量检索与 OpenSearch Serverless 的混合检索精度。

    本次测试采用新数据集 —— 按用户整理的 Amazon 评论数据。

    混合检索验证数据集

    1. 2023年亚马逊评论

    https://amazon-reviews-2023.github.io

    该数据集包含约 2.8 万组

    product/productId: B000GKXY4S product/title: Crazy Shape Scissor Set product/price: unknown review/userId: A1QA985ULVCQOB review/profileName: Carleen M. Amadio “Lady Dragonfly” review/helpfulness: 2/2 review/score: 5.0 review/time: 1314057600 review/summary: Fun for adults too! review/text: I really enjoy these scissors for my inspiration books that I am making (like collage, but in books) and using these different textures these give is just wonderful, makes a great statement with the pictures and sayings. Want more, perfect for any need you have even for gifts as well. Pretty cool!

    在精度验证时,我们准备了如下所示的 “问题 – 答案” 配对,并重点围绕混合检索的核心特征 —— 关键词检索精度展开评估。

    评估用数据集示例

    问题:请告知商品 ID 为 B000GKXY4S 的评论摘要。

    答案:Fun for adults too!

    测试时,知识库配置保持不变,仅将 OpenSearch Serverless 的检索方式指定为 “混合检索”。

    精度验证结果

    S3 Vectors 的精度

    OpenSearch Serverless 的精度

    结果显示,在 “上下文相关性” 和 “上下文覆盖率” 两项指标上,采用混合检索的 OpenSearch Serverless 精度均优于仅支持向量检索的 S3 Vectors。

    以下为 “混合检索可成功匹配,但 S3 Vectors 向量检索未匹配成功” 的查询示例:

    查询示例

    请告诉我商品 ID 为 B000GKXY4S 的评论摘要。

    S3 Vectors(向量检索)结果:未检索到查询中包含的 ID :B000GKXY4S

    返回结果为 “product/productId: B000FP553C product/title: Kinesio Scissors

    OpenSearch Serverless(混合检索)结果:成功检索到查询中包含的 ID :B000GKXY4S

    返回结果为 “product/productId: B000GKXY4S product/title: Crazy Shape Scissor Set

    由此可见,由于 S3 Vectors 仅支持向量检索,在需指定 ID、特定单词等关键词的检索场景中,其精度会出现下降。

    总结

    本文结合与现有向量存储的对比,介绍了 S3 的新功能 ——S3 Vectors。尽管 S3 Vectors 在功能上存在一定限制,但对于仅需向量检索的场景,其功能已足够满足需求;加之其成本极低,非常值得尝试应用。

  • 在 Azure 中使用 Elasticsearch(Elastic Cloud)的要点 (下篇 )

    在 Azure 中使用 Elasticsearch(Elastic Cloud)的要点 (下篇 )

    本文作为在 Azure 中使用 Elasticsearch(Elastic Cloud)的要点下篇,将介绍在 Elastic Cloud 中执行以下操作的步骤。

    1. 版本升级

    1. 审计日志设置

    1. 版本升级

    关于 Elastic Stack 的版本升级

    Elastic Stack 有两种版本升级方式,各自的特点如下表所示:

    序号版本升级方式特点
    1滚动升级(Rolling Upgrade)无需停止服务即可完成版本升级
    2全集群升级(Full Cluster Upgrade)需先将服务全部停止

    在 Elastic Cloud 中,版本升级采用上述第 1 种 “滚动升级” 方式,因此无需停止服务即可完成版本升级。有关升级的详细信息,请参考以下链接:Upgrade versions | Elasticsearch Service Documentation | Elastic

    此外,在 Elastic Cloud 中,只需在图形用户界面(GUI)上点击一下,即可完成版本升级。下面实际操作一下具体步骤。

    在 Elastic Cloud 中升级 Elastic Stack

    (1)根据需要将 Deployment设为维护模式

    在 Elastic Cloud 中,如果对高负载的 Deployment 应用设置变更,不仅设置变更会耗费较长时间,最坏情况下还可能导致服务响应中断、设置变更失败。因此,虽然理论上无需停止服务即可完成版本升级,但当 Deployment 处于高负载状态时,也建议先将其切换为维护模式,之后再进行升级。

    访问 Elastic Cloud 的 Deployment 页面,选择菜单中的 “Edit”

    点击“Edit”

    在页面底部的 “Extented maintenance”(扩展维护)处勾选复选框,然后点击 “Save”(保存),即可将 Deployment 设为维护模式。

    在 “Extented maintenance” 处勾选复选框,点击 “Save”

    (2)点击 Elastic Cloud 的 Deployment 页面右侧的 “Upgrade”

    点击 “Upgrade”

    (3)选择版本,点击 “Upgrade”

    (=选择版本,点击 “Upgrade”

    通过以上步骤,即可完成版本升级。无需复杂操作就能轻松升级版本,从而持续使用最新功能,这是 Elastic Cloud 的一大重要优势。

    2. 审计日志设置

    关于 Elastic Stack 的审计日志

    Elasticsearch 和 Kibana 均支持输出审计日志。通过审计日志,可监控认证失败、连接拒绝等与安全相关的事件。

    有关审计日志的详细信息,请参考以下文档:

    审计日志默认处于未启用状态,因此需按以下步骤开启。

    (1)在 Elastic Cloud 的 Deployment管理页面中,点击 “Edit”

    点击 “Edit”

    (2)点击 Elasticsearch 右侧的链接 “Manage user settings and extensions”

    点击 Elasticsearch 右侧的 “Manage user settings and extensions”

    (3)为 Elasticsearch 应用审计日志设置

    设置内容如下:

    xpack.security.audit.enabled: true

    (4)点击 Kibana 右侧的链接 “Edit user settings”

    点击 “Edit user settings”

    (5)为 Kibana 也应用审计日志设置

    设置内容如下:

    xpack.security.audit.enabled: true

    (6)点击页面下方的 “Save”,应用设置

    点击 “Save”

    (7)在 Monitoring功能的 Logs中查看审计日志

    此时会输出 Elasticsearch 和 Kibana 的审计日志。

    查看审计日志

    从上述审计日志中可以看到,“y_nomura” 用户在两次认证失败(红色高亮部分)后,最终认证成功(黄色高亮部分)。通过输出此类审计日志,能够确认 “谁在何时登录”“访问了哪些资源” 等关键信息。

    总结

    截至目前,我们已通过操作篇,讲解了使用 Elastic Cloud 的关键要点。但除此之外,针对不同使用场景,仍有许多需要考虑的事项。

  • Azure 中使用 Elasticsearch(Elastic Cloud)的要点(上篇)

    Azure 中使用 Elasticsearch(Elastic Cloud)的要点(上篇)

    本文作为Azure 中使用 Elasticsearch(Elastic Cloud)的要点上篇,将介绍操作 Elastic Cloud 所需的各类设置的实施步骤。

    本文中,Elastic Cloud(Elasticsearch Service)将统一表述为 “Elastic Cloud”。

    1. 监控设置(Metric/Logs)

    关于监控功能

    利用监控功能,可一目了然地掌握集群状态;且当发生任何问题时,能够从资源和日志两方面快速开展问题排查。

    在 Elastic Cloud 中启用监控功能

    监控功能默认未启用,需通过以下步骤进行启用:

    (1) 访问 Elastic Cloud 的 Deployment页面,点击菜单中的 “Logs and metrics”

    点击 “Logs and metrics”

    (2) 点击 “Ship to a deployment”中的 “Enable”

    点击 “Enable”

    (3) 选择已构建的 Deployment,点击 “Save”

    监控功能即启用成功。

    点击 “Save”

    查看 Metric

    通过 Metric 可查看 Elastic Stack 各组件的服务器资源占用情况:

    (1) 在 Kibana 页面左侧菜单中,点击 “Stack Monitoring”

    点击 “Stack Monitoring”

    (2) 点击 Elasticsearch 的 “Overview”

    在概览中,可实时查看 Elasticsearch 整体的搜索性能与索引性能。

    点击 “Overview”

    (3) 在 Elasticsearch 的「Nodes」中,选择一个实例并点击

    从「Nodes」(节点)中选择一个实例并点击

    可实时查看每台服务器的资源状况。

    查看 Metric

    查看 Logs(日志)

    通过 Logs 可实时查看、筛选日志并开展排查工作:

    (1) 在 Kibana 页面左侧菜单中,点击 “Logs”

    点击 “Logs”

    在 Stream(流)页面中,会实时显示已导入 Elasticsearch 的各类日志。

    日志实时显示

    (2) 在画面顶部的搜索框中输入 “error”,执行日志筛选

    可通过筛选日志开展问题排查。

    输入 “error” 并执行日志筛选

    修改 Metric(指标)的保留期限

    Metric 的默认保留期限为 3 天。由于不同需求对应的保留期限可能不同,下面我们来修改这一设置:

    (1) 在 Kibana 页面左侧菜单中,点击 “Stack Management”

    点击 “Stack Management”

    (2) 点击 “Index Lifecycle Policies”(索引生命周期策略)

    点击 “Index Lifecycle Policies”

    (3) 在搜索框中输入 “.monitoring”,点击显示结果中的 “.monitoring-8-ilm-policy”

    点击 “.monitoring-8-ilm-policy”

    Elasticsearch 会将索引按 “阶段(Phase)” 进行管理,阶段的转换条件通过 ILM(Index Lifecycle Management,索引生命周期管理)进行定义。

    详情可参考以下链接:ILM: Manage the index lifecycle | Elasticsearch Guide [8.14] | Elastic

    修改前的设置如下表所示:

    阶段设置值
    Hot 阶段索引创建后 3 天,或主分片大小达到 50GB 以上时,对索引执行 Rollover(滚动更新)
    Warm 阶段执行 Forcemerge(强制合并),将分片段数合并为 1
    Delete 阶段滚动更新后 3 天,删除该索引

    简单来说,Hot 阶段中定义的 “Rollover(滚动更新)” 是指当满足特定条件时,自动创建新索引的功能。

    详情可参考以下链接:Rollover | Elasticsearch Guide [8.14] | Elastic

    (4) 将 Delete 阶段的数值从 “3 days”修改为 “31 days”,点击 “Save Policy”

    修改设置并点击 “Save Policy”

    通过上述步骤,已完成设置修改,滚动更新后 31 天的索引将被自动删除。

    2. Snapshot设置

    关于 Snapshot设置

    在 Elastic Cloud 中,默认设置为每 30 分钟获取一次快照。下面我们对该设置进行确认与修改:

    (1) 在 Kibana 页面左侧菜单中,点击 “Stack Management”

    点击 “Stack Management”

    (2) 点击 “Snapshot and Restore”

    点击 “Snapshot and Restore”

    (3) 点击 “Policies”标签页,点击 “cloud-snapshot-policy” 右侧的 “Edit”按钮

    点击 “Edit” 按钮

    (4) 修改「Schedule」的设置值

    时间设置可通过 Cron 表达式进行配置。另外,请注意时间采用 UTC 时区。

    详情可参考:API conventions | Elasticsearch Guide [8.14] | Elastic

    修改 “Schedule” 的设置值

    (5) 根据需要修改 “Expiration”、“Snapshots to retain”的设置值

    根据需要修改设置

    (6) 点击 “Save policy”

    点击 “Save policy”

    (7) 点击 “cloud-snapshot-policy”,查看 “Summary”

    修改后,Snapshot将在每天 0 点自动获取。

    查看 “Summary”

    3. 告警设置

    关于 Elastic Cloud 的告警功能

    在 Elastic Cloud 中,可通过 Alert功能实现监控与通知。此外,系统默认提供了多个可配置的监控项,便于快速完成 Alert设置。下面我们通过创建默认规则来使用 Alert功能:

    (1) 从左侧菜单点击 “Stack Monitoring”,在监控页面右上角选择 “alerts and rules”,点击 “Create default rules”

    点击 “Create default rules”

    (2) 点击 “Create”至此,告警设置完成。最后我们来确认已创建的规则列表。

    点击 “Create”

    (3) 点击 “Stack Management”,选择 “Alerts”,然后点击页面右上角的 “Manage rules”

    点击 “Manage rules”

    此时会显示已创建的规则列表。通过编辑规则,可修改触发条件及配置通知方式。

    已创建的规则列表

    例如,“CPU Usage”规则会在 CPU 使用率 5 分钟平均值超过 85% 时触发检测并发送通知。

    CPU Usage(CPU 使用率)

    另外,默认设置下通知会输出至 Kibana 日志,但也可使用邮件、Slack 等多种连接器作为通知渠道。

    连接器列表

    总结

    在实际操作过程中,除了上述 设置外,可能还需要应对以下需求:

    • 版本升级对应
    • 审计日志

    因此,我们将在下次的文章中对上述内容进行讲解。

  • 在 Elasticsearch 中高速实现类 LIKE 搜索的部分匹配搜索方法

    在 Elasticsearch 中高速实现类 LIKE 搜索的部分匹配搜索方法

    在工作中,经常听到有人反馈关系型数据库(MySQL、PostgreSQL 等)搜索功能存在 “LIKE 搜索速度慢” 的问题。尤其是在处理大量数据的系统中,LIKE 搜索往往会导致性能下降,搜索响应延迟的问题屡见不鲜。因此,越来越多的案例开始考虑从关系型数据库迁移到 Elasticsearch 来解决这一问题。

    Elasticsearch 是一款能够实现高速、灵活全文搜索的强大搜索引擎。但要充分发挥其性能,恰当的数据设计与查询设计至关重要。

    本文将聚焦于 “如何在 Elasticsearch 中高速实现类似 SQL LIKE 搜索的部分匹配搜索” 进行讲解。

    1. 数据类型的差异

    在 Elasticsearch 中进行字符串搜索前,首先需要理解 keyword 型与 text 型的区别。向 Elasticsearch 中注册字符串型字段时,需预先设定该字段采用哪种数据类型。

    keyword 型:适用于精确字符串匹配

    keyword 型是将字符串以原始形式注册到索引中的数据类型。由于其能高速执行完全匹配搜索、排序、聚合等操作,因此像 ID、商品分类这类短字符串通常会注册为 keyword 型。

    text 型:适用于全文搜索

    text 型擅长自然语言处理与全文搜索。设置为该类型的字段在注册到索引时,会通过分析器(Analyzer)将文本按单词或短语拆分后再进行注册。

    文本按何种规则拆分为令牌(Token)由分析器决定,需根据搜索需求设计合适的分析器。

    参考文档:analyzer | Elasticsearch Guide [8.16] | Elastic

    我们可使用分析 API(Analyze API)确认字符串是如何被拆分令牌并注册的。以下是使用默认分析器(standard Analyzer)进行令牌化的示例。

    POST _analyze
    {
      "text":     "Elasticsearch is powerful"
    }
    

    从结果可以看出,文本被拆分为 “elasticsearch”“is”“powerful” 三个令牌。

    {
      "tokens": [
        {
          "token": "elasticsearch",
          "start_offset": 0,
          "end_offset": 13,
          "type": "<ALPHANUM>",
          "position": 0
        },
        {
          "token": "is",
          "start_offset": 14,
          "end_offset": 16,
          "type": "<ALPHANUM>",
          "position": 1
        },
        {
          "token": "powerful",
          "start_offset": 17,
          "end_offset": 25,
          "type": "<ALPHANUM>",
          "position": 2
        }
      ]
    }
    

    通常情况下,部分匹配搜索的目标字段会注册为 text 型。

    2. 实现部分匹配搜索的方法及特点

    keyword 型字段的部分匹配搜索

    对于 keyword 型字段,也可使用 wildcard 查询实现部分匹配搜索。wildcard 查询与 LIKE 搜索类似,是按特定模式匹配字符串的查询,其使用方式与 SQL 的 LIKE 搜索直观上较为接近。

    但需注意,wildcard 查询的计算成本极高,索引规模越大,对搜索系统产生不良影响的可能性就越高。

    wildcard 查询示例(搜索以 “Elasticsearch” 开头的字符串)

    GET test_index/_search
    {
      "query": {
        "wildcard": {
          "message": {
            "value": "Elasticsearch*"
          }
        }
      }
    }
    

    text 型字段的部分匹配搜索

    对 text 型字段进行部分匹配搜索时,通常使用 match 查询或 match_phrase 查询。与 text 型字段拆分令牌后注册到索引的逻辑相同,搜索字符串也会被拆分令牌,只要目标字段与搜索字符串的令牌能够匹配,对应的结果就会命中。其中,match 查询适用于单词搜索,match_phrase 查询适用于短语搜索。

    match 查询示例(搜索以 “Elasticsearch” 开头的字符串)

    GET test_index/_search
    {
      "query": {
        "match": {
          "message": "Elasticsearch"
        }
      }
    }
    

    3. 恰当的分析器设计

    在 Elasticsearch 中进行字符串搜索时,虽然默认使用 match 或 match_phrase 查询,但如果分析器设置不当,可能会出现无法返回预期结果、反而返回大量无关结果等问题。

    例如,在第 1 部分的示例中,若向已注册的 test_index 搜索 “power” 字符串,将无法命中结果。

    搜索 “Elastic” 的查询

    GET test_index/_search
    {
      "query": {
        "match": {
          "message": "power"
        }
      }
    }
    

    搜索结果

    {
      "took": 0,
      "timed_out": false,
      "_shards": {
        "total": 1,
        "successful": 1,
        "skipped": 0,
        "failed": 0
      },
      "hits": {
        "total": {
          "value": 0,
          "relation": "eq"
        },
        "max_score": null,
        "hits": []
      }
    }
    

    无法命中的原因是,索引中注册的令牌为 “elasticsearch”“is”“powerful”,而 “power” 这一令牌并未被注册。因此,要实现预期的搜索结果,必须分别合理设计:

    • 数据注册时使用的分析器
    • 搜索字符串使用的分析器

    4. 对 text 型字段实现类 LIKE 从句的搜索方法

    要对 text 型字段实现类似 LIKE 从句的 “搜索包含特定模式字符串” 的功能,可通过对应用了包含 N-gram 令牌生成器(tokenizer)的分析器的字段执行 match_phrase 查询来实现。

    使用 N-gram 令牌生成器时,注册的字符串会被机械地按任意长度拆分令牌。例如,将 “Elasticsearch” 这一字符串按 2 个字符(bi-gram)拆分 N-gram 令牌,会得到 “El”“la”“as”……“rc”“ch” 等令牌,这些令牌会被注册到索引中。

    可在创建索引时按如下方式设置分析器,为特定字段配置包含 N-gram 令牌生成器的分析器。

    PUT test_index
    {
      "mappings": {
        "properties": {
          "message": {
            "type": "text",
            "analyzer": "my_analyzer"
          }
        }
      },
      "settings": {
        "analysis": {
          "analyzer": {
            "my_analyzer": {
              "tokenizer": "my_tokenizer"
            }
          },
          "tokenizer": {
            "my_tokenizer": {
              "type": "ngram",
              "min_gram": 2,
              "max_gram": 2
            }
          }
        }
      }
    }
    

    即便使用 match_phrase 搜索 “lastic”,搜索字符串也会被拆分为 “la”“as”“st”“ti”“ic” 等令牌,只有包含所有这些令牌的字符串才会命中。通过这种方式,即可实现相当于 LIKE 搜索的部分匹配搜索。

    GET test_index/_search
    {
      "query": {
        "match_phrase": {
          "message": "lastic"
        }
      }
    }
    
    {
      "took": 1,
      "timed_out": false,
      "_shards": {
        "total": 1,
        "successful": 1,
        "skipped": 0,
        "failed": 0
      },
      "hits": {
        "total": {
          "value": 1,
          "relation": "eq"
        },
        "max_score": 1.1507283,
        "hits": [
          {
            "_index": "test_index",
            "_id": "ESDup5MBGJks9_KvUZZQ",
            "_score": 1.1507283,
            "_source": {
              "message": "Elasticsearch is powerful"
            }
          }
        ]
      }
    }

    5. 总结

    本次介绍了在 Elasticsearch 中实现类 LIKE 搜索的部分匹配方法。

    若仅需实现部分匹配搜索,使用 wildcard 查询即可达成,但从系统运行时的搜索性能等角度考量,尽管需要提前进行分析器(Analyzer)设置等额外工作,采用 N-gram 结合 match_phrase 查询仍是基础且推荐的方案

    当然,根据具体的搜索需求,还需要进行更细致的分析器及查询设计。尤其在搜索性能与搜索精度之间如何取得平衡,是运用 Elasticsearch 过程中无法回避的关键问题。希望本文能为 Elasticsearch 的搜索设计提供参考。

  • 尝试用 Cline × Amazon Bedrock 进行 CRUD 应用的全栈开发

    最近,Cline 作为一款开发辅助 AI 智能体备受关注。

    相关参考链接:github.com

    Cline 是 Visual Studio Code(VSCode)的扩展插件,其特点不仅限于生成代码,还能连贯完成命令执行、运行验证及调试等一系列操作。

    Cline 支持指定任意生成式 AI 模型来生成代码。因此,将其与安全性高、可在实际开发场景中运用的 Amazon Bedrock 结合,便能在业务场景中发挥作用。本次,我们将以 Bedrock 作为大语言模型(LLM),围绕 “能否开发具备 CRUD 功能的应用” 这一目标,以开发 TODO 应用为主题展开尝试。

    概述

    什么是 Cline?

    Cline 是一款以 VSCode 扩展插件形式提供的 AI 智能体,只需简单指令,就能生成整个应用的代码。

    其核心特点如下:

    • 可完成命令执行(例如:创建 / 删除文件或目录、安装依赖库、启动已开发的应用等);
    • 可自动完成运行验证与调试;
    • 数据不会发送至 Cline 服务器(因支持配置任意生成式 AI 模型的 API,并通过该 API 生成内容)。

    使用 Amazon Bedrock 的优势

    如前所述,Cline 可与多种生成式 AI 模型联动,本次我们选择使用 Amazon Bedrock。使用 Bedrock 的优势如下:

    • 输入数据不会被用于模型训练,安全性更有保障;
    • 只需通过配置,即可切换使用多个模型。

    基于以上原因,在业务场景中使用 Cline 时,Amazon Bedrock 会成为极具竞争力的选择。接下来,我们就实际尝试用 Cline × Amazon Bedrock 开发具备 CRUD 功能的 Web 应用。

    TODO 应用的概述

    本次开发的 TODO 应用,最终实现效果如下:

    该 TODO 应用支持填写标题、截止日期和说明来添加任务,同时会记录任务的 “是否完成” 状态,还具备删除功能。下面我们开始为开发这款 TODO 应用做准备。

    开发前的准备工作

    创建 IAM 用户

    我们创建了供 Cline 调用 Bedrock 时使用的 IAM 用户,并为其配置了以下权限。实际场景中应进一步缩小权限范围,本次为简化操作,暂赋予 Bedrock 全访问权限。此外,由于 Cline 需要会话令牌,因此还为该用户配置了获取会话令牌的权限。

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "AllowBedrockAll",
          "Effect": "Allow",
          "Action": "bedrock:*",
          "Resource": "*"
        },
        {
          "Sid": "AllowStsGetSessionToken",
          "Effect": "Allow",
          "Action": "sts:GetSessionToken",
          "Resource": "*"
        }
      ]
    }
    

    Cline 的配置

    我们对 Cline 进行了调用 Bedrock 所需的配置。在配置界面中,填入了上一节创建的 IAM 用户的访问密钥、密钥和会话令牌。

    本次选用的模型是 Claude 3.7 Sonnet。此前曾尝试用成本更低的 Claude 3.5 Haiku 开发应用,但模型精度不稳定,例如明明需要显示 “Task Completed”,但应包含 Docker 文件的文件夹中却未生成任何文件等问题。虽然 Cline 在调试阶段会尝试修复这些问题,但过程中需要反复试错修改,既耗费时间,也产生了不必要的成本。因此,若要开发的不是简单脚本,而是像 CRUD 应用这样具备一定复杂度的完整系统,从一开始就使用 Claude 3.7 Sonnet,模型精度会更稳定。

    搭建 Linux 命令执行环境

    Cline 的一大核心特点是支持执行命令,但它默认倾向于执行 Linux 命令。

    而本次我们在 Windows 环境下进行验证,VSCode 的默认终端是 Powershell。若不做调整,Cline 会尝试执行 Linux 命令,导致命令全部报错。

    因此,为了在 Windows 环境下也能执行 Linux 命令,我们按以下步骤进行了设置:

    1. 安装 Git Bash;
    2. 将 Git Bash 设置为 VSCode 的默认终端。

    开发 TODO 应用

    提示词

    本次传递给 Cline 的任务提示词如下:

    请开发一个 TODO 应用
    
    #需求
    
    -支持将任务以带复选框(Checkbox)的项目形式进行添加和删除。
    
    -已完成的任务,通过勾选复选框,文字需变为浅色并添加删除线。
    
    -支持为每个任务输入截止日期(非必填项)。
    
    #约束条件
    
    -采用 PostgreSQL 实现 CRUD(创建、读取、更新、删除)操作。
    
    -通过 Docker 搭建数据库(DB)。
    
    -后端与前端不使用 Docker,直接在运行环境中启动。
    
    -开发完成后,需完成应用的启动操作。
    
    -界面需设计得现代且美观。

    此外,我们在 Cline 的设置界面中,按以下内容配置了 “Custom Instructions”。

    Custom Instructions 是用于编写通用规则等内容的部分,会在每次向 AI 发送请求时,自动追加到提示词的末尾。

    #运行环境信息
    
    -运行环境为 Windows。
    
    -Docker 环境由 Rancher Desktop 提供。
    
    #实现规则
    ##通用规则
    
    -为每个代码块添加中文注释。
    
    -按合理的文件夹结构创建项目
    
    ##后端
    
    -按 Google 风格编写文档字符串(docstring)。
    
    -使用 Python 实现。
    
    -通过 pyenv、Poetry 创建虚拟环境(pyenv 与 Poetry 已提前在环境中安装完成)。
    
    ##前端
    
    -使用 React 实现。
    
    -通过 npm 进行包管理。

    在 Custom Instructions 中,我们指定 “环境搭建工具使用已提前安装的版本”。若未做此指定,Cline 会尝试从安装这些工具开始操作,过程中会出现大量试错,额外耗费时间与成本。因此,开发环境的准备工作由人工完成会更高效。

    使用 Cline 的开发结果

    根据上一节的提示词向 Cline 下达指令后,Cline 自动完成了以下一系列操作:

    1. 创建文件夹结构
    2. 安装所需依赖库
    3. 设计数据库 schema(表结构)
    4. 通过 Docker 搭建数据库
    5. 实现并启动前端与后端
    6. 运行验证与调试

    最终生成的成果如下

    本次仅使用简单提示词,未过多指定细节,但 Cline 仍以接近人工开发的水平完成了项目,例如:

    • 前端使用 Material-UI(Material Design 组件库)
    • 后端使用 FastAPI,并创建了模型类
    • 数据库 schema 中包含 “创建时间”“更新时间” 字段

    此外,本次开发的代码量约为 0.5KL,耗费成本约 5.2 美元。与人工完成 “从开发到运行验证” 所需的人力成本相比,成本大幅降低。

    试用应用

    接下来,我们实际试用一下这款应用。下图展示了 “添加任务后,将其中 1 个任务标记为已完成” 的效果

    我们尝试直接访问数据库,发现操作结果已实时同步到数据库中

    另外,当我们从界面中删除已完成的任务时,数据库中也执行了物理删除操作

    总结

    通过 “Cline×Amazon Bedrock” 的组合,我们借助安全的生成式 AI 模型,完成了 CRUD 应用从 “界面开发” 到 “数据库实现” 的全流程开发与运行验证。

    同时,我们也得出了以下几点感受:

    1. 开发环境的准备工作,由人工提前完成效率更高;
    2. 若要稳定且精准地开发 “CRUD 应用” 这类具备一定复杂度的项目,需使用 Claude 3.7 Sonnet 模型。

    借助 Amazon Bedrock,Cline 在业务场景中的实用性大幅提升,未来我们将积极推动其应用。

  • 活用 Amazon Bedrock 的 Rerank API 提升 RAG 精度

    活用 Amazon Bedrock 的 Rerank API 提升 RAG 精度

    在 RAG(检索增强生成:Retrieval-Augmented Generation)为用户提供准确信息的过程中,检索精度尤为关键。

    而提升检索精度的方法之一便是 “重排序(Rerank)”。

    通过执行重排序操作,将检索得到的结果按相关度重新排序,能更轻松地针对用户所需信息给出回答。

    如今,Amazon Bedrock 已新增支持重排序的模型,且可与 Bedrock Knowledge Base 搭配使用。

    以往,实现这一功能需要自行托管模型等,颇为繁琐;而现在,只需在向 Knowledge Base 发起的检索请求中添加相关设置,即可一并执行检索与重排序操作,且仅能获取重排序后的结果。

    本次我们将实际使用重排序模型,验证检索结果会发生怎样的变化。

    1. 前言

    1.1 什么是重排序(Rerank)

    在包含 Bedrock Knowledge Base 在内的 RAG 检索中,向量检索的应用十分广泛。

    然而,仅依靠向量检索往往无法达到足够的检索精度,难以给出恰当的回答。

    因此,对通过向量检索获取的文档进行重排序处理,可使相关度更高的文档出现在检索结果的靠前位置。

    重新排序的图像

    1.2 以往的实现方式

    此前,要在 RAG 系统中集成重排序处理,需搭建 SageMaker 实例、托管重排序专用模型并执行推理。

    例如,在 2024 年 8 月时,若要使用 Cohere Rerank 3,就需按照下述文章的说明创建 SageMaker 实例。

    aws.amazon.com

    这种方式存在诸多问题,如需要投入精力准备 SageMaker 实例与重排序模型,且会产生运营成本。

    1.3 Bedrock 支持的重排序模型

    自 2024 年 12 月起,可通过 Bedrock 使用重排序模型。

    借助该重排序模型,无需自行托管模型,仅通过调用 API 即可执行重排序操作。

    这不仅省去了运营管理的繁琐工作,还无需一直启动服务器,只需根据使用量付费,让用户能轻松开启重排序功能的使用。

    除了可通过 Bedrock 的 InvokeModel API 调用外,还支持通过 Bedrock Knowledge Base 的 Rerank API、Retrieve API、RetrieveAndGenerate API、RetrieveAndGenerateStream API 进行调用。

    截至 2025 年 1 月,提供的模型有 Amazon Rerank 1.0(以下简称 Amazon Rerank 模型)和 Cohere Rerank 3.5(以下简称 Cohere Rerank 模型)。

    2. 尝试应用重排序模型

    本次验证将使用本文中已采用的、模拟酒店评论检索的数据。

    此次以 “烤肉好吃的酒店” 为检索词,期望 “使用本地产蔬菜和肉类制作的烤肉料理” 的第 10 条评论以及 “炭火烤制的牛排” 的第 7 条评论能出现在检索结果的靠前位置。

    重排序模型选用 Amazon Rerank 模型。

    序号内容
    1这家酒店的温泉堪称顶级疗愈。源泉直供的温泉水格外柔和,泡完后肌肤感觉滑溜溜的。从露天温泉能眺望到美丽的群山,夜晚还能一边泡澡一边欣赏满天繁星。这是一家让人想反复前往的温泉酒店。
    2酒店的温泉非常舒服,能让人彻底放松。室内温泉和露天温泉各具特色,尤其是从露天温泉看到的庭院景色美不胜收,可欣赏到四季不同的美景。水温也恰到好处,长时间浸泡也不会觉得疲惫。
    3早就听闻这是一家以温泉为特色的酒店,实际体验远超预期。因直接使用天然温泉源泉,水质极佳,泡完后身体持续暖暖的。我们还预约了私人温泉,在专属空间里度过了惬意的时光。
    4温泉区域宽敞开阔,视野极佳。从露天温泉能一览大海,可伴着海浪声悠闲度日。水温也不会过高,能慢慢暖遍全身,非常满意。此外,还支持当日往返使用,让人能轻松前来,这点很贴心。
    5温泉散发着令人舒心的硫磺香气,让人真切感受到来到了温泉胜地。温泉水功效显著,能明显感觉到肌肤变得光滑。这里有多个温泉池,有时特定时段还能独享,让人体验到奢华感。另外,泡完温泉后提供的冰镇饮品也是个惊喜服务。
    6酒店的餐食宛如艺术品。大量使用本地新鲜食材制作的怀石料理,不仅外观精美,每一道菜都能让人感受到制作的用心。尤其是用当季海鲜制作的刺身,堪称绝品,仅凭这一点就想再次前来。
    7晚餐有很多本地特色菜,非常满意。特别是炭火烤制的牛排,入口即化,美味得让人想一再续盘。早餐种类也很丰富,用本地蔬菜制作的沙拉和手工豆腐都很美味。
    8晚餐是套餐形式,每道菜都很好吃,其中最令人印象深刻的是用本地采摘的蔬菜制作的前菜和自制甜点。采用凸显食材本味的简单烹饪方式,充分展现了食材的优良品质。早餐营养均衡,刚出炉的面包尤其美味。
    9酒店的餐食超出预期。因靠近海边,大量使用新鲜海鲜,刺身和煮鱼都非常好吃。晚餐分量充足,每道菜的调味都饱含心意。早餐的日式料理也很美味,尤其是温泉蛋堪称绝品。
    10晚餐是大量使用本地食材制作的创意料理,每道菜都能感受到巧思。特别是用本地产蔬菜和肉类制作的烤肉料理,堪称绝品,充分凸显了食材本身的味道。早餐也很用心,有手工果酱和刚出炉的面包等,非常满意。

    2.1 通过 Bedrock 的 InvokeModel API 使用

    InvokeModel API 是用于调用 Bedrock 所提供模型的 API。

    在请求体(body)中输入想要进行重排序的文档列表以及用户的查询语句后,就能在响应结果中获取到按与用户查询语句相关度从高到低重新排序的文档,以及各自的相关度(分数)。

    代码

    query = "烤肉好吃的酒店"
    documents = [
        "这家酒店的温泉堪称顶级疗愈。源泉直供的温泉水格外柔和,泡完后肌肤感觉滑溜溜的。从露天温泉能眺望到美丽的群山,夜晚还能一边泡澡一边欣赏满天繁星。这是一家让人想反复前往的温泉酒店。",
        # (省略)
    ]
    
    response = bedrock.invoke_model(
        modelId="amazon.rerank-v1:0",
        body=json.dumps({
            "query": query,
            "documents": documents,
            "top_n": 3,
        }),
    )
    
    body = json.loads(response["body"].read())
    pprint.pprint(body["results"])
    

    输出

    [{'index': 9, 'relevance_score': 0.001466458403084568},
     {'index': 6, 'relevance_score': 0.0005013742398679934},
     {'index': 8, 'relevance_score': 0.0003640086870995012}]
    

    ※重排序结果中包含的索引(index)以 0 为起始,为了与上方表格保持一致,需在索引数值上加 1。

    结果

    序号内容
    10晚餐是大量使用本地食材制作的创意料理,每道菜都能感受到巧思。特别是用本地产蔬菜和肉类制作的烤肉料理,堪称绝品,充分凸显了食材本身的味道。早餐也很用心,有手工果酱和刚出炉的面包等,非常满意。
    7晚餐有很多本地特色菜,非常满意。特别是炭火烤制的牛排,入口即化,美味得让人想一再续盘。早餐种类也很丰富,用本地蔬菜制作的沙拉和手工豆腐都很美味。
    9酒店的餐食超出预期。因靠近海边,大量使用新鲜海鲜,刺身和煮鱼都非常好吃。晚餐分量充足,每道菜的调味都饱含心意。早餐的日式料理也很美味,尤其是温泉蛋堪称绝品。

    可以确认,正如预期的那样,第 10 条和第 7 条评论内容排在了靠前位置。

    2.2 通过 Bedrock Knowledge Base 的 Rerank API 使用

    Rerank API 是作为 Knowledge Base 的功能提供的,但其本质与上述的 InvokeModel 相同,输入文档列表和用户查询语句后,就能得到重排序后的文档列表。

    代码

    region = boto3.Session().region_name
    amazon_rerank_arn = f"arn:aws:bedrock:{region}::foundation-model/amazon.rerank-v1:0"
    
    response = bedrock_agent.rerank(
        queries=[
            {
                "type": "TEXT",
                "textQuery": {
                    "text": query,
                },
            },
        ],
        sources=[
            {
                "inlineDocumentSource": {
                    "textDocument": {
                        "text": document,
                    },
                    "type": "TEXT",
                },
                "type": "INLINE",
            } for document in documents
        ],
        rerankingConfiguration={
            "type": "BEDROCK_RERANKING_MODEL",
            "bedrockRerankingConfiguration": {
                "numberOfResults": 3,
                "modelConfiguration": {
                    "modelArn": amazon_rerank_arn,
                },
            },
        },
    )
    
    pprint.pprint(response["results"])
    

    输出

    [{'index': 9, 'relevanceScore': 0.0014664584305137396},
     {'index': 6, 'relevanceScore': 0.0005013742484152317},
     {'index': 8, 'relevanceScore': 0.0003640086797531694}]
    

    可以确认,得到了与使用 InvokeModel 时完全相同的结果。

    2.3 通过 Bedrock Knowledge Base 的 Retrieve API 使用

    与 InvokeModel、Rerank API 不同,在 Retrieve API 中,无需传入文档列表作为输入。

    该 API 以用户的查询语句为输入,先通过用户查询语句检索向量数据库,再将检索结果作为文档列表进行重排序。

    为了使用 Retrieve API,我们先创建了知识库,并将上述内容逐条作为一个数据块进行存储。

    首先确认不进行重排序时的结果。

    代码

    response = bedrock_agent.retrieve(
        knowledgeBaseId=knowledgebase_id,
        retrievalConfiguration={
            "vectorSearchConfiguration": {
                "numberOfResults": 3,
                "overrideSearchType": "SEMANTIC",
            },
        },
        retrievalQuery={
            "text": query,
        },
    )
    
    pprint.pprint(response["retrievalResults"])
    

    输出

    [{'content': {'text': '酒店的餐食宛如艺术品。大量使用本地新鲜食材制作的怀石料理,不仅外观精美,每一道菜都能让人感受到制作的用心。尤其是用当季海鲜制作的刺身,堪称绝品,仅凭这一点就想再次前来。',
                  'type': 'TEXT'},
      'location': {'s3Location': {'uri': 's3://xxx/006.txt'},
                   'type': 'S3'},
      'score': 0.43565163},
     {'content': {'text': '酒店的餐食超出预期。因靠近海边,大量使用新鲜海鲜,刺身和煮鱼都非常好吃。晚餐分量充足,每道菜的调味都饱含心意。早餐的日式料理也很美味,尤其是温泉蛋堪称绝品。',
                  'type': 'TEXT'},
      'location': {'s3Location': {'uri': 's3://xxx/009.txt'},
                   'type': 'S3'},
      'score': 0.435101},
     {'content': {'text': '晚餐是大量使用本地食材制作的创意料理,每道菜都能感受到巧思。特别是用本地产蔬菜和肉类制作的烤肉料理,堪称绝品,充分凸显了食材本身的味道。早餐也很用心,有手工果酱和刚出炉的面包等,非常满意。',
                  'type': 'TEXT'},
      'location': {'s3Location': {'uri': 's3://xxx/010.txt'},
                   'type': 'S3'},
      'score': 0.4281698}]
    

    结果

    序号内容
    6酒店的餐食宛如艺术品。大量使用本地新鲜食材制作的怀石料理,不仅外观精美,每一道菜都能让人感受到制作的用心。尤其是用当季海鲜制作的刺身,堪称绝品,仅凭这一点就想再次前来。
    9酒店的餐食超出预期。因靠近海边,大量使用新鲜海鲜,刺身和煮鱼都非常好吃。晚餐分量充足,每道菜的调味都饱含心意。早餐的日式料理也很美味,尤其是温泉蛋堪称绝品。
    10晚餐是大量使用本地食材制作的创意料理,每道菜都能感受到巧思。特别是用本地产蔬菜和肉类制作的烤肉料理,堪称绝品,充分凸显了食材本身的味道。早餐也很用心,有手工果酱和刚出炉的面包等,非常满意。

    当获取前 3 条结果时,第 10 条评论排在第 3 位,而第 7 条评论未出现在检索结果中。

    若使用这样的检索结果进行 RAG,恐怕难以得到高精度的回答。

    接下来,在 Retrieve API 中指定重排序模型,确认检索结果会发生怎样的变化。

    代码

    response = bedrock_agent.retrieve(
        knowledgeBaseId=knowledgebase_id,
        retrievalConfiguration={
            "vectorSearchConfiguration": {
                # (1) 首次检索时获取 10 条结果
                "numberOfResults": 10,
                "overrideSearchType": "SEMANTIC",
                "rerankingConfiguration": {
                    "bedrockRerankingConfiguration": {
                        "modelConfiguration": {
                            "modelArn": amazon_rerank_arn,
                        },
                        # (2) 对检索得到的 10 条结果进行重排序,并返回前 3 条
                        "numberOfRerankedResults": 3,
                    },
                    "type": "BEDROCK_RERANKING_MODEL",
                },
            },
        },
        retrievalQuery={
            "text": query,
        },
    )
    
    pprint.pprint(response)
    

    输出

    [{'content': {'text': '晚餐是大量使用本地食材制作的创意料理,每道菜都能感受到巧思。特别是用本地产蔬菜和肉类制作的烤肉料理,堪称绝品,充分凸显了食材本身的味道。早餐也很用心,有手工果酱和刚出炉的面包等,非常满意。',
                  'type': 'TEXT'},
      'location': {'s3Location': {'uri': 's3://xxx/010.txt'},
                   'type': 'S3'},
      'score': 0.0014721895568072796},
     {'content': {'text': '晚餐有很多本地特色菜,非常满意。特别是炭火烤制的牛排,入口即化,美味得让人想一再续盘。早餐种类也很丰富,用本地蔬菜制作的沙拉和手工豆腐都很美味。',
                  'type': 'TEXT'},
      'location': {'s3Location': {'uri': 's3://xxx/007.txt'},
                   'type': 'S3'},
      'score': 0.0004994205664843321},
     {'content': {'text': '酒店的餐食超出预期。因靠近海边,大量使用新鲜海鲜,刺身和煮鱼都非常好吃。晚餐分量充足,每道菜的调味都饱含心意。早餐的日式料理也很美味,尤其是温泉蛋堪称绝品。',
                  'type': 'TEXT'},
      'location': {'s3Location': {'uri': 's3://xxx/009.txt'},
                   'type': 'S3'},
      'score': 0.0003640086797531694}]
    

    结果

    序号内容
    10晚餐是大量使用本地食材制作的创意料理,每道菜都能感受到巧思。特别是用本地产蔬菜和肉类制作的烤肉料理,堪称绝品,充分凸显了食材本身的味道。早餐也很用心,有手工果酱和刚出炉的面包等,非常满意。
    7晚餐有很多本地特色菜,非常满意。特别是炭火烤制的牛排,入口即化,美味得让人想一再续盘。早餐种类也很丰富,用本地蔬菜制作的沙拉和手工豆腐都很美味。
    9酒店的餐食超出预期。因靠近海边,大量使用新鲜海鲜,刺身和煮鱼都非常好吃。晚餐分量充足,每道菜的调味都饱含心意。早餐的日式料理也很美味,尤其是温泉蛋堪称绝品。

    通过执行重排序,第 10 条和第 7 条内容占据了前 2 位。

    这样一来,就能为用户提供更多其所需的信息了。

    3. Amazon Rerank 模型与 Cohere Rerank 模型的对比

    接下来,我们使用同样可在 Bedrock 上使用的 Cohere Rerank 模型对相同内容进行测试。

    只需将 modelArn 替换为 Cohere Rerank 模型对应的 ARN,就能切换所使用的重排序模型。

    操作起来非常简便。

    代码

    cohere_rerank_arn = f"arn:aws:bedrock:{region}::foundation-model/cohere.rerank-v3-5:0"
    # (省略)
    

    输出

    [{'content': {'text': '晚餐是大量使用本地食材制作的创意料理,每道菜都能感受到巧思。特别是用本地产蔬菜和肉类制作的烤肉料理,堪称绝品,充分凸显了食材本身的味道。早餐也很用心,有手工果酱和刚出炉的面包等,非常满意。',
                  'type': 'TEXT'},
      'location': {'s3Location': {'uri': 's3://xxx/010.txt'},
                   'type': 'S3'},
      'score': 0.3279808461666107},
     {'content': {'text': '酒店的餐食宛如艺术品。大量使用本地新鲜食材制作的怀石料理,不仅外观精美,每一道菜都能让人感受到制作的用心。尤其是用当季海鲜制作的刺身,堪称绝品,仅凭这一点就想再次前来。',
                  'type': 'TEXT'},
      'location': {'s3Location': {'uri': 's3://xxx/006.txt'},
                   'type': 'S3'},
      'score': 0.1456373631954193},
     {'content': {'text': '晚餐有很多本地特色菜,非常满意。特别是炭火烤制的和牛牛排,入口即化,美味得让人想一再续盘。早餐种类也很丰富,用本地蔬菜制作的沙拉和手工豆腐都很美味。',
                  'type': 'TEXT'},
      'location': {'s3Location': {'uri': 's3://xxx/007.txt'},
                   'type': 'S3'},
      'score': 0.11919290572404861}]
    

    结果

    序号内容
    10晚餐是大量使用本地食材制作的创意料理,每道菜都能感受到巧思。特别是用本地产蔬菜和肉类制作的烤肉料理,堪称绝品,充分凸显了食材本身的味道。早餐也很用心,有手工果酱和刚出炉的面包等,非常满意。
    6酒店的餐食宛如艺术品。大量使用本地新鲜食材制作的怀石料理,不仅外观精美,每一道菜都能让人感受到制作的用心。尤其是用当季海鲜制作的刺身,堪称绝品,仅凭这一点就想再次前来。
    7晚餐有很多本地特色菜,非常满意。特别是炭火烤制的和牛牛排,入口即化,美味得让人想一再续盘。早餐种类也很丰富,用本地蔬菜制作的沙拉和手工豆腐都很美味。

    与使用 Amazon Rerank 模型时相比,第 7 条的排名下降了一位,但仍在前三之列。

    第 6 条内容虽然是关于海鲜料理而非肉类料理的评论,但它是关于美味料理的评论,而非温泉相关,因此我认为其得分较高。

    这样一来,在 RAG 生成回答时,也能在不缺失信息的情况下进行内容生成了。

    4. 其他

    4.1 调用速度

    我们对 Amazon Rerank 模型与 Cohere Rerank 模型的响应速度是否存在差异进行了验证。

    针对俄勒冈区域的模型,我们分别对相同请求各执行 5 次,通过比较响应时间的平均值来分析差异。

    Amazon Rerank 模型

    序号响应时间(秒)
    10.895
    20.687
    30.734
    40.828
    50.775
    平均0.784

    Cohere Rerank 模型

    序号响应时间(秒)
    10.454
    20.508
    30.533
    40.495
    50.453
    平均0.489

    对比结果显示,Cohere Rerank 模型的速度约为 Amazon Rerank 模型的 1.5 倍。

    4.2 费用

    本次使用的模型费用如下表所示。

    虽然相较于非重排序模型(例如 Amazon Nova Lite 为每 1000 个输出令牌 0.00024 美元),这些重排序模型的费用略显偏高,但这也意味着仅通过 API 调用就能使用到如此复杂的功能。

    序号模型费用
    1Amazon Rerank 模型1 美元 / 1000 次查询
    2Cohere Rerank 模型2 美元 / 1000 次查询

    总结

    我们对 Bedrock 新增的重排序模型进行了验证,确认其对改善检索结果具有实际作用。

    实验表明,通过执行重排序操作,能够使更贴合用户输入的内容出现在检索结果的靠前位置。

    此外,Bedrock Knowledge Base 的优势在于,无需自行开发实现,仅通过修改设置就能实现检索效果的大幅提升。

    本次验证仅进行到检索(retrieve)阶段,而若使用 retrieve_and_generate 功能,还可将回答生成的过程也交由 Bedrock 完成。

    未来,我希望活用 Bedrock 的重排序功能,开发出更贴合用户意图的 RAG 系统。