线上默认用精确模式。搜索索引用搜索模式把长词再切细。产品名、机构名用自定义词固定住。抽关键词、过滤名词、做高亮，都在分词结果上继续处理。

下面两句贯穿全文。第一句看精确模式、词性和关键词。第二句里有长词和新词，三种模式的差别才看得出来。

text = "春天的早晨，我沿着河边慢慢走，看见柳枝轻摆，几只小鸟飞过水面，心情忽然变得很好。阳光照在草地，孩子笑着奔跑，真开心。"
biz = "他在中国科学院计算所研究机器学习算法，并负责华为鸿蒙系统在南京市长江大桥项目中的落地。如果放到post中将出错。"

1. 启动时预热词典

第一次分词会加载词典，并打出 DEBUG 日志。进程启动时先初始化，把这段耗时挪到启动阶段。

import logging

import jieba

jieba.setLogLevel(logging.INFO)
jieba.initialize()

Windows 上不要调用 jieba.enable_parallel。并行模式只支持 POSIX 系统，调用会直接抛 NotImplementedError。

2. 三种切分

jieba.lcut 返回列表，后面过滤、统计都方便。jieba.cut 返回生成器，逐词处理大文本时再用。

jieba.lcut(text)                        # 精确模式，默认
jieba.lcut(text, HMM=False)             # 只走词典
jieba.lcut(text, cut_all=True)          # 全模式
jieba.lcut_for_search(biz)              # 搜索模式

精确模式是生产主路径：

春天 / 的 / 早晨 / ， / 我 / 沿着 / 河边 / 慢慢 / 走 / ， / 看见 / 柳枝 / 轻摆 / ， / 几只 / 小鸟 / 飞过 / 水面 / ， / 心情 / 忽然 / 变得 / 很 / 好 / 。 / 阳光 / 照 / 在 / 草地 / ， / 孩子 / 笑 / 着 / 奔跑 / ， / 真 / 开心 / 。

HMM=False 关闭新词识别，结果更稳，但词典里没有的搭配会被拆开。「轻摆」在默认模式下是一个词，关掉 HMM 后变成「轻 / 摆」。

全模式会召回句子里所有可能的词，结果有冗余，例如「慢慢」旁边多出「慢走」，「飞过水面」旁边多出「过水」「过水面」。一般不直接拿来做索引。

业务句的精确模式：

他 / 在 / 中国科学院 / 计算所 / 研究 / 机器 / 学习 / 算法 / ， / 并 / 负责 / 华为 / 鸿蒙 / 系统 / 在 / 南京市 / 长江大桥 / 项目 / 中 / 的 / 落地 / 。 / 如果 / 放到 / post / 中将 / 出错 / 。

搜索模式在精确结果上，把长词再切成更短的词，方便倒排索引命中「科学」「大桥」这种短查询：

他 / 在 / 中国 / 科学 / 学院 / 科学院 / 中国科学院 / 计算 / 计算所 / 研究 / 机器 / 学习 / 算法 / ， / 并 / 负责 / 华为 / 鸿蒙 / 系统 / 在 / 南京 / 京市 / 南京市 / 长江 / 大桥 / 长江大桥 / 项目 / 中 / 的 / 落地 / 。 / 如果 / 放到 / post / 中将 / 出错 / 。

原文那句几乎没有长词，所以精确模式和搜索模式结果一样。有「中国科学院」「长江大桥」这种长词时，差别才出现。

3. 自定义词

词典里没有的产品名、机构名会被切开。「机器学习」变成「机器 / 学习」，「鸿蒙系统」变成「鸿蒙 / 系统」。

add_word 把它们固定成整词。词频给高一些，避免被旁边的字抢走。tag 是词性，后面过滤名词时用得上。

jieba.add_word("机器学习", freq=1000, tag="n")
jieba.add_word("鸿蒙系统", freq=1000, tag="nz")

加词后，这两个词保持整词，句子里其余切分不变。

词条多的时候写成词典文件，每行是「词语 词频 词性」：

机器学习 1000 n
鸿蒙系统 1000 nz

然后加载：

jieba.load_userdict("userdict.txt")

效果和多次调用 add_word 相同。

还有一种粘错。「中将」在词典里是军衔，会把「post 中将出错」切成「中将」。想强制拆开时，调高「中」「将」单独成词的概率：

jieba.suggest_freq(("中", "将"), tune=True)
jieba.lcut("如果放到post中将出错。")
# 如果 / 放到 / post / 中 / 将 / 出错 / 。

tune=True 会改全局词典，只对确实要拆开或合并的词使用。

4. 词性标注

jieba.posseg.lcut 返回带词性的对象，用 .word 和 .flag 读取。只要名词时，看 flag 是否以 n 开头。

import jieba.posseg as pseg

pairs = list(pseg.lcut(text))
nouns = [item.word for item in pairs if item.flag.startswith("n")]

常见标记：

| 标记 | 含义 | |

1. 核心心法：递归信任（“套娃”思维）

不要试图在脑子里一层层追踪递归过程（n→n-1→n-2...）。 你只需要相信：只要“小一号的子问题”能解决，当前问题就一定能解决。

2. 写递归函数的三步法

1. 步骤1：定义函数（明确输入输出）
2. 步骤2：找出口（Base Case）- 必须写在最前面，处理最小规模问题
3. 步骤3：找公式（Recursive Rule）- 拆解为“一小步”+“剩余子问题”

3. 典型代码模板

# 线性递归（阶乘）
def factorial(n):
    if n == 1:        # 出口条件：当n=1时，递归结束
        return 1
    return n * factorial(n - 1)  # 公式

# 线性递归（列表求和-健壮版）
def sum_list(lst):
    if not lst:       # 出口条件：当列表为空时，递归结束
        return 0
    return lst[0] + sum_list(lst[1:])

# 两端收缩递归（回文判断）
def is_palindrome(s):
    if len(s) <= 1:   # 出口条件：当字符串长度为0或1时，满足回文，递归结束
        return True
    return s[0] == s[-1] and is_palindrome(s[1:-1])

4. 必须避开的致命陷阱

