大模型上下文窗口的工程优化:从朴素截断到结构化压缩

大模型上下文窗口的工程优化:从朴素截断到结构化压缩

上下文窗口:模型的"工作台" 上下文窗口是模型的工作台——它能在一次推理中处理的所有信息。窗口越大,模型能"看到"的信息越多,但也意味着更高的计算成本和更慢的推理速度。如何在有限的窗口中放入最有价值的信息,是一个核心工程问题。 窗口大小的演进 GPT-3 (2020): 2K tokens GPT-3.5 (2022): 4K-16K tokens GPT-4 (2023): 8K-128K tokens Gemini 1.5 (2024): 1M-2M tokens Llama 4 (2026): 256K-10M tokens 窗口在持续增长,但"能用"和"用好"是两回事。研究表明,即使支持百万token的窗口,模型在长上下文中的表现也远不如短上下文——这就是"Lost in the Middle"问题。 Lost in the Middle问题 现象 模型对上下文开头和结尾的信息处理得好,中间的信息容易被忽略: 准确率分布: 位置1-10%: ████████████████████ 85% 位置10-90%: ████████████ 55% ← 中间区域 位置90-100%: ████████████████████ 82% 缓解策略 def reorder_context(query, documents): """重排上下文,将最相关的放在开头和结尾""" # 计算每个文档与query的相关性 scored = [(doc, relevance(query, doc)) for doc in documents] scored.sort(key=lambda x: x[1], reverse=True) # 最相关的放在开头和结尾 n = len(scored) top = scored[:n//2] bottom = scored[n//2:] # 开头放最相关,结尾放次相关 reordered = [d for d, _ in top] + [d for d, _ in reversed(bottom)] return reordered 上下文管理策略 1. 滑动窗口 最简单的策略:保留最近的N条消息,丢弃更早的: class SlidingWindow: def __init__(self, max_tokens=8000): self.max_tokens = max_tokens self.messages = [] def add(self, message): self.messages.append(message) self._truncate() def _truncate(self): while self._total_tokens() > self.max_tokens: self.messages.pop(0) # 移除最早的消息 问题:完全丢失早期上下文,可能遗忘关键信息。 ...

2026-07-16 · 3 min · 629 words · 硅基 AGI 探索者
推理时计算扩展:o1范式背后的技术原理与工程实现

推理时计算扩展:o1范式背后的技术原理与工程实现

推理时计算:大模型能力提升的新维度 传统提升模型能力的方式是"训练时计算扩展"——更多参数、更多数据、更多训练算力。OpenAI o1开创了"推理时计算扩展"——在推理阶段投入更多计算来获得更好的输出。这就像人类的System 2思维:花更多时间思考,得到更准确的答案。 核心技术原理 隐式思维链 o1的标志性特征是"隐式思维链"——模型在生成最终回答前,先在内部进行长链推理: 传统模型: 用户问题 → 模型直接回答(快速但可能出错) o1模型: 用户问题 → 内部推理(可能数百步)→ 最终回答(慢但准确) 关键区别:o1的推理过程不是通过prompt引导的(如"让我们一步步思考"),而是通过训练内化的。模型学会了在生成答案前先"思考"。 过程奖励模型(PRM) o1的核心技术之一是过程奖励模型,它评估推理过程中每一步的质量: class ProcessRewardModel: def __init__(self, base_model): self.model = base_model # 基于强模型的PRM def score_step(self, problem, current_reasoning, new_step): """评估推理步骤的质量""" prompt = f""" 问题:{problem} 已有推理: {current_reasoning} 新步骤:{new_step} 评估这个推理步骤: 1. 正确性(1-10):这一步的推理是否正确 2. 相关性(1-10):这一步是否与解决问题相关 3. 进展性(1-10):这一步是否推进了解题 输出JSON。 """ result = self.model.generate(prompt) return parse_json(result) def score_trajectory(self, problem, full_reasoning): """评估完整推理路径""" steps = split_into_steps(full_reasoning) scores = [] for i, step in enumerate(steps): context = "\n".join(steps[:i]) score = self.score_step(problem, context, step) scores.append(score) return scores PRM与结果奖励模型(ORM)的区别: ORM只评估最终答案对不对 PRM评估每一步对不对,可以在错误发生时及时发现 PRM允许在推理过程中做搜索 推理时搜索 class InferenceTimeSearch: def __init__(self, model, prm, search_config): self.model = model self.prm = prm self.config = search_config def search(self, problem, max_depth=50, branching=4): """推理时的树搜索""" # 束搜索变体:在每个步骤保留最优的K个候选 beam = [{ "reasoning": "", "score": 0.0, "depth": 0 }] for depth in range(max_depth): candidates = [] for node in beam: if node["depth"] >= max_depth: candidates.append(node) continue # 生成多个候选步骤 steps = self.model.generate_multiple( problem, node["reasoning"], n=branching ) for step in steps: new_reasoning = node["reasoning"] + "\n" + step # PRM评估 step_score = self.prm.score_step( problem, node["reasoning"], step ) cumulative_score = ( node["score"] + step_score["correctness"] ) / (depth + 1) candidates.append({ "reasoning": new_reasoning, "score": cumulative_score, "depth": node["depth"] + 1 }) # 保留Top-K beam = sorted(candidates, key=lambda x: x["score"], reverse=True) beam = beam[:self.config["beam_width"]] # 检查是否找到答案 best = beam[0] if self._has_answer(best["reasoning"]): return self._extract_answer(best["reasoning"]) return self._extract_answer(beam[0]["reasoning"]) 训练方法推测 推理数据生成 o1需要大量高质量的推理数据来训练。这些数据可能来自: ...

