基于RAG与Function Calling构建AI音乐助手：从原理到工程实践 1. 项目概述当音乐遇上AI一个私人音乐助手的诞生最近在GitHub上看到一个挺有意思的项目叫soliblue/songGPT。光看名字你大概就能猜到它的核心用GPT模型来处理和生成与音乐相关的内容。作为一个长期混迹在AI应用和创意工具领域的开发者我对这种将前沿大语言模型能力垂直应用到具体兴趣领域的项目特别感兴趣。它不像那些庞大的通用AI平台而是聚焦于一个我们每个人都熟悉的场景——音乐。简单来说songGPT可以被理解为一个“懂音乐”的AI助手。它的目标不是去替代专业的数字音频工作站或者编曲软件而是解决我们在享受和探索音乐时遇到的一些“软性”需求。比如你听到一段旋律但哼不出歌词它能帮你补全你想为一幅画或一种心情找配乐它能给你推荐甚至你可以和它聊聊某首歌背后的故事或者让它基于一段文字描述生成一段简单的旋律创意。这个项目的价值在于它降低了音乐创作、理解和互动的门槛让即使不懂乐理、不会乐器的普通人也能借助AI的力量更深入地玩转音乐。这个项目适合几类人一是对AI应用开发感兴趣的开发者可以从中学习如何将大模型API与特定领域知识结合二是音乐爱好者或内容创作者可以将其作为一个有趣的工具来激发灵感三是产品经理或创业者可以观察这种垂直化AI应用的设计思路和用户场景。接下来我会结合自己的经验深入拆解这个项目的实现逻辑、关键技术点以及如何让它真正跑起来。2. 核心架构与设计思路拆解2.1 从需求倒推技术栈选择songGPT的核心是“理解”和“生成”与音乐相关的自然语言。这决定了它的技术底座必然是一个强大的语言模型。目前来看最合理的选择是集成 OpenAI 的 GPT 系列 API如 GPT-3.5-Turbo 或 GPT-4或者使用开源的、同等能力的模型如 Llama 3 的 API 服务。选择商用 API 的优势在于省去了部署和微调百亿参数模型的巨大成本可以快速聚焦应用层逻辑。但仅仅有语言模型是不够的。音乐领域有大量专有名词、结构化数据如和弦进行、曲式分析和非文本信息音频特征。因此项目架构中至少包含以下几个关键模块自然语言处理NLP模块负责接收用户的文本查询如“给我写一首关于夏日离别的流行歌曲歌词”并理解其意图。这里可能需要一个“意图识别”层将用户问题分类比如是“歌词生成”、“歌曲推荐”、“音乐知识问答”还是“旋律描述”。音乐知识库与特征工程模块这是项目的“专业大脑”。它可能包含元数据数据库存储歌曲的标题、艺术家、专辑、流派、年代、歌词等。音频特征向量库通过预训练的音频模型如 VGGish、CLAP将歌曲音频提取为特征向量用于基于内容的相似性检索。音乐理论规则库一些基本的和弦走向模板如 1645、节奏型、常见曲式结构用于辅助生成。任务编排与生成模块根据识别出的意图调用不同的“技能”。如果是歌词生成则结合用户输入的主题、风格和语言模型本身的创作能力生成文本。如果是歌曲推荐则结合用户描述的情感、场景从知识库中检索相似特征或相同标签的歌曲。如果是音乐问答则可能从维基百科、音乐数据库API或项目自建的知识库中检索信息再由语言模型整理成友好回答。前端交互界面一个让用户能够方便输入和查看结果的界面可能是 Web 应用、聊天机器人界面或移动端 App。2.2 为什么不是端到端的单一模型你可能会问既然 GPT 已经这么强大为什么不直接让它处理所有事情这里涉及到专业领域应用的深度问题。一个纯粹的、未经特定领域信息增强的 GPT 模型在音乐方面的知识可能是泛化且有时效性的比如它不知道昨天刚发布的新歌。更重要的是它无法直接“听到”音乐或处理音频信号。因此songGPT这类项目的典型架构是“检索增强生成”RAG与“工具调用”Function Calling的结合。当用户问“推荐一首类似《Hotel California》前奏感觉的歌”时系统会先解析出关键实体“《Hotel California》”和属性“前奏感觉”。然后它可能执行以下步骤调用一个音乐元数据服务获取《Hotel California》的歌曲ID。使用音频特征提取模型获取这首歌前奏片段的特征向量。在特征向量库中进行相似度搜索找到最相似的几首歌的前奏。将这几首歌的元信息歌名、艺术家组织成上下文提交给 GPT。GPT 根据这个精确的上下文生成一段自然、友好的推荐语。这种方式既利用了 GPT 强大的语言组织和对话能力又保证了推荐结果的准确性和专业性克服了大模型的“幻觉”问题在专业领域的弊端。3. 关键技术细节与实现难点3.1 音乐特征提取与相似度计算这是实现精准推荐和音乐理解的核心。通常我们不会直接使用原始的音频波形数据进行计算而是将其转化为更能代表音乐特性的“特征向量”。常用特征包括梅尔频谱图Mel-spectrogram模拟人耳听觉特性的时频表示是深度学习音频模型的常见输入。MFCC梅尔频率倒谱系数从频谱中提取的、代表音色特征的一组系数在传统音频处理中广泛应用。预训练模型嵌入Embedding使用在大规模音频数据集上预训练好的模型如OpenAI 的 Whisper的编码器部分、Google 的 VGGish、Meta 的 MusicGen或LAION 的 CLAP来提取高维特征向量。这是目前最主流且效果最好的方法。以 CLAP 模型为例它同时接受了音频和文本的对比学习训练使得音频特征和文本特征被映射到同一个向量空间。这意味着你可以用文本“欢快的电子舞曲”去直接检索出特征相似的音频完美契合songGPT用语言描述音乐的需求。实现步骤简述音频预处理将歌曲统一转换为单声道、固定的采样率如 16kHz并进行归一化。分帧与特征提取如果是整首歌曲可以按固定时长如30秒切片分别提取特征再通过池化平均或最大池化得到一首歌的代表性向量。向量存储与检索将成千上万首歌的特征向量存入专业的向量数据库如ChromaDB、Weaviate或Qdrant。当需要检索时计算查询向量可以是另一首歌的特征也可以是CLAP模型生成的文本特征与库中所有向量的余弦相似度返回最相似的结果。注意特征提取和相似度计算是计算密集型任务。在生产环境中需要对音频库进行离线预处理将生成的特征向量提前存入数据库线上服务只做快速的向量检索以保证响应速度。3.2 与大型语言模型的深度集成如何让 GPT 这类模型“知道”它拥有音乐检索和知识查询的能力这就需要用到Function Calling函数调用或Tool Use工具使用能力。基本工作流如下用户输入“我想听一首歌它的鼓点像《Billie Jean》那么有辨识度但旋律要更忧郁一些。”系统提示词设计在发给 GPT 的初始系统消息中明确定义它的角色和一个可用的工具列表。例如你是一个专业的音乐助手。你可以通过以下工具帮助用户 - search_similar_song_by_audio: 根据一首参考歌曲寻找节奏、旋律或音色相似的歌曲。 - search_song_by_text_description: 根据一段文字描述如情绪、乐器、场景来寻找歌曲。 - get_song_details: 获取歌曲的详细信息如艺术家、专辑、发行年份。 - generate_lyrics: 根据主题和风格生成一段歌词。模型决策GPT 分析用户请求判断需要调用search_similar_song_by_audio和search_song_by_text_description这两个工具。它会返回一个结构化的 JSON 响应指明要调用的函数名和参数如{name: search_similar_song_by_audio, arguments: {reference_track: Billie Jean, aspect: drum_beat}}。本地执行你的后端服务接收到这个 JSON解析后调用相应的本地函数或微服务。比如用《Billie Jean》的鼓点特征去向量库搜索得到一批节奏相似的歌曲列表 A。二次查询与整合将工具执行的结果歌曲列表 A和用户的原始请求再次发送给 GPT。GPT 此时拥有了精确的上下文它可能会说“根据您的描述我找到了一些鼓点风格类似《Billie Jean》的歌曲。为了找到旋律更忧郁的我将结合文本描述进行筛选...” 然后它可能再发起一次基于“忧郁旋律”的文本特征检索得到列表 B最后对 A 和 B 取交集或进行排序生成最终的自然语言回复。这个过程实现了 AI 与专业工具的闭环让模型从“空想”变成了“实干家”。3.3 歌词与旋律生成的挑战这是项目中最具创意也最难的部分。歌词生成相对成熟可以视为一个受控的文本生成任务。我们可以给 GPT 提供以下“约束”风格模板提供一些著名歌手的歌词作为风格示例。结构要求指定需要生成主歌Verse、副歌Chorus、桥段Bridge及其行数、押韵模式。主题与关键词用户输入的核心主题词确保内容不跑偏。旋律生成则复杂得多。一种可行的方法是将旋律转化为一种特殊的文本序列例如ABC 记谱法一种用字母表示音高的文本格式。MIDI 事件序列将音符的音高、时长、力度转化为一系列离散的事件代码。 然后使用在大量音乐数据上训练过的专用音乐生成模型如Google 的 MusicLM、Meta 的 MusicGen或Riffusion或者对 GPT 进行音乐代码的微调让它输出这种结构化序列再通过合成器转化为音频。在songGPT的初期更务实的做法可能是将旋律生成作为一个“黑盒”外部服务来调用。核心逻辑由 GPT 负责理解用户对旋律的描述如“欢快的大调”、“缓慢的钢琴独奏”然后将这些描述转化为音乐生成 API 所需的参数调用该 API 并返回结果给用户。4. 从零开始搭建一个简易版 songGPT4.1 环境准备与依赖安装我们假设使用 Python 作为后端语言构建一个 Web API 服务。以下是一个核心依赖列表# 核心框架 pip install fastapi uvicorn # 用于构建API服务器 pip install python-dotenv # 管理环境变量如API密钥 # AI与机器学习核心 pip install openai # 调用GPT API pip install transformers # 使用Hugging Face的模型如CLAP pip install torch torchaudio # PyTorch及音频处理 # 音频处理与特征提取 pip install librosa # 音频加载和分析 pip install soundfile # 音频文件读写 # 向量数据库与数据管理 pip install chromadb # 轻量级向量数据库 pip install pydub # 音频文件格式转换与切片 pip install requests # 调用外部音乐元数据API你需要准备以下关键资源OpenAI API 密钥用于访问 GPT 模型。一个初始音乐库可以是一些 MP3 文件或者使用 Spotify、Apple Music 的 API需申请开发者账号获取歌曲样本和元数据。请注意版权用于demo的歌曲应确保有合法使用权或使用无版权音乐。预训练模型权重例如从 Hugging Face 下载laion/clap-htsat-unfused模型。4.2 构建音乐特征向量库这是最基础的“基建”工作。我们使用 CLAP 模型来提取文本和音频的通用特征。import librosa import torch from transformers import ClapModel, ClapProcessor import chromadb from chromadb.config import Settings import numpy as np # 初始化CLAP模型和处理器 device cuda if torch.cuda.is_available() else cpu model ClapModel.from_pretrained(laion/clap-htsat-unfused).to(device) processor ClapProcessor.from_pretrained(laion/clap-htsat-unfused) # 初始化ChromaDB客户端和集合 chroma_client chromadb.PersistentClient(path./chroma_db) # 创建一个集合来存储歌曲向量指定嵌入函数维度CLAP是512维 collection chroma_client.get_or_create_collection( namemusic_vectors, metadata{hnsw:space: cosine} # 使用余弦相似度 ) def extract_audio_embedding(audio_path): 提取单首歌曲的音频特征向量 # 加载音频统一为单声道采样率44100CLAP模型期望的 audio, sr librosa.load(audio_path, sr44100, monoTrue) # 截取前30秒可根据需要调整 duration 30 # 秒 if len(audio) sr * duration: audio audio[:sr * duration] # 使用处理器准备输入 inputs processor(audiosaudio, sampling_ratesr, return_tensorspt, paddingTrue) inputs {k: v.to(device) for k, v in inputs.items()} # 提取特征 with torch.no_grad(): audio_features model.get_audio_features(**inputs) # 返回numpy数组并确保是1维向量 return audio_features.cpu().numpy().flatten() # 假设你有一个歌曲文件列表 song_files [song1.mp3, song2.mp3, ...] metadata_list [...] # 对应的元数据如 [{title: Song A, artist: Artist A}, ...] for i, (file_path, meta) in enumerate(zip(song_files, metadata_list)): print(fProcessing {file_path}...) try: embedding extract_audio_embedding(file_path) # 将向量和元数据存入ChromaDB collection.add( embeddings[embedding.tolist()], metadatas[meta], ids[fsong_{i}] # 唯一ID ) except Exception as e: print(fError processing {file_path}: {e})这段代码构建了一个本地的音乐特征搜索引擎。之后你可以用另一首歌的向量或者用CLAP模型将文本“忧郁的钢琴曲”转化为向量去这个库里进行相似度搜索。4.3 实现核心对话与任务调度逻辑这里我们使用 FastAPI 构建一个后端并集成 OpenAI 的 Function Calling。from fastapi import FastAPI, HTTPException from pydantic import BaseModel import openai import os from typing import List, Optional import json app FastAPI() # 配置OpenAI客户端 openai.api_key os.getenv(OPENAI_API_KEY) # 定义工具函数列表这些信息会提供给GPT tools [ { type: function, function: { name: search_songs_by_mood, description: 根据情绪、场景或风格描述搜索歌曲, parameters: { type: object, properties: { description: { type: string, description: 对歌曲情绪、场景或风格的文字描述例如适合学习时听的轻音乐、激昂的战斗背景音乐 }, top_k: { type: integer, description: 返回最相似歌曲的数量默认5, default: 5 } }, required: [description] } } }, { type: function, function: { name: get_song_details, description: 根据歌曲ID获取详细信息, parameters: { type: object, properties: { song_id: { type: string, description: 歌曲在数据库中的唯一ID } }, required: [song_id] } } } ] class UserQuery(BaseModel): message: str def search_songs_by_mood(description: str, top_k: int 5) - List[dict]: 实际执行搜索的函数 # 1. 将文本描述转换为向量 inputs processor(text[description], return_tensorspt, paddingTrue) inputs {k: v.to(device) for k, v in inputs.items()} with torch.no_grad(): text_features model.get_text_features(**inputs) query_embedding text_features.cpu().numpy().flatten() # 2. 在向量数据库中查询 results collection.query( query_embeddings[query_embedding.tolist()], n_resultstop_k ) # 3. 格式化结果 songs [] for i in range(len(results[ids][0])): songs.append({ id: results[ids][0][i], metadata: results[metadatas][0][i], distance: results[distances][0][i] # 相似度距离 }) return songs def get_song_details(song_id: str) - Optional[dict]: 获取歌曲详情 results collection.get(ids[song_id]) if results[metadatas]: return results[metadatas][0] return None app.post(/chat) async def chat_with_music_gpt(query: UserQuery): 主聊天端点 # 第一步将用户消息和工具定义发送给GPT让它决定是否调用工具 response openai.chat.completions.create( modelgpt-3.5-turbo, messages[ {role: system, content: 你是一个专业的音乐助手精通各类歌曲、流派和音乐知识。你可以使用工具来搜索歌曲或获取详细信息。请用中文与用户交流。}, {role: user, content: query.message} ], toolstools, tool_choiceauto, # 让模型自动决定是否调用工具 ) response_message response.choices[0].message tool_calls response_message.tool_calls # 第二步如果模型决定调用工具则执行对应的本地函数 if tool_calls: available_functions { search_songs_by_mood: search_songs_by_mood, get_song_details: get_song_details, } # 将模型回复添加到消息历史中 messages.append(response_message) for tool_call in tool_calls: function_name tool_call.function.name function_to_call available_functions.get(function_name) if function_to_call: function_args json.loads(tool_call.function.arguments) # 执行函数 function_response function_to_call(**function_args) # 第三步将工具执行结果作为新的消息发送给GPT让它生成最终回复 messages.append({ tool_call_id: tool_call.id, role: tool, name: function_name, content: json.dumps(function_response, ensure_asciiFalse), # 注意中文编码 }) # 获得模型结合工具结果后的最终回复 second_response openai.chat.completions.create( modelgpt-3.5-turbo, messagesmessages, ) final_reply second_response.choices[0].message.content else: final_reply response_message.content return {reply: final_reply}这个后端服务提供了一个/chat接口。当用户发送“给我找几首清晨跑步时听的歌”时GPT 会识别出需要调用search_songs_by_mood工具参数是description: “清晨跑步”。后端执行搜索将结果返回给 GPTGPT 再组织成如“我为你找到了以下几首适合清晨跑步的歌曲它们节奏轻快、充满活力...”这样的自然语言回复。4.4 前端界面快速搭建为了让体验更完整我们可以用一个简单的 HTML/JS 页面作为前端。!DOCTYPE html html head titleSongGPT - 你的音乐AI伙伴/title style body { font-family: sans-serif; max-width: 800px; margin: 0 auto; padding: 20px; } #chatbox { border: 1px solid #ccc; height: 400px; overflow-y: auto; padding: 10px; margin-bottom: 10px; } .user-msg { text-align: right; color: blue; margin: 5px 0; } .bot-msg { text-align: left; color: green; margin: 5px 0; } #inputArea { display: flex; } #userInput { flex-grow: 1; padding: 10px; } button { padding: 10px 20px; } /style /head body h1 SongGPT 音乐助手/h1 div idchatbox/div div idinputArea input typetext iduserInput placeholder输入你的音乐需求例如推荐一首下雨天听的歌 button onclicksendMessage()发送/button /div script const API_URL http://localhost:8000/chat; // 你的后端地址 function appendMessage(sender, text) { const chatbox document.getElementById(chatbox); const msgDiv document.createElement(div); msgDiv.className sender user ? user-msg : bot-msg; msgDiv.innerHTML strong${sender user ? 你 : 助手}:/strong ${text}; chatbox.appendChild(msgDiv); chatbox.scrollTop chatbox.scrollHeight; } async function sendMessage() { const inputField document.getElementById(userInput); const message inputField.value.trim(); if (!message) return; appendMessage(user, message); inputField.value ; try { const response await fetch(API_URL, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ message: message }) }); const data await response.json(); appendMessage(bot, data.reply); } catch (error) { console.error(Error:, error); appendMessage(bot, 抱歉服务暂时不可用。); } } // 按回车发送 document.getElementById(userInput).addEventListener(keypress, function(e) { if (e.key Enter) { sendMessage(); } }); /script /body /html将这个 HTML 文件保存用浏览器打开并将后端服务运行起来一个具备音乐推荐和对话能力的简易songGPT就搭建完成了。5. 进阶优化与扩展方向5.1 性能优化与缓存策略当音乐库规模增大到数万甚至数十万首时实时提取特征和全量向量检索会变得缓慢。优化策略包括离线预处理与增量更新所有歌曲的特征提取和向量入库必须在离线阶段完成。新歌曲加入时触发异步的预处理流水线。向量索引优化ChromaDB 默认使用 HNSW 算法对于大规模数据可以调整hnsw:construction_ef、hnsw:search_ef等参数在构建时间和搜索精度/速度之间取得平衡。对于超大规模百万级可以考虑Milvus或Pinecone这类专业的云端向量数据库。多级缓存查询缓存对完全相同的用户查询描述如“悲伤的情歌”进行缓存设定合理的过期时间。结果缓存对高频歌曲或特征向量进行内存缓存避免重复计算。模型缓存将加载的 CLAP 模型、处理器等常驻内存避免每次请求都重复加载。5.2 功能扩展从推荐到创作基础版本实现了基于描述的搜索。可以在此基础上扩展更多“技能”“听歌识曲”增强版允许用户上传一段音频片段哼唱或录音后端提取该音频的特征向量在库中进行搜索。这需要处理用户上传的音频并可能需要对哼唱和原曲之间的特征差异有一定的鲁棒性处理。个性化推荐引入用户历史交互数据。记录用户喜欢或跳过的推荐结果构建简单的用户偏好向量在推荐时进行加权融合实现“越用越懂你”。生成式功能深化歌词生成设计更精细的提示词模板结合特定歌手风格、押韵词典生成质量更高的歌词。简单旋律生成集成如Riffusion这样的模型。用户输入“一段布鲁斯口哨旋律”前端将生成描述发送给后端后端调用 Riffusion API 或本地模型生成一段音频返回给用户。歌单生成根据一个主题如“2024年夏季旅行歌单”让 GPT 生成一个歌曲名称列表然后调用搜索工具为列表中的每一首歌寻找库中最匹配的实体歌曲最终打包成一个可播放的歌单。多模态输入结合图像识别。例如用户上传一张夕阳海滩的照片先用图像描述模型生成文本“宁静的日落海滩”再将此文本作为描述输入音乐搜索模块。5.3 工程化与部署考量要将原型转化为可持续的服务需要考虑API 设计除了聊天端点可以提供独立的 RESTful API如POST /recommend(基于描述推荐)、POST /identify(音频识别)。错误处理与降级当某个工具如外部音乐生成 API失败时应有优雅的降级方案例如回复“暂时无法生成旋律但我可以为你推荐一些现有歌曲...”。日志与监控记录用户查询、模型调用、工具执行耗时和结果用于分析用户偏好和优化系统性能。成本控制GPT API 调用是主要成本。可以通过以下方式优化精心设计系统提示词减少不必要的交互轮次。对工具调用结果进行压缩或摘要后再喂给 GPT。对于常见问题可以构建一个标准问答对库优先进行匹配匹配成功则直接回复避免调用 GPT。部署使用 Docker 容器化应用通过FastAPI的异步特性处理并发。利用Nginx做反向代理和负载均衡。对于计算密集的特征提取任务可以考虑使用Celery等任务队列异步处理。6. 常见问题与避坑指南在实际开发和调试过程中你肯定会遇到各种问题。以下是一些典型问题及解决思路问题现象可能原因排查与解决思路推荐歌曲完全不相关1. 音频特征提取模型不匹配或未正确预处理音频。2. 文本描述向量化与音频向量不在同一语义空间。3. 向量数据库索引未正确构建或相似度度量方式不对。1.检查音频预处理确保所有音频采样率、通道数统一且截取片段有代表性如前奏或副歌部分。2.验证特征一致性用同一首歌的不同片段提取向量计算其相似度应该很高。用“摇滚”文本搜索看返回的是否多是摇滚歌曲。3.检查向量维度确保存入数据库的向量维度与查询向量维度完全一致。检查 ChromaDB 集合的metadata中距离度量如cosine设置是否正确。GPT 不调用工具总是自己瞎编1. 系统提示词中工具描述不够清晰。2. 工具函数定义的description或parameters描述不准确模型无法理解何时使用。3. 用户查询意图模糊。1.优化提示词在系统消息中明确强调“你必须使用我提供的工具来获取准确信息”。2.细化工具描述将工具的描述和参数描述写得极其具体、无歧义。例如将“搜索歌曲”改为“根据对歌曲情绪、风格、乐器或场景的文字描述在本地音乐库中搜索最匹配的歌曲”。3.引导用户在前端设计上可以给出一些查询示例引导用户提出更明确的请求。服务响应速度慢1. 每次请求都实时提取特征。2. 向量数据库检索未优化。3. GPT API 调用网络延迟高。1.坚持离线预处理所有入库歌曲的特征必须提前算好。2.优化检索确保向量数据库使用了索引如 HNSW。对于超大库限制返回数量top_k不要太大。3.设置超时与重试对 GPT API 调用设置合理的超时时间并实现重试机制。考虑使用异步调用避免阻塞。生成歌词或描述过于笼统、空洞GPT 缺乏足够的领域上下文或风格约束。提供示例Few-Shot Learning在系统提示词中加入几个高质量的示例。例如“用户写一段关于失恋的流行歌词。助手[这里是一段符合流行歌曲结构、押韵、带有具体意象的示例歌词]”。让模型模仿示例的风格和细节。处理用户上传音频失败音频格式不支持、文件损坏、或大小超限。1.前端校验在上传前检查文件格式mp3, wav, m4a等和大小。2.后端健壮性使用librosa或pydub时用try...except包裹加载代码对加载失败的音频返回友好错误。统一转换到模型支持的格式和采样率。避坑心得数据质量远大于模型复杂度一个精心整理的、标签准确的小规模音乐库比一个杂乱无章的大库效果要好得多。在项目初期花时间清洗和标注数据至关重要。分阶段实现不要试图一口气实现所有功能。先从最核心的“文本描述搜歌”开始跑通 RAG 的完整流程。然后再逐步加入音频搜索、歌词生成等高级功能。关注版权和法律风险这是音乐类应用的红线。用于 demo 和测试的音乐数据务必确保来源合法。考虑使用官方 API如 Spotify Web API来获取元数据和预览片段或者专注于处理用户自己拥有的音乐库。用户体验设计AI 的回复有时会冗长或偏离重点。可以在后端对 GPT 的回复进行后处理比如提取最关键的歌单列表置于开头或者限制回复长度。让交互结果更直接、有用。这个项目很好地展示了如何将大语言模型作为“大脑”与领域专用的“工具”和“知识”相结合构建出真正实用、有趣的垂直应用。整个过程涉及了现代 AI 应用开发的多个核心环节提示工程、RAG、向量检索、工具调用和系统集成。无论你是想学习这些技术还是想为自己打造一个独特的音乐伙伴songGPT都是一个绝佳的起点和灵感来源。