• 忘记写出口 -> RecursionError（栈溢出）
• 出口逻辑错误（如0!返回0） -> 全盘算错
• 忽略边界（如传入空列表/空字符串） -> IndexError

5. 底层机制：调用栈（Call Stack）

递推：任务暂停压栈 -> 触底 -> 回归：弹栈逐层返回计算结果。

6. 已掌握的两种递归模式

• 线性递归：每次解决一个元素（求和、阶乘）
• 分治（双向）递归：同时从两端向内推进（回文判断）

基础：单向链表入门

把链表想成一列火车 —— 看懂写法与逻辑，修好你自己的代码

一、先建立画面：链表就是一列火车 🚂

你已经写过 temp-shejilianbiao.py，说明基础语法没问题。现在我们要把「链表」这个数据结构在脑子里画出来——画对了，代码就顺了。

想象一列火车：

• 每一节车厢装着一件货物（比如数字 5）；
• 每节车厢后面有一个挂钩，钩着下一节车厢；
• 列车长手里只拿着车头，想找第 3 节车厢，必须从车头一节一节往后走；
• 最后一节车厢的挂钩空着，什么也没钩——那就是 None。

车头      车厢1      车厢2      车厢3
 │         │         │         │
 ▼         ▼         ▼         ▼
[5|●] --> [9|●] --> [2|●] --> [7|∅]
 │         │         │         │
 value     value     value     value=None
 next      next      next      (没有下一节)

在代码里，「车厢」叫 节点 Node，两个属性：

class Node:
    def __init__(self, value):
        self.value = value   # 货物：这个节点存的数据
        self.next = None     # 挂钩：指向下一节车厢（默认空着）

而 head 就是「车头」——链表本身不存任何数据，它只记住第一节课厢是谁：

class MyLinkedList:
    def __init__(self):
        self.head = None     # 空链表：一辆车都没有

二、三个核心动作：所有链表操作都是它们的组合

链表的所有增删查，最后都归结为三件事：走、接、跳。

动作 1：走（遍历）—— 从车头走到尾

cur = head
while cur:            # 只要还有车厢
    print(cur.value)
    cur = cur.next    # 走到下一节

循环结束的条件是 cur 变成 None——也就是走过了最后一节车厢。这就是「遍历」。

动作 2：接（插入）—— 口诀：先接后断！

想在节点 prev 后面挂一节新车厢 new，有两步：

new.next = prev.next   # ① 先接：新钩子先钩住 prev 后面的车厢
prev.next = new        # ② 再断：把 prev 的钩子改挂到 new

顺序为什么不能反？ 如果先写 prev.next = new，prev 后面的整列火车就没人指向了——丢了。就像先解开挂钩再挂新的，后面的车厢全散架了。所以必须「新节点先接住后面，前面的钩子再断开来挂新节点」。

动作 3：跳（删除）—— 让前一个直接跳过它

prev.next = prev.next.next   # prev 的钩子直接指向「下一个的下一个」

删除前：  [..|●] --> [删|●] --> [..|●]
删除后：  [..|●]

樱花二次元图片API-Dmoe

• api: https://www.dmoe.cc/random.php

随机二次元图片API文档（by夜轻）

• blog: https://blog.yeqing.net/acg-api/
• api：https://api.yppp.net/pc.php

提示

游戏库，仿steam库，以卡片形式展示我游玩过的游戏

恶魔商人让XX变得更强

Boss基本数据

Boss弱点

根据守夜Boss推断黑夜王

大空洞水晶位置

个人流派整理

追踪者

轻击重置流

（遗物图）

执行者

冰血刃

(遗物图)

复仇者

力量蜗

（遗物图）

法蜗

（遗物图）

隐士

纯净法师

搓招法师

祷法

守护者

防反鸟

祷鸟

送葬者

力修

祷修

双小曲跳劈

无赖

改特大剑

改大锤

蓝泪无赖

法赖

女爵

法爵

短剑折叠爵

迅剑折叠

战技爵

学者

神秘观察男

吃吃喝喝流

冰血刃

刺剑盾戳

壶人

变量对照表

API Key

| 模型/套餐 | 环境变量 | |

1. 概述与学习目标

本课程聚焦 Agent 进阶与集成，涵盖从低代码到高代码的完整 Agent 开发链路：

• 批处理：对同类型多任务进行批量并行处理
• Coze 应用：构建带 UI 表单的应用级 Agent
• 数据表使用：结构化数据的动态查询与写入
• 多 Agents 模式：分诊台 + 专业子 Agent 的协作架构
• 多工作流复杂应用：嵌套工作流、跨工作流数据传递
• Agent 集成：通过 API 将 Agent 嵌入现有业务系统

2. Agent 核心架构

2.1 Agent 组成公式

Agent = System Prompt + RAG（知识库） + 数据表 + 工具（插件/工作流）

2.2 Agent 运行时流程

1. AI 编程概述

1.1 什么是 AI 编程

AI 编程是指利用大语言模型（LLM）辅助软件开发的编程范式。通过 AI 代码编辑器（如 Cursor、Trae、Claude Code 等），开发者可以用自然语言描述需求，AI 自动生成、修改、解释代码，实现从"手写代码"到"指挥 AI 写代码"的转变。

1.2 AI 编程的核心能力

• 代码生成与补全：根据上下文自动补全代码，生成完整功能模块
• 跨文件编辑：同时理解和修改多个文件，保持项目一致性
• 智能 Debug：分析报错信息，定位根因并提供修复方案
• 代码解释与审查：解释复杂代码逻辑，进行代码质量审查
• 自主任务执行：Agent 模式可独立执行多步骤任务，自动运行命令并迭代修复

1.3 AI 编程能做什么

| 场景 | 说明 | |

1. 课程全景

两条开发路径

1. 概述

1.1 什么是 Text-to-SQL

Text-to-SQL 是指将用户的自然语言问题自动转化为SQL查询语句，并执行查询返回结果的技术。它是数据民主化（Data Democratization）的关键基础设施——让业务人员无需掌握 SQL 语法，即可用自然语言从数据库中获取信息。

1.2 核心价值

1.3 三种主流实现路径

| 方案 | 核心思路 | 适用场景 | 代表项目 | |

1. 项目概述