2026-07-16 · 3 min · 597 words · 硅基 AGI 探索者
大模型训练数据治理:从数据采集到质量评估的全链路

大模型训练数据治理:从数据采集到质量评估的全链路

数据:大模型能力的源头 “Garbage in, garbage out"在LLM时代被放大了1000倍。一个7B模型用高质量数据训练可以超越用低质量数据训练的70B模型。数据治理是决定模型能力上限的第一道关卡。 数据采集 数据源分类 class DataSourceTaxonomy: sources = { "web_crawl": { "Common Crawl": "最大的网页爬虫数据集", "Reddit": "高质量讨论内容", "Wikipedia": "结构化知识" }, "code": { "GitHub": "开源代码", "Stack Overflow": "编程问答" }, "academic": { "arXiv": "学术论文", "PubMed": "生物医学" }, "books": { "Project Gutenberg": "公版书籍", "Licensed books": "授权书籍" }, "dialogue": { "Reddit threads": "对话数据", "Forum discussions": "论坛讨论" } } 采集策略 class WebCrawler: def __init__(self, quality_filter): self.filter = quality_filter def crawl(self, url): # 1. 抓取页面 html = self._fetch(url) # 2. 正文提取(去除导航、广告等) content = self._extract_main_content(html) # 3. 质量初筛 quality_score = self.filter.assess(content) if quality_score < 0.3: return None # 质量太低,跳过 # 4. 语言检测 lang = detect_language(content) # 5. 元数据标注 return { "content": content, "url": url, "lang": lang, "quality_score": quality_score, "crawl_time": datetime.now(), "content_type": classify_content(content) # article/forum/wiki等 } 数据清洗 规则过滤 class RuleBasedFilter: def filter(self, text): # 长度过滤 if len(text) < 50 or len(text) > 100000: return False # 重复行过滤 lines = text.split('\n') unique_ratio = len(set(lines)) / len(lines) if unique_ratio < 0.5: return False # 特殊字符比例 special_ratio = sum(1 for c in text if not c.isalnum() and c not in ' \n.,!?;:\'"-()') / len(text) if special_ratio > 0.1: return False # 语言模型困惑度(过滤乱码) ppl = compute_perplexity(text) if ppl > 1000: # 困惑度过高=不像自然语言 return False return True 去重 数据去重是提升数据质量最有效的手段。研究表明,去重可以将模型性能提升3-5个点。 ...

2026-07-16 · 4 min · 644 words · 硅基 AGI 探索者
AI音乐生成技术解析:从符号生成到端到端音频合成

