针对大规模语言模型的上下文工程技术调研与总结

  • 声明
  • 摘要部分翻译
  • 介绍部分翻译
  • 相关工作部分翻译并摘要
  • 为什么使用上下文工程(翻译并摘要)
  • 基础组件(翻译并摘要)
  • RAG(翻译并摘要+简单介绍一下个人认为比较好的技术)
    • FlashRAG
    • KRAGEN (Knowledge Retrieval Augmented Generation Engine)
      • 1. 总体架构
      • 2. 知识图谱与嵌入预处理
      • 3. 子图检索与 Reranking
      • 4. Graph‑of‑Thoughts 子问题生成
      • 5. 生成与自我反思融合
      • 6. 系统接口与可视化
      • 7. 评估与性能
      • 8. 技术栈与开源实现
        • 后端
        • 图存储
        • 前端
  • 评估部分
  • 未来方向与挑战
  • 结论

声明

本文为翻译类文章如有侵权联系作者删除
原文链接为
点我跳转

摘要部分翻译

大模型的性能在推理阶段,根本上取决于所提供的上下文信息。本综述首次提出“上下文工程”(Context Engineering)这一学科概念,超越传统提示设计,旨在系统化地优化模型输入的信息载荷。我们构建了一个涵盖基础组件与系统实现的完整分类体系:
基础组件
上下文检索与生成:基于提示的文本生成与外部知识获取;
上下文处理:长序列处理、自我迭代完善与结构化信息融合;
上下文管理:记忆层级、压缩策略与性能优化。
系统实现
检索增强生成(Retrieval‑Augmented Generation, RAG):模块化、智能体化及图增强架构;
记忆系统(Memory Systems):支持持久化交互;
工具集成推理(Tool‑Integrated Reasoning):实现函数调用与外部环境交互;
多智能体系统(Multi‑Agent Systems):协调通信与任务编排。
通过对 1,400 余篇论文的系统梳理,我们不仅为上下文工程奠定了技术路线,也揭示了模型在理解复杂上下文方面虽已取得显著进展,却在生成同等复杂度的长文本时存在明显短板。弥合这一不对称差距,将成为未来研究的关键方向。最终,本综述为研究人员与工程师提供了一个统一的上下文感知 AI 框架,助力该领域的持续发展。
关键词:上下文工程;大规模语言模型;LLM 智能体;多智能体系统

介绍部分翻译

大语言模型(LLMs)的出现标志着人工智能领域的范式转变,它们在自然语言理解、生成与推理方面表现出前所未有的能力。然而,这些模型的性能与效能在根本上由其所接收的上下文所决定。所谓“上下文”,可从简单的指令性提示扩展到复杂的外部知识库,是驱动模型行为、增强模型知识并释放其能力的主要机制。随着 LLMs 从基础的指令执行系统演进为复杂应用的核心推理引擎,设计与管理其信息载荷的方法也相应发展,形成了“上下文工程”(Context Engineering)这一正式学科。
上下文工程领域迅猛扩张,催生了大量专业化却较为割裂的研究方向。我们将这一领域概念化为两大部分:基础组件与系统实现。基础组件代表了上下文工程的系统化流程,涵盖三个关键阶段:
上下文检索与生成:包括基于提示的生成与外部知识获取
上下文处理:涉及长序列处理、自我完善机制与结构化信息整合
上下文管理:关注记忆层级、压缩技术与优化策略
这些基础组件构成了更高级、面向应用的系统实现的基石,这些系统将 LLMs 与外部环境有效衔接。其中包括:
高级检索增强生成(RAG):发展出模块化与智能体化架构,实现动态知识注入
显式记忆系统:模拟人类认知中的持久信息保留机制
智能体系统生态:利用函数调用与工具集成推理与外部世界交互,并依赖复杂的智能体通信协议与上下文编排,实现多智能体协同
尽管各研究方向均产生了大量创新成果,但它们往往各自为政,缺乏整体视角。这种碎片化的发展掩盖了各技术间的内在联系,也给希望全面掌握领域全貌的研究者和实践者带来诸多障碍。亟需一个统一的框架,将这些方法系统化地组织起来,澄清其基本原理,并揭示它们的相互依赖关系。
为填补该关键空白,本综述首次对 LLM 的“上下文工程”进行全面、系统的回顾。我们的主要贡献在于提出一套新颖的结构化分类体系,将设计、管理和优化上下文的多种技术分门别类。本分类体系将领域划分为基础组件与其在复杂系统中的集成实现。通过该框架,我们将能够:
清晰、结构化地概览各研究领域的最新进展、深入分析不同方法的核心机制、优劣与局限、指出共性挑战并规划未来研究方向
本工作既为导航上下文工程这一复杂领域提供了技术路线图,也为促进更深入理解和激发后续创新奠定了基础。本文余下结构如下:首先讨论相关工作并正式定义“上下文工程”,然后依次剖析基础组件(上下文检索与生成、上下文处理、上下文管理)及其系统实现(检索增强生成、记忆系统、工具集成推理、多智能体系统),最后探讨评估方法、未来研究方向并总结全文。图 1 展示了本综述的分类体系概览,体现各技术的层级结构及相互关系。

