Posts

常识：AI最难的问题 GPT-6能解决数学奥赛题，却可能在一个简单的物理常识问题上犯错。这种"高智能、低常识"的矛盾是当前AI最大的谜题之一。 2026年，尽管AI在各种专业测试中超越人类，常识理解仍然是AI的"阿喀琉斯之踵"。 什么是常识？ 常识的定义 常识是关于日常世界的基本知识，包括： 物理常识： 物体不能穿透彼此 重物比轻物落得快（实际上不对，但直觉如此） 液体会流动并适应容器形状 热的东西摸了会疼 社会常识： 在图书馆不能大声说话 别人帮助你后应该说"谢谢" 不能随便拿别人的东西 时间常识： 昨天的事不会明天发生 做事情需要时间，不能瞬间完成 数量常识： 100个苹果比5个苹果多 一个房间不能装下一百万个人 常识为什么难 常识之所以被称为"AI最难的问题"，有几个原因： 隐含性：常识很少被明确表述——人们不会写"杯子掉在地上会碎"这样的句子 无限性：常识的覆盖范围几乎是无限的 模糊性：很多常识不是绝对的——“重物落得快"在某些情况下不对 依赖性：常识依赖于文化和环境 ** grounding问题**：文本中的"常识"描述与真实世界的体验是不同的 LLM的常识缺陷 典型错误 尽管GPT-6等模型在大多数常识测试上表现不错，但在"分布外"的常识问题上仍然会犯令人惊讶的错误： 错误1：物理推理 问：“如果把一个西瓜放在桌子上，然后用锤子敲它，会怎样？” GPT-6回答：“西瓜可能会变形。"（实际上会碎裂） 错误2：空间推理 问：“一个球从楼上掉下来，会怎样？” GPT-6有时回答：“球会向上飞。"（如果训练数据中有"球飞起来"的描述） 错误3：因果推理 问：“为什么不能把大象放进冰箱？” GPT-6回答：“因为冰箱太小。"（部分正确，但忽略了重量、门能否打开等常识） 错误4：社会常识 问：“在葬礼上讲笑话合适吗？” GPT-6回答：“这取决于笑话是否好笑。"（忽略了社交场合的敏感性） 为什么LLM缺乏常识 1. 文本vs体验 人类通过物理交互学习常识——推门知道门会开、碰热水知道烫。LLM只从文本中学习，缺乏这种"具身体验”。 LeCun的"芝士蛋糕"比喻：你不能通过阅读菜单来品尝蛋糕的味道。同样，你不能通过阅读文本来真正理解物理世界。 2. 统计vs因果 LLM学习的是统计相关性，不是因果关系。它"知道"雨伞和雨经常一起出现，但不理解"因为下雨所以打伞"的因果关系。 3. 长尾问题 常识的覆盖面无限大。即使训练数据中包含了99%的常识场景，剩余1%的长尾场景仍然会导致错误。 4. 缺乏世界模型 LLM没有内部的世界模型——它不理解物理世界的运行规则，只是模仿了描述世界的语言。 2026年的进展 1. 常识基准测试 2026年出现了更严格的常识测试： CORE-Bench（Commonsense Reasoning Evaluation）： 10,000个日常常识问题 需要物理推理、社会推理、因果推理 GPT-6得分：76.3% 人类得分：97.8% 差距仍然显著。 ...

