Elasticsearch 架构原理深度剖析

Ne0inhk

— 23 min read

前言

在大数据与实时搜索分析技术飞速发展的今天，Elasticsearch 已然成为分布式搜索引擎领域的事实标准。无论是电商平台的商品检索、企业内部的日志分析系统（ELK Stack），还是海量数据的实时监控与商业智能（BI）分析，Elasticsearch 凭借其近实时搜索、分布式集群、高可用性与水平扩展能力，深刻影响着现代数据架构的设计理念。

然而，要真正驾驭这一强大工具，仅停留在 API 调用层面是远远不够的。理解其底层架构原理，不仅有助于解决生产环境中的性能瓶颈，更能指导我们进行合理的数据建模与集群规划。本文将从宏观的分布式设计到微观的索引机制，全方位、深层次地剖析 Elasticsearch 的架构原理。

第一部分：Elasticsearch 核心定位与设计哲学

1.1 什么是 Elasticsearch？

Elasticsearch 是一个基于 Apache Lucene 构建的分布式、可扩展、近实时的搜索与数据分析引擎。它通过 RESTful API 隐藏了 Lucene 的复杂性，提供了全文搜索、结构化查询、聚合分析以及地理空间查询等丰富功能。

核心定位可以概括为：

  • 分布式文档存储：数据以 JSON 文档的形式存储，不再局限于关系型数据库的行列结构。
  • 实时分析引擎：支持从海量数据中快速提取统计指标与聚合结果。
  • 水平扩展平台：通过分片机制，允许用户在不停机的情况下动态扩展集群规模。

1.2 设计哲学：从“库”到“平台”的演进

Elasticsearch 并非从零开始编写自己的搜索引擎，而是站在了巨人的肩膀上——Lucene。Lucene 是一个高性能、全功能的搜索引擎库，但因其复杂性（直接使用 Java API 操作）而令众多开发者望而却步。Elasticsearch 的设计初衷就是封装 Lucene，提供一套简单一致的 RESTful API，并赋予其分布式能力。

这种设计的核心理念在于：

  1. “索引”一词的多义性统一：在 Elasticsearch 中，“索引”（Index）既是名词（存储文档的逻辑容器），也是动词（保存一条文档的过程）。理解这种语义重叠是掌握 ES 架构的第一步。
  2. 分布式透明化：用户操作的是“索引”，而 ES 后台自动处理分片分配、节点故障转移、数据重平衡等分布式难题，让集群看起来像是一个“巨型计算机”。

第二部分：集群层面的顶层架构设计

2.1 集群、节点与分片：分布式的基础单元

一个 Elasticsearch 集群由一个或多个节点（Node）组成，这些节点共同持有整个集群的数据，并提供联合索引和搜索能力。

2.1.1 节点角色（Node Roles）

在 ES 中，节点并非“千篇一律”。通过配置文件 elasticsearch.yml 可以指定节点的多种角色，以实现资源隔离与分工。

  • 主节点（Master-eligible Node）：
    • 职责：负责轻量级的集群范围的操作，如创建或删除索引、跟踪集群节点状态、决定分片分配等。
    • 设计要点：主节点必须稳定且负载较低。对于大型生产集群，建议配置专用的主节点（node.roles: [ master ]），不参与数据存储与请求路由，以防止因垃圾回收（GC）导致集群“脑裂”或状态更新延迟。
  • 数据节点（Data Node）：
    • 职责：持有分片（Shard），执行数据的增删改查、聚合操作。这是最繁忙的节点，对 I/O 和内存消耗极大。
    • 设计要点：数据节点通常需要高性能的 SSD 磁盘和大内存。可根据冷热数据分离架构，进一步将数据节点标记为“热节点”（hot）或“冷节点”（cold）。
  • 协调节点（Coordinating Node）：
    • 职责：接受客户端请求，将请求路由到合适的数据节点，然后合并各节点返回的结果，最后返回给客户端。每一个节点隐式地都是一个协调节点。
    • 设计要点：在大规模聚合查询场景下，协调节点可能会成为 CPU 和内存瓶颈。此时可以部署专用的协调节点（不配主节点资格，也不存数据），专门负责请求分发与结果归并。
  • 预处理节点（Ingest Node）：
    • 职责：在索引数据之前执行预处理管道（Pipeline），例如解析日志格式、删除字段、转换数据等。
  • 仅投票节点（Voting-only Node）：在 7.x 版本之后引入，用于在无法成为主节点的情况下参与主节点选举投票，以提高选举过程的可靠性。
