未分类 · AI Times

DeepSeek_V4_技术报告解读

Fri, 24 Apr 2026 21:28:03 +0800

DeepSeek-V4 技术报告解读

报告日期: 2026年4月24日
模型发布: DeepSeek-V4 预览版（双版本：Pro / Flash）
开源协议: MIT
技术报告: DeepSeek_V4.pdf

一、模型概览与定位

DeepSeek-V4 是深度求索（DeepSeek）于 2026年4月24日 发布的最新一代大语言模型，采用 MoE（Mixture of Experts） 架构，主打百万字超长上下文（1M tokens）与顶尖代码/推理能力。

核心定位：

首发即适配 华为昇腾（Ascend） 平台，同时兼容 NVIDIA GPU
全系标配 1M tokens 上下文窗口（约75万字）
在 Agent 能力、世界知识和推理性能上实现开源领域领先
部分指标比肩甚至超越顶级闭源模型

二、双版本规格对比

规格	V4-Pro（旗舰版）	V4-Flash（经济版）
总参数	1.6T	284B
激活参数（MoE）	49B active	13B active
预训练数据量	33T tokens	32T tokens
上下文长度	1M tokens	1M tokens
最大输出长度	384K tokens	384K tokens
计算精度	FP4 + FP8 混合精度	FP4 + FP8 混合精度
定位	复杂智能体、专业代码生成	日常对话、高并发 API 调用

三、六大核心技术创新

1. 混合注意力机制（CSA + HCA）

CSA（Compressed Sequence Attention，压缩序列注意力）与 HCA（Heavily Compressed Attention，重度压缩注意力）协同工作
效果：在 1M 上下文下，相比 V3.2：
- 单 token 推理 FLOPs 降至 27%（降低 73%）
- KV Cache 占用降至 10%（减少 90%）

2. DSA 稀疏注意力（DeepSeek Sparse Attention）

在 token 维度进行压缩，显著降低长序列处理的计算冗余
改变传统全量注意力的计算范式
实现长上下文与低算耗的统一

3. 流形约束超连接（mHC）

在深层 Transformer 中引入流形约束
抑制深层梯度弥散，提升深层信号稳定性
防止专家激活分布随深度坍缩

4. Muon 优化器

替代传统 AdamW，采用矩阵正交化的动量更新机制
在同等计算量下收敛更快、最终损失更低
在超过 32T tokens 的预训练规模下效果稳定

5. 训练与后训练 Pipeline

超大规模语料预训练 + 策略蒸馏优化
强化推理、编程与世界知识能力
支持 reasoning_effort 参数调节思考强度（high / max）

6. 长上下文效率优化

V4-Pro 单 token 计算量比 V3.2 降低 3.7 倍
V4-Flash 单 token 计算量比 V3.2 降低 9.8 倍
1M 上下文成为 DeepSeek 所有官方服务的标配

四、性能指标与评测结果

4.1 综合基准测试（V4-Pro-Max）

评测项	V4-Pro 成绩	说明
MMLU	90.1	多学科综合
MMLU-Pro	73.5	专业级推理
C-Eval	93.1	中文综合评测
GPQA Diamond	90.1	研究生级科学推理
HumanEval	76.8	代码补全
LiveCodeBench	93.5	动态代码测试
Codeforces Rating	3206	开源模型最高
GSM8K	92.6	小学数学
MATH	64.5	竞赛数学
SWE Verified	80.6%	软件工程修复（官方自测）
SWE Pro	55.4%	工程级修复
Terminal Bench	67.9	终端任务
MRCR 1M	83.5	百万级长上下文召回
CorpusQA 1M	62.0	百万级长文档问答

4.2 与头部闭源模型横向对比

基准测试	GPT-5.4	Claude Opus 4.6	Gemini 3.1 Pro	DeepSeek V4 Pro-Max
MMLU-Pro (知识)	87.5	89.1	91.0	87.5
SimpleQA (事实)	45.3	46.2	75.6	57.9
GPQA Diamond (推理)	93.0	91.3	94.3	90.1
HLE (推理)	39.8	40.0	44.4	37.7
LiveCodeBench (代码)	—	88.8	91.7	93.5
Codeforces (代码)	3168	—	3052	3206
Apex Shortlist (代码)	78.1	85.9	89.1	90.2

关键结论：

✅ 代码能力顶尖：LiveCodeBench、Codeforces、Apex Shortlist 均领先
✅ 推理能力先进：GPQA Diamond 接近竞品
⚠️ 知识类仍有差距：MMLU-Pro、SimpleQA 落后于 Gemini 3.1 Pro

4.3 代际提升（V4-Pro vs V3.2）

类别	指标	V3.2	V4-Pro	提升幅度
知识	MMLU-Pro	65.5	73.5	+8.0
事实问答	SimpleQA	28.3	55.2	+26.9
事实问答	FACTS	27.1	62.6	+35.5
代码	HumanEval	62.8	76.8	+14.0
数学	MATH	60.5	64.5	+4.0
长上下文	LongBench-V2	40.2	51.5	+11.3

核心变化：

事实问答爆发式增长（FACTS +35.5，SimpleQA +26.9）
代码能力大幅跃升（HumanEval +14.0）
长上下文能力显著强化（LongBench-V2 +11.3）

五、API 定价与商业部署

5.1 定价策略（每百万 tokens）

模型	输入（缓存命中）	输入（未命中）	输出
V4-Flash	¥0.2 / $0.028	¥1 / $0.14	¥2 / $0.28
V4-Pro	¥1 / $0.145	¥12 / $1.74	¥24 / $3.48

成本优势：