引言 传统RAG是"一刀切"的——每次查询都检索，每次检索都使用相同的策略。但不是所有问题都需要检索（“1+1等于几”），不同问题需要不同的检索策略。 Self-RAG的核心思想是：让模型自己决定是否需要检索、检索什么、检索结果是否相关、是否需要再次检索。这种"自我反思"的能力让RAG系统更加智能和高效。 一、Self-RAG原理 1.1 反思令牌 Self-RAG引入了"反思令牌"（Reflection Tokens），让模型在生成过程中输出特定的控制信号： [Retrieve] - 是否需要检索？ [IsRel] - 检索结果是否相关？ [IsSup] - 生成是否被检索结果支持？ [IsUse] - 生成是否有用？ 1.2 工作流程 用户问题 ↓ 模型判断 [Retrieve]? → No → 直接生成 → Yes → 执行检索 ↓ 评估每个文档 [IsRel]? → 过滤不相关 ↓ 基于相关文档生成 ↓ 评估生成 [IsSup]? → No → 重新生成 → Yes → 评估 [IsUse]? ↓ 输出最终答案 二、实现 2.1 基本框架 class SelfRAG: def __init__(self, llm, retriever): self.llm = llm self.retriever = retriever async def generate(self, question): # 1. 判断是否需要检索 need_retrieve = await self.predict_retrieve_token(question) if not need_retrieve: # 不需要检索，直接生成 answer = await self.llm.generate(question) return {"answer": answer, "retrieved": False} # 2. 执行检索 docs = await self.retriever.search(question, top_k=5) # 3. 评估每个文档的相关性 relevant_docs = [] for doc in docs: is_rel = await self.predict_isrel_token(question, doc) if is_rel: relevant_docs.append(doc) if not relevant_docs: # 没有相关文档，直接生成 answer = await self.llm.generate(question) return {"answer": answer, "retrieved": True, "relevant": 0} # 4. 基于相关文档生成多个候选 candidates = [] for doc in relevant_docs: candidate = await self.llm.generate( f"基于以下信息回答问题:\n{doc.text}\n\n问题: {question}" ) # 5. 评估每个候选是否被文档支持 is_sup = await self.predict_issup_token(candidate, doc) # 6. 评估是否有用 is_use = await self.predict_isuse_token(question, candidate) candidates.append({ "answer": candidate, "support_score": is_sup, "usefulness_score": is_use, "source_doc": doc }) # 7. 选择最佳候选 best = max(candidates, key=lambda x: x["support_score"] * x["usefulness_score"]) return { "answer": best["answer"], "retrieved": True, "relevant_docs": len(relevant_docs), "source": best["source_doc"] } 2.2 反思令牌预测 class ReflectionTokenPredictor: def __init__(self, llm): self.llm = llm async def predict_retrieve(self, question): """预测是否需要检索""" prompt = f""" 问题: {question} 这个问题是否需要查阅外部资料才能准确回答？ 考虑: - 问题是否涉及事实性知识？ - 你的训练数据中是否有足够的知识？ - 问题是否涉及最新信息？ 输出: "RETRIEVE" 或 "NO_RETRIEVE" """ result = await self.llm.call(prompt) return "RETRIEVE" in result async def predict_isrel(self, question, document): """预测文档是否与问题相关""" prompt = f""" 问题: {question} 文档: {document.text[:500]} 这个文档是否包含回答问题所需的信息？ 输出: "RELEVANT" 或 "IRRELEVANT" """ result = await self.llm.call(prompt) return "RELEVANT" in result async def predict_issup(self, answer, document): """预测答案是否被文档支持""" prompt = f""" 文档: {document.text[:500]} 答案: {answer} 答案中的所有陈述是否都能从文档中找到支持？ 输出: "FULLY_SUPPORTED" / "PARTIALLY_SUPPORTED" / "NOT_SUPPORTED" """ result = await self.llm.call(prompt) if "FULLY" in result: return 1.0 elif "PARTIALLY" in result: return 0.5 else: return 0.0 async def predict_isuse(self, question, answer): """预测答案是否有用""" prompt = f""" 问题: {question} 答案: {answer} 这个答案对提问者有多大帮助？（1-5分） """ result = await self.llm.call(prompt) return int(result.strip()) / 5.0 三、训练Self-RAG 3.1 训练数据构建 class SelfRAGTrainingDataBuilder: async def build_training_data(self, base_dataset): """构建Self-RAG训练数据""" training_samples = [] for sample in base_dataset: question = sample["question"] answer = sample["answer"] relevant_docs = sample.get("relevant_docs", []) # 1. 生成Retrieve标签 retrieve_label = "RETRIEVE" if relevant_docs else "NO_RETRIEVE" # 2. 生成IsRel标签 for doc in relevant_docs: isrel_label = "RELEVANT" training_samples.append({ "input": f"问题: {question}\n文档: {doc}", "label": isrel_label, "token_type": "IsRel" }) # 3. 生成IsSup标签 for doc in relevant_docs: issup_label = "FULLY_SUPPORTED" # 假设标准答案被文档支持 training_samples.append({ "input": f"文档: {doc}\n答案: {answer}", "label": issup_label, "token_type": "IsSup" }) # 4. 生成IsUse标签 isuse_label = "5" # 标准答案评为5分 training_samples.append({ "input": f"问题: {question}\n答案: {answer}", "label": isuse_label, "token_type": "IsUse" }) return training_samples 3.2 模型微调 class SelfRAGTrainer: def __init__(self, base_model): self.base_model = base_model async def train(self, training_data): """微调模型学习反思令牌预测""" # 1. 格式化训练数据 formatted = self.format_training_data(training_data) # 2. 微调 # 方式1: 在基础模型上微调（需要大量数据） # 方式2: 使用few-shot prompting（更实用） # 使用方式2 self.model = self.create_few_shot_model(formatted) def create_few_shot_model(self, training_data): """使用few-shot examples创建Self-RAG模型""" # 为每种反思令牌选择最好的示例 retrieve_examples = self.select_examples(training_data, "Retrieve", n=3) isrel_examples = self.select_examples(training_data, "IsRel", n=3) issup_examples = self.select_examples(training_data, "IsSup", n=3) isuse_examples = self.select_examples(training_data, "IsUse", n=3) system_prompt = f""" 你是一个Self-RAG助手。在回答问题时，你需要: 1. 首先判断是否需要检索外部资料: {self.format_examples(retrieve_examples)} 2. 如果检索，评估每个文档的相关性: {self.format_examples(isrel_examples)} 3. 评估答案是否被文档支持: {self.format_examples(issup_examples)} 4. 评估答案的有用程度: {self.format_examples(isuse_examples)} """ return FewShotModel(self.base_model, system_prompt) 四、生产实践 4.1 混合模式 class HybridSelfRAG: """Self-RAG与规则结合的混合模式""" async def generate(self, question): # 规则前置：某些类型的问题不需要检索 if self.is_simple_factual(question): return await self.llm.generate(question) if self.is_current_event(question): need_retrieve = True else: need_retrieve = await self.predict_retrieve(question) if need_retrieve: return await self.rag_generate(question) else: return await self.llm.generate(question) def is_simple_factual(self, question): """简单事实型问题""" simple_patterns = [ r"^\d+[\+\-\*/]\d+", # 数学计算 r"什么是.*定义", # 定义类 ] return any(re.match(p, question) for p in simple_patterns) def is_current_event(self, question): """时事类问题""" event_keywords = ["最新", "今天", "最近", "现在", "current", "latest"] return any(kw in question.lower() for kw in event_keywords) 4.2 成本优化 class CostAwareSelfRAG: """成本感知的Self-RAG""" def __init__(self): self.token_budget = 100000 # 每次会话的Token预算 self.token_used = 0 async def generate(self, question): # 估算检索+生成的Token消耗 retrieve_cost = 2000 # 检索+反思令牌的估算成本 direct_cost = 500 # 直接生成的估算成本 remaining_budget = self.token_budget - self.token_used if remaining_budget < direct_cost: # 预算不足，使用最省钱的模式 return await self.llm.generate(question) # 正常Self-RAG流程 need_retrieve = await self.predict_retrieve(question) if need_retrieve and remaining_budget > retrieve_cost: result = await self.rag_generate(question) self.token_used += retrieve_cost else: result = await self.llm.generate(question) self.token_used += direct_cost return result 五、评估 class SelfRAGEvaluator: async def evaluate(self, self_rag, test_cases): metrics = { "retrieve_accuracy": [], # 检索决策准确率 "relevance_accuracy": [], # 相关性判断准确率 "support_accuracy": [], # 支持度评估准确率 "answer_quality": [], # 答案质量 "efficiency": [] # 效率（Token消耗） } for case in test_cases: result = await self_rag.generate(case.question) # 检索决策是否正确 should_retrieve = bool(case.relevant_docs) actual_retrieve = result["retrieved"] metrics["retrieve_accuracy"].append(should_retrieve == actual_retrieve) # 答案质量 quality = await self.evaluate_answer(result["answer"], case.expected_answer) metrics["answer_quality"].append(quality) # 效率 metrics["efficiency"].append(result.get("tokens_used", 0)) return {k: np.mean(v) for k, v in metrics.items()} 结语 Self-RAG代表了RAG系统从"机械式"走向"反思式"的方向。不是每次都检索，不是每次都使用相同策略——而是根据问题特征动态调整。 ...