相关工作部分翻译并摘要

上下文工程相关领域的研究进展,主要包括三个方面:
基础组件层面:大量综述集中在如何构造和获取上下文,包括提示工程与外部知识检索(Context Retrieval & Generation)、长序列处理与自我迭代完善(Context Processing),以及记忆层级设计与语义压缩优化(Context Management)。
系统实现层面:研究者将上述组件集成到实际应用架构中,形成了检索增强生成(RAG)、显式记忆系统、工具集成推理和多智能体系统等多种高级方案,用以提升模型在信息注入、持久交互、环境调用和多 Agent 协同等场景下的能力。
评估与挑战:已有工作提出了从组件级到系统级的多层次评估框架,构建了覆盖长文生成、工具调用、多模态交互等方向的基准数据集,并讨论了规模化限制、自检依赖和多工具协调等核心难题。
尽管各子领域研究已颇具深度,仍缺乏横向统一的视角。本综述通过提出“上下文工程”这一统合抽象,以清晰的分类体系贯通基础组件与复杂系统,填补了现有文献的碎片化空白。

为什么使用上下文工程(翻译并摘要)

“上下文工程”是一门旨在系统化、模块化地设计和管理大规模语言模型输入信息的学科。它将模型所需的上下文视为由系统指令、外部知识、工具接口、历史记忆、环境状态和用户查询等多种组件动态组合而成的有机集合,然后通过高层组装函数灵活选取、过滤、格式化这些组件,以最大化模型在理解和生成任务中的效果。
之所以需要“上下文工程”,是因为传统的提示设计方法难以应对多源、动态和结构化信息带来的挑战:模型计算与内存开销随着上下文长度呈二次增长,生成内容往往语法无碍却深度不足,且手工试错的经验方法缺乏系统化和可复用性。通过引入检索增强生成、动态提示策略和精细化压缩优化等技术,不仅能够显著提升模型的性能与生成质量,还能在降低计算成本和推理延迟的同时,为无须重训的上下文学习、自动迭代优化和复杂多步推理等未来应用奠定坚实基础。

基础组件(翻译并摘要)