V4-Pro 输出定价约为 GPT-5.4（$15）的 1/4
V4-Pro 输出定价约为 Claude Opus 4.6（$25）的 1/7
夜间半价：北京时间 23:00—07:00

5.2 版本对比分析

维度	V3.2	V4-Flash	V4-Pro
上下文	128K	1M	1M
输入（未命中）	¥2	¥1	¥12
输出	¥3	¥2	¥24
性价比	基准	加量减价	性能溢价

Flash 版：上下文扩大 8 倍，价格更低，性价比极高
Pro 版：价格大幅上涨，目标性能敏感型企业级场景

5.3 接入与迁移

API 模型名称：deepseek-v4-pro 或 deepseek-v4-flash
接口兼容：支持 OpenAI ChatCompletions 和 Anthropic 格式
旧版停用：deepseek-chat / deepseek-reasoner 将于 2026年7月24日 停用
当前映射：
- deepseek-chat → V4-Flash 非思考模式
- deepseek-reasoner → V4-Flash 思考模式

六、国产算力适配

平台	适配状态	说明
华为昇腾	✅ 首发适配	代码从 CUDA 迁移至华为 CANN；昇腾 950PR/950DT
寒武纪	✅ Day 0 适配	基于 vLLM 框架，适配代码已开源至 GitHub
NVIDIA GPU	✅ 兼容	原生支持

战略意义：首发即适配华为昇腾（而非仅 NVIDIA），被视为在出口管制背景下 AI 算力路径多元化的重要信号。

七、开源生态与部署

开源权重：
- Hugging Face: https://huggingface.co/collections/deepseek-ai/deepseek-v4
- ModelScope: https://modelscope.cn/collections/deepseek-ai/DeepSeek-V4
技术报告：https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro/blob/main/DeepSeek_V4.pdf
开源协议：MIT（商用零门槛）
本地部署：Flash 版最低需 200GB+ 内存，普通开发者难以本地部署

八、战略与商业化动态

融资转折：DeepSeek 长期拒绝外部融资，此次于 2026 年 4 月首次启动对外融资洽谈
目标估值：200 亿美元（腾讯、阿里均参与谈判）
官方引言：「不诱于誉，不恐于诽，率道而行，端然正己。」（出自《荀子・非十二子》）

九、总结与评价

核心卖点

百万上下文普惠化：1M tokens 成为标配，通过 DSA 稀疏注意力实现低算耗
代码能力顶尖：LiveCodeBench、Codeforces 等核心代码基准领先
事实问答可靠性大幅提升：FACTS +35.5，幻觉显著减少
开源生态友好：MIT 协议，兼容 OpenAI/Anthropic API

适用场景

V4-Flash：长文本处理、高并发 API 调用、成本敏感型业务
V4-Pro：复杂 Agent 任务、专业代码生成、事实准确性要求高的场景

与闭源模型差距

⚠️ 通用知识（MMLU-Pro、SimpleQA）仍落后于 Gemini 3.1 Pro
⚠️ 复杂逻辑推理（BBH）与前代基本持平，非此代重点突破方向

信息来源：综合自 DeepSeek 官方公告、AI Insight、IT之家、投资界、小众软件、AIHub、AITOP100 等渠道，发布日期均为 2026 年 4 月 24 日。

代码生成 Copilot 产品的应用和演进 | AICon

Fri, 28 Jun 2024 14:53:27 +0800

ref:https://www.infoq.cn/article/I2PS1f3dC9BS5Sy2QE19
这篇分析不错，说了很多代码生产模型的细节-
1.自研评测指标
2.科学定义产品指标
3.A/B测试

代码生成 Copilot 产品回顾

GitHub Copilot 的成功因素

首先，回顾一下代码生成 Copilot 这种产品形式。当我们谈论代码生成 Copilot 或者 Copilot 这个词时，不得不提到 GitHub 在 2021 年 6 月推出的 GitHub Copilot。这个产品不仅拥有一个响亮的名字，而且定义了一种新的 AI 产品的范式。GitHub Copilot 在 2021 年 6 月推出了技术预览版，随着不断的迭代，其效果令人印象深刻，使人们意识到将大语言模型应用于代码生成领域具有巨大的潜力。业界也开始迅速构建类似的产品，无论是在模型还是产品上都取得了快速的迭代。

这里有一个关键问题：为什么是 GitHub Copilot 引爆了这个热点？实际上，将自然语言处理（NLP）技术应用于代码生成并不是一个新概念，例如 TabNine 这样的产品在 GPT-2 时代就已经将其应用于代码补全。那么，GitHub Copilot 究竟有何特别之处呢？我们想要从几个方面和维度来探讨这个问题。

首先，我想提到团队，GitHub Next 是这个产品的孵化团队。GitHub Next 是一个具有研究属性的团队，他们的任务是探索未来软件开发的新方式。如果访问他们的官网，你会发现许多有趣的项目，其中就包括 Copilot。团队主要由程序分析师、软件工程师以及研究员组成，他们持续关注的一个重要话题是如何实现通用的代码生成。

接下来，我想谈谈一个重要的契机，那就是 2020 年 6 月 GPT-3 的问世。由于 GitHub 现在是微软的子公司，而微软与 OpenAI 有着深入的合作，GitHub 团队很早就获得了 GPT-3 的预览版，并对其能力感到非常兴奋。他们认为必须利用 GPT-3 在代码生成领域做出一些创新，因此与 OpenAI 紧密合作，基于 GPT-3 迭代开发出了专门用于代码的大型语言模型 Codex。随后，他们对 Codex 进行了持续的微调训练，打造了专属的模型。一个强大且优秀的基础模型实际上决定了产品的上限，因此 GPT-3 的出现对这款产品的贡献是巨大的。