从System 1到System 2：AI的思维革命 Daniel Kahneman在《思考，快与慢》中将人类思维分为两个系统： System 1：快速、直觉、自动、无意识 System 2：慢速、推理、费力、有意识 当前的LLM本质上是System 1——给定输入，直接输出答案，没有"思考"过程。2026年最重要的AI研究趋势之一，就是让AI拥有System 2能力——在回答前"想一想"。 System 1的局限 1. 复杂推理错误 LLM在简单问题上表现出色，但在需要多步推理的复杂问题上容易出错： 简单数学：“2+3=?” → 正确 多步数学：“一个商店进货200件商品，以标价的8折卖出60%，剩余的以5折卖出，总利润率是多少？” → 经常出错 原因：LLM的推理是"一次性"的，没有检查和修正的机会。 2. 缺乏自我纠错 System 1的输出是"第一反应"，没有反思和纠错的过程。人类在做复杂题时会：先尝试一种方法→发现不对→换一种方法→验证结果。LLM缺乏这种迭代能力。 3. 无法处理"需要思考"的问题 有些问题不是"知识"问题，而是"思考"问题——需要在不同选项之间权衡、推理、决策。LLM在这类问题上表现不稳定。 2026年System 2的实现方式 1. 思维链（Chain-of-Thought）的进化 基础CoT在2022年就已出现。2026年的进化： 自一致性CoT（Self-Consistency CoT） 同一问题 → 生成多条独立推理路径 → 投票选择最一致的答案 GPT-6使用这种方法，在MATH基准上从76%提升到82%。 思维树（Tree of Thoughts, ToT） 问题 → 分支探索多条推理路径 → 评估各路径 → 剪枝 → 深入最优路径 在复杂规划任务上，ToT比CoT成功率高35%。 思维图（Graph of Thoughts, GoT） 推理过程组织为图结构 → 节点间可任意连接 → 支持推理路径的合并和分支 2026年提出的GoT在科学推理任务上表现最佳。 2. OpenAI o系列的"推理模型" OpenAI的o系列模型是System 2 AI的代表： ...