首先,上下文检索与生成阶段聚焦于如何以高效且灵活的方式获取模型所需的各种信息载荷。在这一阶段,设计者不仅需要在少样本或零样本提示技术上寻找最优示例和提示格式,还要将外部知识库(如文档片段、知识图谱或实时 API 调用)与模型输入无缝融合。动态上下文组装机制通过高层函数对提示示例、检索结果与系统指令等多个信息源进行智能拼接和格式化,以适应不同长度限制和任务需求,从而在推理时提供最相关、最精炼的上下文。
“上下文处理”部分聚焦于对原始上下文进行深度加工,以解决超长序列的计算瓶颈并提升内容质量。为突破 Transformer 自注意力 O(n²) 的限制,研究者提出了分层注意力(Hierarchical Attention)、FlashAttention、Ring Attention、StreamingLLM、Infini‑attention 等多种高效内核与流式处理机制;与此同时,自我精炼(Self‑Refinement)、自我批判(Self‑Critique/Reflexion)和多轮反馈循环,使模型能够在初步生成后自动纠错、补全与迭代;结构化与多模态融合方面,则有 StructGPT、GraphFormers、KG‑Integration、MLLMs 等方法,将表格、图谱、图像和音频等多种形式的信息映射为统一的序列表示,增强跨模态理解与推理能力
最后,“上下文管理”板块针对实际部署环境中的资源与性能约束,提出了全面的生命周期管理策略。基础约束分析揭示了上下文长度与计算、内存的关联;记忆层级设计则通过 KV‑Cache、PagedAttention(借鉴虚拟内存分页原理)、MemoryBank(基于艾宾浩斯遗忘曲线动态调节记忆强度)等机制,构建短期缓存与长期持久化存储的分层架构;在压缩技术方面,包括 In‑Context Autoencoder(ICAE)实现 4× 以上的上下文压缩、Recurrent Context Compression(RCC)和 Activation Refilling(ACRE)等多种语义摘要、令牌精简与向量量化方法;此外,异步预载、动态剪枝与成本—延迟权衡策略的引入,有效降低了在线推理的延迟与开销,并在文档处理、多轮对话、协同智能体等场景中获得了显著效果提升。

RAG(翻译并摘要+简单介绍一下个人认为比较好的技术)

首先提出了这样一个核心思想:通过将外部知识源与语言模型的生成能力紧密结合,RAG 既能利用模型内在的参数化知识,又能够动态地拉取最新的领域信息,从而突破单纯依赖训练时数据的局限。它通过将检索模块(Retriever)和生成模块(Generator)解耦,并在它们之间引入灵活的接口与汇聚机制,实现了对上下文信息的实时注入,让模型在推理过程中能够访问并整合最新的文档片段、知识库条目或知识图谱内容。
在模块化 RAG 架构中,RAG 系统被设计成多层级、可重构的组件化框架:最上层是宏观的检索‑生成流水线,中层由若干子模块(如查询重写、检索管理、结果融合等)组成,最下层则是执行单元(如向量检索器、交叉编码器重排序器、文本拼接器)。这种分层设计不仅支持多路数据源的并行接入,还允许按照任务需求动态地路由和调度各子模块,实现检索策略与生成策略的自适应组合。以 FlashRAG 为例,其提供了五大核心模块和十六个子组件,用户可以按需启用或替换某一环节;而 KRAGEN 则结合生物医学知识图谱与向量数据库,通过针对性提示模板有效抑制生成过程中的无关“幻觉”;ComposeRAG 则引入问题分解与查询重写的原子化模块,并通过自我反思机制迭代优化检索与生成结果。
在智能体化 RAG 系统中,检索‑生成管道被嵌入到自主决策的代理框架中,代理能够在多个检索策略之间进行规划与切换,并在检索结果基础上调用工具、执行环境交互,进而形成连续推理流程。Self‑RAG 是典型代表,它在每次检索与生成后加入反思标记,以引导模型对先前步骤进行评估和修正。此外,图增强 RAG 则将知识图谱结构显式融入检索环节,通过实体关系网络与子图提取,构建面向递归生成的上下文路径,并利用剪枝技术剔除低相关分支,最终在保持透明化推理轨迹的同时,大幅提升了上下文的相关性和精炼度。5.1.4 节进一步介绍了这些 RAG 系统在实时生产环境中的应用实践,包括动态知识更新、多智能体协同检索和链式推理链路的落地,以及相应的系统评估方法。

FlashRAG