有了模型之后，团队开始思考应该开发什么样的产品形态。根据 GitHub 的分享，他们最初的想法是开发一款 Chatbot，即一款能够解答编码过程中遇到的任何问题并提供代码的对话聊天产品。但他们很快发现，尽管知识库中大部分问题都能得到回答，但只有大约 20% 的回答是正确且被接受的。尤其是在 GPT-3 时期，ChatGPT 还要两年后才出现，他们意识到这种 Chatbot 产品的效果并不理想。如果大部分时候给出的答案都不是用户想要的，用户对产品的信任度会很低。于是他们决定先采用代码补全这种容错率更高的产品形态，一方面代码补全是个开发者使用频率非常高的功能，也有很强的依赖性，更重要的是开发者对于这个功能的预期是给出建议而不是 100% 准确的答案。

选择好产品形态后的一个要素是交互方式。GitHub Copilot 放弃了传统 IDE 中从下拉列表选择补全建议的交互，而是选择了用 Ghost Text 进行展示，用 Tab 键进行采纳，继续输入则取消推荐。这种交互方式发挥了模型在多行补全上的优势，推荐代码和已有代码融为一体，方便开发者快速基于上下文判断是否采纳。

代码补全产品的一个技术挑战是实现低延迟，Jetbrains 在开发传统的补全功能时甚至要求在 150ms 内出现推荐列表以达到最佳的开发者体验。因为专业开发者的输入速度通常较快，过高的延迟会失去很多推荐的机会或者迫使用户停顿等待。GitHub Copilot 在大语言模型的推理速度和工程链路上进行了优化，让一个基于云端推理的 LLM 应用做到 500ms 左右的平均延迟。

如果说基座模型决定了产品能力的上限，那么提示工程所做的努力就是去逼近这个上限。通过研究开发者日常开发中会关注的上下文，在 prompt 中加入文件路径、相似代码、浏览记录等信息，让模型在代码补全方面的表现大幅提升，如今这些提示工程上的实践也被大家广泛应用。

字节跳动内部代码生成的探索历程

字节跳动在内部探索代码生成的过程中，面临多种优化选择：可以在模型层面进行优化，也可以选择在工程链路上优化，或在交互体验上进行改进。团队需要灵活地做出决策。

随着大语言模型的发展，特别是从 2023 年开始，这个领域开始受到广泛关注，新的模型和产品层出不穷。为了迭代和优化模型，字节跳动首先建立了自己的评测方法和自动化评测系统。这涉及到模型选型的决策，快速评估训练过程中的 checkpoint 效果，以及产品上线后如何收集线上反馈，包括用户编辑过程中的正反馈和负反馈。字节跳动还建立了一个完整的数据链路，以决定哪些数据被采纳，哪些被丢弃，并实施 A/B 测试系统来验证不同的 prompt 策略、参数配置，甚至是新模型的上线效果。字节跳动的自研大语言模型也已经发布，团队逐渐切换到这个自研模型上。基于此，字节跳动引入了对话方式，使代理模型能够理解整个工程结构，并根据实际情况生成代码。此外，还引入了多点代码编辑推荐功能，这是一个较新的功能。今天的分享将围绕三个重点进行详细分析：

构建自研评测体系的重要性；
如何科学定义产品指标；
A/B 测试的重要性。

构建自研评测体系的重要性

构建自研评测体系的重要性在于，它可以帮助我们避免使用不恰当的评测指标，如 HumanEval，它可能无法准确反映模型在实际应用中的表现。HumanEval 通过完成人工编写的算法题并运行单元测试来评估模型，虽然模型在测试的分数可能很高，但这并不意味着模型在代码补全产品中的表现就一定好。例如，GitHub Copilot 在 HumanEval 上的得分可能不高，但其用户体验仍然出色。

自建评测集可以避免数据泄露问题，确保题目和答案不会被模型提前接触到。同时，自建评测集可以引入真实项目中的跨文件上下文，这对于评估模型能否合理利用上下文信息至关重要。此外，自建评测集还可以引入大量公司内部代码，因为开源代码与内部代码的使用场景和分布可能存在显著差异。评测体系还需要包括基于单元测试的验证方式，因为同一功能可能有多种不同的代码实现方式，而单元测试可以更准确地验证生成代码的正确性。

最后，安全的自动化评测系统对于模型迭代至关重要。它不仅可以通过执行结果来验证代码的正确性，还可以防止模型生成有害代码，如删除根目录或造成大量内存分配等问题。高效的沙箱测试环境和高并发支持对于大规模的评测也是必不可少的。通过这样的评测系统，我们可以在训练过程中对不同 checkpoint 的模型效果进行评估，从而为模型选型和迭代提供有力支持。

如何科学地定义指标

在科学地定义指标时，我们需要考虑代码补全流程中的各个环节，并确保所选指标能够准确反映产品优化的需要。一个有效的指标应该能够指导整个链路的优化，帮助我们识别瓶颈并进行相应的调整。采纳率是一个常被提到的指标，它通常定义为采纳次数除以推荐次数。虽然这个定义简单，但它并不是一个好的指标。首先，采纳率容易被操纵。例如，如果减少推荐次数，只在非常确定的时候去帮你补一个分号，采纳率就会提高，但这并不意味着产品的实际效果有所提升。其次，采纳率没有很好地拆解推荐和采纳过程中的具体因素，无法明确指出是推荐更快了，还是其他因素导致采纳次数增多。

体验指标是另一个需要考虑的方面。当用户在使用代码补全产品时，如果一个 Tab 操作就能接受推荐的代码并完成工作，这自然会带来良好的用户体验。体验指标可以反映用户对产品的满意度，但它并不直接指导产品优化的方向。在定义指标时，我们需要更细致地考虑如何反映产品的实际性能和用户体验，同时避免指标被操纵，并确保指标能够指导我们进行有效的产品迭代和优化。

