@llej 我反而觉得后端更容易让 LLM 知道问题，只要你有足够好的 unit test 。但是对前端来说，你即使告诉给他差多少个像素点，LLM 也很难处理，因为它无法「想象」这段代码实际的布局效果是什么样（这个要求就相当于让 LLM 训练得到一个差不多的渲染引擎，这很难）。

实际体验里也经常遇到这种问题。

@ciki 做不到。

Si, Chenglei, et al. "Design2Code: Benchmarking Multimodal Code Generation for Automated Front-End Engineering." arXiv preprint arXiv:2403.03163 (2024).

可以看看这里的 benchmark ，这还只是 HTML+CSS 的简单页面。

@ciki 因为你的前端是自由发挥的，你让 LLM 去严格对照设计稿还原，几乎是没有任何可能还原成功的。真实场景不可能让 LLM 去自由发挥。

大家把前端理解为画 UI 是不是过于偏颇了？

附一张图，大部分情况下，LLM 解决软件开发问题的成功率满足 Python > Java > TypeScript > JavaScript ≈ C++ 的规律。

https://imgur.com/a/DvjSqQr

@bigtan copilot 的 cmd + i 对应的是 cursor 的 cmd + k

举个例子，copilot 至今没有一个类似 cmd + i 的快捷键，可以把选区添加到 chatbot 里。

就这么一个小的功能，真的会很影响自己开发时候的流畅度

@gneko 是 我自己感受一直都是 claude 3.5 > 3.7 > 4.0 。现在的 benchmark 关注竞争性编程，反而会损坏日常业务需求需要的能力。

这两个应该是不同团队做的，NotebookLM 属于 Google Workspace ，Gemini App 是专门做 Ai Chatbot 的组。

@asdblue 我理解这个叫私有化部署，可以直接买全套方案，我比较疑惑的是个人用户部署一个 LLM 在自己的机器上

@nowant 我一直没想明白本地部署的意义，现在 api 已经很便宜了

有很多种方式来并行。最简单的，你如果有 256 个 batch 要训练/推理，那就分成若干份，比如 4 个 64 个样本，这样就能一次推理得到 256 个样本的结果。但是如果模型参数足够大，以至于一张卡装不下，那就得在其他层面进行并行。

生育率暴跌的背景下还能算优质资产吗？

理论上来说，我们的训练语料能够覆盖到工具的使用，LLM 是可以自己规划的。但是现实是，即使我们考虑一些简单的场景，比如代码检索，LLM 也需要额外的一些信息[1].

举个例子，现在 LLM 写 UI ，它是无法「想象」出来页面长什么样子的，这是一件比较困难的事情，也是 design2code 到现在还在做几十年前的纯 HTML 和 CSS 数据集还取得一个非常低的分数的原因[2]。现在能做的，是把真正运行的结果用各种方式让 LLM 感知到。

[1].Gao Z, Wang H, Wang Y, et al. ViC: Virtual Compiler Is All You Need For Assembly Code Search[J]. arXiv preprint arXiv:2408.06385, 2024.
[2].Si C, Zhang Y, Li R, et al. Design2Code: Benchmarking Multimodal Code Generation for Automated Front-End Engineering[J]. arXiv preprint arXiv:2403.03163, 2024.

没必要用推理模型，推理模型对不需要推理的场景，可能并不能比得过普通的模型。

1. prompt ，现在 LLM 在对齐阶段一般做过格式的对齐，所以直接让输出 JSON 效果就会不错，如果还是不行把温度系数调一下；
2. 受限解码，大致思想是要求 LLM 的 output 必须符合某个语法结构，如果不行就重新采样。好处是可以保证一定不会出现格式错误，但是这样做的问题是会影响本身的性能，不推荐；

@itsCoderStudio 有 ChatGPT 怕啥，现在最不需要的就是对具体语法的了解

@maocat 有推荐吗

@yvescheung Adobe 最近在大量招募做 CV 的人，他们的抠图工具、填充工具都在用新的技术

因为 LLM 目前为止主要的用途还是做文本生成。