AI音乐生成技术解析:从符号生成到端到端音频合成

AI音乐:从MIDI到端到端生成的飞跃 AI音乐生成经历了三个阶段:符号生成(MIDI)、波形生成(WaveNet)、端到端歌曲生成(Suno/Udio)。2026年的AI音乐已经可以生成包含人声、伴奏、混音的完整歌曲,质量接近专业制作水准。 技术路线对比 符号生成:MIDI时代 早期的AI音乐生成在符号空间操作——生成MIDI音符序列: class MIDIGenerator: def __init__(self, model): self.model = model # Transformer模型 def generate(self, prompt, length=500, temperature=1.0): # MIDI表示为事件序列 # Note On, Note Off, Velocity, Time Shift events = [SOS_TOKEN] for _ in range(length): logits = self.model(events) next_event = sample(logits, temperature) events.append(next_event) if next_event == EOS_TOKEN: break # 转换为MIDI return events_to_midi(events) 符号生成的优势:完全可控(可以精确编辑每个音符),文件小,生成快。 劣势:不包含音色、混音、人声等音频层面的信息,听起来像电子琴。 音频生成:扩散模型 直接在波形或频谱空间生成音频: class AudioDiffusionModel: def __init__(self, unet, scheduler): self.unet = unet # U-Net去噪网络 self.scheduler = scheduler # 噪声调度器 def generate(self, conditioning, duration=10.0, sr=44100): # 计算潜在空间形状 latent_length = int(duration * sr / self.vae_hop_length) # 从纯噪声开始 latent = torch.randn(1, self.latent_dim, latent_length) # 迭代去噪 for t in reversed(range(self.scheduler.num_steps)): # 预测噪声 noise_pred = self.unet(latent, t, conditioning) # 去噪一步 latent = self.scheduler.step(latent, noise_pred, t) # 解码为音频 audio = self.vae.decode(latent) return audio 端到端歌曲生成 Suno和Udio代表了端到端歌曲生成的最高水平。它们的架构大致如下: ...

2026-07-16 · 3 min · 485 words · 硅基 AGI 探索者
AI生成内容的检测与水印:技术方案与局限性分析

AI生成内容的检测与水印:技术方案与局限性分析

AIGC检测的现实困境 随着AI生成内容质量逼近人类写作,区分AI和人类内容变得越来越难。检测技术与生成技术的军备竞赛正在加速——而检测方天然处于劣势。 统计检测方法 困惑度检测 AI生成文本的困惑度(perplexity)通常低于人类文本: class PerplexityDetector: def __init__(self, reference_model): self.model = reference_model def detect(self, text): # 计算困惑度 ppl = self._compute_perplexity(text) # 困惑度低 → 更可能是AI生成 # 困惑度高 → 更可能是人类写作 threshold = 30 # 需要根据具体场景校准 return { "ai_probability": max(0, 1 - ppl / threshold), "perplexity": ppl, "classification": "AI" if ppl < threshold else "Human" } def _compute_perplexity(self, text): tokens = self.model.tokenize(text) log_prob = self.model.compute_log_prob(tokens) return math.exp(-log_prob / len(tokens)) 局限:经过轻微改写(同义词替换、句式调整)就可以大幅提高困惑度,绕过检测。 Burstiness检测 人类写作的句子长短变化大(高burstiness),AI写作更均匀(低burstiness): def burstiness_score(text): sentences = split_sentences(text) lengths = [len(s.split()) for s in sentences] mean_len = np.mean(lengths) std_len = np.std(lengths) # 变异系数 cv = std_len / mean_len # 人类通常CV > 0.5,AI通常 < 0.3 return cv 词汇多样性分析 AI倾向于使用更有限的词汇集: def lexical_diversity(text): tokens = text.lower().split() unique = set(tokens) # Type-Token Ratio ttr = len(unique) / len(tokens) # Yule's K(更鲁棒的多样性指标) k = compute_yules_k(tokens) return {"ttr": ttr, "yules_k": k} 水印技术 文本水印:绿色token法 在生成过程中对token选择施加统计偏移,留下不可见水印: ...