ChatBI 是一个基于 qwen-agent 框架构建的智能股票分析助手，实现了从数据获取、SQL 查询、自动可视化到高级技术分析（ARIMA 预测、MACD 信号、布林带检测、Prophet 周期性分析）的完整垂直领域 Agent。

核心定位

理解业务需求 → 打造 Skill → POC 快速验证 → 架构迁移迭代

关键技术栈

| 层级 | 技术选型 | |

1. Agent 平台：Coze、Dify 与 Agent 进阶集成

1.1 什么是 LLM Agent？

定义：LLM Agent = LLM + 工具 + 记忆 + 规划循环。

| 维度 | 单轮 LLM 调用 | LLM Agent | |

1. 课程概述

本课围绕 Embedding（向量化） 与 向量数据库 两大主题，核心学习目标：

| 模块 | 内容 | |

1. 大模型应用开发的三种模式

在AI大模型应用开发中，有三种主要的技术路线：提示工程、RAG 和 微调。

| 模式 | 适用场景 | 核心思想 | |

RAG 多模态数据处理实战指南

传统 RAG 系统大多围绕纯文本构建：把文档切成片段、编码成向量、检索后拼进 Prompt。但真实业务里的知识往往是混合形态的——官方规定是 PDF，内部 FAQ 是 Word，活动介绍里有大量海报图片和表格，培训资料是视频。如果只处理文字，这些信息在入库的那一刻就被丢掉了，检索自然也就回答不了"最近万圣节的活动海报长什么样"或者"我的车被剐蹭了，你能看到视频吗"这类问题。

多模态 RAG 要解决的核心问题，是让文本、图片、视频在同一个向量空间里可比较。当一张万圣节海报和一句"万圣节活动海报"被编码得足够接近时，"以文搜图"就不再是额外的工程，而是同一次相似度计算的自然结果。

本文围绕两条主线展开：前半部分是 Gemini 的多模态理解能力与通义多模态 Embedding 的使用，后半部分是一个完整的迪士尼 RAG 助手实战，最后补齐切片策略与 NotebookLM 两个主题。文中代码与运行结果均取自课程课件与配套 Notebook，按原样整理。

多模态 RAG 的整体结构

一个多模态 RAG 系统可以拆成数据层、向量化层、索引存储层、检索层和生成层五段。关键点在于向量化层：文本、图片、视频走的是同一个 Embedding 模型，产出维度一致的向量，因此后续只需要维护一份索引。

这套结构带来的直接好处是：索引只有一份，新增一种模态不需要额外的检索通道；代价是对 Embedding 模型的要求更高，它必须在同一个语义空间里同时"读懂"一句话和一张图。

Gemini 的多模态处理

多模态能力概览

Gemini 的多模态是"原生统一架构"：从预训练开始就把文本、图像、音频、视频、PDF、代码放在同一表征空间里学习，而不是先训一个大语言模型再外挂视觉或语音模块。因此信息损耗更小，时序和细节保留更完整。

它有几个比较关键的能力特征：

• 端到端推理：同一组 Transformer 参数直接处理任意组合的输入。给它一张 CT 影像加一段病历文本，可以同步给出诊断建议；给它一段手写食谱视频，可以直接转成可分享的数字菜谱。
• 上下文规模：Gemini 3 Pro 支持 100 万 token 的长窗口，可一次性读入 1 小时视频或 700 页 PDF，再输出 6.4 万 token 的结构化报告。
• 生成能力：不仅能"看"和"听"，还能"画"和"说"，包括文本生成图像、图像编辑、褪色修复、3D 模型输出，以及流式生成音频实现边看边解说。

课件里还提到了用于方案配图的 Nano Banana（正式名称对应 Gemini 3.0 Pro Image）。它在写实感、文字渲染、角色一致性和世界知识几个维度上表现突出，其中"能在图片里把字写对"和"同一角色跨场景保持一致"是过去图像模型比较薄弱的地方。日常汇报中常见的四种配图风格可以总结为：

| 风格 | 提示要点 | 适用场景 | |

朴素 RAG 的流程可以用三个动作概括：Indexing、Retrieval、Generation。真正把 RAG 应用从 Demo 推到落地，难点几乎全部集中在"如何把知识存得更好"和"如何把有用的那一小撮知识找出来"这两件事上。本文将课件脉络与工作区中的四组可运行代码结合起来，梳理一条完整的调优路径。

工作区中的代码按主题分为三个目录：

| 目录 | 主题 | 关键文件 | |

1. 项目背景与比赛任务

1.1 企业RAG挑战赛

比赛仓库：https://github.com/trustbit/enterprise-rag-challenge

比赛任务是基于公司年度报告构建一个问答系统，比赛当天的流程如下：

• 收到随机挑选公司的 100 份年度报告，需在 2.5 小时内解析这些报告并构建数据库；报告为 PDF 格式，每份最长可达 1000 页
• 系统随后生成 100 个随机问题（基于预设模板），RAG 系统必须尽快作答
• 所有问题都有确定的答案，例如：是/否、公司名称（某些情况下是多个公司名）、领导职位头衔、推出的产品名称、数值指标（营收、商店数量等）
• 每个答案都必须注明引用的页码，确保系统从原文得出答案，而不是输出虚假信息（hallucinate）

1.2 冠军方案 RAG-Challenge-2

参考项目：https://github.com/IlyaRice/RAG-Challenge-2

RAG-Challenge 系统在比赛中赢得了所有类别的奖项，在处理公司年度报告问答上表现突出。这是竞赛代码，功能完善但存在一些临时方案，比如 IBM Watson 集成部分是竞赛特定的，脱离比赛环境无法正常工作。

系统特点：

• 定制 PDF 解析：使用 Docling 解析 PDF 文档
• 向量搜索与父文档检索：通过向量搜索实现文档检索
• LLM 重排序：利用 LLM 对检索结果重新排序，提高上下文相关性
• 结构化输出提示：采用链式推理（chain-of-thought reasoning）进行结构化输出
• 查询路由：支持多公司比较的查询路由功能