节点角色核心职责资源消耗重点生产建议
主节点管理集群状态、分片分配内存（集群状态存储）3 台专用主节点，避免高 GC
数据节点数据存储与查询计算磁盘 I/O、内存、CPU使用 SSD，按冷热分层配置
协调节点请求路由、结果合并CPU、内存（处理大结果集）应对高并发聚合查询时部署
预处理节点数据管道清洗转换CPU日志清洗场景建议独立部署

2.2 分片（Shard）：Elasticsearch 的“并行单元”

分片是 ES 实现分布式存储与并行计算的核心抽象。一个索引（Index）在物理层面上被横向切割为多个主分片（Primary Shard）。

  • 主分片：文档写入时的第一落点。每个文档通过路由规则确定归属的主分片。主分片数量在索引创建时指定，且不可更改。这一限制源于路由算法 shard = hash(routing) % number_of_primary_shards，一旦数量变化，所有数据的路由位置都将失效。
  • 副本分片（Replica Shard）：主分片的拷贝。副本分片不仅提供数据冗余以防止硬件故障，还可以处理读请求（搜索、聚合），从而提升查询吞吐量。副本数量可以动态调整。
为什么主分片数量不能随意修改？
想象一下，有一个哈希函数将文档均匀分布在 5 个桶里。如果突然把桶的数量改为 6，再根据同一个哈希函数找文档时，会去错误的桶里找，导致数据“丢失”。ES 正是通过这种机制保证数据路由的一致性。

2.3 集群协调与发现机制

在分布式系统中，节点之间的相互发现与状态同步是基础。ES 采用Zen Discovery（7.x 之前）和Raft 共识算法（7.x 及以后）来实现集群协调。

  • 发现过程：节点启动后，通过单播（Unicast）向配置的主机列表发送请求，找到集群中的现有节点并加入。
  • 主节点选举：
    • 当主节点失联时，剩余的主资格节点发起选举。
    • 基于 Raft 算法，节点获得超过半数的投票（discovery.zen.minimum_master_nodes）才能成为主节点。该参数的经典计算公式为 (master_eligible_nodes / 2) + 1，用以防止“脑裂”（即集群分裂成两个相互不通信的小集群各自选举主节点）。
  • 集群状态发布：主节点负责维护集群状态（Cluster State），包含所有索引的映射、分片路由表等信息。每当状态变更（如节点加入、索引创建），主节点会通过发布机制将新状态同步到集群中的所有节点。

第三部分：数据写入的“高速公路”——近实时机制探秘

Elasticsearch 之所以被称为“近实时”（Near Real-Time，NRT）搜索引擎，是因为文档写入后并不能立即被搜索到，通常会有 1 秒的延迟。这种设计是对写入性能与搜索可见性的一种权衡。

3.1 写入流程全解析

当客户端发起一个索引（写入）请求时，内部经历了一次精巧的协作之旅：

第一阶段：协调节点路由

  1. 客户端请求发送到任意节点（假设为 Node A），Node A 成为该请求的协调节点。
  2. 协调节点解析请求，根据文档 ID（或指定的 routing 值）通过公式 shard = hash(document_id) % number_of_primary_shards 计算出文档应落入哪个主分片。
  3. 查询集群状态，定位该主分片所在的节点（假设为 Node B）。

