AI 软件工程开发 AI 算法 架构与业务

前言

AI会改变开发模式甚至行业岗位

1.AI 软件工程开发

工程方向

1.1. AI Developer Studio （playground级）

开发平台/工具一般包含多种先进的LLM，并开放了很多定制化设置，供用户开发。相比于纯ChatGPT这种使用工具，AI Developer Studio是基于AI的工作平台。
一般来说，满血的账号费用都较高，免费使用的阉割了很多功能，仅开放一小部分数据训练、参数调整以及少量LLM供选择。

1.Vertex AI (Geogle)

• Vertex AI Studio：Multimodal、Language(text/tasks/code…)、Vision(video/image…)、Speech(audio…)

• LLM (Large Language Model) prompt: Zero-shot prompting / One-shot prompting / Few-shot prompting

• Prompt design:
  1.freedom:大模型直接问答
  2.structured(Context给出背景，Example给出想要的input和output，以规训重点，最后Test)：大模型根据你的偏好，save一个特定大模型，回答你的问题

• How to design Prompt（Prompt工程师）:
  Be concise
  Specific and clearly-defined
  ask one task at once
  ask to classify instead of generate(要选择题最好不要发散式)
  include examples

• temperature(概率分布): 对回答的随机程度进行调优， 0-1, 0是确定, 1是随机, 即越靠近0概率越大
  top K: 对回答的概率最高的一部分答案进行随机
  top P: 对回答的概率最高的答案进行累加，直到累加值达到top P，即对回答的概率最高的答案进行随机

• 模型调优(Model tuning):
  How to customize and tune a gen AI model:
  越来越偏技术：
  1.Prompt design: Input(required) Context(optional) Example(optional)
  2.Adapter tuning(Parameters-efficient tuning): Fine-tuning a model on a specific task or dataset.监督，给出一小部分样本调优参数
  3.Reinforcement tuning(Parameters-efficient tuning): Fine-tuning a model on a specific task or dataset.非监督调优
  4.Distilling(Student model weight updates): 在Geogle cloud可以做, 可以更加生成特定模型。我理解就是迁移学习。

• Difference between AI and Machine Learning:
  输出确定的、“旧的”东西，用学术的话，输出的是Number、Discrete、Class、Probability的，叫ML。
  能输出“新的”东西，用学术的话，输出的是Natural language、Image、Audio（即所谓的非结构化数据），叫GEN AI。
  举个例子，如果输入猫狗图片，且每张图片label是文字“猫”、文字“狗”。训练后模型最后能预测猫狗，这叫ML。
  如果输入大量的猫狗图片，且按照你想要的方式进行训练（这里涉及到模型了，具体需不需要lable或者怎么lable有疑惑）。训练后模型最后能生成新的猫狗图片，这叫Gen AI。

• AI Develop
  Data Security，开源的模型，私有化部署local AI(teacher student…)

2.Azure AI Foundry (Microsoft)

1.2. Agent & RAG

1. Agent

• 能够基于任务目标执行(行动，动作，action)多步骤动作的系统，它能通过调用工具、API 、知识库、插件、代码库等等，动态规划并完成复杂任务。Agent 具备一定程度的自主决策能力。

• 核心组成：
  Brain: 处理/计算/记忆/计划/决策
  Perception: 多模态输入
  Action: 调用工具、SDK、API 、知识库、插件、代码库等等，完成交互

• Agent 设计模式
  Reflection pattern：LLM审核LLM（LLM串）
  Tool use pattern：Tool, Database, API and MCP
  ReAct pattern：Reasoning and Acting. 由于推理类模型发展，由R模型自己出调用方式及顺序。再串通用模型（G模型）。
  Planning pattern：升级成任务维度。每个任务交给一个ReAct Agent。
  Multi-agent pattern：升级成人类组织维度。每个工作交给特定职位Agent，且能内部之间交互。