获胜方案在 native RAG 的基础上，加入了两个路由器（router）和 LLM 重排序模块（LLM reranking），在 retrieval、generation 以及总分上都取得了不错的成绩，采用 o3-mini 进行推理。

1.3 工作区中的两个项目

| 维度 | RAG-Challenge-2-main（原版） | RAG-cy（改造版） | |

第 0 章 导读与工程速览

0.1 问题的起点

RAG（Retrieval-Augmented Generation，检索增强生成）在过去两年几乎成了"让大模型接入私有知识"的默认答案。但工程实践中，它反复暴露出三类问题：

1. 切碎了就拼不回来——文档被切成固定大小的 Chunk，主题边界被破坏，跨页引用、表格、代码逻辑全部断裂。
2. 检索是"系统行为"，不是"模型行为"——搜索策略、召回数量在系统上线前就写死了，LLM 只能被动接收 Top-k，不参与任何检索决策。
3. 知识是静态的——新增文档只是"多了一份搜索素材"，知识之间的关联、摘要、实体关系不会随之更新。

而"超长上下文""Agentic Retrieval""LLM Wiki"这三条路线，恰好分别瞄准了这三点。

0.2 配套工程速览：Agentic Search

本文的工程样本是工作区中的 Agentic Search——一个基于 Qwen 模型推理决策的多源企业搜索系统。它的技术栈与规模如下：

| 层次 | 文件 | 规模 | 职责 | |

RAG 是大模型应用开发岗位面试的必考项。面试官的问题看上去零散，其实都挂在同一条主线上：怎么把知识存进去（Indexing）→ 怎么把真正有用的那一小部分找出来（Retrieval）→ 怎么让模型结合提问和检索结果生成答案（Generation）。

这三个步骤看似简单，但从构建到落地，中间塞满了分块、Embedding、改写、重排、评估、维护这些细活。本文按这条主线把高频面试题、对应的技术方案和可落地的代码整理在一起，面试前逐条过一遍即可。

Coding Agent 已经可以根据一句话需求完成开发了，为什么我们还要学习方法？

在一些常见的小型项目中，一句话需求已经能够生成一个可以运行的初版。但这句话里通常还留着很多没有说清楚的内容：给谁用、在什么情况下用、需要哪些功能、做到什么程度才算符合预期。Agent 生成代码时会根据自己的理解补上这些，而这些补出来的内容是否符合实际需要，需要我们判断。

本文围绕四个问题展开：要做什么、怎样才算做对、用什么验证、根据什么继续修改。 前半部分讲 Spec 与 SpecDD，后半部分讲 Test Case 与 TDD，最后看两者怎样围绕同一条行为要求配合，并把这套方法整理成 Agent 可以读取的工作指引。

贯穿全文的案例是一个直播聊天分析应用：在本机监听一个直播间，在自己的界面显示采集到的评论；积累一段时间后，选择分析范围，向自己的 Agent 提问，例如"这段时间大家最关心的问题是什么"，在同一界面得到基于这批评论的回答。

2. 一句话能生成软件，为什么还要学习使用方法

在一句话需求的背后，通常还留着没有说清楚的部分。Agent 在生成代码时，会根据自己的理解补上这些内容。我们需要判断，它补出来的内容是否符合实际需要。

2.1 从一句话需求到具体的业务场景

比如"帮我做一个直播间聊天分析工具"。Agent 可以做一张词频图，也可以做自动回复机器人，或者做一个能针对评论提问的分析页面。这些方案解决的问题并不相同。

我们希望监听一个直播间，在自己的界面显示采集到的评论。积累一段时间后，选择分析范围，向自己的 Agent 提问，例如"这段时间大家最关心的问题是什么"，让它根据这批评论给出回答。

| 需要明确的内容 | 直播聊天分析应用 | |

第一章：PyTorch 核心基础

1.1 什么是 PyTorch？

PyTorch = NumPy + GPU，它完美解决了 NumPy 只能使用 CPU 计算、大数据场景下速度过慢的痛点。

PyTorch 的核心数据结构是张量（Tensor），它的用法和 NumPy 几乎完全一致，唯一的区别是张量可以被轻松迁移到 GPU 上运行，计算速度能提升几十倍。

1.2 张量（Tensor）入门

张量是 PyTorch 中最基础的数据结构，我们可以像操作 NumPy 数组一样操作它：

import torch
import numpy as np

# 1. 创建自定义张量
x = torch.Tensor([[1, 2, 3], [4, 5, 6], [7, 8, 9]])
print(x)

# 2. 创建全零张量
x=torch.zeros(3)
print(x)

# 3. 从NumPy数组无缝转换为张量
a = np.ones(3)
x = torch.from_numpy(a)
print(x)

1.3 张量的基本运算

PyTorch 提供了丰富的张量运算，所有运算都支持 GPU 加速：

import torch
x = torch.Tensor([[1, 2, 3], [4, 5, 6], [7, 8, 9]])

# 求幂运算
print(x.pow(-1.0))  # 倒数
print(x.pow(2.0))   # 平方

# 按列求和（dim=0 代表列维度）
print(x.sum(dim = 0))

# 按行求和（dim=1 代表行维度）
print(x.sum(dim = 1))

# 对角矩阵转换
temp = x.sum(dim = 1).pow(-1.0)
print(temp.diag_embed())

1.4 自动求导机制

神经网络训练的核心是反向传播，手动推导导数公式非常复杂，而 PyTorch 的 ** 自动求导（Autograd）** 帮我们解决了这个问题：

你只需要编写前向传播的计算逻辑，PyTorch 会自动记录所有操作，调用.backward()就能自动算出所有参数的梯度。

# 定义需要计算梯度的张量
x = torch.tensor(2.0, requires_grad=True) 

# 前向计算：y = x²
y = x**2 

# 反向传播，自动计算梯度
y.backward() 

# 梯度 dy/dx = 2x = 4
print(x.grad)

1.5 动态图与静态图

与 TensorFlow 1.x 的静态图不同，PyTorch 使用动态计算图：

• 静态图：先写好完整的网络结构，编译后才能运行，调试困难

• 动态图：每次前向传播都会实时构建计算图，所见即所得，可以随时打印变量、逐行调试，就像写普通 Python 脚本一样方便

