Zvec:轻量级进程内向量数据库


基本信息


导语

随着大模型应用的深入,向量数据库已成为检索增强生成(RAG)系统的核心组件。然而,传统方案往往引入了复杂的架构依赖,增加了系统维护的难度。本文介绍的 Zvec 是一款轻量级、高性能的进程内向量数据库,旨在简化技术栈。通过阅读本文,读者将了解 Zvec 的核心特性与适用场景,掌握如何在无需独立服务的情况下,高效实现本地向量存储与检索。


评论

深度评论:技术架构与场景适配性分析

核心观点: Zvec 所代表的“进程内向量库”技术路线,实质上是对向量检索技术栈的一次“垂直整合”尝试。通过将计算边界从独立服务收拢至应用进程内部,该方案在特定场景下解决了网络I/O与运维复杂度问题,但也引入了资源隔离与扩展性的新挑战。其核心价值在于重新定义了“轻量级”在向量检索语境下的工程含义。

技术权衡与边界分析:

  1. 架构模式:进程内计算与网络I/O的取舍

    • 技术逻辑: 不同于 Milvus 或 Weaviate 等采用的 Client-Server 架构,Zvec 采取嵌入式架构。这种设计消除了网络序列化与传输的开销,使得检索延迟主要取决于内存访问速度,通常可将端到端延迟控制在微秒(µs)级别。
    • 适用边界: 这种架构极适合对延迟敏感且数据规模可控的场景(如推荐系统的实时召回层、边缘设备侧的本地知识库)。然而,这种紧耦合意味着应用逻辑与数据库引擎共享 CPU 与内存资源。在高并发或计算密集型业务中,可能导致资源争抢,影响整体服务的稳定性,这也是传统独立数据库架构存在的根本原因。
  2. 数据持久化与一致性的简化

    • 技术逻辑: 为了达成“轻量级”目标,此类库通常会简化分布式共识协议(如 Raft)及复杂的 WAL(预写日志)机制,转而采用更直接的持久化策略(如基于 SQLite 的持久化或简单的文件追加写)。
    • 适用边界: 这种设计符合“读多写少”及允许最终一致性的应用需求(如文档归档、日志检索)。但在金融交易或核心用户画像等要求数据强一致(ACID)及高可用的场景下,进程内的单点故障风险可能导致内存索引数据丢失,无法满足企业级的数据安全标准。
  3. 索引算法与存储介质的适配

    • 技术逻辑: 高性能向量检索通常依赖 HNSW(分层导航小世界图)算法,其查询性能优异但构建成本高昂且常驻内存。若 Zvec 仅依赖纯内存方案,其数据承载量受限于单机硬件内存上限。
    • 适用边界: 为了突破内存墙,技术深度取决于其是否实现了类似 DiskANN 的磁盘索引优化,或是否支持 Product Quantization (PQ) 等压缩技术。如果缺乏对 SSD 友好的索引支持,当数据量超过单机内存容量(例如数十 GB 级别)时,其性能将面临显著挑战。

总结与行业定位:

Zvec 的出现反映了向量数据库领域正在发生的**“去服务化”趋势**。随着 Llama 3 等参数量在 7B-70B 之间的模型逐渐普及,算力需求正在向边缘端和单机端下沉。Zvec 这类轻量级库填补了“重型分布式集群”与“纯算法SDK(如 Faiss)”之间的空白,特别适合构建**“模型+数据库”共存的边缘 AI 应用SaaS 多租户隔离场景**。其核心竞争力不在于挑战大规模分布式检索的极限,而在于以极低的运维成本提供中等规模下的极致性能。


