最简单的方案用 embedding ，clip 和 vit 都行。两类照片分别找 5 个，算出 embedding 保存到向量数据库。然后对给定的新照片计算一个 embedding ，从数据库找最相近的 5 个，出来的哪个分类多就是哪个分类

1 块 3090 还不如搞 4 块 P40 ， 核心和 2080TI 一样，24GB 显存。Qwen-VL 的模型我 8 块 2080ti 没跑起来，准备换成 P40 了。

moonlight + sunshine 串流，网速好 120FPS ，还能把触摸屏当 pad 用。

在写日志的时候就一边写一边回收，起一个 logtail 的边车，写完了就立即把日志收上去。业务不想写回收逻辑就启一个 logrotate 的边车帮他们回收。

科技翻译这个 gpts 的提示词如下:

你是一位精通简体中文的专业翻译，尤其擅长将专业学术论文翻译成浅显易懂的科普文章。请你帮我将以下英文段落翻译成中文，风格与中文科普读物相似。

## 规则
- 翻译时要准确传达原文的事实和背景。
- 即使上意译也要保留原始段落格式，以及保留术语，例如 FLAC ，JPEG 等。
- 保留公司缩写，例如 Microsoft, Amazon, OpenAI 等。
- 输入格式为 Markdown 格式，输出格式也必须保留原始 Markdown 格式
- 在翻译专业术语时，第一次出现时要在括号里面写上英文原文，例如：“生成式 AI (Generative AI)”，之后就可以只写中文了。
- 以下是常见的 AI 相关术语词汇对应表（ English -> 中文）：
* Transformer -> Transformer
* Token -> Token
* AI Agent -> AI 智能体
* LLM/Large Language Model -> 大语言模型
* Zero-shot -> 零样本
* Few-shot -> 少样本
* AGI -> 通用人工智能

## 策略：
分 3 步进行翻译工作，并打印每步的结果：
1. 根据英文内容直译，保持原有格式，不要遗漏任何信息
2. 反思第一步直译的结果，指出其中存在的具体问题，要准确描述具体问题和文本位置，也不要偏离原意，包括不仅限于：
- 不符合中文表达习惯，明确指出不符合的文本位置
- 晦涩难懂，读者不易理解的语句，对其给出解释
- 其他问题
3. 根据第一步直译的结果和第二步反思的结果，重新进行意译，保证内容的原意的基础上，使其更易于理解，更符合中文的表达习惯，同时保持原有的段落和文本格式不变，不要删除和遗漏任何内容

## 格式
返回格式如下，"{xxx}"表示占位符：

### 直译
{直译结果}

***

### 反思
{反思结果}

***

### 意译
{意译结果}


这个 GPTS 是作者为了追踪当下 AI 领域最新文章创建的,可能并不适合每个人.根据不同领域可以进行相应的调整.

如果可以的话 @chutsetien 可以贴一下原文吗?我来试试创建一个 gpts,不敢说能达到 DeepL 的效果,但是我觉得应该能做到比当前直接使用科技翻译的效果强.

如果不用阿里云的 dms 之类的东西，可以用 gh-ost 。监听 binlog ，开始复制表，apply binlog, lock + rename table 。一切都是无感的非常好用。

分享一下之前写做的关于 gh-ost 的笔记。

对于数据库运维人员来说,MySQL 的大表表结构变更一直都是个麻烦事,为了尽量不影响业务,业内常用的解决方案无外乎三种，

一是利用 Percona 的 pt-online-schema-change,Facebook 的 OSC 等三方工具；

二是在备库修改通过切换实现滚动变更；

三则是升级 MySQL 到 5.6/5.7 通过官方 Online DDL 实现部分变更。

然而,引入触发器带来的锁竞争问题,主备切换带来的附加成本以及 Online DDL 的局限性都不让 DBA 省心。

gh-ost 的设计号称无触发器，可监控，可动态调整暂停等，更重要的是切换方案的优秀设计。下面就介绍下其实现原理和 cut-over(新旧表切换)的详细过程。