FlashRAG 是一个面向 RAG 研究的高效、模块化开源工具包,旨在为研究者提供一个统一、一致的实验与开发环境。该工具包的设计初衷源自于现有 RAG 框架(如 LangChain、LlamaIndex)在灵活性和轻量化方面的不足:它们通常体量庞大,且难以针对研究需求进行定制。
为了解决这一痛点,FlashRAG 提供了:
高度可定制的模块化框架:将 RAG 流水线拆分为检索、重排序、融合、生成等可插拔组件,研究者可根据需要替换或扩展任意子模块;
多模态 RAG 能力:内置对文本、图像等多种模态检索与融合的支持,方便在多元数据场景下进行实验;
丰富的预实现方法:已集成 16 种前沿 RAG 算法(包括但不限于经典管道、图增强、智能体化 RAG 等),研究者可以一键复现或基于此开展改进;
全面的基准数据集:收录并整理了 38 个公开可用的数据集,涵盖知识问答、长文摘要、领域检索等多种任务;
高效辅助脚本与评估指标:提供数据预处理、索引构建、自动化评测等脚本,并支持一套标准化的评估流程,确保实验可比性和结果可复现。
开源地址

KRAGEN (Knowledge Retrieval Augmented Generation Engine)

KRAGEN 是一个端到端框架,深度融合结构化知识图谱与LLM,目标是在复杂领域问答与决策支持场景中,最大限度地利用外部事实与多跳推理能力,抑制“幻觉”并提升答案准确度。

1. 总体架构

  1. 知识图谱构建与预处理
    • 从领域文献/数据库抽取实体–关系三元组
    • 节点与边使用 TransE、RGCN 等算法训练图嵌入
    • 将嵌入索引到 FAISS 向量数据库
  2. 向量检索与子图抽取
    • 对用户查询生成向量,进行近似最近邻检索召回 Top‑k 实体
    • 基于 BFS/DFS 或 Personalized PageRank 抽取多跳子图
  3. Graph‑of‑Thoughts 子问题拆解
    • 使用 LLM 将原始查询拆分为多个子问题
    • 为每个子问题生成对应子图路径的自然语言描述
  4. 生成与融合
    • 将子问题描述和路径提示传入 LLM,得到初稿
    • 通过二次检索与“自我反思”循环,迭代优化答案
    • 汇总各子问题答案,输出最终高置信度解决方案

2. 知识图谱与嵌入预处理

  • 三元组抽取:使用领域专用关系抽取器(如 BioRE)标注实体与关系
  • 图嵌入训练:选择 TransE、ComplEx 或结构化 RGCN
  • 索引构建:将所有图嵌入存入 FAISS,支持增量更新

3. 子图检索与 Reranking

  • 快速召回:余弦相似度或内积匹配,召回相关实体
  • 子图抽取:基于节点邻居关系生成子图
  • 重排序:使用 Cross‑Encoder 对候选子图路径打分,保留前 m 条高价值路径

4. Graph‑of‑Thoughts 子问题生成

  • 自动拆分:Prompt 模板示例

    “请将以下问题拆解为三条子问题,并指出每条子问题所需核心信息。”

  • 路径提示化

    “实体 A 与实体 B 通过关系 R 连接;B 与 C 通过关系 S 连接。”

  • 多跳推理:在提示中显式要求模型进行多跳逻辑推理

5. 生成与自我反思融合

  • 初稿生成:依次回答各子问题
  • 反思改进:向模型输入

    “请检查以上回答,指出逻辑或事实漏洞并修正。”

  • 答案融合:将高质量子问题答案合并为连贯整体

6. 系统接口与可视化

  • API 设计:RESTful & gRPC,一次请求完成全流程
  • Web UI 面板
    • 动态展示检索到的子图
    • 可视化 Graph‑of‑Thoughts 拆分
    • 中间稿交互式审核

7. 评估与性能

  • 基准测试:BioASQ、CPQA 等上提升 F1 12–18%
  • 多跳问答:准确率从 62% 提升至 78%
  • 错误率:事实错误率降低约 30%

8. 技术栈与开源实现

后端

Python, FastAPI, PyTorch, Huggingface Transformers, FAISS

图存储

Neo4j (可视化 & 复杂查询) + FAISS (向量检索)

前端

React, D3.js (子图渲染), Ant Design

评估部分