这也是为什么 PyTorch 成为了学术界和研究人员的首选框架。

1.6 分布式训练进阶

PyTorch 支持多种分布式训练方案，帮助你快速利用多 GPU 加速训练：

1. DataParallel：最简单的单机多 GPU 方案，一行代码包装模型即可

2. DistributedDataParallel：更高效的多机多 GPU 方案，负载更均衡

3. PyTorch Lightning：封装了所有分布式细节，只需指定 GPU 数量即可自动启用

# PyTorch Lightning 简化多GPU训练
trainer = Trainer(accelerator="gpu", devices=4, strategy="ddp") 
trainer.fit(model)

1.7 PyTorch 训练完整流程

1.8 实战：你的第一个 PyTorch 神经网络

我们用波士顿房价预测来演示一个完整的训练流程：

import torch
import torch.nn as nn
import torch.optim as optim
import pandas as pd
from sklearn.model_selection import train_test_split

# 1. 加载数据集
data = pd.read_csv('housing.csv', header=None, sep='\s+')
X = data.iloc[:, :13].values # 13个房屋特征
y = data.iloc[:, 13].values  # 房价标签

# 2. 划分数据集并转换为张量
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2)
X_train = torch.from_numpy(X_train).float()
y_train = torch.from_numpy(y_train).float().unsqueeze(1)
X_test = torch.from_numpy(X_test).float()
y_test = torch.from_numpy(y_test).float().unsqueeze(1)

# 3. 定义3层全连接神经网络
class Net(nn.Module):
    def __init__(self):
        super(Net, self).__init__()
        self.fc1 = nn.Linear(13, 64)  # 输入层->隐藏层
        self.fc2 = nn.Linear(64, 32)  # 隐藏层->隐藏层
        self.fc3 = nn.Linear(32, 1)   # 隐藏层->输出层
        
    def forward(self, x):
        x = torch.relu(self.fc1(x))
        x = torch.relu(self.fc2(x))
        x = self.fc3(x)
        return x

model = Net()

# 4. 定义损失函数和优化器
criterion = nn.MSELoss()
optimizer = optim.Adam(model.parameters(), lr=0.001)

# 5. 训练循环
epochs = 1000
for epoch in range(epochs):
    # 前向传播
    y_pred = model(X_train)
    loss = criterion(y_pred, y_train)
    
    # 反向传播和优化
    optimizer.zero_grad()  # 清空梯度
    loss.backward()        # 计算梯度
    optimizer.step()       # 更新权重
    
    if epoch % 100 == 0:
        print(f'Epoch {epoch}, Loss: {loss.item():.4f}')

1. 大模型微调概述

1.1 什么是模型微调

微调（Fine-tuning） 是将预训练好的大模型进行二次训练，使其适应特定任务或领域的过程。

1.2 为什么需要微调

| 问题类型 | 具体表现 | 解决方案 | |

1. 前置知识：什么是 SFT 微调？

1.1 通俗理解

想象你已经有一个"博学的大学生"（基座模型，如 Qwen3.5-0.8B），他什么都知道一点，但对医疗领域不够专业。你希望他变成一名"实习医生"，能够用专业的中文回答患者的医疗问题。

SFT（Supervised Fine-Tuning，监督微调） 就是拿一堆"标准问答对"（患者问题 → 专业回答）去训练这个模型，让它学会特定的领域知识和回答风格。

1.2 核心概念速查表

| 概念 | 通俗解释 | 本文中的实例 | |

一、前置知识扫盲

1.1 什么是大语言模型（LLM）

类比理解：一个读过海量书籍的"超级学霸"

想象你有一个朋友，他从小就把整个互联网上的文章、书籍、对话全部读了一遍。当你问他任何问题时，他能根据自己读过的内容，预测出最合理的回答。大语言模型（Large Language Model，简称LLM）就是这样一种AI程序——它通过"阅读"海量文本数据，学会了理解人类语言并生成回复。

🏭 工业界的叫法：你可能会听到"GPT"、"Qwen"、"DeepSeek"、"LLaMA"这些名字，它们都是不同公司或团队训练出来的大语言模型，就像不同学校培养出来的学霸，各有特长。

核心概念：

| 术语 | 通俗解释 | |

1. 概述

1.1 用日常比喻理解"视觉大模型"

想象一下，你有一个既能看到图像、又能读懂文字、还能开口说话的超级助手：

• 你给它看一张车祸现场的照片，它能告诉你"这辆白色轿车的右前门被撞凹了，保险杠开裂"；
• 你让它看一段行车记录仪视频，它能总结"视频中有两个人，一辆白车剐蹭到了墙角"；
• 你丢给它一份扫描的日文病历 PDF，它能提取出其中的关键信息并翻译成中文。

这就是视觉大模型（Visual Large Model，简称 VLM）在做的事情：让计算机同时"看懂"图像和"读懂"文字，并用自然语言回答你的问题。

📌 通俗版定义：
VLM = 图像识别器 + 文本理解器 + 语言生成器，三者合为一体。

📌 专业版定义：
视觉大模型是一种基于 Transformer 架构的多模态神经网络，它通过将图像和文本映射到统一的语义空间（embedding），实现跨模态的对齐与推理，从而支持图像描述、视觉问答、文档理解等任务。

1.2 "多模态理解"解决了什么问题？

在传统 AI 系统中，图像识别和文本理解是分开的两条线：

传统方式：
  图像 → CNN/YOLO → "这是一辆车"（标签）
  文本 → RNN/BERT → "车被撞了"（分类）

VLM方式：
  图像 + 文本 → 一个统一模型 → 这辆白色特斯拉Model 3的右前门严重凹陷，预估维修费用约8000元

多模态理解的核心价值在于：

| 痛点 | VLM 的解决方案 | |

1. Coze 平台概述

1.1 什么是 Coze？

Coze（扣子）是字节跳动推出的 AI Agent（智能体）开发平台，定位为低代码 / 零代码的 AI 应用构建工具。它将大语言模型（LLM）比作"发动机"，而 Coze 则是"汽车工厂"——开发者不需要制造发动机，只需拼装工作流，就能让一个 AI 应用运转起来。

1.2 Coze 的发展演进

