llm decoder的研究 引入 对于大模型来说，常见的是decoder-only transformer架构。因此，研究解码器的原理至关重要。 笔者通过实践，实践了默认解码方法的调用和自己重写解码器。 如何调用开源LLM LLM可分为开源和闭源两种。其中闭源的LLM会提供api，如gpt4等模型。 可使用requests库发送请求并接收信息。部分llm支持openai库 1 2 3 4 5 6 7 8 9 10 11 12 13 from openai import OpenAI client = OpenAI(api_key=api_key, base_url=base_url) # 调用API检索 response = client.chat.completions.create( model=model_name, messages=[ {"role": "user", "content": prompt}, ], stream=False ) # 获取优化后的代码结果 result = response.choices[0].message.content stream=True代表流式输出。反之直接输出最终的文本。 对于开源llm，可使用transformers库来调用 在科研中，尽管开源的llm调用起来十分方便，但也没有那么自由。因此，当我们需要访问llm的logits、attention权重等参数时，需选择开源llm进行研究。 常见的有llama系列（llama2, llama3）、mistral系列等。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 # 读取模型 model = AutoModelForCausalLM.

llm Agent的Tool call原理解析 引入 转眼间进入2025年，新年第一篇博客记录一下近期的发现。 笔者在实践中，探索langchain框架可以自动调用工具（tool calling）。 见 langchain 然而，众所周知，LLM是用于文本生成的工具，可以理解成func(input:str) -> str 那么工具究竟是谁在调用呢？如何判断何时调用？ 回顾 我们先简单回顾一下langchain的agent调用工具的例子。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 # # 初始化 ChatZhipuAI from langchain.tools import Tool from langchain.