代码示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
# 示例1:基础向量存储与相似度搜索
def basic_vector_search():
    """
    演示Zvec最核心的功能:
    1. 创建内存数据库
    2. 存储文本的向量表示
    3. 执行相似度搜索
    """
    import zvec
    import numpy as np
    
    # 1. 初始化Zvec数据库(维度为3)
    db = zvec.Database(dim=3)
    
    # 2. 准备示例数据(实际场景通常使用embedding模型生成)
    items = [
        ("苹果", np.array([0.1, 0.2, 0.3])),
        ("香蕉", np.array([0.2, 0.1, 0.4])),
        ("橙子", np.array([0.15, 0.25, 0.35]))
    ]
    
    # 批量插入数据
    for text, vec in items:
        db.add(text, vec)
    
    # 3. 查询与"苹果"相似的物品
    query_vec = np.array([0.1, 0.2, 0.3])
    results = db.search(query_vec, top_k=2)
    
    print("最相似的结果:")
    for score, text in results:
        print(f"- {text} (相似度: {score:.2f})")

# 说明:这个示例展示了Zvec最基础的向量检索流程,
# 适用于需要快速原型开发的语义搜索场景。
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
# 示例2:带元数据的文档检索系统
def document_retrieval():
    """
    演示如何构建带元数据的文档检索系统:
    1. 存储文档时附加元数据
    2. 支持按元数据过滤
    3. 实现混合搜索(向量+元数据)
    """
    import zvec
    import numpy as np
    from datetime import datetime
    
    db = zvec.Database(dim=3)
    
    # 添加带元数据的文档
    docs = [
        {"title": "AI教程", "content": "人工智能基础", "date": "2023-01", "vec": np.array([0.5, 0.1, 0.2])},
        {"title": "Python指南", "content": "Python编程入门", "date": "2023-02", "vec": np.array([0.3, 0.4, 0.1])},
        {"title": "机器学习", "content": "ML算法详解", "date": "2023-03", "vec": np.array([0.4, 0.2, 0.3])}
    ]
    
    for doc in docs:
        db.add(
            items=doc["content"],
            vector=doc["vec"],
            metadata={"title": doc["title"], "date": doc["date"]}
        )
    
    # 带过滤条件的搜索
    query = np.array([0.45, 0.15, 0.25])
    results = db.search(
        query_vector=query,
        top_k=2,
        filter={"date": {"$gte": "2023-02"}}  # 只搜索2月及以后的文档
    )
    
    print("过滤后的搜索结果:")
    for score, item in results:
        print(f"- {item.metadata['title']}: {item.text} (分数: {score:.2f})")

# 说明:这个示例展示了Zvec在文档检索系统中的应用,
# 特别适合需要结合语义搜索和元数据过滤的场景。
  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
# 示例3:实时推荐系统
def real_time_recommendation():
    """
    演示如何构建实时推荐系统:
    1. 动态更新用户兴趣向量
    2. 实时获取推荐结果
    3. 处理冷启动问题
    """
    import zvec
    import numpy as np
    import random
    
    # 初始化商品数据库
    product_db = zvec.Database(dim=5)
    
    # 添加商品(实际中应该是真实的商品特征)
    products = [
        ("手机", np.array([0.8, 0.1, 0.1, 0.0, 0.0])),
        ("笔记本电脑", np.array([0.7, 0.2, 0.1, 0.0, 0.0])),
        ("运动鞋", np.array([0.1, 0.8, 0.1, 0.0, 0.0])),
        ("小说", np.array([0.1, 0.1, 0.7, 0.1, 0.0])),
        ("耳机", np.array([0.6, 0.1, 0.1, 0.2, 0.0]))
    ]
    
    for name, vec in products:
        product_db.add(name, vec)
    
    # 模拟用户兴趣向量(初始随机)
    user_interest = np.random.rand(5)
    
    # 模拟用户行为更新兴趣向量
    def update_interest(action_item):
        nonlocal user_interest
        # 简单的加权更新(实际中可能需要更复杂的算法)
        item_vec = product_db.get(action_item).vector
        user_interest = 0.7 * user_interest + 0.3 * item_vec
    
    # 获取推荐
    def get_recommendations():
        return product_db.search(user_interest, top_k=3)
    
    # 模


---
## 案例研究


