记一次前端幽灵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呈现正弦或余弦波动。

Hugo博客部署教程 写在前面 今天，笔者有空整理了下hugo搭建教程。 首先在云服务器上下载hugo，pick自己喜欢的主题（我选择了Lovelt）、配置.toml文件 。这些网上有详细的教程，不予赘述。 下面介绍一些小技巧。 友链的配置 hugo本身提供了posts、tags、categories，并没有提供友链。因此需要自己单独配置。 在layouts/shortcodes中加入代码friend.html 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 {{ if .IsNamedParams }} {{- $src := .Get "logo" -}} {{- $small := .Get "logo_small" | default $src -}} {{- $large := .Get "logo_large" | default $src -}} <div class="flink" id="article-container"> <div class="friend-list-div" > <div class="friend-div"> <a target="_blank" href={{ .

go项目部署+实战（二） 多表联查的实现 谈到多表联查，有多种实现方法。比较传统的为数据库课程所教的视图方法。然而灵活性较差。 在Springboot中，采用映射表实现，而go+gin+gorm框架中，又有所不同。 下面笔者通过一个案例介绍多表联查的应用场景。 有一个合唱团，声部长负责批改作业。该接口需要查询声部长负责声部的所有人作业情况。 实体表有用户表、合唱团表、用户-合唱团表、作业表、作业提交表。 分析 首先需要明确设计表结构，易混淆的在于用户的角色权限和声部是隶属用户-合唱团表，而非用户本身。 思路为，查询用户所在声部权限比他低的人。 示例代码 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 func AdminGetHomeworks(c *gin.Context) { homeworkId, _ := strconv.Atoi(c.Param("homeworkId")) var submissions []HomeworkSubmissionInfo chorusLeaderID := c.GetInt("userId") err := config.DB.Table("homework_submission"). Joins("JOIN homework ON homework.id = homework_submission.homework_id"). Joins("JOIN join_chorus ON homework.chorus_id = join_chorus.chorus_id"). Joins("JOIN user ON homework_submission.user_id = user.id and is_final = 1"). Where("join_chorus.user_id = ?