引言 在RAG系统中，向量检索负责从海量文档中快速召回候选结果，但召回结果的排序不一定准确。重排序（Reranking）作为第二步，对候选结果进行更精确的排序，将最相关的文档排在最前面。 2026年，重排序已经成为RAG系统的标配组件。一个好的重排序模型可以将RAG的准确率提升20-40%。本文将深入探讨重排序技术。 一、为什么需要重排序 1.1 向量检索的局限 向量检索使用双塔模型（Bi-encoder）：查询和文档分别编码，通过向量相似度排序。这种方式速度快，但精度有限——因为查询和文档的交互发生在最后的相似度计算阶段。 1.2 重排序的优势 重排序使用交叉编码器（Cross-encoder）：将查询和文档拼接在一起输入模型，模型可以充分理解查询和文档的关系。精度更高，但速度更慢。 向量检索: encode(query) · encode(doc) → similarity score (快，精度中等) 重排序: encode([query, doc]) → relevance score (慢，精度高) 1.3 两阶段架构 查询 → 向量检索（召回Top-100）→ 重排序（精排Top-10）→ 生成 向量检索负责"快而全"，重排序负责"准而精"。 二、重排序模型 2.1 交叉编码器 class CrossEncoderReranker: def __init__(self, model_name="cross-encoder/ms-marco-MiniLM-L-12-v2"): self.model = load_model(model_name) async def rerank(self, query, documents, top_k=10): # 1. 构建query-document对 pairs = [(query, doc.text) for doc in documents] # 2. 模型打分 scores = self.model.predict(pairs) # 3. 排序 ranked = sorted(zip(documents, scores), key=lambda x: -x[1]) return [doc for doc, score in ranked[:top_k]] 2.2 LLM重排序 class LLMReranker: def __init__(self, llm): self.llm = llm async def rerank(self, query, documents, top_k=10): # 方法1: 逐个打分 scores = [] for doc in documents: score = await self.score_document(query, doc) scores.append(score) # 方法2: 两两比较（更准确但更慢） # ranked = await self.pairwise_rank(query, documents) # 排序 ranked = sorted(zip(documents, scores), key=lambda x: -x[1]) return [doc for doc, score in ranked[:top_k]] async def score_document(self, query, document): """使用LLM对query-document对打分""" prompt = f""" 查询: {query} 文档: {document.text[:500]} 请评估文档与查询的相关性: 0 - 完全不相关 1 - 弱相关 2 - 部分相关 3 - 相关 4 - 高度相关 只输出数字。 """ result = await self.llm.call(prompt) return int(result.strip()) async def pairwise_rank(self, query, documents): """两两比较排序""" # 使用类似冒泡排序的方法 for i in range(len(documents)): for j in range(i+1, len(documents)): comparison = await self.compare(query, documents[i], documents[j]) if comparison == "B is better": documents[i], documents[j] = documents[j], documents[i] return documents 2.3 ColBERT ColBERT是一种延迟交互模型，介于双塔和交叉编码器之间： ...