| 阶段 | 内容 | |

1. Dify 平台概述

1.1 什么是 Dify？

Dify 是一个开源的大语言模型（LLM）应用开发平台，融合了 Agent、AI Workflow、RAG（检索增强生成） 等核心能力，帮助开发者快速构建和部署 AI 原生应用。它可视化了 LangChain 的核心理念，降低了 AI 应用开发的门槛。

1.2 Dify vs 其他平台

| 维度 | Dify | Coze | LangChain | |

第一部分：LangChain基础概念

1.1 LangChain是什么

LangChain是一个强大的开源框架，专门用于简化大语言模型（LLM）应用程序的开发过程。它提供了一套完整的工具、组件和接口，使开发者能够更加高效地构建基于LLM的应用程序。LangChain的核心价值在于将复杂的LLM应用开发过程模块化、组件化，让开发者可以专注于业务逻辑而非底层实现细节。

LangChain的设计理念是“组合优于继承”，通过将各种功能组件（如提示词模板、模型接口、工具集、记忆系统等）解耦为独立模块，开发者可以根据实际需求灵活组合这些组件，构建出功能强大的LLM应用。这种设计思想大大降低了LLM应用的开发门槛，同时也为复杂应用场景提供了足够的扩展性。

LangChain最初于2022年底发布，经过快速发展，于2024年发布了1.0版本，标志着该框架进入了成熟稳定的阶段。1.0版本在架构上进行了重大重构，引入了LCEL（LangChain Expression Language）表达式语言，使得组件的组合和调用更加直观和灵活。

1.2 LangChain核心组件架构

LangChain框架由六大核心组件构成，每个组件都承担着特定的功能职责，共同支撑起整个框架的能力体系。理解这些组件的作用和相互关系，是掌握LangChain的基础。

模型层（Models） 是LangChain与各种大语言模型交互的接口层。该层封装了对GPT-4、Claude、通义千问等主流模型的调用，提供了统一的接口规范。LangChain支持两种模型类型：LLM用于文本补全任务，ChatModel用于对话任务。ChatModel相比LLM具有更好的对话支持，并且支持tool calling功能，能够让模型调用外部工具。

提示词层（Prompts） 负责管理和优化提示词。该组件包括提示词模板（PromptTemplate）、提示词优化器以及提示词序列化功能。通过使用提示词模板，开发者可以将用户输入动态插入到预设的提示词框架中，实现提示词的复用和标准化管理。

记忆层（Memory） 为LLM应用提供了持久化上下文的能力。在默认情况下，LLM是无状态的，每次交互都是独立的。Memory组件允许应用保存和检索对话历史，使LLM能够记住之前的交互内容，从而实现真正的多轮对话体验。

索引层（Indexes） 提供了结构化文档处理的能力，是构建知识库应用的核心组件。该层包含文档加载器、文档转换器、文本分割器、向量计算器、向量存储和检索器等功能模块。如果需要构建基于私有知识的问答系统，索引层是必不可少的基础设施。

链层（Chains） 是将多个组件串联起来执行的核心机制。通过Chain，开发者可以定义一系列有序的组件调用，将用户的输入经过多个处理步骤后得到最终输出。Chain是LangChain最核心的执行单元。

代理层（Agents） 赋予LLM自主决策的能力。与Chain的固定执行流程不同，Agent能够根据用户的问题自主决定调用哪些工具、如何组织执行顺序，直到得到满意的答案。Agent是构建智能助手和自动化代理系统的关键技术。

1.3 LangChain 1.0版本重大变化

LangChain从0.3X升级到1.0版本，发生了架构性的重大变化。虽然核心概念保持一致，但包结构和使用方式有了显著改进，开发者需要特别注意这些变化。

包结构完全重构 是1.0版本最明显的变化。原有的单一langchain包被拆分为多个独立的子包：langchain-core只包含抽象基类和LCEL表达式语言，所有第三方集成不再直接依赖完整langchain包；langchain-community包含社区维护的几十种loader、retriever和tool实现；合作伙伴包如langchain-openai、langchain-anthropic等独立成库，体积更小、升级更加灵活。这种模块化设计使得依赖管理更加清晰，也减少了不必要的依赖传递。

新增官方子项目 进一步完善了LangChain生态系统。LangGraph是用于“图”编排多步、多角色、有状态工作流的新组件，替代了传统多重Chain嵌套的写法，特别适合复杂业务流程的建模；LangServe可以将链或代理一键封装为REST API，自带/invoke、/stream、/batch端点和Swagger页面，大大简化了LLM应用的部署；LangSmith是可视化调试、回归测试和在线监控平台，与1.0版本的回调系统深度集成，提供了专业的LLM应用开发和运维能力。

API风格全面转向LCEL 是1.0版本的核心改进。新的API鼓励使用|管道运算符将组件拼装成Runnable对象，而不是继承Chain基类。这种链式表达式的写法更加直观和Pythonic，例如prompt | llm | output_parser这样的代码清晰表达了数据流的整个过程。LCEL还支持并行执行、条件分支、流式输出等高级特性，使得复杂业务流程的实现变得简单。

AI Agent 框架入门指南

学习目标: 让刚入行的程序员能够理解 AI Agent 的核心概念,并能够使用主流框架搭建简单的智能应用。

HuggingFace生态实战：从模型应用到高效微调

1. HuggingFace简介

1.1 什么是HuggingFace

HuggingFace 是一个专注于人工智能的开源社区和平台，被誉为"AI界的GitHub"和"AI界的App Store"。如果说PyTorch是造车的发动机，那HuggingFace就是直接送了程序员一辆跑车。

1.2 HuggingFace的三大核心

| 核心组件 | 名称 | 作用 | 类比 | |

第一章：神经网络基础概念

1.1 从生物神经元到人工神经元

神经网络的概念源于对生物大脑中神经元工作方式的模拟。在生物大脑中，单个神经细胞只有两种状态：兴奋和抑制。网络中的每个节点（神经元）接收输入信号，如果所有信号的加权总和超过一个“阈值”，它就被“激活”（兴奋），并向下传递信息；否则就保持“抑制”。这种简单的开关机制，构成了整个网络决策和学习的根本。