原理
gh-ost 不依赖于触发器,是因为他是通过模拟从库,在 row binlog 中获取增量变更,再异步应用到 ghost 表的。

有三种功能模式：

a.连接从库间接应用到主库/c 在从库上进行修改

连接从库
校验完后,在主库创建新表
迁移原表数据到新表
模拟从库的从库，拉取解析增量 binlog 应用到主库
cut-over 阶段，用新表替换掉原表

b.连接主库直接修改

直连主库
主库上创建 ghost 表
新表(ghost 表)上直接 alter 修改表结构
迁移原表数据到新表
拉取解析 binlog 事件,应用到新表
cut-over 阶段,用新表替换掉原表

两者不同的点就在于,通过连接从库来进行变更,对主库的性能影响最小

变更流程
以直连主库修改为例，详细介绍 gh-ost 做了哪些操作：

校验
测试 db 是否可连通,并且验证 database 是否存在
确认连接实例是否正确
权限验证 show / gh-ost / grants for current_user()
binlog 验证,包括 row 格式验证和修改 binlog 格式后的重启 replicate
原表存储引擎,外键,触发器检查,行数预估等

初始化
初始化 stream 的连接,添加 binlog 的监听
初始化 applier 连接,创建 ghosttable 和 changelogtable
判断是否符合迁移条件,写入结果到 tablesInPlace channel

迁移
迁移过程中,row copy 和 binlog apply 是同时进行,其中原则是 binlog apply 的优先级一定大于 row copy 操作的优先级。

状态展示
Copy: 9451000/10000060 94.5%; Applied: 31; Backlog: 0/100; Time: 8m26s(total), 8m26s(copy); streamer: mysql-bin.000040:68321839; ETA: 29s

cut-over
尝试 lock 原表
成功后,进行 rename 原子性操作,被 block 住
unlock 原表,rename 完成切换
后续中间表清理工作

迁移和切换的细节实现
关于 gh-ost 的实现，这里只挑了 rowcopy 和 binlog apply 的顺序问题和 rename 过程做了详细解析。

在数据迁移的过程中，数据变量有三个，暂且分为，A:来自原表的 rowcopy ，B:binlog 的 apply ，C:对原表的 dml 操作。

C 操作会记录 binglog 从而触发 B 操作，所以 B 操作一定在 C 操作的后面，因此一般情况下，会有 ACB ，CBA 两种组合，同时特殊情况如 binlog apply 延迟，则会有 CAB 这种组合。

分析三种组合之前要先了解 gh-ost 在 sql 改写方面是如何映射的：

RowCopy select insert ignore into 复制数据
BinlogApply insert replace into 复制期间增加数据

update update 复制期间变更数据

delete delete 复制期间删除数据

在上述原则的基础上，我们再来逐个分析不同顺序组合的影响:

insert 操作
binlog 是最权威的,gh-ost 的原则是以 binlog 优先。

假设一段数据正在复制到新表时产生了插入，我们来分情况看一下如何保证数据一致

复制需要先从原表 select 再插入到新表，假设插入（ binlog ）发生在 select 之前

那么新表在数据到达之前会先从 binlog 插入将数据插入，复制的数据到达后，因为有主键的原因，所以 insert ignore into 会忽略这行数据

如果插入（ binlog ）发生在 select 之后

那么 binlog 在到达新表后会使用 replace into 覆盖之前复制过来的数据

无论是先还是后都可以保证以 binlog 为准

update/delete 操作
一般情况下：

ACB 组合，即对已经 rowcopy 过的数据，出现对原表的 update/delete 操作。这时候会全部通过 binlog apply 执行，注意 binlog apply 的 update 是对某一条记录的全部列覆盖更新，所以不会有累加的问题。

CBA 组合，即对尚未迁移的数据，出现对原表的 update/delete 操作。这时候对新表的 binlog apply 会是空操作，具体数据由 rowcopy 迁移。

特殊情况下:

CAB 组合，即先对原表更新完以后，rowcopy 在 binlog apply 之前把数据迁移了过去，而在 binlog event 过来以后，会再次应用。这里看似有问题，但是结合 gh-ost 的 binlog aplly 的 sql 映射规则，insert 操作会被 replace 重新替换掉，update 会更新对应记录全部行，delete 会是空操作。最终数据还是一致的状态。

cut-over 过程
在 pt-osc 或者 online ddl 中,最后的 rename 操作一般是耗时比较短,但如果表结构变更过程中,有大查询进来,那么在 rename 操作的时候,会触发 MDL 锁的等待,如果在高峰期,这就是个严重的问题。所以 gh-ost 是怎么做的呢？

gh-ost 利用了 MySQL 的一个特性，就是原子性的 rename 请求，在所有被 blocked 的请求中，优先级永远是最高的。gh-ost 基于此设计了该方案：一个连接对原表加锁，另启一个连接尝试 rename 操作，此时会被阻塞住，当释放 lock 的时候，rename 会首先被执行，其他被阻塞的请求会继续应用到新表。

migrator.go:iterateChunks() 函数来确定何时开始 cut － over

具体切换流程如下
会话 A START

CREATE table tbl_old
防止 rename 过早执行

LOCK TABLES tbl WRITE, tbl_old WRITE
通过 lock_wait_timeout 设置为 2s 控制超时，超时失败会重试次数为配置 default-retries ，默认 60 次

新的请求进来，关于原表的请求被 blocked
RENAME TABLE tbl TO tbl_old, ghost TO tbl , 同样被 blocked

新的请求进来，关于原表的请求被 blocked
检查是否有 blocked 的 RENAME 请求，通过 show processlist
DROP TABLE tbl_old
UNLOCK TABLES
END

不同阶段失败后如何处理
如果第一步失败，退出程序
如果会话 A 建表成功，加锁失败，退出程序，未加锁
rename 请求来的时候，会话 A 死掉，lock 会自动释放，同时因为 tbl_old 的存在 rename 也会失败，所有请求恢复正常
rename 被 blocked 的时候，会话 A 死掉，lock 会自动释放，同样因为 tbl_old 的存在，rename 会失败，所有请求恢复正常
rename 死掉，gh-ost 会捕获不到 rename ，会话 A 继续运行，释放 lock ，所有请求恢复正常

WPF 是最好用的。不过如果你真想看看其它的 UI 框架的话，我推荐 gaclib https://gaclib.net/contact.html

照着 demo 糊一个简单的应用非常容易。
没有授权问题，除非你要改 gaclib 本身的代码。
纯 C++，反编译困难。
遇到问题可以直接加群问。

@doudouwang 对，感知机也是神经网络，我说的感知机应该是去掉非线性激活函数，应该是多元线性回归。所以我理解

多层的（多元线性回归 + 非线性激活函数） = 神经网络拟合
多元线性回归 + 变量的 2 次方 + 变量的三次方 = 多项式拟合

那么之前有没有人走过多项式拟合这条路。应该就是一楼说得多项式回归。

是的,RAM 服务整个挂了,所以影响到所有使用 ram 的服务

我想问 google 搜索的时候有没有能设置屏蔽 csdn 的地方

@joyhub2140 笑死，距离产生美嘛

贡献个低成本的方案

首先是分词，用 hanlp 的多语言分词模型就不错，tok 的分词效率很高。可以把自家的敏感词当作 force 字典加进去，然后对于误杀的，只要保证词长度比敏感词更长就能解决。

然后对每个分词作 ac 自动机检测，只要有一个命中就报错出来。

然后可以再做一层 zero-shot-classification ，把每个敏感词分个类，比如刀属于管制器械，但是刀剑神域是游戏，命中的时候判断刀剑神域是不是管制器械，可以进一步降低误杀概率，hg 上一大堆 zsc 的模型。随便搞一个，之后还能积累一波数据做个微调。

我们的场景相对来说没有太多敏感词，所以主要的性能消耗在 hanlp 的分词，实际运行效率非常高。10 万量级的词库，50 个 30-50 个字符的检测差不多 200-300ms 。