【导航台账】老蒋的技术博客全系列文章汇总（持续更新）

如果说上一篇文章回答了“为什么要学”（认知破冰篇01-为什么一个20+年IT老兵决定系统性学习AI人工智能），这一篇文章要回答“怎么理解”。作为写了二十多年SQL和Java的老IT，我把AI的底层概念翻译成了我们熟悉的语言。读完你会发现：AI没那么玄，只是换了一套工具集，目标依然是解决问题。

---

一、引言：AI编程到底是什么？

        我开始学习AI编程的时候第一周，最困惑的不是代码，而是概念。向量、嵌入、相似度、召回、推理、token……这些词我一个都不熟悉。打开技术文章，满篇都是“高维空间语义相似度”、“神经网络的注意力机制”，看了半小时，似懂非懂。

后来我想通了——我不是要成为AI研究员，我是要成为AI应用开发者。 我不需要重新学一遍线性代数，我只需要理解这些概念在工程上意味着什么。

于是我用自己最熟悉的语言来重新理解AI：数据库语言。

• 表 → 向量集合

• 行 → 向量

• 索引 → HNSW图

• 查询 → 相似度搜索

• 存储过程 → 模型推理

        如果你也是一名写了多年SQL、Java、Python的IT从业者，这篇文章就是为你写的。我会用我们熟悉的数据库思维，把AI的核心概念一个一个拆解开。

二、用数据库思维理解向量

2.1 什么是向量？

数据库视角：向量就是一行有N个字段的记录。

举例：

-- 传统数据库的一行 
SELECT id, name, age, city FROM users WHERE id = 1; 
-- 返回：1, '张三', 32, '北京' 
-- 向量数据库的一行（384个字段） 
SELECT id, text, vec_1, vec_2, ..., vec_384 FROM documents WHERE id = 'doc_001'; 
-- 返回：'doc_001', '十五五规划纲要', 0.23, -0.45, 0.67, ..., 0.12

关键认知：传统数据库的行是“描述事实”，向量数据库的行是“描述语义”。每个向量位置（维度）不是一个具体属性，而是模型学习到的某种语义特征的强度。

2.2 维度意味着什么？

维度	传统数据库	向量数据库
3维	(X, Y, Z) 坐标	在三维空间中，很难区分100个不同的概念
384维	384个字段（几乎不可能手工设计）	在384维空间中，可以区分海量概念
768维	更大的字段数	区分能力更强，但计算更慢

        关键认知：向量维度的本质是表达空间的大小。384维意味着模型用384个“特征轴”来区分不同的语义。维度越高，区分能力越强，但计算成本也越高。

2.3 如何生成向量？

传统数据库：
    INSERT INTO users (name) VALUES ('张三');
    → 直接存储字符串 '张三'

向量数据库：
    text = "十五五规划纲要"
    → 调用向量化模型（如 all-MiniLM-L6-v2）
    → 生成384个浮点数：[0.23, -0.45, 0.67, ..., 0.12]
    → 存入向量数据库

        关键认知：向量是“算出来的”，不是“填进去的”。向量化模型就是编码器，把人类语言翻译成机器能够计算比较的数学语言。

三、用索引类比理解向量检索

3.1 传统索引 vs 向量索引

对比维度	传统数据库索引（B+树）	向量数据库索引（HNSW）
数据结构	平衡多叉树	分层导航小世界图
查询方式	精确匹配 / 范围查询	近似最近邻（ANN）
返回结果	精确命中	近似最相似
时间复杂	O(log n)	O(log n) 近似
适用场景	“等于”、“大于”、“LIKE”	“最相似”

3.2 HNSW的直观理解

        HNSW（Hierarchical Navigable Small World）是向量数据库最常用的索引算法。它可以理解为：

多层地图导航系统

想象你要在一个陌生城市找一家咖啡店：

• 顶层（粗粒度）：只有主干道和主要地标，快速定位到大致区域

• 中层（中粒度）：有主要街道和小区，缩小范围

• 底层（细粒度）：所有街巷和店铺，精确定位目标

HNSW也是同样原理：

查询向量 → 从顶层快速跳转到大致位置 → 逐层细化 → 在底层精确比较

底层比较时，不是全量比较，而是只比较“跳转路径上”的节点
→ 这就是“近似”的来源——牺牲一点点精度，换取速度的巨大提升

        关键认知：向量检索不保证100%精确，但能保证“足够好且足够快”。这正是AI应用能够落地的工程基础。

四、用存储过程类比理解模型推理

4.1 存储过程 vs 模型推理

对比维度	传统存储过程	大模型推理
输入	参数（如 user_id, start_date）	Prompt文本
逻辑	程序员预先编写的SQL+过程逻辑	模型参数中蕴含的海量模式
处理	确定性计算	概率性生成
输出	固定格式的结果集	动态生成的文本
维护	修改存储过程代码	更新模型权重文件

4.2 推理的直观理解