AI的记忆困境 人类记忆是令人惊叹的——我们可以记住几十年前的事情，在不忘记旧知识的情况下学习新知识，在需要时灵活检索相关记忆。 AI的记忆远不如人类。当前LLM的"记忆"有三种形式，每种都有严重局限： 上下文窗口：容量有限（即使是10M的Claude 5也有上限），“忘记"上下文之外的信息 模型权重：训练后固定，不能更新（除非重新训练），存在"灾难性遗忘” 外部数据库（RAG）：检索不精确，无法进行记忆"整合"和"推理" 人脑的记忆系统 人脑有多个记忆系统，各有不同功能： 感觉记忆（<1秒） 短暂保留感官信息，如视觉的"后像"。 短期记忆（30秒-几分钟） 临时存储当前任务相关信息，容量有限（7±2项）。 长期记忆 情景记忆：具体事件的记忆（“昨天在咖啡馆见了朋友”） 语义记忆：一般知识的记忆（“巴黎是法国首都”） 程序记忆：技能和习惯（“骑自行车”） 工作记忆 在短期记忆的基础上进行推理和操作，是人脑的"工作台"。 终身记忆 通过巩固和整合，人脑可以保持终身记忆，并从中提取抽象知识。 AI记忆的层次化架构 第一层：上下文记忆（已有） 当前LLM的上下文窗口。相当于人脑的"感觉记忆+短期记忆"。 2026年的进步：Claude 5的10M上下文窗口已经可以处理完整书籍或代码库，但仍无法处理"一生的经历"。 第二层：工作记忆（发展中） LLM在推理过程中使用的"草稿纸"。相当于人脑的"工作记忆"。 2026年的实现方式： 思维链（CoT）：LLM在回答前的推理过程 思维树（ToT）：多条推理路径的并行探索 外部工作区：LLM在推理过程中"写出"中间结果 class WorkingMemory: def __init__(self): self.facts = [] # 已知事实 self.hypotheses = [] # 假设 self.derivations = [] # 推导结果 def add(self, item, type): if type == "fact": self.facts.append(item) elif type == "hypothesis": self.hypotheses.append(item) # ... def retrieve(self, query, top_k=5): # 基于相关性检索 all_items = self.facts + self.hypotheses + self.derivations return semantic_search(query, all_items, top_k) 第三层：情景记忆（发展中） AI对具体交互事件的记忆。相当于人脑的"情景记忆"。 2026年的实现： 对话历史：保存与用户的交互记录 会话摘要：将长对话压缩为关键信息 时间索引：按时间检索记忆 ChatGPT的记忆功能是情景记忆的初步实现——它能记住用户在之前对话中提到的偏好。但功能有限且不可靠。 第四层：语义记忆（部分实现） AI的一般知识库。相当于人脑的"语义记忆"。 2026年的实现： 模型权重：训练数据中的知识被"存储"在权重中 知识图谱：结构化的知识表示 向量数据库：RAG系统的基础 挑战：如何在不重新训练的情况下更新语义记忆？这是"持续学习"的核心问题。 第五层：终身记忆（未实现） AI能够在其整个"生命周期"中持续积累和整合记忆。这是AI记忆架构的终极目标。 ...

