大模型开发入门：掌握基础概念是关键

Zui近几年，AI/LLM无疑是科技领域的热门话题。作为一名开发者，我日常dou在使用AI提高工作效率，但真正利用大模型开发应用的机会并不多。Zui近，我有幸参与了一个将公司内部代码仓库转换为wiki的项目，并在此基础上实现了基于项目内容的对话功Neng。在这个过程中，我逐步理解了大模型应用开发的关键概念和运行原理。

LLM大家应该dou比较熟悉了：本质上，大模型是一种概率预测模型。当你给它一段话时它在后台Zuo的事情是：“根据我读过的几万亿字，接在这段话后面概率Zui高的下一个字是什么？”简单来说大模型并不直接认识javaRust或者“编程”这些词。在模型内部，所有的文字dou会先被转换成一系列数字，即向量。

RAG的全称是Retrieval-Augmented Generation，它不是类似于LLM的模型，而是一种架构模式。简单来说RAG的本质是：不改模型参数，用检索到的外部资料来“喂”模型，让它查完再答。这样Neng解决三个问题：1）避免在查询时带上不需要的内容，干扰Zui终的结果；2）让模型基于私有数据或Zui新数据进行回答；3）在一定程度上缓解了大模型的“幻觉”问题。

在使用RAG模式时需要一个非常关键的组件，那就是向量数据库。简单来说向量数据库是将一些非结构化的数据通过Embedding 模型转换成一串数字数组，即向量。查询的时候也会将查询内容转换为向量，然后返回在向量空间里相近的数据。

LLM + RAG + 向量数据库是一种新的应用架构，它结合了大模型的强大语言理解和生成Neng力、RAG的检索增强生成Neng力以及向量数据库的高效相似性搜索Neng力。这种架构Ke以实现基于私有数据或特定领域数据的智Neng问答、知识检索等功Neng。

在开发大模型应用时需要了解几个关键概念：

System Prompt为模型设定特定的角色或任务。

User Prompt用户的输入，用于触发模型的响应。

Few-shot通过提供几个示例来引导模型的输出。

Token模型的输入输出基本单位，通常是字或词。

上下文窗口限制每个模型dou有Zui大token的限制。Ru果输入输出超过这个限制，模型可Neng会丢掉前面的记忆或者直接报错。

我们的项目是基于开源的deepwiki-open进行开发的，目标是将公司内部的代码仓库转换为一个wiki，并实现基于项目内容的对话功Neng。我们需要对原始数据进行清洗，排除掉不需要的内容，如第三方库、编译后产生的target目录等。然后利用RAG架构，结合向量数据库，实现基于私有数据的智Neng问答。

Few-shot学习和Prompt工程是大模型应用开发中的两个重要方面。通过精心设计的Prompt，Ke以引导模型产生geng准确、geng有用的输出。同时通过Few-shot学习，Ke以让模型快速适应新的任务或领域。

tiktoken是一个用于计算token数量的工具库。根据不同的embedding模型，tiktokenKe以采用不同的编码方式来计算token数量。这对于估算API调用成本和优化Prompt设计非常有用。此外还Ke以通过OpenAI的实例网站可视化查kantoken的计算规则，以geng好地理解模型的输入输出机制。

  
# Choose encoding based on embedder type  
if embedder_type == 'ollama':  
    # Ollama typically uses cl100k_base encoding  
    encoding = tiktoken.get_encoding  
elif embedder_type == 'google':  
    # Google uses similar tokenization to GPT models for rough estimation  
    encoding = tiktoken.get_encoding  
else:  # OpenAI or default  
    # Use OpenAI embedding model encoding  
    encoding = tiktoken.encoding_for_model  
return len)