2. RAG, Retrieval Augmented Generation

• RAG：Retrieval-Augmented Generation的缩写，指“检索增强生成”，这是一个跨越检索和生成任务的框架，通过先从数据库或文档集合中检索到相关信息，然后利用生成模型（如Transformer模型）来生成最终的输出。工程领域。

• LLM应用方案。将大模型应用于实际业务场景遇到几个问题：1.无法具备全部知识（包括实时数据、非公开数据、私有数据、私有专家知识等） 2.幻觉（无法具备全部知识）3.数据安全 4.微调计算成本较高

• 核心思想：检索 增强 生成。检索体现在：私有数据/数据存储到向量数据库（因为结合了transformer训练时数据处理word embedding）后高效的检索能力，召回目标知识。生成体现在：大模型+Prompt工程，将召回的知识合理利用，融入到Prompt里，大模型更根据目前的提问+能够参考相应的知识（上下文），生成目标答案。主要分三个阶段：数据准备、数据召回（向量搜索出最相近的k个数据库）和答案生成

• 向量数据库：Faiss等等

• 词嵌入Embedding：将高维、稀疏的离散数据，如文本、图像、用户行为等，映射到低维、稠密的连续向量空间。通过向量形式能够精准捕捉数据间的潜在语义关系，使得计算机可以通过几何距离，如欧氏距离、余弦相似度，来量化分析数据的相似性和相关性。

• 提示词工程（Prompt Engineering）

Tips:
Prompt工程：一般包括任务描述、背景知识（检索得到）、任务指令（一般是用户提问）

3. 再谈RAG

传统朴素RAG流程:
Document -> Chunking - > Embedding -> VectorStore <- Embedding <- Query/Prompt(LLM) <- Query ↓ Retrieval chunks(高维向量语义相似度, VectorDB针对向量快速检索/大规模并行处理/存储等专业功能) ↓ Prompt/Answer ↓ LLM↓ Answer to UserRAG 2.0 针对不足，进一步在流程编排和工程/算法上做优化:
RAGFlow框架

1.3. LangChain & LangGraph

LangChain for LLM Application Development:

• LangChain is a open-source framework for developing applications powered by language models(LLM Applications).
• python version(packages) & JS/TS version(packages)
• Composition and modularity
• Components / Off-the-shelf chains: Off-the-shelf chains make it easy to get started. Components make it easy to customize existing chains and build new ones.

modules：

• Components fall into the following modules:
  1.Models
  2.prompt and output parsers
  3.index(for RAG)
  4.Chain(eg. prompt + LLM + output parsing. And more and more application chains)
  5.Agents(LLM base, Memory(chatbot), Action)

Models, Prompts, Output Parsers: API/Local. (LangChain’s hello world)

Memory: LLMs are stateless. Chatbots appear to have memory by providing the full conversation as context. However, LLMs API is charge by token. Langchain provide some memory tricks, feature like keep just a number of conversiation/tokens.

Chains: use ‘MoE’ idea in Enginner. Intertesting.

Q&A with Documents: word embedding, vector database, index. query come, after this, give LLM. Stuff method, simple RAG. Additional 3 methods: Map_reduce/Refine/Map_rerank

Evaluation: use LLM to evaluation answer.

Agent: pre/cus tools.

• LCEL

LangChain Expression Language (LCEL): 异步、批处理和流支持
eg. 代码里写chain = prompt | model | output_parser，类似学linux操作系统里的linux命令的piple概念。

• ReAct
  The ReAct (Reasoning and Acting) pattern is a framework for building AI agents that combine reasoning (thinking) with acting (taking actions).Break Down.

Built an agent from scratch.

Prompts: can import. allow reusable prompts(LangChain hub).

Tools: get a tool from the library.

Others: pattern is also like graphs.

• LangGraph

Knowledge Graph 知识图谱：是结构化的语义知识库，用于迅速描述物理世界中的概念及其相互关系。实体,关系,实体。