第二阶段：主分片写入
4. 协调节点 Node A 将请求转发给主分片所在节点 Node B。
5. 写入 Lucene 索引：

  • Node B 接收到请求后，首先将文档写入 Index Buffer（内存缓冲区）。
  • 同时，为了数据安全，本次操作会立刻写入 Translog（事务日志，落盘）。在 ES 2.0 之后，默认每次写请求都会 fsync 到磁盘，确保数据不丢失。
  1. 转发副本：当文档在主分片写入 Index Buffer 并记录 Translog 成功后，主分片 Node B 并行地将请求转发给该分片的各个副本分片所在的节点（如 Node C、Node D）。
  2. 各副本分片执行与主分片相同的写入流程（Index Buffer + Translog）。
  3. 副本分片写入成功后，向主分片 Node B 发送成功确认。
  4. 主分片 Node B 在收到所有副本分片（或满足 write_consistency 设定的数量，如 quorum）的确认后，向协调节点 Node A 返回成功响应。
  5. 协调节点 Node A 最终向客户端返回 200 OK。

3.2 Refresh：让数据“可见”的秘密

经过上述流程，文档还存在于 Index Buffer 中，这是一个内存区域，尚未被搜索到。为了使文档可被搜索，Elasticsearch 定期执行 Refresh 操作。

  • 工作原理：Refresh 会将 Index Buffer 中的文档清空，生成一个新的 Lucene 段（Segment）。这个段首先被写入操作系统的文件系统缓存（Filesystem Cache）（并非直接落盘），然后打开该段使其对搜索可见。
  • 默认设置：每 1 秒自动执行一次 Refresh。这就是 ES 实现“近实时”的根源——刚写入的数据最多等待 1 秒即可被搜索。
  • 性能影响：频繁 Refresh 会产生大量细小的 Segment，影响查询性能。对于日志类场景（追求写入吞吐量 > 实时可见性），可调大 refresh_interval，如设置为 30s 或 -1（禁用自动刷新）。

3.3 Flush：持久化与提交点

Refresh 保证了数据可搜索，但尚未落盘，如果节点宕机，文件系统缓存中的数据将会丢失。这就需要 Flush 操作来确保数据真正持久化。

  • 触发时机：默认每 30 分钟，或当 Translog 达到一定大小（如 512MB）时自动触发。
  • 执行过程：
    1. 刷盘：将文件系统缓存中所有当前 Segment 强制 fsync 到磁盘，确保物理存储。
    2. 提交点更新：写入一个包含当前所有 Segment 信息的提交点（Commit Point）文件。
    3. Translog 清理：清空当前的 Translog 文件，并创建新的 Translog，因为之前的操作已经通过 Segment 持久化，不再需要重放。

3.4 Translog：数据安全的“救命稻草”

Translog（事务日志）是保证数据不丢失的关键设计。

  • 工作模式：类似于数据库的 Write-Ahead Log（WAL）。在每次写入操作（index、delete、update）被执行时，不仅会写入内存 Index Buffer，也会同时写入 Translog。在 ES 2.0 及以后版本，默认每个请求都会 fsync Translog 到磁盘（index.translog.durability: request），这意味着一个写请求在返回成功给客户端前，其 Translog 记录必须已经物理落盘。
  • 恢复作用：当节点重启时，ES 会读取最后一个提交点，并将提交点之后记录的 Translog 中尚未刷入磁盘的操作重新执行，从而保证数据完整性。

第四部分：查询的“分布式战场”——Scatter/Gather 机制

查询一个分布式索引比查询单个索引复杂得多。ES 采用Scatter/Gather（分散/收集）模型来处理搜索请求。

4.1 两阶段查询：Query 与 Fetch

一个典型的搜索请求分为两个阶段：

第一阶段：Query（查询阶段）
  1. 广播：协调节点接收客户端请求后，将请求转发至索引的所有分片（主分片或副本分片，通过轮询实现读负载均衡）。
  2. 本地执行：每个分片在本地执行查询，读取倒排索引，找到匹配的文档，并计算文档的相关性得分（_score）。
  3. 返回局部结果：每个分片仅返回一个优先队列（Priority Queue）给协调节点，默认大小为 from + size。这个优先队列包含文档 ID 和排序所需的值（如得分）。