评估框架与方法论
评估既要关注单个模块的性能,也要考察整个系统的端到端效果。组件级评估针对检索、生成、记忆管理、自我精炼等各项技术,设计专门的度量指标来分析其内部表现;系统级评估则在实际下游任务(如问答、摘要、工具调用或多智能体协同)中检验各组件协同后的综合效果与稳定性。
基准数据集与评价范式
为了对比不同技术,研究者使用了丰富的标准化测试集。针对基础组件的评测,有信息检索准确率测试、结构化数据理解与持久记忆测试等;针对系统实现的评测,则包含多跳推理、长文本生成质量、工具调用成功率等多维度指标测试。通过这些公开数据集和统一流程,可以公平地比较各方案的优劣。
评估挑战与新兴方向
评估工作仍面临多模态场景和多工具协同缺乏统一度量、长交互与对抗性输入下的鲁棒性验证不足等难题。最新趋势包括引入在线用户反馈、在仿真或沙箱环境中进行闭环测试,以及加强对模型安全性和稳健性的专门评估,从而更全面地反映上下文工程技术在真实应用中的表现。

未来方向与挑战

在基础研究层面,亟需构建更加完备的理论框架和数学模型,以解释上下文与模型行为之间的内在机制,制定上下文规模与性能之间的定量尺度律,并攻克自注意力在超长序列处理上的 O(n²) 复杂度瓶颈。同时,多模态融合与组合式理解也需要系统化研究,探索如何将图像、音频、结构化数据等多源信息紧密耦合,并从信息论角度优化上下文载荷的表达与传递。多智能体协调的理论基础同样是重点,推动统一的交互协议与编排范式,为大规模智能体网络中的共享上下文和高效协作奠定支撑。
在技术创新层面,研究者应继续挖掘新型注意力机制和高效内核,比如基于可学习分块的 LongMamba、滑动注意力等,以实现更低复杂度的长序列处理;在记忆体系上探索新的嵌入增强与自适应更新策略,构建可扩展的多级记忆架构;在检索增强生成领域推进模块化与图增强方法,不断优化上下文组装与查询分解算法;在工具集成推理与智能体系统中,完善自动化的自我精炼与自我批判循环,提升系统在动态环境下的自适应与稳健性。
应用驱动研究则应聚焦于具体行业需求的深度定制与落地:在医疗、金融、法律等高风险领域开展域特定上下文优化与安全评估;推动多智能体通信协议(如 MCP、A2A、ACP、ANP)的标准化,为跨系统协作提供一致接口;探索人机协同工作流、隐私保护与安全隔离技术,以及在大规模生产环境中的弹性部署与性能监控;并在此基础上严格考虑伦理和合规要求,确保上下文工程技术在现实应用中既高效可靠,又可控可审计。

结论

本综述首次以正式学科的视角,系统地阐述了“上下文工程”在大规模语言模型(LLMs)中的核心地位。通过对 1400 多篇文献的梳理,我们构建了一个统一的分类框架,将上下文工程技术划分为基础组件(上下文检索与生成、上下文处理、上下文管理)和系统实现(检索增强生成、记忆系统、工具集成推理、多智能体系统),并演示了这些技术如何在满足实际需求的复杂架构中协同工作。我们提炼出若干关键洞见:LLMs 在理解复杂上下文方面能力卓越,却在生成同等复杂度输出时存在显著短板;多种技术正呈现出高度协同的整合模式,超越各自独立功能;模块化与组合化趋势为多样化应用提供了灵活而一致的支撑;现有评估方法难以捕捉系统的动态与整体行为,亟待更完善的度量体系。
面向未来,上下文工程将在构建复杂、多组件 AI 系统中扮演越来越重要的角色。该领域的跨学科特性要求计算机科学、认知科学、语言学及各行业专家通力合作,以共同完善理论基础、突破技术瓶颈并推动标准化落地。随着 LLMs 持续演进,“上下文决定性能”的核心洞见将继续引领 AI 发展。本文不仅为研究者提供了当前全貌,还为后续研究指明了路线,奠定了上下文工程作为独立学科的原则、方法和挑战,为促进上下文感知 AI 的创新与责任化实践打下坚实基础。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如若转载,请注明出处:http://www.pswp.cn/news/915488.shtml
繁体地址,请注明出处:http://hk.pswp.cn/news/915488.shtml
英文地址,请注明出处:http://en.pswp.cn/news/915488.shtml