图数据库：Neo4j

LangGraph 是一个结合 LangChain 与知识图谱（Knowledge Graph）的应用，旨在通过结构化的知识库增强语言模型的理解和响应能力。

Graphs to build Agent:
1.Nodes(Agents or functions), Edges(connect nodes), Conditional edges(decisions)
2.Data/State: State Memory (State Snapshot)
3.Image: can draw the image of your graph.
4.powerfull Tool: Search Tool(like Tavily)
5.persistence and streaming: usefully in long running application.
checkpoints(database, SQL, NoSQL) for persistence.
get individual messages / observation message / token of streaming(not .invoke)
Above of these can config as 2 thread to separate 2 mode. (another model don’t have this model’s persistence/memory)
6.user/human can interrupt the loop and choose(improve)

• SQLite

一款轻型-轻量级的数据库，是遵守ACID的关系型数据库管理系统。

架构：MySQL 是一个客户端/服务器架构的数据库管理系统，这意味着它需要一个单独的服务器进程来运行。而 SQLite 是一个无服务器的数据库管理系统，它直接读取和写入磁盘文件。

存储：MySQL 数据库存储在磁盘上的文件中，但需要通过 MySQL 服务器进程来访问和管理。SQLite 数据库也存储在磁盘上的文件中，但可以直接通过 SQLite 命令行工具或编程语言的 SQLite 库来访问和管理。

SQLite是文件级的。所以替代的是文件存储的级别，不是client/server数据库的级别。单体/接单用足够。直接给它存成文件。

LangGraph写Agent用到了。

• Spring AI
  Java有Spring AI

1.4. MCP, Model Context Protocol

MCP, Model Context Protocol，旨在统一大型语言模型（LLM）与外部数据源和工具之间的通信协议。分client和server。client在host里。

host指的我们的调用程序本体，可以是LLM程序，IDE，AI工具，LangChain代码框架。

client / server，感觉和之前原始手写socket一个意思，一个client一个server建立网络通信TCP/IP。

协议

阿里云百炼 业内首发MCP服务，与开发者共同打造企业级AI应用新生态

1.5. Ollama

• Get up and running with large language models.
• 本地部署（非常方便的）多种LLMs
• 支持模型微调
• 支持命令行运行与直接交互、Ollama 的 Python SDK使用、API交互、WebUI

1.6. Coze & Dify

• Coze: 个人开发者 & Demo应用
• Dify：企业级

2.AI 算法

2.1. GenAI算法相关

2.1.1 Transformer

1.绝大多数先进的多模态大模型（如 GPT-4o、DeepSeek、Qwen2.5 等）的底层架构均基于 Transformer，但会根据多模态需求进行扩展和优化。Transformer 的核心优势在于其 自注意力机制（Self-Attention），能够高效建模长距离依赖关系，并天然支持并行计算。对于多模态任务（文本、图像、音频等），模型会通过以下方式扩展：

• 多模态输入编码：将不同模态数据（如文本、图像、音频）统一编码为向量序列。例如：图像被切分为小块并通过视觉编码器（如 ViT）转换为嵌入向量；音频通过语谱图、波形编码、短时傅里叶变换等预处理方式，预处理为向量序列（my work）。
• 跨模态注意力机制：允许不同模态的嵌入向量在注意力层中交互。

2.Transformer 模型的训练方式
核心训练范式：自监督预训练 + 有监督微调

• 阶段 1：预训练（自监督学习）：让模型从海量无标注数据中学习通用表示（如语言规律、跨模态关联）。输入和标签均来自同一数据，无需人工标注。典型的方法有掩码语言建模、自回归预测、多模态对齐等
• 阶段 2：微调（有监督学习）：针对特定任务（如问答、图像描述生成）优化模型。需要人工标注的输入-输出对。指令微调、强化学习等
• 阶段 3：推理（部署后）。训练时需标签（显式或隐式），推理时仅需输入。