第二阶段：Fetch（获取阶段）
  1. 全局排序：协调节点收到所有分片的优先队列后，进行合并、全局排序，截取出真正需要返回给用户的文档列表（从 from 开始，共 size 条）。
  2. 回查数据：协调节点根据最终文档列表，向各相关分片发送 GET 请求，获取文档的完整 _source（原始 JSON）数据。
  3. 组装响应：各分片返回完整文档数据，协调节点组装后返回给客户端。

4.2 Query 与 Filter 的深度剖析

在 ES 的查询 DSL 中，存在两种上下文：Query Context 和 Filter Context。

  • Query Context：
    • 用于“全文搜索”，需要计算文档与查询的相关性得分。
    • 查询结果不缓存，因为得分依赖于词频（TF）、逆文档频率（IDF）等统计数据，这些数据会因索引的变更而变化。
  • Filter Context：
    • 用于“结构化精确查询”（如 status 字段等于 200，create_time 在某个范围）。
    • 不计算得分（所有文档得分为 0），极大地降低了 CPU 开销。
    • 可缓存：ES 会自动将常用的过滤器结果缓存到节点级别的 Filter Cache 中。下次同样的过滤查询可以直接从缓存中获取文档 ID 集合，无需再次遍历倒排索引。这是提升查询性能的重要手段。
实践建议：对于不需要相关度评分的查询条件（如时间范围、状态过滤），尽量使用 Filter 上下文（bool 查询中的 filter 子句），以利用缓存机制加速查询。

第五部分：核心数据结构与算法

Elasticsearch 之所以能在大数据场景下实现毫秒级响应，得益于其底层 Lucene 先进的数据结构设计。

5.1 倒排索引（Inverted Index）：全文搜索的基石

关系型数据库使用“正排索引”：文档 ID -> 关键词。而全文搜索引擎使用倒排索引：关键词 -> 文档 ID 列表。

结构示例：

假设有以下三篇文档：

  • 文档1：“架构师之路”
  • 文档2：“Elasticsearch 架构”
  • 文档3：“架构设计原理”

倒排索引的简化形式如下：

关键词文档ID列表词频(TF)位置信息
架构[1, 2, 3][1, 1, 1][2], [1], [1]
师[1][1][3]
Elasticsearch[2][1][0]
设计[3][1][1]

当搜索“架构”时，直接通过字典树找到“架构”一词，快速返回包含它的文档 1、2、3。这种结构的查询时间复杂度为 O(1) 或 O(logN)，远超传统数据库的全表扫描。

5.2 倒排索引的存储优化：FST（有限状态转换器）

倒排索引中的词典需要高效存储与快速查找。Lucene 采用了 FST 这一高级数据结构。

  • 特点：
    • 共享前缀/后缀：对于“架构”、“架构师”这类词，FST 可以重用共同部分，大大节约内存。
    • 内存效率高：FST 在内存中的占用通常比 HashMap 小得多，且支持有序遍历。
    • 查询速度快：可以在 O(len(term)) 的时间复杂度内判断一个词是否存在。

5.3 索引的物理单元：Segment

在 Lucene 层面，一个分片（Shard）由一个或多个 Segment 组成。Segment 是不可变的（immutable），这种设计带来了诸多好处：

  • 简化并发：无需考虑并发写冲突，读操作不受写操作影响。
  • 充分利用缓存：不变性使得 Segment 可以轻松被操作系统或应用层缓存。
  • 故障恢复简单：无需处理复杂的部分写入状态。

然而，不可变性也带来了挑战：更新文档实际上是在新的 Segment 中写入新文档，旧文档在旧的 Segment 中标记为删除。随着写入的持续，Segment 数量会爆炸式增长，导致查询时需要遍历大量 Segment，性能下降。

5.4 Segment Merge：化零为整