### 1:个人知识库管理工具 Obsidian 插件开发

 1个人知识库管理工具 Obsidian 插件开发

**背景**:
Obsidian 是一款流行的本地优先的个人知识管理工具许多用户希望在本地数千条笔记中通过语义搜索来查找内容而不是仅仅依赖关键词匹配然而Obsidian 插件运行在本地 Node.js 环境中对资源消耗极其敏感

**问题**:
传统的解决方案通常需要用户单独安装 Docker 容器或部署 MilvusQdrant 等重型向量数据库这极大地提高了使用门槛导致普通用户难以配置同时外部服务调用会破坏 Obsidian "本地优先"  "离线可用" 的核心体验

**解决方案**:
开发者使用 Zvec 作为嵌入式向量数据库集成到 Obsidian 插件中Zvec 以轻量级库的形式存在无需任何外部依赖或守护进程插件在本地对笔记进行分块并向量化后直接将索引存储在本地文件系统中通过 Zvec 进行毫秒级的相似度检索

**效果**:
- **部署零门槛**: 用户只需安装插件即可使用语义搜索无需配置服务器或 Docker
- **性能优异**: 在包含 10,000+ 篇笔记的库中语义搜索响应时间控制在 100ms 以内且内存占用仅增加了约 50MB几乎不影响 Obsidian 的流畅度
- **隐私安全**: 所有向量化数据和索引完全存储在本地满足了隐私敏感用户对数据不出域的要求

---



### 2:SaaS 平台的高频实时推荐系统

 2SaaS 平台的高频实时推荐系统

**背景**:
一家处于快速成长期的 B2B SaaS 企业为其用户提供行业新闻和文档的推荐功能随着用户量从 5,000 增长到 50,000原有的基于 PostgreSQL 的向量搜索扩展 pgvector在高并发查询下开始出现性能瓶颈

**问题**:
虽然 PostgreSQL + pgvector 能够满足基本需求但在业务高峰期复杂的向量相似度计算会占用大量数据库连接池和 CPU 资源导致核心的 OLTP 事务如订单处理用户写入出现延迟此外引入专门的分布式向量数据库 Weaviate对于该团队目前的运维成本来说过高

**解决方案**:
团队决定将"读密集型"的向量检索逻辑从主数据库中剥离在应用服务的微服务中引入 Zvec构建应用内的内存向量索引主数据库在数据变更时通过 CDC (Change Data Capture) 异步通知应用层Zvec 负责在内存中实时更新倒排索引

**效果**:
- **释放数据库压力**:  90% 的向量搜索流量从 PostgreSQL 转移到了应用层 Zvec 实例中主数据库 CPU 使用率下降 40%显著提升了交易系统的稳定性
- **低延迟体验**: 由于 Zvec 是进程内调用省去了网络 I/O 开销推荐接口的 P99 延迟从原来的 200ms 降低至 20ms 以内
- **成本控制**: 无需采购额外的专用向量数据库服务器仅利用现有的应用服务器算力即可支撑业务增长

---



### 3:边缘计算设备上的离线 AI 助手

 3边缘计算设备上的离线 AI 助手

**背景**:
某工业物联网公司开发了一款运行在树莓派Raspberry Pi或工业网关上的"智能运维助手"该设备需要根据设备的历史维修日志和手册为现场工程师提供实时的故障诊断建议由于工厂环境通常网络受限或不仅联网系统必须完全离线运行

**问题**:
边缘设备的硬件资源非常有限1GB-2GB 内存ARM 架构)。大多数开源向量数据库不仅体积庞大而且对 ARM 架构的支持不稳定或者需要过多的内存才能加载索引导致设备频繁 OOM (Out of Memory) 崩溃

**解决方案**:
开发团队选用了 Zvec 作为核心检索引擎利用 Zvec 轻量级且无外部依赖的特性将其编译进原生的 Go/Python 运行时环境中系统启动时将预计算好的设备维修手册向量索引加载到 Zvec 