人工神经元是生物神经元的数学抽象，它由输入值、权重、偏置和激活函数组成。对于给定的输入 $x_1, x_2, ..., x_n$，神经元首先计算加权和：

$$z = \sum_{i=1}^{n} w_i \cdot x_i + b$$

什么是 Agent？

AI 模型 vs AI Agent

简单来说：

• AI 模型（LLM）：提供智能，能回答问题、生成内容
• AI Agent：保证结果，能执行任务、调用工具、完成实际工作

📌 核心思想：模型提供智能，Agent 保证结果

为什么需要 Agent？

LLM（大语言模型）存在以下局限性：

1. LLM 会有幻觉：可能生成不准确或虚构的内容
2. LLM 只会说，不会做：只能输出文字，无法执行实际操作
3. LLM 规划的步骤不靠谱：自动生成的执行步骤可能不准确

有些任务需要极高的准确度和可控性，这时就需要 Agent 来弥补 LLM 的不足。

一、核心能力概览：多模态AI能做什么？

多模态AI的核心能力在于打破信息形式的壁垒，让机器像人一样同时“看”图像、“听”声音、“读”文字，并将这些信息融合理解、综合输出。它不再局限于单一类型的数据处理，而是实现了跨模态的认知与创造。

这种能力带来了三大关键突破：

• 视觉转译：将图像内容自动转化为文字描述

  示例：上传一张街景照片，AI能告诉你“这是一条雨后的城市街道，路边有咖啡馆和行人撑伞走过”。

• 融合推理：结合图文信息进行逻辑判断与决策

  示例：看到厨房起火的视频并听到“快报警”的语音指令，AI可自动触发紧急响应流程。

• 视觉编辑：根据语言指令直接修改或生成图像

  示例：对一张风景照说“把天空换成晚霞”，AI即可实时完成画面调整。

这一能力的本质是构建一个统一的理解中枢，能够接收多种输入（文本、图像、音频等），提取各自特征后在深层进行融合分析，最终实现灵活的内容生成与交互。相比传统AI模型只能处理单一任务，多模态系统更像一把“万能瑞士军刀”，具备更强的通用性与适应力。

二、基本原理：视觉与语言如何被AI同时理解？

多模态AI之所以能“看懂”图像、“读懂”文字，并将两者联系起来，关键在于它并非简单地并列处理信息，而是通过一套精密的机制，让视觉与语言在模型内部实现语义对齐和深度融合。这个过程可以分为三个核心步骤：

1. 特征提取：从原始数据中提炼“意义”

就像人眼看到一张图片时不会只记住像素点，而是识别出“猫”“桌子”“窗户”等物体一样，AI也需要先将图像和文字转换为可计算的数学表示。

• 图像特征提取：使用卷积神经网络（CNN）或视觉Transformer等技术，把一张图片分解成一系列数字向量，这些向量代表了图中的物体、颜色、布局等关键信息。
• 文本特征提取：将一句话拆分成词或子词单元，再通过语言模型转化为对应的语义向量，捕捉词语之间的关系和句子的整体含义。

✅ 简单类比：这就像给每张图片和每段文字都生成一个独特的“身份证编码”，后续所有操作都基于这个编码进行。

2. 特征对齐：让不同模态的语言“互通”

图像和文字原本是两种完全不同的“语言”。为了让它们能被统一理解，模型需要在一个共享的空间中建立对应关系。

• 模型会学习将“狗”的文字编码与包含狗的图像编码尽可能靠近
• 同样，“红色汽车”的文本描述也会与相应画面的特征向量对齐

🔍 这一过程通常依赖大量图文配对数据（如带标题的图片）进行训练，使模型学会哪些视觉内容对应哪些语言表达。

3. 融合推理：跨模态信息协同决策

当图像和文本特征完成对齐后，模型就能进行真正的“融合思考”。

| 推理类型 | 输入示例 | AI行为 | |

一、前言：为什么需要学习提示词和RAG？

在当今人工智能快速发展的时代，大语言模型（Large Language Model，简称LLM）已经成为了许多应用的核心技术。从智能客服到知识问答，从内容创作到代码生成，LLM正在改变我们与技术交互的方式。然而，要让LLM真正发挥价值，我们需要掌握两个关键技术：提示词工程和RAG技术。

1.1 课程内容概览

本课程主要涵盖三大核心主题：

| 序号 | 主题 | 核心要点 | |:

第一部分：AI的层次与类型

AI (人工智能)

“会学习的机器”

• 就像给机器一个大脑，让它能学习下棋、识图、翻译。我们的“超级学徒厨师”就属于AI。

AGI (通用人工智能)

“像人一样全能的AI”

• 现在这个学徒只会做菜。但AGI就像一个真正的“人”，他不仅能做菜，还能写诗、做科研、和你谈人生哲学，在不同领域都能达到或超越人类水平。
• 目前还没有实现，是很多科学家的终极目标。

ASI (超级人工智能)

“在一切领域都远超全人类的超级存在”

• 科幻片里的概念。比AGI更强大，它的智慧人类无法理解。就像厨房里突然来了一个能瞬间创造新宇宙法则的“厨神”。

AIGC (AI生成内容)

“用AI来搞创作”

• 让我们的学徒厨师不单做菜，还让他生成新的菜谱、画菜单的插图、给美食视频配音。所有AI生成的文本、图片、视频、音乐都叫AIGC。

Gen AI (生成式AI)

“会创造的AI”

• 这是实现AIGC的核心技术。以前的AI主要做“分类”和“识别”（比如判断这是猫还是狗）。而生成式AI学会了“创造”（比如根据描述画出一只从没见过的猫）。
• 我们的学徒厨师就是一个生成式AI，因为他能“生成”新的菜。

AI Native (AI原生)

“为AI而生，靠AI而活”

• 不是把一个老式厨房（传统软件）改造成智能厨房，而是从零开始设计一个全新的智能厨房，它的每个灶台、每把刀都专为那个AI学徒设计，能最大化发挥他的能力。
• 很多新的AI应用就是AI原生的。

产品举例

• 支小助
• AiPPT
• HeyGen数字人
• 美团-小美AI Agent
• 星野-AI陪聊智能体
• meitu