如若内容造成侵权/违法违规/事实不符,请联系英文站点网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

QT配置Quazip外部库

1.下载QuaZip源码网址:https://sourceforge.net/projects/quazip/  注:下载->解压->打开.pro文件2.编译QuaZip源码2.1配置zlib注:QuaZip需zlib的支持,我们需要引用zlib找到本地安装Qt目录下zlib目录:注&#x…

从C++开始的编程生活(4)——类的定义、访问限定符、类域、类的实例化和this指针

前言 本系列文章承接C语言的学习,需要有C语言的基础才能学会哦~ 第3篇主要讲的是有关于C的类的定义、访问限定符、类域、类的实例化和this指针。 C才起步,都很简单呢! 目录 前言 类 基本语法 访问限定符 基本语法 类域 类的实例化 内…

AD域控制器虚拟化的安全加固最佳实践

以下是AD域控制器虚拟化安全加固的7项核心实践,结合最新Windows Server 2022特性与虚拟化环境需求:基础架构强化‌ 采用静态IP分配并确保所有域控节点DNS指向主DC(如192.168.1.10)‌ 虚拟机模板需预配置林/域功能级别为Windows Se…

java解析nc气象数据

1.1pom.xml<dependency><groupId>edu.ucar</groupId><artifactId>netcdfAll</artifactId><version>5.4.1</version></dependency>1.2 netcdf使用/** param type 0 ,1, 2 wind 1 or 2 其他 0 .* return Map* */public Map i…

STC8H8K64U SKDIP28芯片频率占空比PWM波形

/****PWM输出任意周期占空比波形*******/ #include "STC8H.h" // #include "intrins.h" // #define uchar unsigned char // #define uint unsig…

【RK3576】【Android14】USB开发调试

获取更多相关的【RK3576】【Android14】驱动开发&#xff0c;可收藏系列博文&#xff0c;持续更新中&#xff1a; 【RK3576】Android 14 驱动开发实战指南 硬件接口 RK3576支持两个USB3.0控制器 驱动开发 dts配置 在“Android14/kernel-6.1/arch/arm64/boot/dts/rockchip/rk…

20. TaskExecutor与ResourceManager心跳

20. TaskExecutor与ResourceManager心跳 现在&#xff0c;需要回过头看 ResourceManager是如何产生心跳管理服务的。cluster.initializeServices 方法的 heartbeatServices createHeartbeatServices(configuration);产生一个 HeartbeatServicesImpljobmanager的 resourceManag…

OS19.【Linux】进程状态(上)

目录 1.情景引入 2.操作系统学科对进程状态的分类 运行状态 基于时间片的轮转调度算法 阻塞状态 等待IO设备的例子 等待其他进程中需要获取的数据 进程唤醒 挂起状态(全称为阻塞挂起状态) 简单谈谈虚拟内存管理 就绪状态 笔面试题 3.Linux对进程状态的分类 R和S状…

如何优雅地修改项目的 Android 版本(API 级别)

引言 在 Android 开发的日常迭代中&#xff0c;我们经常需要升级或降级项目的 minSdkVersion、targetSdkVersion 与 compileSdkVersion。升级可以解锁新特性和性能优化&#xff1b;降级则可能为了兼容旧机型或快速验证问题。本文将手把手演示在 Android Studio 里修改 Android …

GNU Radio多类信号多种参数数据集生成技巧

参考我的这篇博客&#xff0c;我想自制一个多信号数据集&#xff1a; 【多雷达信号硬件模拟】 3台USRP1台VSG信号发生器模拟多雷达信号&#xff0c;1台USRP产生高斯噪声模拟更多信道环境&#xff0c;1台USRP采集信号 需要在多个波段对四种信号进行参数设置&#xff0c;带宽有…

Ansible + Shell 服务器巡检脚本

