【认知破冰篇02】AI编程与传统IT的区别——用我熟悉的语言重新理解

发布时间:2026/6/30 1:24:10
【认知破冰篇02】AI编程与传统IT的区别——用我熟悉的语言重新理解 如果说上一篇文章回答了“为什么要学”认知破冰篇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的直观理解HNSWHierarchical Navigable Small World是向量数据库最常用的索引算法。它可以理解为多层地图导航系统想象你要在一个陌生城市找一家咖啡店顶层粗粒度只有主干道和主要地标快速定位到大致区域中层中粒度有主要街道和小区缩小范围底层细粒度所有街巷和店铺精确定位目标HNSW也是同样原理查询向量 → 从顶层快速跳转到大致位置 → 逐层细化 → 在底层精确比较 底层比较时不是全量比较而是只比较“跳转路径上”的节点 → 这就是“近似”的来源——牺牲一点点精度换取速度的巨大提升关键认知向量检索不保证100%精确但能保证“足够好且足够快”。这正是AI应用能够落地的工程基础。四、用存储过程类比理解模型推理4.1 存储过程 vs 模型推理对比维度传统存储过程大模型推理输入参数如 user_id, start_datePrompt文本逻辑程序员预先编写的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逐词拼接成完整回答五、用事务类比理解RAG5.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性能监控检索质量 模型响应时间七、对比总结维度传统ITAI编程核心能力精确定义和操作语义理解和生成数据模型结构化表/字段/关系非结构化文本/向量/语义查询方式精确匹配, , LIKE近似匹配相似度结果确定性100%确定概率性有一定随机性开发工具链SQL/Java/IDEPython/LLM/向量库调试方式断点调试、日志Prompt调优、Embedding质量评估性能考量索引、查询优化Token数、上下文长度、响应时间价值定位精确数据处理智能内容生成八、实践建议8.1 如果你只记得三件事向量≈语义坐标检索≈找最近邻居不需要理解高维空间只需要理解“距离近语义像”Token≈处理单位成本≈Token数问题越短、文档越精简成本越低Prompt≈编程语言调优≈调试写好Prompt需要反复试错就像调试代码一样8.2 学习建议阶段建议第一个月跑通Demo聊天、搜索、RAG建立直观认知第二个月深入理解向量检索、Prompt工程开始优化效果第三个月尝试Agent、多工具调用构建完整应用8.3 避坑指南坑避坑建议过度追求精确向量检索是概率性的接受一定误差忽略上下文长度大模型有Token限制控制输入长度低估Prompt重要性同样的模型不同的Prompt效果天差地别一次性追求完美先跑通再优化迭代推进九、下篇预告下一篇将继续回到工程实践继续我们之前已经开始的RAG知识库实战把本文的理论落实到代码和场景中。作者Javy21javy21csdn博客主页javy21-CSDN博客首发日期2026年7月本文是《老攻城狮的AI编程实践之路》专栏的第02篇。用数据库思维理解AI用工程方法落地AI。本文采用CC BY-NC 4.0许可协议。欢迎转载请注明出处。