为了解决 Segment 过多的问题，Lucene 在后台启动一个线程定期执行 Merge 操作。

  • 过程：将多个小 Segment 合并成一个大 Segment。
  • 清理：在合并过程中，将标记为“删除”的文档真正物理丢弃（.del 文件中的文档不会写入新 Segment），从而释放磁盘空间。
  • 资源消耗：Merge 操作是 CPU 和磁盘 I/O 密集型任务。如果 Merge 速度跟不上 Segment 生成速度，可能会导致磁盘 I/O 阻塞（磁盘爆满或查询延迟飙升）。合理设置 refresh_interval 和 merge 策略参数是 ES 调优的关键一环。

第六部分：高级特性与扩展机制

6.1 聚合分析（Aggregations）

聚合分析是 ES 区别于纯搜索引擎的另一大利器。它将查询结果视为数据集，并进行统计分析。

  • Metric 聚合：计算指标，如 avg、sum、min、max、stats。
  • Bucket 聚合：将文档分组到桶中，类似于 SQL 的 GROUP BY。例如 terms 聚合（按字段值分组）、date_histogram（按时间柱状图分组）。
  • Pipeline 聚合：对聚合结果再次进行聚合，如计算累计和、导数、移动平均等。

聚合分析之所以快，是因为它直接在倒排索引或列式存储（doc_values）上进行遍历计算，避免了大量数据的网络传输与对象序列化。

6.2 Doc Values：列式存储的威力

当对某字段进行排序或聚合时，如果使用倒排索引（词 -> 文档），效率极低。因此，ES 引入了 Doc Values。

  • 数据结构：这是 Lucene 在构建索引时同时生成的列式存储数据（文档 ID -> 字段值）。
  • 存储位置：存储在磁盘上，而不是内存，但利用操作系统的文件系统缓存进行加速。
  • 用途：专用于排序、聚合、以及脚本访问字段值。它避免了在排序聚合时将大量文档加载到内存（fielddata）导致的 OOM 风险。
  • 启用与否：对于不需要排序聚合的字段，可以禁用 doc_values 以节省磁盘空间。

6.3 索引生命周期管理（ILM）

随着时间推移，索引数据会不断膨胀。ILM 允许用户定义策略，自动化管理索引在不同阶段的处理方式。

  • 阶段（Phases）：
    • Hot：索引正在主动写入和查询。
    • Warm：索引不再写入，但偶尔查询。
    • Cold：索引很少查询，允许存储于廉价硬件。
    • Delete：数据过期，允许删除。
  • 动作（Actions）：在每个阶段，可执行 rollover（滚动）、shrink（收缩分片）、forcemerge（强制合并）、freeze（冻结）等操作。

第七部分：深入理解集群容灾与高可用

7.1 副本机制与故障转移

ES 的高可用依赖于副本分片。

  • 节点宕机：假设某个数据节点持有主分片 P0 和副本分片 R1 宕机。
  • 主分片恢复：集群主节点检测到节点失联后，会立即将宕机节点上丢失的主分片在其他存有该分片完整副本的节点上提升为主分片。
  • 重新均衡：集群状态变为 Yellow（有未分配的副本分片），主节点在其他健康节点上分配新的副本分片，以确保冗余性。
  • 数据完整性：由于 Translog 和复制的存在，已确认写入的数据不会丢失。

7.2 “脑裂”问题及解决方案

“脑裂”是指集群中出现多个主节点，各自为政，导致集群状态混乱。

解决方案：

  1. minimum_master_nodes：设置主节点选举所需的最小主资格节点数。推荐设置为 (N/2)+1，其中 N 是候选主节点数量。例如 3 个候选主节点，该值设为 2。这确保了要形成集群，必须获得至少 2 票，从而无法分裂出两个均不过半的小集群。
  2. 网络稳定性：避免网络抖动，配置合理的超时时间。
  3. 专用主节点：分离主节点与数据节点，减少主节点负载，降低 GC 导致无响应的概率。

第八部分：性能调优实战指南