在探讨如何科学地定义指标时，引入了 CPO（Character per opportunity）这一指标，它是由一家专门从事代码补全产品的公司提出的。CPO 的计算公式由五个因子相乘得到：尝试率、反馈率、采纳率、每次采纳平均的 token 数以及 token 的平均字符长度。

尝试率指的是用户在编辑器中进行操作时，AI 提供建议的频率。例如，如果用户敲击键盘 10 次，但只有 6 次触发了对模型的请求，尝试率就是 6/10。这个指标反映了 AI 实际为用户提供建议的次数。

反馈率考虑了 AI 给出补全建议时存在的延迟问题。如果因为延迟太高，开发者已经进行了其他操作，那么即使推荐返回了也没有意义。如果发起 6 次请求，最终只有 3 次被展示，反馈率就是 3/6。

采纳率是大家熟悉的指标，即用户接受推荐的次数与推荐次数的比值。例如，三次推荐中只有一次被采纳，采纳率就是 1/3。

引入每次采纳平均的 token 数和 token 的平均字符长度这两个参数，是为了衡量不同长度代码带来的价值。不同的语言模型有不同的分词器，因此需要计算每个 token 平均的字符长度。例如，ChatGPT 的词表较大，平均一个 token 可以生成的字符数可能大于其他模型。

CPO 指标的计算公式是这几个因子的乘积，它衡量的是在每次有机会向用户推荐时，推荐了多少字符给用户。这个指标不仅可以衡量产品给开发者带来的价值，还可以拆解到整个链路的各个部分进行优化。例如，可以通过优化模型推理性能，提高反馈率，或者在代码注释中提供推荐来优化尝试率。此外，当线上出现问题时，CPO 指标也可以用来分析可能存在的问题所在。

A/B 测试的重要性

A/B 测试在产品开发过程中扮演着至关重要的角色。尽管离线评测可以帮助我们进行模型选型，但一个模型是否真正有效，还需要通过线上测试来验证。有时候，一个模型在评测中得分很高，但这并不代表它在线上的实际表现同样出色。例如，一个非常强大的模型如 GPT-4，可能会因为高延迟而影响用户体验。

A/B 测试还可以帮助我们确定各种参数配置的合适值。比如，如果一个模型支持 16K 的上下文长度，是否就应该使用完整的 16K 呢？实际上，如果上下文过长，可能会导致整体延迟增加，影响用户体验。因此，需要通过 A/B 测试来找到最合适的上下文长度。

此外，A/B 测试还可以验证新的提示工程策略的效果。例如，如果我们在模型中加入了函数签名或其他包结构信息，是否真的能提升效果？模型是否能够有效利用这些上下文？以及为了采集这些上下文信息而引入的额外延迟，是否值得？这些问题都需要通过 A/B 测试来验证。

最后，A/B 测试还可以帮助我们发现并改进产品指标。假设我们最初使用的是采纳率作为指标，但在进行 A/B 测试后，我们发现延迟提高后，采纳率反而增加了。这种情况可能表明我们的指标存在问题，需要重新考虑和调整。

代码编辑推荐：代码补全的进化

代码补全的进化形式可以被视为代码编辑推荐。大语言模型擅长生成下一个 token，这与代码补全或续写任务非常契合。然而，传统的代码补全主要针对编写全新代码的场景，而软件工程师在日常工作中不仅需要编写新代码，还需要编辑现有代码，包括重构和删除代码。在这些场景下，传统的补全功能可能无法高效地满足需求。在编辑现有代码时，简单地删除一行然后重新编写是低效的。理想情况下，我们希望模型能够自动完成新增、删除、替换等操作，从而提高代码编辑的效率。因此，代码编辑推荐作为代码补全的进化，能够更好地适应软件工程师在实际工作中的各种代码操作需求，提供更加全面和智能的代码辅助功能。

代码编辑推荐的概念

代码编辑推荐的概念涉及到一种更高级的代码辅助功能，它不仅包括传统的代码补全，还涵盖了对代码进行更深层次的理解和编辑。例如，假设你写了一个 log 函数，该函数用于打印一个 message，并且有两个函数作为调用方来使用这个 log 函数。

如果你决定给 log 函数添加两个新的参数，比如 sourceMethod 和 level，用以打印出对应的方法名称和日志等级，这时你实际上需要执行两个后续操作：首先，在 print 语句中添加新参数，以便能够打印出这些新信息；其次，在所有的调用方中也添加这些新参数，确保它们能够传递正确的值给 log 函数。

在这种情况下，代码编辑推荐的目标是让模型在你添加完新参数后，能够自动帮你完成剩余的内容。理想状态下，当你完成添加参数的操作时，模型已经预测出你需要在 print 语句中加入这些参数，并且在你移动到调用方时，模型已经知道你接下来需要在这些调用点添加新参数。

在 Go 语言中，如果你有一个结构体并且希望它在多线程环境下保持线程安全，通常会引入互斥锁（mutex）来实现。在这种情况下，你需要在结构体的初始化（new）、设置（set）和获取（get）方法中添加锁操作。智能的代码编辑推荐系统应该能够预测到你接下来需要进行的操作。例如，当你在 new 函数中添加锁时，推荐系统可以自动提示你在 set 和 get 方法中也添加相应的加锁代码。当你的光标移动到相应的方法上时，推荐系统就可以给出这些建议。

数据构建和模型训练方法

数据构建和模型训练是提升代码生成能力的关键环节。模型的能力来源于数据，尤其是 Git 仓库中海量的 commit 数据，这些数据包含了丰富的用户编辑信息。