引言 RAG系统的第一步是将文档分块（Chunking）。这个看似简单的步骤，实际上对RAG质量有巨大影响——分块太大，检索不精确；分块太小，丢失上下文。 2026年，分块策略已经从简单的"按字数切分"发展出多种智能策略。本文将系统对比这些策略。 一、为什么分块很重要 1.1 检索精度 文档: "Python是一种解释型语言。它由Guido van Rossum于1991年创建。Python强调代码可读性..." 分块A（太大大）: 整个文档作为一个块 → 检索时可能返回很多不相关的内容 分块B（太小）: "Python是一种解释型语言。" → 缺少上下文，不知道在说什么 分块C（合适）: "Python是一种解释型语言。它由Guido van Rossum于1991年创建。" → 信息完整且精确 1.2 上下文完整性 好的分块应该保持语义完整性——一个块应该表达一个完整的意思。 1.3 检索效率 块的大小直接影响向量索引的大小和检索速度。 二、分块策略分类 2.1 固定大小分块 class FixedSizeChunker: def __init__(self, chunk_size=500, overlap=50): self.chunk_size = chunk_size # 字符数或token数 self.overlap = overlap def chunk(self, text): chunks = [] start = 0 while start < len(text): end = start + self.chunk_size chunk = text[start:end] chunks.append(chunk) start = end - self.overlap # 重叠部分 return chunks 优势：简单、快速、可预测。 劣势：可能在句子中间截断，破坏语义。 最佳实践：设置50-100 token的重叠，减少截断影响。 2.2 句子分块 class SentenceChunker: def __init__(self, max_sentences=5, max_tokens=500): self.max_sentences = max_sentences self.max_tokens = max_tokens def chunk(self, text): sentences = self.split_sentences(text) chunks = [] current_chunk = [] current_tokens = 0 for sentence in sentences: sent_tokens = self.count_tokens(sentence) if current_tokens + sent_tokens > self.max_tokens or \ len(current_chunk) >= self.max_sentences: if current_chunk: chunks.append(" ".join(current_chunk)) current_chunk = [sentence] current_tokens = sent_tokens else: current_chunk.append(sentence) current_tokens += sent_tokens if current_chunk: chunks.append(" ".join(current_chunk)) return chunks 优势：保持句子完整，语义更好。 劣势：块大小不均匀。 ...

引言 “我的RAG系统效果怎么样？“这是每个RAG开发者都会问的问题。但回答这个问题并不简单——RAG系统包含检索和生成两个环节，每个环节都有多个质量维度。 2026年，RAG评估已经形成了一套比较完整的指标体系。从检索的准确率和召回率，到生成的忠实度和相关性，再到端到端的用户满意度。本文将系统介绍这些指标。 一、RAG评估框架 1.1 评估维度 RAG系统 ├── 检索质量 │ ├── 准确率（Precision） │ ├── 召回率（Recall） │ ├── 排序质量（NDCG/MRR） │ └── 多样性（Diversity） ├── 生成质量 │ ├── 忠实度（Faithfulness） │ ├── 答案相关性（Answer Relevance） │ ├── 完整性（Completeness） │ └── 正确性（Correctness） └── 端到端质量 ├── 用户满意度 ├── 响应延迟 └── 成本效率 1.2 评估方法 人工评估：最准确但成本高 自动评估：使用LLM或规则自动评估 基准测试：在标准数据集上测试 A/B测试：线上对比不同版本 二、检索质量指标 2.1 准确率与召回率 class RetrievalMetrics: def precision_at_k(self, retrieved, relevant, k): """Top-K准确率""" retrieved_k = retrieved[:k] relevant_set = set(relevant) retrieved_set = set(retrieved_k) return len(relevant_set & relevant_set) / k def recall_at_k(self, retrieved, relevant, k): """Top-K召回率""" retrieved_k = retrieved[:k] relevant_set = set(relevant) retrieved_set = set(retrieved_k) return len(retrieved_set & relevant_set) / len(relevant_set) def average_precision(self, retrieved, relevant): """平均准确率""" relevant_set = set(relevant) precisions = [] num_relevant = 0 for i, doc in enumerate(retrieved): if doc in relevant_set: num_relevant += 1 precisions.append(num_relevant / (i + 1)) if not precisions: return 0.0 return np.mean(precisions) def mean_average_precision(self, queries_results): """MAP""" return np.mean([self.average_precision(r["retrieved"], r["relevant"]) for r in queries_results]) 2.2 排序质量 def ndcg_at_k(self, retrieved, relevance_scores, k): """NDCG@K""" # DCG dcg = sum( (2 ** relevance_scores.get(doc, 0) - 1) / np.log2(i + 2) for i, doc in enumerate(retrieved[:k]) ) # IDCG（理想排序的DCG） ideal_order = sorted(relevance_scores.values(), reverse=True)[:k] idcg = sum( (2 ** score - 1) / np.log2(i + 2) for i, score in enumerate(ideal_order) ) return dcg / idcg if idcg > 0 else 0 def mrr(self, queries_results): """平均倒数排名""" reciprocal_ranks = [] for result in queries_results: for i, doc in enumerate(result["retrieved"]): if doc in result["relevant"]: reciprocal_ranks.append(1 / (i + 1)) break else: reciprocal_ranks.append(0) return np.mean(reciprocal_ranks) 2.3 上下文相关性 class ContextRelevanceMetric: async def measure(self, question, retrieved_context): """评估检索到的上下文与问题的相关性""" prompt = f""" 问题: {question} 检索到的上下文: {self.format_context(retrieved_context)} 请评估上下文与问题的相关性: 1. 有多少段落直接相关？ 2. 有多少段落间接相关？ 3. 有多少段落完全不相关？ 4. 相关性评分（0-1） """ result = await self.llm.call(prompt) return result["relevance_score"] 三、生成质量指标 3.1 忠实度（Faithfulness） 答案是否忠实于检索到的上下文，不产生幻觉： ...