入行需要的步骤

1. 首先要了解AI的模型和技术应用知识（作用：从基座模型二开）
2. 熟练使用AI开发工具
3. 要构建AI驱动的原型，需要将概念转化为实际应用
4. 保持AI最新技能同步
5. 不断学习和做项目实战

需要掌握什么技术？

AI技术介绍

Agent

从无状态，到特定状态的定义和识别

状态：（报出的回答结构化）

巴黎奥运会的金牌回答，可以按照金银铜牌的数量回答给用户

Prompt

提示词工程，用户输入

Function Call

与外部函数或API交互的能力，通过理解语义来结构化调用信息，询问用户补全信息，然后结构化调用工具，基于返回的结构化信息，整合生成回复

１.　理解语义，自主决策使用天气查询工具

２.　结构化调用，需要结构化信息

３.　询问用户，补全信息

４.　结构化调用天气查询工具

５.　基于返回的结构化天气信息，整合生成回复

面试题：如果Function Call的成功率比较低，需要怎么解决？

答案：考虑从LLM基座模型或者选型上去思考

RAG

通过从外部资源或数据库中纳入相关信息来实现

Fine Tuning

微调（可能不需要，但是复杂场景需要，可以先考虑模型的选型）

第一步：本地创建项目

PS D:\project> pnpm create vuepress-theme-hope ./Vuepress-Version-Blog-Pnpm
✔ Select a language to display / 选择显示语言 简体中文
✔ 选择包管理器 pnpm
✔ 你想要使用哪个打包器？ vite
生成 package.json...
✔ 设置应用名称 hello-vuepress
✔ 设置应用描述 no
✔ 设置应用版本号 2.0.0
✔ 设置协议 MIT
生成 tsconfig.json...
✔ 你想要创建什么类型的项目？ blog
✔ 项目需要用到多语言么? No
生成模板...
✔ 是否初始化 Git 仓库? Yes
✔ 是否需要一个自动部署文档到 GitHub Pages 的工作流？ Yes
安装依赖...
这可能需要数分钟，请耐心等待.
我们无法正确输出子进程的进度条，所以进程可能会看似未响应

   ╭───────────────────────────────────────────────────────────────────╮
   │                                                                   │
   │                Update available! 10.6.1 → 10.28.1.                │
   │   Changelog: https://github.com/pnpm/pnpm/releases/tag/v10.28.1   │
   │                 Run "pnpm add -g pnpm" to update.                 │
   │                                                                   │
   ╰───────────────────────────────────────────────────────────────────╯

Packages: +353
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Progress: resolved 438, reused 340, downloaded 20, added 353, done

devDependencies:
+ @vuepress/bundler-vite 2.0.0-rc.26
+ sass-embedded 1.97.2
+ vue 3.5.27
+ vuepress 2.0.0-rc.26
+ vuepress-theme-hope 2.0.0-rc.102

Done in 5.2s using pnpm v10.6.1
模板已成功生成!
✔ 是否想要现在启动 Demo 查看? Yes
启动开发服务器...
启动成功后，请在浏览器输入给出的开发服务器地址(默认为 'localhost:8080')

> hello-vuepress@2.0.0 docs:dev D:\project\Vuepress-Version-Blog-Pnpm
> vuepress-vite dev src

✔ Initializing and preparing data - done in 321ms
Port 8080 is in use, trying another one...

  vite v7.1.12 dev server running at:

  ➜  Local:   http://localhost:8081/
  ➜  Network: http://192.168.125.4:8081/

第二步：github新建仓库

• 输入名称
• 输入描述（可选）
• 设置公开
• 添加README

第三步：github仓库创建新的分支

• 作用：用于存储静态html编译好的代码
• 方法：在github点击分支创建，分支名称为blog_pages

第四步：需要让github支持对外访问

1. 点击仓库的Setting
2. 选择左侧侧边栏的Github Pages
3. 选择将什么分支映射为可访问的静态站点，选择刚才创建的新分支blog_pages
4. 点击save保存

第五步：去github生成一个Access Token

1. 点击你的头像
2. 选择下方的设置Settings
3. 选择左侧侧边栏的开发者设置developer Settings
4. 选择个人访问令牌（经典）
5. 点击生成新令牌，选择经典
6. 备注可以说明令牌的作用，令牌有效期选择无有效期
7. 勾选设置权限为repo，使得令牌可以支持修改发布你的仓库
8. 令牌复制，比如：XXXXXXXX

第六步：将令牌设置到博客仓库

1. 在左侧侧边栏，选择安全-机密和变量（secrets and variables）- 代码空间
2. 点击新建机密
3. 标题为ACCESS_TOKEN，将密钥复制到密钥处
4. 点击添加机密

第七步：vscode修改仓库.github/workflows下方的yml文件

1. 修改部署文档的分支

- name: 部署文档
  uses: JamesIves/github-pages-deploy-action@v4
  env:
	  GITHUB_TOKEN: ${{ secrets.ACCESS_TOKEN }}
  with:
	  # 部署文档
	  branch: blog_pages
	  folder: src\.vuepress\dist

第八步：绑定远程仓库

• 将远程仓库的git地址添加到远程仓库
• 将本地代码和远程的main分支进行合并
• 发布到远程

第九步：修改部署的bug

• 指定pnpm版本，如下

  - name: 设置 pnpm
	uses: pnpm/action-setup@v4
	with:
	  version: 10

• 将下斜杠windows的路径修改为上斜杠linux路径

第十步：修改src下的config.ts

• 已经可以访问，但是样式不对，所以需要修改
• 修改base键值，根据访问的github提供的名称

export default defineUserConfig({
  base: "/Vuepress-Version-Blog-Pnpm/",
  lang: "zh-CN",
  title: "博客演示",
  description: "vuepress-theme-hope 的博客演示", 
  theme,
  // 和 PWA 一起启用
  // shouldPrefetch: false,
});

• 重新上传

页面标题

The first H1 title in Markdown will be regarded as page title.

Markdown 中的第一个 H1 标题会被视为页面标题。

你可以在 Markdown 的 Frontmatter 中设置页面标题。