存储过程：
    CALL get_user_orders(1001, '2024-01-01', '2024-12-31')
    → 执行预设的SQL逻辑
    → 返回固定结构的订单列表

模型推理：
    Prompt = "请列出十五五规划中关于能源转型的主要目标"
    → 模型根据参数中的模式“理解”问题
    → 逐词生成回答（每次预测下一个最可能的词）
    → 返回自然语言文本

4.3 Token的概念

Token是模型处理文本的基本单位，可以理解为“单词的碎片”。

# 一个Token示例
"十五五规划" → ["十", "五", "五", "规", "划"]  # 中文单字切分
"Artificial Intelligence" → ["Art", "ificial", " Intelligence"]  # 英文词块切分

# Qwen2.5:7B的上下文窗口是128K Tokens
# 约等于：中文10-15万字，英文8-10万词

关键认知：

• 模型不“读”文字，它“读”Token序列

• 模型不“理解”语义，它“预测”下一个Token的概率

• 每次生成一个Token，逐词拼接成完整回答

五、用事务类比理解RAG

5.1 为什么需要RAG？

问题	纯大模型	RAG方案
幻觉	模型可能编造不存在的“事实”	从外部知识库中检索答案
知识截止	只懂训练截止前的信息	可以检索最新文档
数据安全	训练数据可能泄露	数据本地化，不上传云端
成本	大模型参数量巨大	用小模型+知识库，成本可控

5.2 RAG的流程

关键认知：

• 向量检索≈SQL查询（但查的是“语义”而非“精确值”）

• 上下文构建≈数据组装

• 模型推理≈存储过程执行（但结果是动态生成的）

六、整体对比框架

6.1 完整对照表

传统IT概念	AI编程对应概念	简要说明
数据库表	向量集合（Collection）	存放向量的容器
数据库行	向量（Vector）	一段文本的数学表示
字段	维度（Dimension）	语义特征的轴，通常384或768维
B+树索引	HNSW/IVF索引	加速近似搜索的数据结构
SQL查询	相似度搜索（Similarity Search）	查找最相似的向量
WHERE条件	过滤（Filter）	按元数据筛选
JOIN操作	上下文构建（Context Building）	组合多个检索结果
存储过程	模型推理（Inference）	根据输入生成输出
事务	Agent循环（Agent Loop）	多轮思考-行动-观察
触发器	RAG检索增强	在推理前自动检索知识
视图	向量嵌入（Embedding）	文本→向量的转换

6.2 开发流程对比

阶段	传统IT开发	AI应用开发
需求分析	理解业务需求	理解业务需求 + 评估AI能力边界
设计	设计表结构、接口	设计向量结构、Prompt模板、检索策略
编码	写SQL、Java、Python	写Python + LangChain链 + Prompt调试
测试	测试精确结果	测试相似度质量 + 人工评估回答
部署	部署到服务器	部署模型 + 向量库 + Web服务
运维	监控SQL性能	监控检索质量 + 模型响应时间

七、对比总结

维度	传统IT	AI编程
核心能力	精确定义和操作	语义理解和生成
数据模型	结构化（表/字段/关系）	非结构化（文本/向量/语义）
查询方式	精确匹配（=, >, LIKE）	近似匹配（相似度）
结果确定性	100%确定	概率性（有一定随机性）
开发工具链	SQL/Java/IDE	Python/LLM/向量库
调试方式	断点调试、日志	Prompt调优、Embedding质量评估
性能考量	索引、查询优化	Token数、上下文长度、响应时间
价值定位	精确数据处理	智能内容生成

八、实践建议

8.1 如果你只记得三件事

1. 向量≈语义坐标，检索≈找最近邻居

   • 不需要理解高维空间，只需要理解“距离近=语义像”

2. Token≈处理单位，成本≈Token数

   • 问题越短、文档越精简，成本越低

3. Prompt≈编程语言，调优≈调试

   • 写好Prompt需要反复试错，就像调试代码一样

8.2 学习建议

阶段	建议
第一个月	跑通Demo（聊天、搜索、RAG），建立直观认知
第二个月	深入理解向量检索、Prompt工程，开始优化效果
第三个月	尝试Agent、多工具调用，构建完整应用

8.3 避坑指南

坑	避坑建议
过度追求精确	向量检索是概率性的，接受一定误差
忽略上下文长度	大模型有Token限制，控制输入长度
低估Prompt重要性	同样的模型，不同的Prompt效果天差地别
一次性追求完美	先跑通，再优化，迭代推进

九、下篇预告

        下一篇将继续回到工程实践，继续我们之前已经开始的 RAG知识库实战，把本文的理论落实到代码和场景中。

作者：Javy21（javy21@csdn）
博客主页：javy21-CSDN博客
首发日期：2026年7月

本文是《老攻城狮的AI编程实践之路》专栏的第02篇。用数据库思维理解AI，用工程方法落地AI。

本文采用 CC BY-NC 4.0 许可协议。欢迎转载，请注明出处。🙌