有很多种方式来并行。最简单的，你如果有 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 目前为止主要的用途还是做文本生成。

突发性耳聋治疗时间窗就一星期，错过这一星期是什么样就是什么样了

是的，自购硬件绝对是不划算的。服务商能跑满 GPU ，基本上不留空闲，个人很难做得到。

@Loocor cursor 做到这件事情应该是先做检索，找到需要修改的片段。这里的难点是，检索出来的内容不一定是唯一需要修改的，所以 copilot 直接做全量 edit 。

@dbskcnc 做得确实也不够好，无论是用户体验上还是生成质量

可能需要一个 BI 平台

@zfy941 嗯... Claude 的 客户端经常卡死

@zfy941 这一轮 chatbot 的客户端应该基本上都是 web 技术，包括 OpenAI 、Claude 、Gemini 这些

瑞幸经常会买咖啡液送咖啡杯

可以用来 debug 。然后很多实验室没能力训更大规模的模型，只能在 0.5b 1b 上试试。

@AlghaPorthos 幻觉问题可以通过 Knowledge Edit 解决。我并不太同意 RAG 可以解决幻觉，RAG 能做的只是给 LLM 添加一些提示信息，一方面 RAG 本身可能会引入错误信息，另一方面，提示信息并不能避免幻觉的出现，比如在长程推理场景下，RAG 输入的提示信息会被稀释。

另一个 RAG 目前试图解决上下文长度不够的问题。

我认为我们对上下文的需求是有极限的，比如 context window 已经能装下一整个 codebase 了，追求更长的上下文的意义就没那么大。

此外我们还有一些特别的技术比如 context compression 我认为这是比 RAG 解决 context length 更好的方案。