8.1 写性能优化

  • 批量提交：使用 _bulk API，一次性提交成百上千条文档，大幅减少网络往返开销。每条请求的大小建议控制在 5-15MB 之间。
  • 调整 Refresh 间隔：对于日志、指标收集场景，将 refresh_interval 设置为 30s 或更大，甚至可以在导入数据期间临时禁用 Refresh。
  • 使用多个工作线程：客户端多线程并发写入，充分利用服务端资源。
  • 避免文档过大：过大的文档会增加网络传输和解析开销。单条文档建议不超过 100KB。
  • 合理设置 Translog 刷盘策略：在允许极少数据丢失（如非金融日志）的场景，可将 index.translog.durability 设为 async，并调大 sync_interval，以提升写入吞吐量。

8.2 读性能优化

  • Filter 优先：尽量将查询条件放入 bool 查询的 filter 上下文中，利用缓存加速。
  • 文档建模优化：避免 nested 类型或父子关系，因为它们会大幅降低查询效率。尽量通过 denormalization（冗余数据）将关联数据扁平化。
  • 预索引数据：例如，查询某条日志的时间范围，如果经常需要按天统计，可以在索引时预先计算好 day_of_week 字段，查询时直接 term 查询，避免运行时计算。
  • 使用路由：如果业务可以明确按某个维度（如用户 ID、机房）拆分数据，写入时指定 routing，查询时也使用相同的 routing，这样请求只会命中特定的分片，而不是广播至所有分片。
  • 强制合并只读索引：对于不再写入的旧索引（如历史日志索引），执行 forcemerge 将众多小 Segment 合并为几个大 Segment（max_num_segments=1），可以极大提升查询速度，并减少内存开销。

8.3 内存与磁盘优化

  • 50% 法则：给 Lucene 留出一半的内存（文件系统缓存），给 ES 的 JVM 堆留一半内存（通常不超过 32GB，推荐 31GB 左右以利用压缩指针）。
  • 禁用 Swap：通过 bootstrap.memory_lock: true 锁定内存，防止 JVM 堆被交换到磁盘。
  • 使用 SSD：随机 I/O 性能至关重要，SSD 是 ES 的最佳搭档。
  • 合理规划分片大小：官方建议每个分片的大小控制在 10GB 到 50GB 之间。分片过小会导致文件句柄过多，分片过大会影响移动和恢复速度。单个节点管理的分片数（包括主分片和副本）不应超过每 GB 堆内存 20 个分片。

第九部分：Elasticsearch 生态与未来展望

9.1 生态圈：ELK Stack

Elasticsearch 的强大不仅在于自身，更在于其丰富的生态。

  • Logstash：服务器端数据处理管道，从多个源采集数据、转换数据，然后发送到 Elasticsearch。
  • Kibana：数据可视化平台，通过图表、地图展示 Elasticsearch 数据，并提供控制台（Dev Tools）与集群交互。
  • Beats：轻量级数据采集器，部署在边缘节点，如 Filebeat（日志文件）、Metricbeat（指标）、Packetbeat（网络数据）。

9.2 未来趋势

  1. 云原生与 Serverless：Elastic Cloud 已经推出 Serverless 产品，用户无需管理集群、节点和分片，只需关注数据写入与查询，Elasticsearch 自动弹性伸缩。
  2. 向量搜索与 AI 集成：随着生成式 AI 的兴起，Elasticsearch 增强了对向量数据的支持，允许存储和检索 Embedding 向量，结合大语言模型实现“检索增强生成”（RAG）应用。
  3. 更智能的性能自适应：基于机器学习的自动化调优，如自动调整索引策略、预测查询负载等。

Read more

2025-2026年中国AIGC产业发展趋势报告：AI生成PPT好用排行榜

2025-2026年中国AIGC产业发展趋势报告：AI生成PPT好用排行榜