记一次前端幽灵bug的解决 写在前面 笔者在微信小程序开发具备较多的经验，从原生开发到uniapp，以及Taro均有涉猎。 在一个项目业务逻辑中，每次重进小程序将自动登录最近登录过的账号，同时进入登录页面显示历史账号。 然而，近期出现一个奇怪的bug：小程序无法自动登录，历史账号也消失了。 更令人匪夷所思的是，笔者在开发者工具和手机上反复测试，并未发现任何bug。这bug如同幽灵一般，随机的出现。 经过广泛测试，事实上，该bug在一部分人的手机上出现，但在另一部分人手机上完全正常。 排查过程 由于笔者调试时并未发现任何问题，并且以往也从未出现该bug，竟然有种无从下手的尴尬。 以下为寻找解决方案的经过。 尝试将代码复原至上一个版本 (×) 首先，我将最新的改动还原，试图解决该问题。然而该问题仍然存在，令人费解。 在出问题的手机上启动“开发调试”（√） 尽管程序看起来逻辑完全正确，但按照常理，一定是有报错阻碍了相关内容的呈现。 在出现bug的手机上启动小程序“开发调试”，找到了“报错”，如图所示。 解决方法： 经过分析报错，定位到一段代码： 1 2 3 4 5 6 7 8 9 10 11 12 13 onLoad() { this.accountList = uni.getStorageSync('accountList') || [] // (1) if (this.accountList.length) { const [arr1, arr2] = this.accountList.reduce((result, item) => { item.identity = Number(item.identity) // 根据 identity 将对象分配到不同的数组 result[item.identity - 1].push(item) // identity取值为1：家长 2：教师 return result }, [[], []]); // 初始化为两个空数组 this.

Day1 12:10 - 14:55 杭州萧山 —— 重庆江北 10号线转2号线 江北机场T3航站楼站—曾家岩站（10号线）曾家岩站—临江门站（2号线）入住江景民宿 打车去七星岗 品味火锅 爆火锅 德福火锅 彭三老火锅 红火锅 欢火锅 业城胖妹火锅 吃完饭休息一下去酒吧： 月光漫步高空酒吧 41层 苏丝的天空高空酒吧 重点推荐 位于WFC摩天大楼顶端 74层 海拔590米 性价比高 旅行感受 第一天就被重庆的魅力所吸引，住宿旁边正是著名的魁星楼。同一高度是1层也是12层更是22层。 住在高空江景民宿中，可远眺嘉陵江、千厮门大桥、洪崖洞的绝美风景。 WFC环球金融中心是渝中区最高的建筑，在顶楼观赏夜景是一件十分愉悦的事。 重庆火锅专治不老实，如果不能吃辣，可以和服务员说明“微微辣”。 Day2 魁星楼 白象居 山城步道（一般） 十八梯（没意思，商业气息浓） 白象居 湖广会馆 来福士 晚上报了观光团，去了几个攻略外的地方。 苏家坝观景平台 俯瞰最高的立交桥 城上天幕观光塔 共52层，位于南岸区，欣赏渝中区夜景。 洪崖洞 千厮门大桥上十分壮观 旅行感受 网上攻略说“轻松省力”，其实玩一整天下来也需要较好的体力。 魁星楼 解放碑属于打卡型景点。 十八梯在上面拍个照即可，走下去也不过如此。 山城步道建议打车至佳实养老院，走下坡路，不然很消耗体力。 印象最深的景点是白象居。24楼没有电梯，但有三个不同楼层均是“1楼”。一个居民楼成为网红打卡点，还成为众多电影取景地，值得一玩。 城上天幕去的时候正逢大雨，观感大打折扣。 Day3 武隆景区一日游 天坑 + 地缝 仙女山建议天气好去 旅行感受 跟团游 风景很棒，自然风光十分震撼。不过午饭吃得差，建议自带干粮。 几个印象深的景点： 前往天坑的电梯，非常震撼。 地缝有盗墓笔记的感觉。

大模型Prompt——思维链 初探思维链 思维链方法由google大脑研究院（现跳槽至OpenAI）的Jason Wei大佬在 首篇论文《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》中提出。 思维链的形式 给定Prompt，包含三元组 <input, chain of thought, output> 举例： 思维链的妙处 COT使得模型将多步骤问题解构成直接的步骤，意味着附加计算能够被分配到需要更多推理步骤的问题。 COT对模型的表现提供了可解释的窗口，表明它如何到达具体的答案，并且提供debug推理错误的机会。 COT推理能够被用于数学文字问题、常识推理和表征计算，并有潜力应用（原则上）到人们能通过语言解决的任何问题。 思维链的效果 在数学推理、常识推理、象征推理三大领域运用数据集予以验证。 错误的思维链分析 计算错误 象征映射错误 少步骤错误 思维链存在的局限性 尽管思维链模仿了人类推理过程的步骤，这并没有回答神经网络是否真的在推理，留作开放性讨论。 尽管在少样本环境下，手动将思维链条增加到示例中的成本很低，但这种标注成本在微调时可能是不可承受的。 思维路径并没有保证是正确的，这可能导致生成正确或错误的答案；提高语言模型生成事实性内容的准确性是未来研究的一个方向。 最后，思维链条推理的涌现只有在大型模型中才会出现，这使得其在实际应用中成本较高；进一步的研究可以探索如何在小型模型中引导出推理能力。 拓展与改进 1. 自动思维链 AutoCoT 在思维链引出之后，李沐老师团队发表了《AUTOMATIC CHAIN OF THOUGHT PROMPTING IN LARGE LANGUAGE MODELS》。 思维链的两种范例： 在提问之前给出简单的prompt 如“让我们一步一步地思考” —— Zero-Shot-CoT 使用一些人工的案例，提供问题解构和推理链从而得到答案。—— Manual-CoT 其中第一种方法能够减轻人工的工作量，但生成的思维链常常包含错误。 但第二种方法很费人力，因为对于不同类型的任务（数学推理、常识推理等）都需要人工标注思维链。 因此论文提出一种新的自动COT提示词范式——AutoCoT。旨在自动化构建例子包含问题和推理链。具体地，Auto-CoT利用LLM的“让我们一步步思考“的提示词为每一个样例逐个生成推理链。 挑战 给定数据集中的一个测试问题，检索语义近似的问题并加入Zero-Shot-CoT来生成推理链将会失败。 我们的分析显示关键在于样例问题的多样性。因此，我们的AutoCoT方法通过两步： 将给定数据集分成几个簇 从每个簇中选取一个有代表性的问题，使用简单的通过启发式方法，使用零样本CoT生成推理链。 两种方法： Retrieval-Q-CoT

transformer位置编码初探 笔者在研究NLP和LLM时发现，位置编码至关重要。从Transformer开山之作（Attention is all you need）中的绝对位置编码，到llama中的旋转位置编码，有各种各样。博客中笔者列举了一些常见的位置编码，并分析其中的原理。 Transformer架构 为什么需要位置编码 Attention没有关注位置信息。在NLP中，很显然同一个词在不同的位置有截然不同的意义。如”他对我说“和”我对他说“。因此引入位置编码（Positional Embedding）记录每个token的位置信息。将PE和原单词的嵌入向量相加，输入Transformer模型加以训练。 此外，位置编码和大模型外推性息息相关。 大模型的外推性指的是训练与预测时长度不一致。一般俩说，预测时上下文长度远大于训练时，容易出现泛化能力下降。选取合适的位置编码能够提升外推能力。 原始论文中Sinusoidal编码 $$ PE_{pos,2i} = sin(\frac{pos}{10000^{\frac{2i}{d_{model}}}}) $$ $$ PE_{pos,2i+1} = cos(\frac{pos}{10000^{\frac{2i}{d_{model}}}}) $$ 即 $$ \left[ \begin{matrix} PE_{pos} = [sin(\omega_1\cdot{pos})] \\ PE_{pos} = [cos(\omega_1\cdot{pos})] \\ PE_{pos} = [sin(\omega_2\cdot{pos})] \\ PE_{pos} = [cos(\omega_2\cdot{pos})] \\ \ldots \\ PE_{pos} = [sin(\omega_{\frac{d}{2}}\cdot{pos})] \\ PE_{pos} = [cos(\omega_{\frac{d}{2}}\cdot{pos})] \end{matrix} \right] $$ 采用sin和cos奇偶交替，具有平滑性、不会重复。 其中PE代表位置编码，pos代表每个单词的位置，0,1,2,3……。d_{model}代表嵌入维度。 由于 $$ 0 \le \frac{2i}{d_{model}} \le 1, \\ 有 1 \le 10000^{\frac{2i}{d_{model}}} \le 10000 $$ 另外可观察到，对于同一个向量分量，PE随着pos呈现正弦或余弦波动。