神经符号AI：两条道路的融合 AI的历史上有两条主要路线：符号主义（Symbolic AI）和连接主义（Connectionism/Neural Networks）。符号主义擅长逻辑推理但缺乏感知能力；连接主义擅长感知但缺乏推理能力。 2026年，这两条路线终于开始深度融合——神经符号AI（Neuro-symbolic AI）正在成为通向AGI最有前景的方向之一。 两条路线的优劣 神经网络（连接主义） 优势： 感知能力强（图像、语音、自然语言） 模式识别出色 可从数据中学习 鲁棒性强（处理噪声和模糊输入） 劣势： 推理能力弱（多步逻辑推理容易出错） 可解释性差（黑箱模型） 数据饥饿（需要大量训练数据） 组合泛化能力弱 符号AI（符号主义） 优势： 逻辑推理能力强 完全可解释 不需要训练数据 组合泛化能力强 劣势： 感知能力弱 知识获取瓶颈（需要人工编码知识） 对噪声和模糊性不鲁棒 难以扩展到开放域 融合的目标 神经符号AI的目标是"两全其美"： 用神经网络做感知 用符号系统做推理 两者无缝协作 2026年的融合方式 1. 工具调用式融合 最简单的融合方式——LLM作为"前端"，调用符号推理工具： 用户问题 → LLM理解 → 识别需要推理 → 调用符号引擎 → 返回结果 → LLM格式化输出 2026年的实践： GPT-6内置了数学推理引擎（Lean 4）用于数学证明 Claude 5可以调用Z3 SMT求解器进行形式化验证 多个Agent系统集成了Prolog推理引擎 这种方式简单有效，但LLM和符号系统是分离的——LLM不理解符号推理的过程。 2. 嵌入式融合 将符号推理嵌入到神经网络中： 神经定理证明器（NTP） 将逻辑推理转化为可微分操作： class NeuralTheoremProver(nn.Module): def __init__(self): self.fact_encoder = nn.TransformerEncoder(...) # 编码事实 self.rule_encoder = nn.TransformerEncoder(...) # 编码规则 self.proof_step = nn.Linear(hidden, hidden) # 证明步骤 def forward(self, goal, facts, rules): # 1. 编码目标、事实和规则 goal_emb = self.fact_encoder(goal) fact_embs = self.fact_encoder(facts) rule_embs = self.rule_encoder(rules) # 2. 可微分推理 proof_score = self.proof_step(goal_emb, fact_embs, rule_embs) return proof_score # 证明的可信度 这种方式的推理过程是可微分的，可以端到端训练。2026年在数学推理任务上取得了好成绩。 ...