**效果**:
- **极致轻量化**: Zvec 运行时占用内存极低在低端 ARM 设备上运行流畅不仅支持文本检索甚至有余力处理传感器时序数据的异常检测
- **即时响应**: 工程师在终端输入故障描述Zvec 在本地毫秒级匹配最相关的维修案例无需将数据上传至云端保证了数据的绝对安全和响应速度
- **简化维护**: 由于 Zvec 是嵌入式库不需要在边缘设备上维护复杂的数据库服务状态大大降低了远程运维的难度

---
## 最佳实践

## 最佳实践指南

### 实践 1:合理选择应用场景与数据规模

**说明**: Zvec 是一个轻量级进程内的向量数据库它不具备分布式能力且依赖内存运行因此它最适合于原型开发中小规模的语义搜索RAG检索增强生成系统的后端存储或者作为边缘设备上的本地向量引擎它不适合处理海量数据亿级向量或需要多节点分布式写入的场景

**实施步骤**:
1. 评估当前项目的数据量级确认向量数量在百万级以内
2. 确认应用部署架构如果是单机容器或单体应用则非常适合
3. 若数据量持续增长超过内存限制应考虑迁移至分布式向量数据库 Milvus  Weaviate)。

**注意事项**: 避免在生产环境中将其用于需要高可用性和故障转移的核心业务除非配合外部持久化和恢复机制

---

### 实践 2:实施严格的内存管理与监控

**说明**: 由于 Zvec 是进程内数据库所有向量索引通常加载在内存中以实现极速检索如果不加限制大规模数据插入可能导致 OOM内存溢出),直接导致进程崩溃

**实施步骤**:
1. 在启动应用时设置严格的堆内存或进程内存限制
2. 实施数据分片策略例如按时间或类别将数据存储在不同的 Zvec 实例中而不是单实例存储所有数据
3. 监控进程的内存使用率设置告警阈值

**注意事项**: 在进行批量向量插入时务必分批处理不要一次性加载整个数据集

---

### 实践 3:利用持久化机制防止数据丢失

**说明**: 虽然 Zvec 是内存优先的但为了防止进程退出或服务器重启导致数据丢失需要配合其持久化功能通常是快照保存或写入事务日志)。

**实施步骤**:
1. 配置定期的快照保存间隔根据数据更新的频率平衡性能与数据安全性例如每 5 分钟保存一次)。
2. 确保将快照文件和数据日志挂载到持久化磁盘或云存储中而不是仅存储在容器临时层
3. 在应用启动时编写逻辑自动从最近的快照文件中恢复索引状态

**注意事项**: 持久化操作可能会产生 I/O 阻塞建议在异步线程中执行保存操作以免阻塞主搜索请求

---

### 实践 4:优化向量维度与索引参数

**说明**: Zvec 的性能与向量维度和索引算法 HNSW的参数设置密切相关过高的维度会显著增加计算量和内存占用

**实施步骤**:
1. 在生成 Embedding 选择合适的模型维度例如使用较小的量化模型或降维技术),在精度和速度之间取得平衡
2. 根据业务需求调整索引参数 HNSW  `ef_construction`  `M` )。如果更看重写入速度而非极致的召回率可适当降低构建参数
3. 对不同类型的数据建立独立的 Collection以便针对不同场景应用不同的索引配置

**注意事项**: 修改索引参数通常需要重建索引请在业务低峰期或初始化阶段完成

---

### 实践 5:构建高效的批量处理管道

**说明**: 单条插入向量会导致频繁的锁竞争和索引重建严重影响吞吐量利用 Zvec 的批量 API 可以显著提升写入性能

**实施步骤**:
1. 在代码中将向量数据积攒到一定数量例如 500  1000 再调用批量插入接口
2. 使用生产者-消费者模式将向量计算与入库操作分离避免阻塞主业务线程
3. 对于实时性要求不高的数据可以采用定时任务进行批量刷盘