现有的模型训练并没有充分利用这些数据，因为它们往往包含噪音，例如在 commit 信息中夹带无关内容。因此，需要通过启发式规则或模型来过滤掉这些噪音，提取出有相关性和逻辑关系的编辑操作。

在编辑过程中，修正 Lint 错误是一个常见任务，这些错误信息及其修复方式也是非常宝贵的数据资源。在训练模型时，通常会选择一个基于大型代码表示模型作为基础，并通过持续训练和 SFT（Supervised Fine-Tuning）等方法让模型理解代码变更的差异。

模型在修正代码时可能会出现过度编辑的情况，即模型可能会过于激进地进行不必要的修改。因此，需要采取措施抑制这种行为，确保模型的编辑是恰当和准确的。

进行中的优化

在进行中的优化方面，我们认识到目前的交互体验和展示方式可能并非最理想的状态。我们认为，集成在集成开发环境（IDE）中并进行一些 UI 上的定制，可能会带来更好的用户体验。

此外，我们已经在内部支持了对链接错误（Link Error）和警告（Warning）的修复功能。这是一个重要的进步，因为它能够帮助开发者更快速地解决编译时遇到的问题。

我们还在探索光标移动的自动识别和推荐功能。目前，模型通常需要等到开发者的光标移动到特定位置后才能进行预测和推荐。我们希望优化这一点，让模型在开发者完成编码时就能预测下一步可能的编辑位置，并直接提供相应的推荐。这样的优化将进一步提升代码编辑的流畅性和效率。

代码生成 Copilot 的未来展望

对于代码生成模型来说，一个明显的趋势是能够处理更长的上下文。理想情况下，模型能够理解整个代码仓库的内容。目前，K 级别和 M 级别的上下文可能还不够，模型需要能够无限地处理上下文信息。谷歌等公司已经提出了相关计划。但随着上下文的增长，保持推理速度不降低也是一个挑战，需要维持在几百毫秒的水平。一些公司如 Magic.dev 和 Supermaven 正在探索使用非 Transformer 架构来实现这一点。

对于产品形式，完全自主的 Agent 可能不太适合复杂的任务开发。程序员有时可能想用自然语言或注释来描述编码意图，但由于自然语言的局限性和文档编写的困难，最好的做法可能是 AI 与开发者通过交互的方式反复构思确认，并迭代完成复杂功能的开发。

AI 应该更智能地识别人类的意图，例如通过编辑位置的预测来主动参与编码过程，提前帮助预判并提供推荐。虽然这个概念比较抽象，但最近出现了一些体现这一思路的例子。Replit 公司开发的代码修复 Agent 展示了 AI 作为一个虚拟协作者参与交互过程的能力。在多人协同的 IDE 中，AI 能够发现错误并以协作者的身份帮助修正，这是一种有效的主动式 AI 交互方式。

明尼苏达大学的研究 “Sketch Then Generate” 展示了一种人与 AI 交互持续迭代的方法。通过编写有结构化的注释来指导模型，这些注释可以与代码的实体、符号、方法关联起来，先构建代码架构，然后逐步指导模型生成更多细节和代码。

代码生成 Copilot 的未来将更加注重上下文理解、交互式产品开发、智能意图识别和人机协同工作，以实现更高效和智能的代码生成和编辑体验。

微软autogen-进一步使用2

Mon, 09 Oct 2023 22:40:08 +0800

本着好奇的态度，进一步看了下它的例子，发现有些惊艳： https://github.com/microsoft/autogen/blob/main/notebook/agentchat_teaching.ipynb 考虑这样一个场景:需要找到某个主题的研究论文，对应用领域进行分类，并绘制每个领域的论文数量的条形图。

首先解决墙内访问OpenAI的问题，继续使用openai-forward 代理到自己的转发服务上，修改代码如下：

import autogen

config_list =[
 {
 "model": "gpt-4",
 "api_key": "fk-xxxx",
 "api_base": "http://47.251.x.xxx:18088/v1"
 }
]

llm_config={
 "request_timeout": 600,
 "seed": 44, # change the seed for different trials
 # "config_list": autogen.config_list_from_json(
 # "OAI_CONFIG_LIST",
 # filter_dict={"model": ["gpt-4-32k"]},
 # ),
 "config_list":config_list,
 "temperature": 0,
}

//然后告诉assistant 代理：到arxiv搜对应主题的文章
task1 = """
Find arxiv papers that show how are people studying trust calibration in AI based systems 
"""

user_proxy.initiate_chat(assistant, message=task1)

然后代理给出的结论答案很是厉害：
1.直接代码都给写好了。包括搜索arxiv的方法、解析方法，都提供了实现。

输出也是比较有效：完整的标题、作者、摘要

任务2：进行解读、摘要任务，也是非常顺利的完成。甚至还在对话和执行中，能纠正变量缺失、依赖包缺失的问题。

task2 = “analyze the above the results to list the application domains studied by these papers “

user_proxy**.initiate_chat(assistant, message=task2, clear_history=False**)

任务3：用图标展示分析数据：

task3 = “””Use this data to generate a bar chart of domains and number of papers in that domain and save to a file “””

user_proxy**.initiate_chat(assistant, message=task3, clear_history=False**)

more：Create Recipes 甚至可以把上面的任务，定义成模板，然后进行复用！ –因为涉及输入比较大，需要32k上下文模型

来自微软的AutoGen

Sun, 08 Oct 2023 09:44:08 +0800

https://microsoft.github.io/autogen/