references：
Attention is all you need
十分钟理解Transformer

2.2. 传统AI算法相关

SCI-2区：LSTM-convolutional-BLSTM encoder-decoder network for minimum mean-square error approach to speech enhancement
EI / 中文核心：基于抛物面焦点麦克风预处理和迁移学习的语音增强方法
专利：一种基于混合掩蔽学习目标的语音增强方法

3.架构与业务（架构与垂直领域）

3.1 BPM

3.1.1. BPMN概念

• Business Process Model and Notation，业务流程模型与标记法

BPMN 2.0 最革命性的变化在于引入了可执行性 (Executability)。这彻底改变了BPMN的定位。不仅要统一图形，更要统一其执行语义和文件格式。它的核心是“建模与执行”(Modeling and Execution)

• BPMN 2.0规范中有一百多个符号，但日常工作中80%的场景只需要用到其中不到20%的核心符号。

1.流对象 (Flow Objects)：流程图中的主要图形元素。

• 事件 (Events)：表示流程中发生的事情。用 圆圈 表示。

  • 开始事件 (Start Event)：一个细线圆圈，表示流程的起点。
  • 结束事件 (End Event)：一个粗线圆圈，表示流程的终点。
  • 中间事件 (Intermediate Event)：一个双线圆圈，表示流程进行中发生的事情（如等待、收到消息）。
  • 消息时间 (Message Event)：一个带箭头的圆圈，表示流程中接收或发送消息。

• 活动 (Activities)：表示需要完成的工作。用 圆角矩形 表示。

  • 任务 (Task)：一个原子性的工作单元，不可再分。
    （用户任务：当流程引擎走到一个用户任务时，它会暂停该流程实例的执行，并在其内部数据库中创建一个“待办任务”记录，并将其分配给BPMN图中指定的负责人（assignee）或候选组（candidate group），引擎会一直等待，直到有人通过外部应用（如您的Express应用）来“完成”这个任务；服务任务：需要由系统自动完成的工作（例如调用外部API、发送邮件、处理数据），对于Java来说，可以写一个Java的业务实现类，然后配置给流程引擎，由流程引擎调用。）
  • 子流程 (Sub-Process)：一组相关的任务，可以折叠和展开。

• 网关 (Gateways)：表示流程的分叉和合并。用 菱形 表示。

  • 排他网关 (Exclusive Gateway)：菱形里一个"X"。表示只有一个分支会被选择（类似if-else）。
  • 并行网关 (Parallel Gateway)：菱形里一个"+"。表示所有分支都将同时执行。
  • 包容网关 (Inclusive Gateway)：菱形里一个"O"。表示可以有一个或多个分支被选择。

2.连接对象 (Connecting Objects)：用于连接流对象。

• 顺序流 (Sequence Flow)：实线箭头，表示执行的顺序。
• 消息流 (Message Flow)：虚线箭头，表示不同流程参与者之间的消息传递。

3.泳道 (Swimlanes)：用于组织和分类活动。

• 池 (Pool)：代表一个独立的流程参与者（如一个公司、一个部门）。
• 道 (Lane)：在池内部，用于区分不同的角色或系统（如“申请人”、“经理”、“财务系统”）。

4.工件 (Artifacts)：提供额外的信息。

• 数据对象 (Data Object)：表示流程中需要用到的数据（如“报销单”）。
• 注释 (Annotation)：对图表进行文字说明。

(
更复杂场景也支持，如：
不同类型的事件：定时器事件（等待特定时间）、消息事件（接收/发送消息）、错误事件等。
不同类型的任务：用户任务、脚本任务、服务任务等。
事务性子流程 (Transactions) 和 补偿 (Compensation)。
)

3.1.2. BPMN类系统/低代码系统 前端框架 Logicflow