**注意事项**: 批量大小不宜过大需结合单次请求的内存占用时间进行压测避免单次请求耗时过长导致超时

---

### 实践 6:建立连接池与并发控制策略

**说明**: 如果 Zvec 被用于多线程服务端程序 Java/Python Web 服务),必须处理好并发读写问题防止索引结构损坏或性能下降

**实施步骤**:
1. 确保对 Zvec 实例的访问是线程安全的如果 Zvec 客户端本身非线程安全应在应用层使用读写锁或单例模式封装访问逻辑
2. 限制并发写入的线程数过多的并发写会导致索引锁争用反而降低吞吐量
3. 实现熔断机制当数据库负载过高时暂时拒绝新的查询请求防止系统雪崩

**注意事项**: 在进行耗时的索引重建或批量导入时可能会阻塞读请求建议在架构设计上考虑读写分离或主从热备如果支持)。

---
## 学习要点

- Zvec 是一个轻量级且高性能的进程内向量数据库专为嵌入式场景设计无需部署独立的基础设施
- 它采用 Rust 编写利用 SIMD 指令集优化实现了极快的向量检索速度和低延迟
- 该数据库支持在本地进程内直接运行消除了网络 I/O 开销非常适合边缘计算或客户端应用
- Zvec 提供了简洁的 API 设计允许开发者轻松地将向量搜索功能集成到现有的应用程序中
- 作为一个专注于效率的解决方案它在保持轻量体积的同时仍能处理大规模的向量数据集

---
## 常见问题


### 1: 什么是 Zvec,它与 Pinecone 或 Milvus 等传统向量数据库有何不同?

1: 什么是 Zvec它与 Pinecone  Milvus 等传统向量数据库有何不同

**A**: Zvec 是一个专为进程内设计的轻量级极速向量数据库 Pinecone  Milvus 等传统向量数据库不同Zvec 不需要独立的服务器或容器来运行它作为一个库直接嵌入到您的应用程序代码中消除了网络延迟这使得它非常适合边缘计算无服务器环境或本地优先的应用程序在这些场景中运行独立数据库的开销或复杂性是不必要的



### 2: Zvec 是如何实现高性能的?

2: Zvec 是如何实现高性能的

**A**: Zvec 的性能主要归功于其架构首先通过在进程内运行它完全避免了网络 I/O 开销这意味着向量搜索仅受内存速度和 CPU 算力的限制其次它通常使用高度优化的内存数据结构和 SIMD单指令多数据指令集来加速向量距离计算如余弦相似度或欧几里得距离)。这种组合使得 Zvec 在处理中小规模数据集时比基于客户端-服务器的解决方案快得多



### 3: Zvec 的主要使用场景有哪些?

3: Zvec 的主要使用场景有哪些

**A**: Zvec 最适合需要在本地进行快速语义搜索或相似性匹配的场景常见用例包括为本地 LLM大语言模型提供 RAG检索增强生成上下文在客户端设备如笔记本电脑或手机上进行文档或图像搜索实时推荐系统以及作为内存缓存层它不适合需要 PB 级数据存储或需要多节点分布式写入的超大规模系统



### 4: 既然 Zvec 是“进程内”的,数据持久化是如何处理的?

4: 既然 Zvec 进程内数据持久化是如何处理的

**A**: 作为进程内数据库Zvec 的数据通常存储在应用程序的内存地址空间中为了持久化它通常支持将向量索引保存到磁盘例如通过内存映射文件或序列化快照)。这意味着虽然搜索速度极快在内存中进行),但在应用程序重启时可以从磁盘快速加载之前保存的索引状态从而在保持轻量级的同时实现数据的持久化



### 5: Zvec 支持哪些索引算法或距离度量?

5: Zvec 支持哪些索引算法或距离度量

**A**: 虽然具体实现取决于库的版本但像 Zvec 这样的现代轻量级向量数据库通常支持标准的近似最近邻ANN算法 HNSW - 分层导航小世界图以平衡速度和准确性在距离度量方面它通常支持内积余弦相似度和 L2 距离欧几里得距离),这些是机器学习和语义搜索中最常用的度量标准