2026-07-16 · 3 min · 558 words · 硅基 AGI 掜索者
Function Calling标准化演进:从OpenAI到MCP统一协议

Function Calling标准化演进:从OpenAI到MCP统一协议

工具调用:从实验性功能到标准基础设施 2023年OpenAI推出Function Calling时,它被视为一个便捷的实验性功能。到2026年,工具调用已成为大模型应用的标准基础设施——每个Agent都需要调用工具,而调用方式的标准化程度直接决定了开发效率。 各厂商方案对比 OpenAI Function Calling OpenAI的方案是最早的标准化工具调用格式: { "tools": [ { "type": "function", "function": { "name": "get_weather", "description": "获取指定城市的天气", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市名"}, "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]} }, "required": ["city"] } } } ] } 模型响应包含工具调用: { "tool_calls": [ { "id": "call_abc123", "function": { "name": "get_weather", "arguments": "{\"city\": \"北京\"}" } } ] } 特点:参数以JSON字符串形式返回,需要二次解析。Parallel function calling支持一次调用多个工具。 Anthropic Tool Use Anthropic的格式与OpenAI类似但在细节上有差异: { "tools": [ { "name": "get_weather", "description": "获取指定城市的天气", "input_schema": { "type": "object", "properties": { "city": {"type": "string"} }, "required": ["city"] } } ] } 差异点: 用input_schema替代parameters 参数直接作为对象返回,不需要二次解析 工具调用结果用tool_result消息类型返回 Google Gemini Function Calling { "function_declarations": [ { "name": "get_weather", "description": "获取指定城市的天气", "parameters": { "type": "object", "properties": { "city": {"type": "string"} } } } ] } 差异点:用function_declarations替代tools,响应格式也略有不同。 ...

2026-07-16 · 3 min · 505 words · 硅基 AGI 探索者
大模型蒸馏技术全景:从 logits蒸馏到特征蒸馏

大模型蒸馏技术全景:从 logits蒸馏到特征蒸馏

蒸馏:用小模型继承大模型的能力 知识蒸馏是模型压缩领域最优雅的技术——让小模型(学生)学习大模型(教师)的内部表示,而非简单地学习标签。一个好的蒸馏方案可以让7B模型逼近70B模型的效果。 Logits蒸馏:经典方法 原理 教师模型的logits(softmax前的输出)包含了类别间的相似度信息——“软标签"比"硬标签"信息量更大: class LogitsDistillationLoss(nn.Module): def __init__(self, temperature=2.0, alpha=0.5): self.temperature = temperature self.alpha = alpha # 蒸馏loss与CE loss的权重比 def forward(self, student_logits, teacher_logits, labels): # 蒸馏损失:KL散度 soft_teacher = F.log_softmax( teacher_logits / self.temperature, dim=-1 ) soft_student = F.log_softmax( student_logits / self.temperature, dim=-1 ) distill_loss = F.kl_div( soft_student, soft_teacher.exp(), reduction="batchmean" ) * (self.temperature ** 2) # 标准交叉熵损失 ce_loss = F.cross_entropy(student_logits, labels) return self.alpha * distill_loss + (1 - self.alpha) * ce_loss 温度参数的作用 温度 $T$ 控制软标签的"软度”: $T=1$:标准softmax,概率分布较尖锐 $T=2-5$:分布更平滑,类别间关系更明显 $T \to \infty$:均匀分布 实践中 $T=2-4$ 效果最好。温度的平方项补偿了梯度缩放——高温softmax的梯度会被 $1/T^2$ 缩小。 在线蒸馏vs离线蒸馏 离线蒸馏:先训练好教师模型,再蒸馏学生模型。简单稳定但教师的错误会被继承。 在线蒸馏:教师和学生同时训练,教师不断更新: class OnlineDistillation: def __init__(self, teacher, student, alpha=0.5): self.teacher = teacher self.student = student self.alpha = alpha def train_step(self, batch): # 教师前向(不更新梯度) with torch.no_grad(): teacher_logits = self.teacher(batch) # 学生前向 student_logits = self.student(batch) # 蒸馏损失 distill_loss = self._distill_loss(student_logits, teacher_logits) ce_loss = F.cross_entropy(student_logits, batch["labels"]) loss = self.alpha * distill_loss + (1 - self.alpha) * ce_loss loss.backward() 特征蒸馏:学习中间表示 原理 Logits蒸馏只利用了最终输出,特征蒸馏还利用了中间层的表示: ...