AutoGen is a framework that enables development of LLM applications using multiple agents that can converse with each other to solve task. AutoGen agents are customizable, conversable, and seamlessly allow human participation. They can operate in various modes that employ combinations of LLMs, human inputs, and tools.
来自官方的简介：大概描述起来就是基于LLM模型，使用多角色互动来分解、解决问题的框架。目前已经出现了多个类似的，比如之前文章里面写过的MetaGPT

Main Features

AutoGen enables building next-gen LLM applications based on multi-agent conversations with minimal effort. It simplifies the orchestration, automation and optimization of a complex LLM workflow. It maximizes the performance of LLM models and overcome their weaknesses.
It supports diverse conversation patterns for complex workflows. With customizable and conversable agents, developers can use AutoGen to build a wide range of conversation patterns concerning conversation autonomy, the number of agents, and agent conversation topology.
It provides a collection of working systems with different complexities. These systems span a wide range of applications from various domains and complexities. They demonstrate how AutoGen can easily support different conversation patterns.
AutoGen provides a drop-in replacement of openai.Completion or openai.ChatCompletion as an enhanced inference API. It allows easy performance tuning, utilities like API unification & caching, and advanced usage patterns, such as error handling, multi-config inference, context programming etc.

The figure below shows the built-in agents in AutoGen.

MAC OS插电源也掉电找到原因了

Thu, 10 Aug 2023 12:27:55 +0800

应该是从2022年更新某个系统版本开始，经常发现插着电100%充满的 mbp，电池会掉到80%。我还一度怀疑电池有问题了。

优化充电方案类似新能源车电池管理方案，就是先充到80%，然后采用涓流充电模式，在电脑闲置时缓慢进行充电。

所以用户看到的是充到80%以后，同时又在使用电脑的情况下，似乎就停止充电了。实际上如果你一直插着外接电源，停止使用电脑的话，mac会慢慢充满到100%，只是从80%-100%的时间较长。

如果你想每次插上电源后都直接充满，可以把“电池优化充电”前的勾去掉。好处是你会有更多的时间拥有100%电量，坏处是长期这样，对于锂电池寿命不利。

如果保持“电池优化充电”选项，好处是电池寿命会有一定延长，坏处是如果着急的话，时常你的电脑只有80%电量。

“优化电池充电”功能的作用是延长电池使用寿命以及缩短 Mac 处于充满电状态的时间。启用这项功能后，在某些情况下，您的 Mac 将暂缓充电至 80% 以上。Mac 会学习您的日常充电习惯，目的是确保 Mac 在拔掉电源线时已充满电。

又是给Facebook这垃圾公司整的一周

Tue, 16 May 2023 09:40:52 +0800

借数字安全、隐私之名，行转嫁风险之实。对中小开发者提出一些不切实际的要求

每次tmd的才给几天时间来响应

【TED】TikTok的首席执行官谈其未来——以及是什么让其算法与众不同

Sat, 06 May 2023 09:54:09 +0800

TikTok’s CEO on its future — and what makes its algorithm different

摊牌了，让GPT给我做的文书日常

Sat, 06 May 2023 08:29:35 +0800

软件开发账号管理文档下载

软件开发账号管理文档

一、概述

在软件开发过程中，对代码库访问权限的管理是确保源代码安全与项目稳定发展的关键环节。本规范旨在为我们的开发者提供一个清晰的访问权限生命周期管理流程，涵盖访问权限的授予、审核和撤销程序，以减少潜在的安全风险。

二、访问权限生命周期管理

访问权限的申请与授予

开发者需要向项目负责人（或代码库管理员）提交访问权限申请，包含以下信息：

个人信息（姓名、团队、职责等）

访问权限级别（只读、读写等）

申请理由（需要访问的项目、任务等）

项目负责人（或代码库管理员）在收到申请后，根据实际情况进行评估，并在 1-3 个工作日内给出回复。

审批通过后，项目负责人（或代码库管理员）将为开发者分配相应的访问权限。

访问权限的审核与监控

项目负责人（或代码库管理员）需要定期（建议每季度）对开发者的访问权限进行审核，确保开发者的访问权限与其实际工作内容相符。

使用版本控制系统（如 Git）的审计日志功能，跟踪开发者在代码库中的活动，确保访问权限被合理使用。

对于潜在的滥用访问权限的行为，项目负责人（或代码库管理员）有权对开发者进行警告或撤销其访问权限。

项目负责人（或代码库管理员）需要定期（建议每季度）对开发者的访问权限进行审核，确保开发者的访问权限与其实际工作内容相符。

使用版本控制系统（如 Git）的审计日志功能，跟踪开发者在代码库中的活动，确保访问权限被合理使用。

对于连续 90 天未访问代码库的开发者，项目负责人（或代码库管理员）应考虑撤销或降低其访问权限。

访问权限的撤销

开发者离职、调岗或项目结束等情况下，项目负责人（或代码库管理员）需要及时撤销其对代码库的访问权限。

在审核过程中发现开发者不再需要访问特定代码库时，项目负责人（或代码库管理员）应与开发者协商后撤销其访问权限。

如发现开发者滥用访问权限或存在严重安全风险，项目负责人（或代码库管理员）有权立即撤销开发者的访问权限，并进行必要的安全审查。

三、建议与注意事项

为确保代码库的安全，建议使用基于角色的访问控制（RBAC）策略，对不同角色的开发者分配不同级别的访问权限。

审核过程中，密切关注权限过度分配的情况，避免不必要的安全风险。

建议开发者遵循最低权限原则，按需申请访问权限。

本规范旨在为开发团队提供一个安全、高效的代码库访问权限管理流程。通过遵循这些规范，我们可以确保源代码安全，并降低访问权限管理带来的潜在风险。

测试报告：数据泄露发现与处理-2022.11 下载