面对市面上琳琅满目的AI PPT工具，如何选择一款既高效又真正适合自己的？这份基于两个月实测的详细榜单或许能给你答案。 又到年底，办公室里的键盘敲击声似乎比平时更加急促。很多人正在为一件共同的年度大事发愁——制作年终总结PPT。写好的Word文档、散乱的Excel数据表、收集的参考资料，如何将它们快速整合成一份专业、美观、逻辑清晰的PPT，成了职场人绕不开的挑战。 传统制作方式耗时费力，而近年来兴起的各类AI生成PPT工具，正是为解决这一痛点而生。进入2026年，这一赛道已趋于成熟，但产品之间差异显著：有的设计精美但逻辑欠缺，有的生成迅速但深度不足，还有的水土不服，对中文职场环境支持不佳。 如何在众多工具中，找到那个能真正理解你、切实提升效率的“最佳搭档”？本文将为你揭晓答案。我们历时两个月，对市场上主流及新兴的AI PPT工具进行了深度实测与横向对比，从性能表现、功能完整性、本土化体验和综合性价比四个维度，为你呈现这份客观、详尽的2026年AI生成PPT工具综合排行榜。评测发现，一款名为ChatPPT的国产工具，正以其卓越的全流程解决方案和深刻的本土化洞察，成为本年度最大的黑马

By Ne0inhk
本地文件深度交互新玩法：Obsidian Copilot的深度开发

本地文件深度交互新玩法：Obsidian Copilot的深度开发

前言 当 “本地知识库管理” 撞上 “AI 智能分析”，会擦出怎样的火花？试想一下：你的 Obsidian 里存着多年积累的笔记、文档，却只能手动翻阅检索；而现在，一个插件 + 蓝耘 API，就能让这些 “静态文字” 瞬间 “活” 起来 —— 自动总结核心内容、智能回答专业疑问，甚至挖掘隐藏关联！今天，就带大家拆解 Obsidian 联动蓝耘 API 的全新玩法，看看如何让本地文件从 “信息仓库” 变身 “智能助手” 。 蓝耘API KEY的创建 先进行API的创建 先点击蓝耘进行一个正常的注册流程 进入到主页之后，我们点击上方的MaaS平台 进入到平台后我们可以看到很多的大模型 不仅仅是文本生成、音频理解、视频理解还是视频生成，都有对应的大模型 每个模型都有很详细的介绍以及价格示例，用过api调用的都可以看到这个价格还是比较贴近平民的 并且可以进行在线体验的，这里是先进行思考的，

By Ne0inhk

20分钟一篇！！！最好用详细的AI写作论文综述（开题报告、最新技术）方法总结（字数、时效性和参考文献都严格一致符合要求、参考文献和正文引用都真实存在），模型gemini 2.5 pro

具体流程： 在自己想要引用的网站，如ieee xplore、知网、web of science这些网站中使用高级搜索、找到自己想要引用的文献（也就是和自己写的方向高度相关的文献），选择指定的年份（如比较新的23-25年），然后批量选择后选中批量导出文献，选择自己需要的文献格式（ieee格式，中国国标格式等），然后将导出的文献保存在txt文件中，这些就是自己要引用的所有文献，一般建议多导出几十条，这样可以让AI从中挑选合适的论文，去除一些不适合的论文。 然后在gemini 2.5 pro模型中，开启联网模式（ground with google search），将自己的参考文献通过文件上传（没有的话就直接将参考文献复制粘贴到输入框里），然后贴入自己的prompt（也就是自己对这个生成论文的细节要求（如领域、题目、格式等要求），里面要提到“请基于我提供的参考文献【50篇ieee和20篇cnki的】，从中选取50篇合适的论文，撰写一篇学习报告”），然后生成后，检查一些参考文献是否真实，真实无误的话就没问题啦！ prompt如下：  你是一名资深信息安全技术研究员，擅长文献检索、前

By Ne0inhk

Whisper 模型本地化部署：全版本下载链接与离线环境搭建教程

Whisper 模型本地化部署指南 一、模型版本与下载 Whisper 提供多种规模版本，可通过以下官方渠道获取： 1. GitHub 仓库 https://github.com/openai/whisper 包含最新代码、预训练权重和文档 * tiny.en / tiny * base.en / base * small.en / small * medium.en / medium * large-v2 (最新大模型) Hugging Face 模型库 所有版本下载路径： https://huggingface.co/openai/whisper-{version}/tree/main 替换 {version} 为具体型号： 二、离线环境搭建教程 准备工作 1.

By Ne0inhk