脚本概述这是一个用于服务器日常巡检的 Shell 脚本&#xff0c;主要功能包括&#xff1a;检查多台主机的网络连通性 监控CPU、内存和磁盘使用率 生成详细的巡检报告 通过企业微信发送告警通知核心技术点1. 主机批量管理使用Ansible工具远程执行命令和脚本 通过主机…

Linux-rpm和yum

一、RPMRPM&#xff08;Red Hat Package Manager&#xff09;是一个用于管理 Red Hat 系列 Linux 发行版&#xff08;如 RHEL、CentOS、Fedora&#xff09;软件包的工具。RPM 允许用户以统一的格式来安装、卸载、升级和查询软件包。它是 .rpm 文件的主要工具&#xff0c;后缀名…

手推OpenGL相机的正交投影矩阵和透视投影矩阵(附源码)

概述计算OpenGL的正交投影矩阵和透视投影矩阵是有现成函数的。自己手推不是为了重复造轮子。手推一遍&#xff0c;可以极大的加强对这两个矩阵的理解。同时也可以满足一下自己求知欲。正交投影矩阵手推正交投影矩阵源码 WGMatrix4x4 WGMatrix4x4::BuildOrtho(double l, double …

【跨国数仓迁移最佳实践2】MaxCompute SQL执行引擎对复杂类型处理全面重构,保障客户从BigQuery平滑迁移

本系列文章将围绕东南亚头部科技集团的真实迁移历程展开&#xff0c;逐步拆解 BigQuery 迁移至 MaxCompute 过程中的关键挑战与技术创新。本篇为第二篇&#xff0c;跨国数仓迁移背后 MaxCompute 的统一存储格式创新。 注&#xff1a;客户背景为东南亚头部科技集团&#xff0c;…

react(基础篇)

React由Meta公司研发&#xff0c;用于构建Web和原生交互界面的库。 React 官方中文文档 查看JSX &#xff08;一&#xff09;React组件 用户界面的一部分&#xff0c;通俗的来讲&#xff0c;最小的元素组成的单元&#xff0c;可以实现部分逻辑与功能 房子的门就可以看成一个…

数据结构-哈希表(一)哈希函数、哈希表介绍、优缺点

哈希表 哈希函数哈希表使用了哈希函数来完成key到地址的快速映射&#xff0c;所以在了解哈希表之前&#xff0c;需要先明白哈希函数的概念和特点。 哈希函数的定义 哈希函数 哈希函数是一种将任意长度输入的数据&#xff0c;转换成固定长度输出的算法哈希函数H可以表示为yH(x) …

Shader开发(一)什么是渲染

前言在现代游戏开发和计算机图形学领域&#xff0c;渲染技术是连接虚拟世界与视觉呈现的关键桥梁。无论你是刚接触图形编程的新手&#xff0c;还是希望深入理解渲染原理的开发者&#xff0c;掌握渲染的核心概念都是必不可少的第一步。什么是渲染&#xff1f;渲染&#xff08;Re…

策略模式+工厂模式(案例实践易懂版)

最近,可以说这2025年度,自己更文的次数都大大减少,主要最近大环境不景气,自己职业也受到波及,学习的东西也是因为AI而变得更多, 没办法,你不学,总有人会学,关于AI的我也准备出个专辑,相信绝对帮助到大家 额,好像说多了,言归正传,我们看一下今天的主题:策略模式工厂模式 本文主要…

【NLP舆情分析】基于python微博舆情分析可视化系统(flask+pandas+echarts) 视频教程 - snowNLP库实现中文情感分析

大家好&#xff0c;我是java1234_小锋老师&#xff0c;最近写了一套【NLP舆情分析】基于python微博舆情分析可视化系统(flaskpandasecharts)视频教程&#xff0c;持续更新中&#xff0c;计划月底更新完&#xff0c;感谢支持。今天讲解snowNLP库实现中文情感分析 视频在线地址&…

大根堆,小根堆,双指针

码蹄集OJ-大约 #include<bits/stdc.h> using namespace std; priority_queue<int>max2,maxDel; priority_queue<int,vector<int>,std::greater<int>>min2,minDel; const int N1e51; int n,result0,a[N]; int main( ) {cin>>n;for(int i1…