测试报告：数据泄露发现与处理 2022.11

测试报告：数据泄露发现与处理

一、背景

本次测试主要专注于在使用 MyBatis 和 Druid 框架进行开发的项目中，发现和处理潜在的数据泄露问题。该项目涉及敏感信息，因此在保护数据安全方面需要引起特别关注。

二、测试目的

验证当前系统是否存在数据泄露的漏洞。
评估数据泄露漏洞发现与处理程序的有效性。
为今后进一步提高数据安全性提出改进措施。

三、测试范围

分析可能的数据泄露途径：用户认证、权限控制、数据接口、日志文件等。
检查和评估项目代码和配置文件中是否存在不安全实践。
使用自动化工具和手动测试方法对持久层和数据层进行安全扫描。
对处理数据泄露的程序进行仿真测试。

四、测试步骤

使用安全扫描工具执行自动化测试。
对代码和配置文件进行手动审查。
使用代理工具（如 Burp Suite）来分析数据接口，并分析可能的数据泄露风险。
检查日志文件是否存储了敏感信息。
发现潜在的数据泄露风险后，及时通知开发团队进行修复，并要求重新测试。

五、测试结果与分析

通过安全扫描工具及代码审查，发现部分接口存在未授权访问的风险，但未发现明显的数据泄露。
日志文件存储了一些敏感信息（如用户密码），需要进一步的优化。
数据库连接配置存在一定的泄露风险，密码使用明文存储。
在发现数据泄露风险时及时通知开发团队，并得到迅速修复。

六、建议与改进

对于存在未授权访问风险的接口，需要加强权限控制，提高访问限制。
优化日志记录方式，避免记录敏感信息，同时定期对日志文件进行审计，确保安全。
对于数据库连接配置，采用加密算法对密码进行加密，防止泄露风险。
强化开发团队的安全意识，定期进行安全培训，提高安全开发能力。

七、总结

通过本次测试和分析，我们发现项目中存在一定的数据泄露风险，部分问题已经得到timely修复。虽然未发现明显的数据泄露，但仍需要在开发和运维过程中注意安全防护措施。针对本次测试发现的问题，我们提出了相关的改进措施，以降低数据泄露的可能性，提高项目的安全性。同时，这次测试也为我们积累了丰富的经验，将有助于我们在以后的项目中更好地防范数据泄露风险。

安全事故应对计划2023 下载

安全事故应对计划

目标

本计划旨在确保在发生安全事故时能够迅速、有效地进行应对，减轻事故给公司造成的损失。本计划包括以下内容：(1)角色和责任分配；(2)事故侦测；(3)根据法律义务采取反应步骤和恢复；(4)事故后审查过程。

角色和责任

为有效应对安全事故，公司设立应急响应小组，成员包括：

应急响应负责人：负责安全事故的总体及时响应，制定并组织执行应急计划。
技术团队：负责安全事故的调查、分析和技术措施的实施。
法务团队：负责处理与事故相关的法律问题，向监管机构或数据主体发出数据泄漏通知。
公关团队：负责协助法务团队完成通知工作，媒体发布和客户沟通。

事故侦测

公司将定期对网络、服务器和应用系统进行安全检查，发现异常及时报告。一旦发现系统出现安全事故征兆，应急响应负责人将立即启动应急响应机制，技术团队负责收集证据、分析问题、寻找漏洞并及时修复。

事故侦测是安全事故应对计划的核心环节，需要实时监控系统及网络活动，以便尽早发现潜在的安全事故。以下是事故侦测的细节：

定期安全检查与审计：定期对网络、服务器、应用程序和数据库等进行安全检查，检查项目包括漏洞扫描、入侵检测、访问控制、日志审计等。
安装和配置安全监控工具：部署如防火墙、入侵检测系统（IDS）、安全信息与事件管理（SIEM）系统等工具，实时监控网络活动及异常行为。确保这些工具能够自动更新，以应对不断变化的安全威胁。
日志管理：收集并整理网络设备、服务器、应用程序等相关日志，便于在发生安全事故时全面分析异常活动。
实时告警机制：在系统出现异常事件时，提供实时告警功能，以便迅速启动应急响应流程。告警方式可包括邮件、短信、电话、应用通知等。
定期安全培训：提高员工信息安全意识，定期进行安全培训，帮助员工识别潜在的安全风险，如钓鱼邮件、恶意软件等。
信息分享和情报获取：关注国内外安全形势变化，及时获取相关安全情报和漏洞预警，做好风险评估和应对措施。
在事故侦测阶段，重要的是建立全面的安全检测体系，包括人、机、制度三个方面。预防为主，及时发现异常情况，迅速启动应急响应计划，减轻事故对企业带来的损失。同时，通过事故后的审查和总结，不断完善安全监控体系，提高事故侦测能力。

法律义务的反应步骤和恢复

根据适用法律法规，公司在发生安全事故后将采取以下措施：

必要时，及时向监管机构报告安全事故。

向受影响的数据主体发出数据泄漏通知，告知事故原因、影响范围、应急措施及补救建议等。

评估事故损失，采取必要恢复措施，制定改进计划。

依法承担相应法律责任。

事故后审查过程

安全事故后，应急响应小组需进行事故总结，组织相关人员开展事故审查：

总结事故发生、演变过程。
评估事故应对措施的有效性。
根据审查结果，修订完善应急计划，提升安全防护水平。
对有责任的人员依规处理，防止类似事件再次发生。
及时向上级和相关部门汇报审查结果和改进措施。

通过整个事故应对计划的执行，公司能在遇到安全事故时迅速作出应对，降低事故对公司造成的损失。同时，通过事故后的审查和总结，不断完善公司的安全防护体系，提高公司整体安全水平。