LogicFlow 是一款滴滴客服技术团队开源的流程图编辑框架，它提供了一系列流程图交互、编辑所必需的功能和灵活的节点自定义、插件等拓展机制。

Apache-2.0开源、支持前端三大框架

（Logicflow用法上，和g2plot/echarts之类的用法类似，代码里各种配置参数）

（发散聊一下，前端框架很多，如UI框架Element UI/Plus、Ant等等，还有低代码前端的框架，还有基于三大框架开发的工程化的项目框架即web那一套动态路由等等工程上的问题也全封装好了）

3.1.3. BPMN类系统后端引擎（BPMN引擎）

Flowable / Camunda 8(Cloud Native)：两大开源流行的BPMN 2.0流程引擎。可以直接在挡墙微服务里嵌入集成（即引包并配置），也可以独立部署（即单独部署一个服务，然后调用）。

问：floable和Camunda 提供拖拉拽设计流程页面吗？他们相当于是对xml进行编解码？举个例子：我在bpm建模器（如floable和Camunda）拖拉拽建模，会生成xml，然后java代码里集成floable和Camunda可以解析xml流程，然后执行。所以相当于代码永远不变，变的是xml？

答：

1. Flowable和Camunda提供这个页面吗？

是的，它们都提供！ 这就是我们之前提到的“BPMN建模器”，它是整个生态系统不可或缺的一部分。
Camunda: 提供一个名为 Camunda Modeler 的免费桌面应用程序。这是业界的黄金标准，非常强大和易用。
Flowable: 提供一个名为 Flowable Designer 的Web应用。它通常集成在Flowable的完整产品套件中，让你可以直接在浏览器里建模。

2. 它们相当于是对XML进行编解码？

编码 (Encoding): 当您在BPMN建模器里拖拽图形、填写属性时，建模器正在实时地将您的可视化操作编码成符合BPMN 2.0标准的XML文件。您看到的图形是给人看的，背后的XML是给机器读的。
解码 (Decoding / Parsing): 当您的Java应用（集成了Flowable/Camunda）启动或部署这个XML文件时，流程引擎会读取这个文件，并将其解码成一个它可以在内存中理解和执行的、由Java对象构成的流程模型。

3. 总结：

建模阶段: 您（或业务分析师）在BPMN建模器中通过拖拉拽的方式，设计或修改业务流程。完成后，您得到一个 .bpmn (本质是XML) 文件。

部署阶段: 您将这个 .bpmn 文件部署到流程引擎。对于嵌入式集成，通常就是把它放在Java项目的资源文件夹里，应用启动时引擎会自动加载并解析XML。

执行阶段: 您的Java代码（比如一个Controller）调用 runtimeService.startProcessInstanceByKey(…)。引擎接收到指令，根据它已经解析好的流程模型，开始一步步执行流程。

监控阶段：自定义

4. 所以相当于代码永远不变，变的是XML

我们把您的Java代码分成两类来看，这个概念会更清晰：

a) “流程控制”代码 (The Orchestration Code) - 这部分【永远不变】
这部分代码就是您在Express或Spring里写的那些通用的、与具体业务步骤无关的代码。

startProcess(…)
getTasksForAssignee(…)
completeTask(…)
这些代码就像一个CD播放机。它非常通用，它的功能就是“播放光盘”、“查询曲目”、“下一首”。不需要为了换一张CD而改造播放机本身。

b) “具体工作”代码 (The Implementation Code) - 这部分【可能需要补充】
这部分代码是指BPMN流程图中“服务任务(Service Task)”背后需要执行的具体业务逻辑，通常是一个JavaDelegate类。

这就像是CD播放机的特效插件。

如果流程变化只是调整顺序、修改条件、增减人工审批步骤：
比如审批金额从5000改成3000。比如在总监审批后增加一个“副总审批”的人工任务。
在这种情况下，您只需要修改XML（换一张CD），Java代码一行都不用动。

