摘要:
基于最新鸿蒙系统的技术书籍《鸿蒙HarmonyOS 6应用开发:从零基础到App上线》上市啦,要知道 HarmonyOS 6 在一个多月前的10月22日才正式发布,因此这本鸿蒙教程可谓贴近最新的 HarmonyOS 6 系统。 当前 HarmonyOS 6 的装机量迅猛增长,有望在春节前突破500 阅读全文
基于最新鸿蒙系统的技术书籍《鸿蒙HarmonyOS 6应用开发:从零基础到App上线》上市啦,要知道 HarmonyOS 6 在一个多月前的10月22日才正式发布,因此这本鸿蒙教程可谓贴近最新的 HarmonyOS 6 系统。 当前 HarmonyOS 6 的装机量迅猛增长,有望在春节前突破500 阅读全文
posted @ 2026-01-24 11:24
aqi00
阅读(658)
评论(0)
推荐(3)
记录下FFmpeg的学习笔记目录,完整的FFmpeg开发实战内容详见《FFmpeg开发实战:从零基础到短视频上线》一书。 下面是补充的FFmpeg开发笔记内容目录,主要是对《FFmpeg开发实战:从零基础到短视频上线》一书的进阶增补。 第一章 Linux环境编译FFmpeg FFmpeg开发笔记(
前面的文章在构建RAG并检索时,既使用了国外大模型,也使用了国内大模型;既运用了内存向量检索库FAISS,也运用了磁盘向量数据库Chroma。 但知识库的原始来源却是knowledge数组,这与现实场合有所出入,因为实际资料都保存在TXT、PDF、WORD等格式的文档中,甚至来自互联网上的HTML网
前面两篇文章在演示RAG功能时,做向量化的文本嵌入模型都用国外的all-MiniLM-L6-v2,该模型主要适用英文,对于中文总体也能用,但在细节上处理欠佳。本文就来介绍如何使用国产离线的文本嵌入模型替换国外模型,以及如何体现国产模型的比较优势。 一、all-MiniLM-L6-v2的缺点 虽然al
上一篇文章通过all-MiniLM-L6-v2模型结合FAISS实现了简单的RAG检索功能,但FAISS运行于内存中,无法持久化保存向量数据,重启后又得重新对文本做向量化,比较浪费算力资源。本文就来介绍如何使用向量数据库来持久保存向量数据。 一、向量数据库Chroma Chroma是一个本地向量数
上一篇文章采用字符串匹配的方式来查找知识,这种方式比较呆板不够智能,接下来引入向量数据库,通过向量化实现更精细的知识检索。 一、文本嵌入Embedding模型 向量化一段文本的时候,经常用到all-MiniLM-L6-v2,它是一个轻量级的文本嵌入Embedding模型,专门把文字转成数字向量,给R
前面的文章依次介绍了如何截断历史会话的对话记录,包括按照记录数量截断、按照Token长度截断,以及浓缩为摘要截断等等,其中摘要操作又分为三大类: 1、使用第三方的摘要库对文本摘要; 2、使用在线大模型对文本摘要; 3、使用离线大模型对文本摘要; 以上对会话记录的各种处理操作,统称为AI应用的上下文
上一篇文章末尾使用了在线大模型压缩文本生成摘要,但该方式会消耗Token,不便初学者长期使用,更好的办法是采用离线大模型来生成文本摘要。 一、离线大模型的种类 国内常用的离线大模型有阿里Qwen、智谱GLM、深度求索DeepSeek、百度文心等等,以千问的文本大模型为例,又有Qwen1.5-1.8
HarmonyOS 6.1.1 已于 2026 年 5 月下旬正式发布,该版本在 HarmonyOS 6.1 基础上增强了若干特性,让鸿蒙系统变得更流畅更好用,下面结合《鸿蒙HarmonyOS 6应用开发:从零基础到App上线》一书对 HarmonyOS 6.1.1 新特性中的常用部分逐一讲解。
前面两篇文章分别介绍了根据消息数量截断历史对话和根据Token长度截断历史对话,可是这两种方式有两个共同的问题: 1、被删去的早期记录可能包含关键信息,直接截断会导致信息丢失。 2、原始的对话记录可能存在重复、冗余、拖沓的文字内容。 一、为什么要对原始记录做摘要 要知道,重复、冗余、拖沓的文字内容
上一篇文章说到按照消息数量来截断历史对话,这种方式有个问题,就是每次对话的内容可长可短,导致固定消息数量的对话内容忽长忽短。 历史对话内容不光要存入数据库,还要作为初始提示词发给下次新会话的大模型。太长的提示词不仅冗余,还会消耗大量Token,让用户钱包快速缩水。太短的提示词容纳的信息量不足,难以
AI大模型服务的用户很多,它对每个用户的印象仅存在于当前会话中,一旦用户离开当前会话重新开启新的会话,AI会把该用户当作是新用户,而非之前已经对话过的某个用户。 也就是说,AI没有持久记忆的功能,它记不住你上次问了什么,也记不住它上次回答了什么。这意味着AI没法从过往的对话中吸取经验,原本纠正了的
浙公网安备 33010602011771号