递归自我改进：AI的终极加速器 1965年，I.J. Good提出了"智能爆炸"假说：如果一台超智能机器能够设计更好的机器，那么它将不断自我改进，导致智能以指数速度增长。这就是所谓的"递归自我改进"（RSI）。 60年后，AI社区正在认真讨论：当前的AI系统是否已经展现出自我改进的初步迹象？如果是，这条路的终点在哪里？ 自我改进的层次 第一层：数据自我改进 当前状态：已实现 AI模型参与生成下一代模型的训练数据： GPT-5生成高质量推理数据用于训练GPT-6 DeepSeek V3生成合成数据训练V4 Anthropic使用Claude 4生成宪法AI训练数据 这种"数据自我改进"已经是大模型训练的标准实践。但它不是真正的"递归"——每一代模型的改进仍然需要人类深度参与。 第二层：架构自我改进 当前状态：初步探索 AI辅助设计下一代AI架构： Google使用AI搜索更高效的Transformer变体 NVIDIA使用AI设计GPU子模块 DeepMind的AlphaEvolve在进化算法中搜索新架构 2026年的进展：AlphaEvolve发现了一种新的注意力机制，比标准多头注意力效率高15%。这种"AI发现的架构"已被用于Google的下一代模型。 但AI还不能从零设计全新的架构范式——它只能在已有框架内做局部优化。 第三层：训练自我改进 当前状态：理论阶段 AI自动优化训练过程： 自动选择超参数 自动设计训练课程 自动进行数据筛选和加权 自动调整模型规模和结构 一些自动化ML工具（AutoML）已经能做部分工作，但距离"AI自己训练自己"还有很大距离。 第四层：递归自我改进 当前状态：科幻 AI完全自主地设计、训练和改进下一代AI，形成正反馈循环： AI(v1) → 设计 → AI(v2) → 设计 → AI(v3) → ... 每一代比上一代更聪明，改进速度越来越快 这是"智能爆炸"的设想。目前没有任何AI系统接近这个能力。 当前的"准自我改进"现象 虽然没有真正的递归自我改进，但2026年的AI已经展现出了几个有趣的"准自我改进"现象： 1. 合成数据飞轮 模型M → 生成数据 → 训练模型M+1 → 生成更好数据 → 训练模型M+2 → ... OpenAI确认，GPT-6的训练数据中约18%是GPT-5生成的合成数据。GPT-5的数据中约8%是GPT-4生成的。这个比例在逐代上升。 关键问题：这种"合成数据飞轮"能持续多久？ 模型坍缩风险：如果训练数据中AI生成的内容比例过高，模型可能会逐渐"坍缩"——多样性降低，错误被放大。 2026年的解决方案： 使用多个不同模型生成数据（增加多样性） 严格的质量过滤（使用人类标注+AI评估） 保留足够比例的真实数据 2. 自我蒸馏 模型通过"自我蒸馏"提升能力： ...

引言 真实世界的信息不只存在于文本中。图片、视频、音频、表格——这些非文本模态包含着文本无法替代的信息。传统的文本RAG无法处理"找一张包含红色汽车的产品图片"这类查询。 2026年，多模态RAG已经成为AI系统的标配能力。它能够跨模态检索信息、融合多模态上下文、生成多模态输出。本文将深入探讨多模态RAG的架构与实践。 一、多模态RAG的核心挑战 1.1 表示鸿沟 不同模态的数据需要不同的编码方式： 文本：文本embedding模型 图像：视觉embedding模型 音频：音频embedding模型 如何让不同模态的表示在同一个空间中可比？ 1.2 检索鸿沟 用户可能用文本查询图像，也可能用图像查询文本： 文本→图像: "找一张展示AI架构的图" 图像→文本: "这张图对应的技术文档在哪？" 图像→图像: "找类似的图片" 1.3 融合鸿沟 检索到的多模态信息如何融合？文本和图像的信息如何整合在一起喂给LLM？ 二、架构设计 2.1 整体架构 ┌─────────────────────────────────────────────┐ │ 多模态查询处理 │ │ (文本/图像/音频 → 统一表示) │ ├─────────────────────────────────────────────┤ │ 跨模态检索引擎 │ │ ┌─────────┬─────────┬─────────┐ │ │ │文本检索 │图像检索 │音频检索 │ │ │ └─────────┴─────────┴─────────┘ │ ├─────────────────────────────────────────────┤ │ 多模态融合层 │ │ (跨模态排序、上下文组装) │ ├─────────────────────────────────────────────┤ │ 多模态生成 │ │ (文本+图像+表格 → 统一回答) │ └─────────────────────────────────────────────┘ 2.2 多模态编码 class MultiModalEncoder: def __init__(self): self.text_encoder = load_model("text-embedding-3-large") self.image_encoder = load_model("clip-vit-large") self.audio_encoder = load_model("audio-embedding-model") async def encode(self, content, modality): """编码不同模态的内容""" if modality == "text": return await self.text_encoder.embed(content) elif modality == "image": return await self.image_encoder.encode(content) elif modality == "audio": return await self.audio_encoder.encode(content) elif modality == "mixed": # 混合内容：分别编码后融合 return await self.encode_mixed(content) async def encode_mixed(self, content): """编码混合模态内容""" embeddings = [] for item in content: emb = await self.encode(item["data"], item["modality"]) embeddings.append({"embedding": emb, "modality": item["modality"]}) # 使用跨模态对齐模型将不同模态的embedding映射到统一空间 unified = await self.align_embeddings(embeddings) return unified 2.3 跨模态对齐 使用CLIP等模型实现跨模态对齐： ...