如果流程变化是增加了一个【全新的自动化步骤】：
比如业务部门要求：“在财务审批通过后，系统需要自动调用ERP系统接口来创建凭证。”
这时，需要在BPMN图上增加一个“服务任务”，并告诉它需要调用一个名为 ErpIntegrationDelegate 的Java类。如果代码库里还没有这个 ErpIntegrationDelegate.java 文件，那么就需要新增这个Java类（安装一个新的“特效插件”）。

但是，原有的“流程控制”代码（播放机本身）依然不需要改变。

最终结论
90%的情况下，业务流程的变更都只是逻辑、顺序和条件的调整。对于这些变更，您只需要修改BPMN图（即XML），而您的核心代码库保持稳定、无需改动。

这实现了业务流程的热插拔，将易变的业务规则从相对稳定的程序代码中解耦出来，这正是流程引擎带来的革命性优势。

以单独部署流程引擎服务为例：1.启动流程:
前端: 用户填写申请表单。
Java后端: 接收表单数据，调用 ApprovalService.startProcess(processDefinitionKey, variables)会返回id。
流程引擎: 启动流程实例，创建第一个用户任务（“经理审批”）。
(processDefinitionKey会指向.bpmn文件即流程定义，.bpmn 文件本质上是一个遵循 BPMN 2.0 XML Schema 定义的 XML 文档)2.经理审批 (用户任务):
前端: 经理登录，调用 GET /api/process/tasks/managerId
Java后端: 查询任务，返回给前端（==和流程引擎交互获取流程信息==）。
前端: 展示“经理审批”任务。经理点击“批准”。
前端: 调用 POST /api/process/tasks/{taskId}/complete，传入 approved: true。
Java后端: 调用 ApprovalService.completeTask()。
流程引擎: 收到完成指令，根据BPMN图和approved变量，流程流转到“总监审批”用户任务。3.总监审批 (用户任务):
重复经理审批的步骤，只是assignee变成了总监。4.财务审批 (用户任务):
重复总监审批的步骤，只是assignee变成了财务。5.发送通知邮件 (服务任务):
如果BPMN图中有这个服务任务，当流程流转到它时，流程引擎会自动调用您在Java后端实现的 SendEmailDelegate 的 execute 方法。
SendEmailDelegate 执行邮件发送逻辑。
流程引擎继续推进流程，直到结束。

流程定义（BPMN XML）和流程实例状态（运行时数据）之间的根本区别: 建筑蓝图 vs. 正在建造的房子BPMN XML文件（.bpmn）：
流程定义。它是静态的，可移植的，任何符合BPMN 2.0标准的引擎都能解析。
这就像一张建筑蓝图。它详细定义了房子的结构、房间布局、水管电线的走向、门窗的位置、以及各种施工规范。
它是一个静态的、通用的设计图纸。
它不包含任何关于“正在建造的房子”的信息：比如房子盖到第几层了，哪个工人正在哪个房间里施工，墙刷了什么颜色，里面住了谁。流程引擎的数据库（运行时数据）(流程引擎支持N种数据库，==会自动在连接的数据库里面建表，自动管理Schema==)：
是流程执行器和状态管理者。每个引擎实例都有自己的数据库来存储运行时（Runtime）的流程实例状态。
这就像正在建造的房子本身。它记录了：
这栋房子（某个流程实例）的唯一ID。
房子目前盖到了哪一步（流程执行到哪个节点）。
房子里有哪些家具（流程变量，比如申请金额、审批意见）。
哪个工人（用户）正在哪个房间（任务）里工作。
房子的历史（之前盖了哪些部分，谁盖的）。
这些信息是动态的、特定于某个实例的。每个流程引擎都有自己内部管理运行时数据的数据库表结构和状态管理逻辑。这些表结构虽然概念上相似（都有任务表、流程实例表），但具体字段、索引、内部ID生成方式等可能存在差异。