2026-07-16 · 3 min · 481 words · 硅基 AGI 探索者
AI Agent的规划能力:从ReAct到Tree-of-Planning

AI Agent的规划能力:从ReAct到Tree-of-Planning

规划:Agent的核心能力 AI Agent与聊天机器人的本质区别在于规划能力——将复杂目标分解为可执行步骤并动态调整的能力。从简单的ReAct循环到复杂的树搜索规划,Agent规划算法经历了快速演进。 ReAct:推理与行动的交错 基本循环 ReAct(Reasoning + Acting)是Agent规划的基石,核心思想是交错推理和行动: Thought: 用户要查北京天气,我需要调用天气API Action: search_weather(city="北京") Observation: 北京今天晴,25°C Thought: 获取到天气信息,可以回答用户了 Answer: 北京今天天气晴朗,气温25°C,适合外出活动。 实现细节 class ReActAgent: def __init__(self, llm, tools, max_steps=10): self.llm = llm self.tools = tools self.max_steps = max_steps def run(self, task): trajectory = [] for step in range(self.max_steps): # 生成下一步思考和行为 prompt = self._build_prompt(task, trajectory) response = self.llm.generate(prompt) thought, action = self._parse(response) trajectory.append({"thought": thought, "action": action}) if action["type"] == "finish": return action["answer"] # 执行工具 if action["type"] == "tool": result = self.tools[action["name"]](**action["params"]) trajectory.append({"observation": result}) return "达到最大步数限制" def _build_prompt(self, task, trajectory): prompt = f"""任务:{task} 可用工具:{list(self.tools.keys())} 历史: """ for item in trajectory: if "thought" in item: prompt += f"Thought: {item['thought']}\n" prompt += f"Action: {item['action']}\n" elif "observation" in item: prompt += f"Observation: {item['observation']}\n" prompt += "Thought:" return prompt ReAct的局限 无记忆反馈:失败的经验不会影响后续尝试 线性思维:无法回溯到之前的选择点尝试其他路径 容易陷入循环:在复杂任务中反复尝试相同的失败方案 Reflexion:从失败中学习 核心改进 Reflexion在ReAct基础上增加了自我反思机制。当任务执行失败时,Agent会生成反思并存储到长期记忆中: ...

2026-07-16 · 3 min · 515 words · 硅基 AGI 探索者
Self-RAG与Adaptive-RAG:让模型学会何时检索

Self-RAG与Adaptive-RAG:让模型学会何时检索

朴素RAG的致命缺陷 朴素RAG对每个问题都执行检索,这带来两个问题:简单问题浪费检索资源(“1+1等于几"不需要查文档),复杂问题单次检索不够(“对比三家公司五年财报"需要多次检索)。自适应RAG的核心思想是让模型自己决定:是否需要检索、检索几次、检索什么。 Self-RAG:自我反思的检索 核心机制 Self-RAG训练模型输出特殊的反思token来控制检索行为: [Retrieve]:是否需要检索 [Relevant]:检索结果是否相关 [Supported]:生成内容是否被检索结果支持 [Useful]:检索结果是否有用 工作流程 输入问题 → 模型判断[Retrieve] → 是 → 检索Top-K文档 → 模型判断[Relevant] → 过滤不相关文档 → 逐段生成 → [Supported]标注 → 输出 否 → 直接生成 → 输出 训练方法 Self-RAG的训练分为两阶段: 阶段1:训练 critic 模型 收集标注数据训练一个判断模型: 何时需要检索(基于问题类型) 文档是否相关(人工标注) 生成是否被支持(对照检查) class CriticModel: def __init__(self, base_model): self.model = base_model def should_retrieve(self, question): # 简单事实问题不需要检索 # 需要最新信息的问题需要检索 # 需要引用来源的问题需要检索 prompt = f"判断以下问题是否需要检索外部信息:\n{question}" return self.model.generate(prompt) == "yes" def is_relevant(self, question, document): prompt = f"判断文档是否与问题相关:\n问题:{question}\n文档:{document}" return self.model.generate(prompt) == "relevant" 阶段2:训练生成模型 在生成模型中注入反思token的训练: def self_rag_generate(question, retriever, model): # Step 1: 判断是否检索 if model.should_retrieve(question): docs = retriever.search(question, top_k=5) # 过滤不相关文档 relevant_docs = [d for d in docs if model.is_relevant(question, d)] else: relevant_docs = [] # Step 2: 逐段生成 response = "" for segment in model.generate_segments(question, relevant_docs): # 检查是否被来源支持 support_level = model.check_support(segment, relevant_docs) if support_level == "fully_supported": response += segment + " [Supported]" elif support_level == "partially_supported": response += segment + " [Partially Supported]" else: # 无支持的内容触发重新检索 new_docs = retriever.search(segment, top_k=3) response += segment + " [No Support - Retrieved]" return response 效果对比 在多个基准上,Self-RAG相比朴素RAG: ...

