AI/LLM

c/ai_llm

来看这个新技术 PTS (Pivotal Token Search, 关键token检索)

简单来讲, PTS的想法基于——大模型干活的时候不是所有输出的 token 都能成为决策点, 而是几个关键点 token 能决定大模型输出的东西对不对, 其它全是水词, 于是PTS方法提取这些 token, 形成 DPO(Direct Preference Optimization, 直接偏好优化)数据集. 数据集包含 “选择的 token” (增加成功率的 token), “拒绝的token” (降低成功率的 token)。然后进行针对性微调.

除了微调, PTS 方法还可以提取关键 token 的激活模式, 生成 steering vectors(引导向量)。然后在模型推理过程中引导,这样就不用微调了。(当然计算量会增加一些)

不过我咋感觉这个方法只是将一部分参数在向量空间的分布概率拉大?尤其是作者说是收到Phi4启发的。但Phi4的效果没啥惊艳的地方。那么这个方法真的有什么改进么?还是我理解的不太对?想听听有没有大佬的想法或者实践经验 …

1
message-square
0

1
message-square
0

1
message-square
0

1
message-square
0

BitNet 模型又增加了,来看 TII 的 Falcon-E-1B/3B

据官方说这个模型性能与 Qwen3-1.7B 相当,但内存占用仅有 Qwen3-1.7B 的 1/4

1
message-square
0

1
message-square
0

1
message-square
2

[https://zhuanlan.zhihu.com/p/1905008654861734139] (这是我在知乎发的帖子转载过来,所以格式和图片有所丢失)

为什么选择本地AI与Copilot?

数据隐私:所有数据处理都在本地进行,无需担心笔记内容上传云端。 离线使用:一旦设置完成,部分功能可在无网络环境下使用。…

2
message-square
4

1
message-square
0

微软发了篇新论文 ARTIST (Agentic Reasoning and Tool Integration in Self-improving Transformers, 使用自主推理与工具的自改进 Transformer 框架)

我刚看完, 直接用大白话给大家总结下论文讲了啥

这个框架集成了外部工具调用和自主推理, 来提升效果. 并且推理可以多步骤. 得到结果后进行强化学习, 不断反刍, 最终效果提升高达 22%.

1
message-square
0

速报:Manus 不用邀请码就能用了哈

1
message-square
0

1
message-square
0

HiDream i1 full在3070m上生成1920x1088分辨率的图片要12分钟,dev版本要3.5分钟,fast版本要2分钟,因结构表现下降不推荐使用。目前TeaCache还没有支持。

生成效果方面,HiDream i1 dev效果优于Flux.1 dev,但细节和光照表现还是明显低于HiDream i1 full,后者生成效果也接近比较优秀的闭源绘画模型。考虑后续有TeaCache支持的速度情况,个人还是偏向full版本。

HiDream i1发布有一段时间了,在这个适合测试是因为刚开始看到光照不如Pixelwave FLux.1 dev,但使用后者遇到细节问题,就决定尝试HiDream i1。个人认为综合光照表现,HiDream i1仍然是更好的选择。

3
message-square
0

2
message-square
0

最近使用AI辅助创建了两个项目,仍然使用Streamlit,功能比以前的项目复杂,算是实现了个人比较满意个人网站功能: https://github.com/Willian7004/new-blog https://github.com/Willian7004/media-blog

仓库内大部分程序是使用Deepseek R1编写的,在文件开头的多行注释记录了提示词。有几个程序试过用Qwen3 235b,但大部分程序还是Deepseek R1表现更好。不过虽然是比较简单的技术栈,部分程序也接近Deepseek R1的能力上限了,需要多次生成或人工修改才能完成。另外规划了一个GitHub Action,用于在每次更新时分别创建更新文件列表和更新文件全文的release,但没有实现预期功能,最终弃用了。

这两个项目改用markdown存储文本,后续也方便与GitHub Pages对接,但至少要等Deepseek R2推出才有希望正式转到web技术栈。

4
message-square
1

来个 Qwen3 愉快使用要规避的几个问题, 尤其是使用 Qwen3-30B-A3B 或者 Qwen3-32B :

​1. 上下文避免触及到召回长度,尤其是快到 16K 就应该新开了,不然质量下降很快

​2. 模型为了小又效果好,推理时长和 token 输出是要比其它模型高很多的。(想象一下神童小孩哥没学过高数,然后却能通过现有知识手撕吉米多维奇,那么他思考的时间肯定是要比同样的神人大学生要花时间的)。这个问题从 qwq 时代就存在。可以看我这个截图,运行同样数量的请求 qwq 消耗的 token 量是 claude-3.7-sonnet-thinking 的1.7倍。大部分都花在思考上了

2
message-square
3

大瓜:llama-4 用了 27 个模型刷榜 ChatBot Arena

来吃瓜昨天那个扒 ChatBot Arena 榜单造假的论文, 我看了一遍理了下,主要是这么几个地方。但在此之前,给不熟悉这个测试的同学说下他们是怎么测试的

1
message-square
0

小米 3小时前刚刚发布了四个模型!

MiMo-7B-Base 是基础模型 MiMo-7B-RL-Zero 是基于基础模型训练的 RL 模型 (强化学习) MiMo-7B-SFT 是基于基础模型训练的 SFT 模型 (监督式微调) MiMo-7B-RL 是基于 SFT 模型再 RL 的模型

2
message-square
0

Qwen3 的长上下文召回测试出了!

Fiction.Livebench 公布了最新的测试结果,Qwen3 整个系列在16K上下文时召回均能保持在60%以上(除了Qwen3-30B-A3B, 毕竟激活只有3B).

能得出的结论有:

如果运行30B大小的模型,那么还是优先选择 Qwen3-32B 而非 MoE 的Qwen3-30B-A3B。 …

1
message-square
0

Qwen3 写代码能力测试来啦!

简单说结论——可以加显卡了,这就是可以本地部署的最强开源写代码大模型

2
message-square
1