【摘录】【Stable Diffusion】之原理篇

Thu, 04 May 2023 18:03:22 +0800

【Stable Diffusion】之原理篇
https://zhuanlan.zhihu.com/p/618862789

前言

一、扩散模型的组成

1、图像信息生成器

2、图像解码器

二、什么是扩散（Diffusion）？

三、扩散是如何工作的？

四、如何通过去噪声来绘制图像？

五、速度提升：在压缩(潜在)数据上扩散而非在像素数据上

六、文本编码器：一个 Transformer 语言模型

七、CLIP如何训练？

八、将文本信息喂给图像生成过程

九、Unet 噪声预测器的隐层（不包括文本）

十、带有文本的 Unet 噪声预测器隐层

总结

AI 图像生成技术是近期以来最震撼人心的 AI 能力。通过文本描述生成生动图像所体现的能力，具有一种神奇的特质，并且清晰地指明人类艺术创作的转变方向。稳定扩散模型的推出是在此发展过程中的一个明确里程碑，其对大众提供了高性能的模型能力（不止于图像质量、速度、相对低资源/内存需求）。

扩散模型的组成

扩散模型是一个系统，由几个组件和模型构成，而非单独一个模型。当我们关注底层原理时，首先注意到的是有一个“文本理解组件”也就是文本编码器，它将“文本信息”转变成“数字化描述”，从而让AI能够捕捉到文本中的含义。

我们可以说这个文本编码器是一个特殊的Transformer语言模型（技术：CLIP模型的文本编码器）。它接收文本做输入，然后输出数组表示每个词/表征（每个表征都是一个向量）。然后这些信息被提供给由一堆组件构成的“图像生成器”。

这里的图像生成历经下面两个过程：

1、图像信息生成器

这个组件是扩散模型的秘密武器，它是该模型远超之前模型的价值所在。
这个组件分好几步来生成图像信息。Step 参数通常是 50 或者 100，在扩散模型的公开接口或者开放库中。图像信息生成器完全在图像信息空间（潜在空间）中工作。我们将在后续介绍其更多的意义。这一特性使得扩散模型比之前在像素空间工作的扩散模型要更快。用技术术语来说，这一组件由网格网络和调度算法组成。单词 diffusion 描述了这一组件中发生了什么。正是对信息一步一步的处理，使得高质量图像得以最终生成。

2、图像解码器

图像解码器通过前置信息生成器得到的信息来生成图像。它只在最后运行一次来生成最终的像素图像。

有了这些我们再来看组成SD扩散模型的3个主要组件

1）Clip Text 用于文本编码

输入：文本
输出：77 个表征向量，每个有 768 维度

2）网格网络+调度，逐渐处理/扩散信息到潜在（信息）空间。

输入：文本向量和起始多维数组（结构化的数字列表，也叫 Tensor）由噪声组成。
输出：处理后的信息数组

3）自编码解码器，绘出最后的图像，借助之前处理过的信息数组。

输入：处理过的信息数组（维度:（4，64，64））
输出：结果图像（维度:（3，512，512）分别是红 / 绿 / 蓝，宽，高）

二、什么是扩散（Diffusion）？

扩散发生于下图粉色组件“图像信息生成器”中。获取表达输入文本的表征向量，以及一个随机启动的图像信息数组，这一过程产生后续的图像解码器用来绘图的所需信息数组

AWS的IAM难用的像一坨shit

Fri, 28 Apr 2023 10:58:28 +0800

AWS 身份管理概述：用户 – AWS Identity and Access Management (amazon.com)

未分类 · AI Times

DeepSeek_V4_技术报告解读

DeepSeek-V4 技术报告解读

一、模型概览与定位

二、双版本规格对比

三、六大核心技术创新

1. 混合注意力机制（CSA + HCA）

2. DSA 稀疏注意力（DeepSeek Sparse Attention）

3. 流形约束超连接（mHC）

4. Muon 优化器

5. 训练与后训练 Pipeline

6. 长上下文效率优化

四、性能指标与评测结果

4.1 综合基准测试（V4-Pro-Max）

4.2 与头部闭源模型横向对比

4.3 代际提升（V4-Pro vs V3.2）

五、API 定价与商业部署

5.1 定价策略（每百万 tokens）

5.2 版本对比分析

5.3 接入与迁移

六、国产算力适配

七、开源生态与部署

八、战略与商业化动态

九、总结与评价

核心卖点

适用场景

与闭源模型差距

代码生成 Copilot 产品的应用和演进 | AICon

代码生成 Copilot 产品回顾

GitHub Copilot 的成功因素

字节跳动内部代码生成的探索历程

构建自研评测体系的重要性

如何科学地定义指标

A/B 测试的重要性

代码编辑推荐：代码补全的进化

代码编辑推荐的概念

数据构建和模型训练方法

进行中的优化

代码生成 Copilot 的未来展望

微软autogen-进一步使用2

来自微软的AutoGen

Main Features​

MAC OS插电源也掉电找到原因了

又是给Facebook这垃圾公司整的一周

【TED】TikTok的首席执行官谈其未来——以及是什么让其算法与众不同

摊牌了，让GPT给我做的文书日常

一、概述

二、访问权限生命周期管理

访问权限的申请与授予

访问权限的审核与监控

访问权限的撤销

三、建议与注意事项

安全事故应对计划

目标

角色和责任

事故侦测

法律义务的反应步骤和恢复

事故后审查过程

【摘录】【Stable Diffusion】之原理篇

扩散模型的组成

1、图像信息生成器

2、图像解码器

二、什么是扩散（Diffusion）？

AWS的IAM难用的像一坨shit

Main Features