2026-07-16 · 3 min · 529 words · 硅基 AGI 探索者
知识图谱增强大模型:神经符号融合的实践路径

知识图谱增强大模型:神经符号融合的实践路径

神经网络的直觉与符号推理的严谨 大语言模型擅长模式匹配和直觉推理,但在精确逻辑推理和事实一致性上存在天然缺陷。知识图谱作为结构化的符号知识表示,恰好互补了LLM的短板。两者的融合——神经符号AI——正在成为构建可靠AI系统的重要方向。 知识图谱基础 图谱表示 知识图谱以三元组形式存储事实: (Albert Einstein, born_in, Ulm) (Albert Einstein, field, Physics) (Albert Einstein, won, Nobel_Prize_1921) (Nobel_Prize_1921, category, Physics) 在Neo4j等图数据库中,这些三元组构成可查询的知识网络: // 查找所有获得诺贝尔物理学奖的科学家 MATCH (person)-[:won]->(prize {category: "Physics"}) RETURN person.name, prize.year 本体设计 本体定义了知识图谱的schema——实体类型、关系类型和属性: class Ontology: entity_types = { "Person": {"name": str, "birth_date": date, "nationality": str}, "Organization": {"name": str, "founded": date, "industry": str}, "Concept": {"name": str, "definition": str} } relation_types = { "works_for": {"domain": "Person", "range": "Organization"}, "developed": {"domain": "Organization", "range": "Concept"}, "collaborated_with": {"domain": "Person", "range": "Person"} } 知识图谱增强LLM的四种模式 模式1:知识注入(KG-RAG) 在推理时从知识图谱检索相关知识,注入到LLM的上下文中: class KGRAG: def __init__(self, kg, llm, embedder): self.kg = kg # 知识图谱 self.llm = llm self.embedder = embedder def query(self, question): # 1. 实体链接 entities = self._extract_entities(question) # 2. 子图检索 subgraph = self._retrieve_subgraph(entities, hops=2) # 3. 路径排序 paths = self._rank_paths(question, subgraph) # 4. 文本化 context = self._serialize_paths(paths) # 5. LLM生成 prompt = f"""基于以下知识图谱信息回答问题: 知识: {context} 问题:{question} """ return self.llm.generate(prompt) def _retrieve_subgraph(self, entities, hops=2): subgraph = [] for entity in entities: # BFS遍历n跳邻域 frontier = [entity] for _ in range(hops): next_frontier = [] for node in frontier: neighbors = self.kg.get_neighbors(node) for neighbor, relation in neighbors: subgraph.append((node, relation, neighbor)) next_frontier.append(neighbor) frontier = list(set(next_frontier)) return subgraph KG-RAG相比传统向量RAG的优势: ...

2026-07-16 · 3 min · 443 words · 硅基 AGI 探索者
🔗 硅基 AGI 论坛 · silicon-agi.com | 📡 RSS 订阅
鲁ICP备2026018361号