在这个过程中，我从一个大模型应用开发的小白逐步理解了其中的一些关键概念，以及了解了一个大模型应用的运行原理。总的来说使用RAG + 向量数据库 + LLM deepwiki-open :比如支持geng多的数据源、优化检索算法等，以实现geng强大的功Neng和geng好的用户体验。同时也期待在大模型应用开发领域kan到geng多的创新和突破。 大模型应用开发是一个充满挑战和机遇的领域。通过掌握基础概念、了解关键技术，我们Ke以geng好地利用大模型的潜力，创造出geng多有价值的应用。 总体下来的感受是 LLM 应用大部分的代码dou是 prompt 提示词，而不同大模型应用的主要区别也是提示词，反而代码大部分dou是趋同的。 在Zuo大模型应用开发的时候尤其需要注意 token 的用量，毕竟这是计费的标准。在日常开发估算中，Ke以大概估算一下这个比例。 区别就是用了什么框架，但是共同的就是调用大模型 API，将传统的 request/reponse 的请求模式换为流式响应。 实际效果大概和上半年hen火的 deepwiki 类似。所以他回复你的多半是瞎编的内容，或者直接告诉你不知道。 此时也许你会有以下一些问题： 1. LLM + RAG + 向量数据库，是不是类似于用 LLM 训练私有化数据？这两者的效果是否类似？ Ru果不同，区别在哪里？ 2. 在使用 RAG 时还需要额外考虑到数据清洗的步骤，比如我们这里要把一些第三方库、编译后产生的 target 目录等不需要的内容排除掉。而我们是想基于开源的 deepwiki-open进行开发，所提供的功Nengdou是类似的。 所以大模型的每次回答内容可Neng不同，也不Neng % 的告诉你准确答案。我们先要在 RAG 里检索出相关的上下文，就是在向量数据库里Zuo查询，具体流程如下： 用你的数据geng新模 型参数 ，让“记住”这些模式和知识，避免在查询时带上这些内容。Ke以把 LLM  当成一个“通用大脑”，但不一定知道Zui新的、私有数据。 查询的时候也会将查询内容转换为向量，然后返回在向量空间里相近的数据。上文里提到 RAG 模式，需要一个非常关键组件——向量数据库：将非结构化的数据通过 Embedding 转换一串数字数组即向量； 我们的项目需要将公司内部代码 repo 转为 wiki，同时还Ke以基于项目内容对话以了解geng具体内容，Zui近正好有这么个机会 。 在这个过程中我也从⼀个⼤模 型应⽤开发 的⼩⽩逐步 理解 了其中的⼀些关键概念，以及 了 解了⼀个⼤模 型应⽤ 的运⾏原理 。 LLM 大型语言模 型Zui 近几 年毋庸置疑的是 热度第⼀ ，虽然日常⼀直 在⽤ AI 提效，但真正使⽤⼤模 型Zuo⼀个应⽤ 的机会还 是少。大模 型并 不直接认识诸如java 、Rust 等词汇；所有文字dou会先被转换成一系列数字，即向量表示。 本质 是 ： 不修改模 型参数 ，而是通过检 索 外部资料来提供给模 型以辅助其回答，即“查完再答”。 还有⼀个 是 上下 文窗⼝ 的限制，每个模 型dou 会有Zui⼤ token 的限制。Ru果 Prompt 加上模 型的 回复超过了 这个限制 ，模 型就 会丢掉前⾯ 的记忆 或者 直接报错 。 也有相关的库 Ke以帮助 我们 计算 token ：t ikt oken 。此外也Ke以 通过 Open AI 的 实例 网站 可视化 查kan token 的 计算规 则 。 R AG 全称 Retrieval - Augmented Gener ation ，它 不是 类似 于 LLM 的模 型，而 是⼀种架 构模式 。 此时 就 需要 R AG 了他 Ke以 在真正询 问 LLM 之 前先 到内 部 的资 料库 里通 过 用户 的 问题 将 相关 上下 文 查询 出来然后 再拼 接成 一个完 整 的 prompt 发送 给 LLM ， 让 LLM 根据 你 通过 的数 据进 行回 答 。 举 个例 子 ： 比 如 你 问 Chat GPT 关 于 你 们公 司 的某 一 个规 章制 度，大 概率 Chat GPT 的训 練语 料 是 没 有 你 们公 司 的内 部 数据 的。 所 以 他回 复 你 的多 半 是 瞎编 内 容，或 者直 接告 诉 你不 知道 。 模 型的概 念是对 现实世 界事 物特 征 的模拟 和抽象表 示 。 在数 据 库中 数 据模 型是用 来抽 象表 示 和处 理 现实世 界 中数 据的工作 。