企业官网建设流程全解析

上门做睫毛哪个网站,免费 flash网站源码,怎么开发一款app软件,pinthis wordpress背景 AI/LLM 大模型最近几年毋庸置疑的是热度第一#xff0c;虽然我日常一直在用 AI 提效#xff0c;但真正使用大模型做一个应用的机会还是少。 最近正好有这么个机会#xff0c;需要将公司内部的代码 repo 转换为一个 wiki#xff0c;同时还可以基于项目内容进行对话了解…背景AI/LLM 大模型最近几年毋庸置疑的是热度第一虽然我日常一直在用 AI 提效但真正使用大模型做一个应用的机会还是少。最近正好有这么个机会需要将公司内部的代码 repo 转换为一个 wiki同时还可以基于项目内容进行对话了解更具体的内容。实际效果大概和上半年很火的 deepwiki 类似。而我们是想基于开源的 deepwiki-open进行开发提供的功能都是类似的。在这个过程中我也从一个大模型应用开发的小白逐步理解了其中的一些关键概念以及了解了一个大模型应用的运行原理。LLMLLMLarge Language Model大语言模型大家应该都比较熟悉了本质一个通过海量文本训练出来的概率模型能力理解/生成文本、代码做推理、对话等特点参数固定训练完之后“记忆”是固化在参数里的知识有时间点只知道训练截止前的数据有知识截止时间可以把LLM当成一个“通用大脑”但不一定知道最新的、你的私有数据。目前的 AI 也就是大模型本质上还是概率预测当你给它一段话Prompt时它在后台做的事情是“根据我读过的几万亿字接在这段话后面概率最高的下一个字Token是什么”所以大模型每次回答的内容可能不同也不能 100% 的告诉你准确答案。Token大模型并不直接认识java、Rust或者“编程”这些词。在模型内部所有的文字都会先被转换成一系列数字。字/词 ≠ Token一个 Token 既不是一个字符也不是一个单纯的单词。灵活切分常见的词如the,apple通常对应1 个 Token。罕见的词或长的复合词如microservices可能会被拆分成几个 Token如microservices。中文通常比较特殊一个常用的汉字可能是 1 个 Token但不常用的汉字可能会占用 2-3 个 Token。在做大模型应用开发的时候尤其需要注意 token 的用量毕竟这是计费的标准。还有一个是上下文窗口的限制每个模型都会有最大 token 的限制如 8k, 32k, 128k。如果你的 Prompt 加上模型的回复超过了这个限制模型就会丢掉前面的记忆或者直接报错。在日常开发估算中可以大概估算一下这个比例英文文本1000 Tokens ≈ 750 个单词。中文文本1000 Tokens ≈ 500 到 600 个汉字随着模型词表的演进现在的模型处理中文的效率在不断提升。。代码代码中的空格、缩进和特殊符号都会消耗 Token。Python 等由于缩进较多消耗通常比纯文本快。也有相关的库可以帮我们计算 token/* by 01130.hk - online tools website : 01130.hk/zh/androidmanifest.html */ # Choose encoding based on embedder type if embedder_type ollama: # Ollama typically uses cl100k_base encoding encoding tiktoken.get_encoding(cl100k_base) elif embedder_type google: # Google uses similar tokenization to GPT models for rough estimation encoding tiktoken.get_encoding(cl100k_base) else: # OpenAI or default # Use OpenAI embedding model encoding encoding tiktoken.encoding_for_model(text-embedding-3-small) return len(encoding.encode(text))也可以通过 openai 的一个实例网站来可视化查看 token 的计算规则RAGRAG 的全程是Retrieval-Augmented Generation检索增强生成他不是类似于 LLM 的模型而是一种架构模式。举个例子比如你问 ChatGPT 关于你们公司的某一个规章制度大概率 ChatGPT 的训练语料是你没有你们公司的内部数据的。所以他回复你的多半是瞎编的内容或者直接告诉你不知道。此时就需要 RAG 了他可以在真正询问 LLM 之前先到内部的资料库里通过用户的问题将相关上下文查询出来然后再拼接成一个完整的 prompt 发送给 LLM让 LLM 根据你通过的数据进行回答。这样能解决一下三个问题幻觉问题你问它一个它不知道的事情它会一本正经地胡说八道。知识过时大模型的知识停留在它训练结束的那一天。私有数据安全你不能为了让 AI 懂你的业务代码就把几百万行私有代码全发给模型提供商训练一个新模型那太贵且不安全。使用 RAG 时还需要额外考虑到数据清洗的步骤比如我们这里的 repo wiki 的场景我们需要把一些第三方库、编译后产生的 target 目录等不需要的内容排除掉。避免在查询时带上这些内容干扰最终的结果。向量数据库上文里提到 RAG 模式需要一个非常关键的组件那就是向量数据库。我们先要在 RAG 里检索出相关的上下文就是在向量数据库里做查询具体流程如下把文档切块段落级别用一个Embedding 模型把每个块转成向量把这些向量存进向量数据库用户提问时也把问题转成向量用向量相似度检索出最相关的文档块把这些文档块 问题喂给 LLM让它生成答案简单来说就是将一些非结构化的数据图片、视频、文字通过Embedding 模型转换成一串数字数组即向量例如[0.12, -0.59, 0.88, ...]。查询的时候也会将查询内容转换为向量然后返回在向量空间里相近的数据。QA此时也许你会有以下一些问题LLM RAG 向量数据库是不是类似于用 LLM 训练私有化数据这两者的效果是否类似 如果不同区别在哪里LLM RAG 向量数据库本质是不改模型参数用检索到的外部资料来“喂”模型让它查完再答。你的数据在外部向量数据库里只是当作参考材料塞进 prompt。在私有数据上训练微调 / 预训练本质是用你的数据更新模型参数让模型“记住”这些模式和知识。你的数据被“烤进”模型权重里调用时不需要再查这份数据。维度RAG向量库微调 / 私有训练知识存放外部向量库模型参数里更新成本改文档即可重建 / 增量向量索引需要重新训练部署生效时间几分钟级训练上线小时天级支持频繁变更很适合很不适合透明度/可解释性高可以追溯到原文出处低模型直接给出无法确切知道来源总的来说使用 RAG 外挂私有化向量数据的成本更低也更灵活。对于一些更垂直的场景可以考虑使用私有数据训练模型。总结总体下来的感受是 LLM 应用大部分的代码都是 prompt 提示词普通 app 的主要内容是代码而不同大模型应用的主要区别是提示词反而代码大部分都是趋同的。区别就是用了什么框架但是共同的就是调用大模型 API将传统的 request/reponse 的请求模式换为流式响应大模型的响应很慢。在开发应用时需要了解System Prompt系统预设角色、User Prompt用户提问和Few-shot给模型几个例子引导它。好的 Prompt 是让 RAG 结果准确的关键。后续还需要更加完善deepwiki-open优化 splitter使用更适合代码分割的 splitter比如 tree-sitter将存储在本地的向量替换为一个独立的向量数据库持续优化提示词更加符合我们的项目背景Blog作者 crossoverJie出处 https://crossoverjie.top欢迎关注博主公众号与我交流。本文版权归作者所有欢迎转载但未经作者同意必须保留此段声明且在文章页面明显位置给出, 如有问题 可邮件crossoverJie#gmail.com咨询。