### 6: 在生产环境中使用 Zvec 有哪些局限性?

6: 在生产环境中使用 Zvec 有哪些局限性

**A**: 主要的局限性在于可扩展性和隔离性由于 Zvec 运行在应用程序进程内它消耗应用程序的内存和 CPU 资源如果向量数据集变得过大可能会导致应用程序内存不足OOM)。此外它无法像独立数据库那样轻松地在多个应用程序实例之间共享数据除非使用分布式内存或文件系统锁),且不具备传统数据库提供的复杂身份验证或访问控制层



### 7: Zvec 是用什么编程语言编写的,它支持哪些语言绑定?

7: Zvec 是用什么编程语言编写的它支持哪些语言绑定

**A**: 为了追求极致的性能和轻量化此类核心库通常使用 RustC  C++ 编写Zvec 很可能提供了多种语言的接口Bindings),特别是 Python因为它是数据科学和 AI 领域的主导语言这种设计允许开发者在 Python 等高级语言中轻松调用高性能的底层代码而无需担心底层系统的复杂性

---
## 思考题


### ## 挑战与思考题

### ### 挑战 1: [简单]

### 问题**: Zvec 强调 "In-process"(进程内)架构。请分析在构建一个嵌入式向量数据库时,相比于传统的 Client-Server 架构(如通过 HTTP 调用独立的向量数据库),"In-process" 架构在网络开销、数据序列化和延迟方面有哪些具体的性能优势?请列出至少三点。

### 提示**: 思考数据在内存和磁盘之间移动的路径,以及跨进程通信(IPC)或网络通信(TCP/IP)带来的成本。

### 

---
## 引用

- **原文链接**: [https://github.com/alibaba/zvec](https://github.com/alibaba/zvec)
- **HN 讨论**: [https://news.ycombinator.com/item?id=47000535](https://news.ycombinator.com/item?id=47000535)

> 文中事实性信息以以上引用为准观点与推断为 AI Stack 的分析

---


---
## 站内链接

- 分类 [开发工具](/categories/%E5%BC%80%E5%8F%91%E5%B7%A5%E5%85%B7/) / [数据](/categories/%E6%95%B0%E6%8D%AE/)
- 标签 [向量数据库](/tags/%E5%90%91%E9%87%8F%E6%95%B0%E6%8D%AE%E5%BA%93/) / [Zvec](/tags/zvec/) / [轻量级](/tags/%E8%BD%BB%E9%87%8F%E7%BA%A7/) / [进程内](/tags/%E8%BF%9B%E7%A8%8B%E5%86%85/) / [Rust](/tags/rust/) / [Embeddings](/tags/embeddings/) / [高性能](/tags/%E9%AB%98%E6%80%A7%E8%83%BD/) / [开源](/tags/%E5%BC%80%E6%BA%90/)
- 场景 [Web应用开发](/scenarios/web%E5%BA%94%E7%94%A8%E5%BC%80%E5%8F%91/)

### 相关文章

- [Zvec轻量级进程内向量数据库](/posts/20260215-hacker_news-zvec-a-lightweight-fast-in-process-vector-database-6/)
- [Zvec轻量级进程内向量数据库](/posts/20260215-hacker_news-zvec-a-lightweight-fast-in-process-vector-database-3/)
- [Zvec轻量级进程内向量数据库](/posts/20260215-hacker_news-zvec-a-lightweight-fast-in-process-vector-database-4/)
- [Zvec轻量级进程内向量数据库速度快](/posts/20260214-hacker_news-zvec-a-lightweight-fast-in-process-vector-database-6/)
- [Zvec轻量级进程内向量数据库](/posts/20260215-hacker_news-zvec-a-lightweight-fast-in-process-vector-database-2/)
*本文由 AI Stack 自动生成包含深度分析与可证伪的判断*