企业官网建设流程全解析

最近和一些做 AI 应用的朋友交流，聊得最多的一句话就是 “Startups are chasing the next big thing in LLMs”。模型能力在快速迭代，资本和创业者都在押注下一个爆发点，但真到了技术落地环节，很多团队的进展并没有想象中顺利。大家面对的是同一个问题：模型选哪一个，框架用哪一套，先做 API 调用还是直接私有化部署，知识库检索怎么做得准，线上成本怎么控制得住。

这篇文章不准备讨论某个具体模型发布，而是从开发者视角，把 LLM 应用开发这条链路完整拆开。你会看到 LLM 的核心能力边界、开发框架怎么选、环境怎么搭、一个知识库问答助手怎么从零写出来、部署时有哪些硬件和架构边界，以及创业团队在技术选型时容易忽略的几个工程问题。无论你是刚接触大模型的新手，还是已经在做应用落地的开发者，这份内容都可以作为一份系统性的参考。

1. LLM 应用开发：从概念到工程的真实门槛

1.1 LLM 到底解决了什么问题

大语言模型本质上是“文本到文本”的生成模型。它根据输入的提示词，逐 token 预测下一个最合适的 token，从而生成回答、摘要、代码、翻译等内容。它擅长的是把海量文本中学到的语言模式和知识，以自然语言的方式输出出来。

在业务场景里，这意味着很多原来需要人工完成的文本处理工作，现在可以交给模型来做：

• 客服对话：根据用户描述给出解答或引导。
• 文档知识问答：基于企业内部资料回答员工或客户问题。
• 内容生产：生成营销文案、产品描述、周报初稿。
• 代码辅助：代码补全、解释、单测生成、重构建议。
• 数据抽取：从非结构化文本中提取结构化字段。
• 智能体自动化：让模型调用工具、规划步骤、完成多轮任务。

但这里有一个关键认知：LLM 不是一个数据库，也不是搜索引擎。它不会精确记住你给它的一切，也不能保证生成内容一定真实。它是“基于概率的文本生成器”，回答得好不好，取决于模型能力、提示词设计、检索到的上下文，以及你对输出的约束方式。

1.2 当前 LLM 应用的主要形态

目前创业团队做的 LLM 应用，大概可以分成这几类：

第一类是对话增强型。在聊天窗口基础上加入行业知识和业务规则，典型就是智能客服、销售助手、培训陪练。这类应用对检索质量要求高，对回答的合规性也有很强约束。

第二类是知识库问答型（RAG）。把企业文档、PDF、网页内容切分、向量化后存起来，用户提问时先检索相关内容，再交给模型生成回答。这是目前落地最多、见效最快的方向，也是后面实战部分要重点演示的案例。

第三类是工作流自动化型（Agent）。让模型根据目标自动拆解步骤、调用 API、读取数据库、操作工具，最终完成一个完整的业务流程。比如自动生成周报、自动分类工单、自动完成竞品信息收集。这类应用对模型规划能力和工具调用稳定性要求很高。

第四类是内容生成工具型。面向编辑、运营、设计等角色，提供批量文案、图片描述、视频脚本、SEO 内容等生成能力。这类应用竞争激烈，需要靠场景模板和垂直数据做出差异化。

1.3 创业团队最容易忽略的三个环节

很多团队在 Demo 阶段跑得很快，接入一个 API、写一个 prompt、做一个聊天框，看起来就“成了”。但进入生产环境之后，真正消耗时间的反而是这些环节：

• 评测体系缺失。没有足够的测试问题和判断标准，无法知道新版本模型是变好还是变坏，也很难向客户证明回答质量。
• 成本意识不足。每一个调用都在消耗 token，长上下文、多次重试、频繁检索都会放大成本，不做成本控制的项目很难盈利。
• 安全和合规考虑滞后。用户输入会不会泄露到模型服务方，模型会不会生成违规内容，回答会不会包含未经授权的数据，这些问题在接入前就应当有答案。

这些环节不是“以后再说”的事，它们决定了应用能不能从 demo 走向可交付的产品。

2. 大语言模型的核心概念与能力边界

2.1 什么是大语言模型

大语言模型（Large Language Model，LLM）是一类基于 Transformer 架构、参数量达到数十亿甚至数千亿的神经网络模型。它通过在海量语料上进行预训练，学习语言的统计规律和世界知识。用户输入一段文本，模型会预测下一个最可能的 token，并不断重复这个过程，直到生成完整回答。

从开发者视角看，你不需要理解每一个注意力头，但需要理解几个关键概念：

• Token：模型处理文本的最小单位。一个 token 可能是一个完整的英文单词，也可能是一个汉字或一个子词。不同模型的 tokenizer 不一样。
• 上下文窗口（Context Window）：模型一次能看到的输入和输出总长度。窗口越大，能处理的文档越长，但显存开销和成本也会增加。
• Temperature：控制输出随机性。值越高回答越发散，值越低回答越稳定。知识问答场景通常调到 0.1~0.3。
• Max Tokens：控制单次生成的最大长度。不是设置得越大越好，因为生成的时间成本和费用都会上升。

2.2 当前模型接入方式正在融合

如果你观察最近一年的模型服务，会发现一个明显的趋势：不同厂商的 API 正在向 OpenAI 兼容格式靠拢。也就是说，你只需要修改base_url、api_key和model名称，很多代码可以直接复用。这对开发者是很大的利好，意味着应用层不用被单一厂商绑定。

本地部署的模型也可以通过 vLLM、Ollama、FastAPI 等工具暴露成兼容接口。这就形成了一种很灵活的接入方式：

• 早期验证用云端 API，快速验证效果。
• 需要私有化时把模型切到本地推理服务。
• 应用层代码基本不变，只需要修改配置文件。

这也是为什么很多团队在建“模型网关”或者“模型路由层”，目的就是让上层应用感知不到底层模型的变化。

2.3 LLM 能做与不能做的事

先把边界讲清楚，可以减少很多无效尝试。

** LLM 擅长的事情**

• 文本总结、改写、扩写、翻译。
• 从非结构化文本中抽取实体、关系、关键词。
• 基于给定上下文做问答，比如 RAG 场景。
• 代码生成、解释、Debug 辅助。
• 多轮对话中的意图理解和信息汇总。
• 生成结构化输出，比如 JSON、表格、Markdown。

** LLM 不擅长的事情**

• 精确计算：四则运算容易出错，复杂逻辑最好把计算交给代码。
• 实时信息：训练数据有截止时间，需要接入搜索或数据源。
• 事实核对：模型会“自信地胡说”，也就是幻觉。
• 超长精确记忆：即使上下文窗口够大，模型也容易在长文本中遗漏细节。
• 多跳推理：步骤较多、逻辑链条较长的任务，失误率会明显上升。

理解了这些边界，你在做技术方案时就会更理智：能检索的不要让模型硬背，能计算的不要让模型心算，能代码处理的不要把逻辑交给 prompt。

3. 技术栈与开发框架选型

3.1 自建模型、调用 API 还是开源模型私有化

创业团队第一个要决定的事情，就是模型从哪里来。

调用云端 API 是起步最快的方式。优点是不需要 GPU 成本，不用关心模型部署，可以快速验证产品方向。缺点是长期看 token 成本会随调用量增长，同时数据会经过第三方服务，部分行业客户不接受。

开源模型私有化适合对数据安全要求高的场景，比如金融、政务、医疗、企业内部知识管理。国内可以选择的开源模型也比较多，比如 Qwen、DeepSeek、ChatGLM、Yi 等系列，各有不同的参数规模和授权协议。私有化的代价是硬件投入、运维成本和持续的模型调优投入。

自建模型训练是成本最高、周期最长的路径，除非你的团队有很强的算法基因和充足的预算，否则不建议创业初期选择这条路线。

我的建议是：产品验证阶段用 API，跑通之后再根据客户需求决定是否私有化。模型层做抽象，让切换成本降到最低。

3.2 常见 LLM 开发框架盘点

框架选择没有绝对标准，按团队技术栈和业务类型来选择更合理。

LangChain / LangGraph：LangChain 是最早火起来的 LLM 应用编排框架，封装了模型调用、提示词模板、记忆、工具调用、Agent 等模块。LangGraph 是它的升级方向，用图的方式来编排复杂流程，更适合需要清晰控制流程的 Agent 应用。适合有一定开发能力、需要深度定制逻辑的团队。

LlamaIndex：专注于数据索引和检索增强生成，对 RAG 的支持非常细致，适合做知识库、文档问答这类以检索为核心的应用。如果你主要在做“给模型加知识”这件事，可以重点关注它。

Dify / FastGPT：这两个是开源的可视化 LLMOps 平台，提供完整的 Web 界面，可以拖拽配置工作流、知识库、模型接入、日志查看。适合产品团队快速搭建 MVP，或者给非技术成员配置运营后台。Dify 更偏向通用 LLMOps，FastGPT 在知识库问答和在线客服场景使用很广。

Semantic Kernel：微软出品的 SDK，支持 C#、Python、Java，和微软生态结合紧密，适合 .NET/Java 背景的企业级团队。

Spring AI：Java 生态的 LLM 应用框架，如果你所在团队以 Java 为主，想让 LLM 能力和 Spring Boot 项目结合，可以关注这个方向。

3.3 框架选型决策表

无论选哪个框架，都要意识到：框架是工具，不是护城河。真正决定应用质量的是你的数据质量、流程设计、评测机制和工程化水平。

4. 环境准备与模型接入

4.1 开发环境

本文的实战案例以 Python 为例，建议使用 Python 3.10 及以上版本。你需要准备：

• Python 3.10+，建议使用 venv 创建虚拟环境。
• 一个可用的大模型 API，或本地启动的兼容 OpenAI 格式的服务。
• 一个向量化用的 Embedding 模型接口。
• 代码编辑器和终端。

创建虚拟环境并安装依赖：

python -m venv venv source venv/bin/activate # Windows 使用 venv\Scripts\activate pip install openai==1.30.0

版本需要根据你的项目实际情况调整，本文示例以常见环境为例，重点演示配置思路。

4.2 通过 API 调用大模型

无论你使用的是哪家模型服务，只要接口兼容 OpenAI 格式，代码结构都差不多。以 Python 为例：

import os from openai import OpenAI client = OpenAI( api_key=os.getenv("LLM_API_KEY"), base_url=os.getenv("LLM_BASE_URL", "https://api.openai.com/v1"), ) resp = client.chat.completions.create( model="your-chat-model", messages=[ {"role": "system", "content": "你是一个知识库问答助手，回答尽量简洁准确。"}, {"role": "user", "content": "什么是大语言模型的上下文窗口？"}, ], temperature=0.2, ) print(resp.choices[0].message.content)

关键点解释：

• LLM_API_KEY和LLM_BASE_URL建议通过环境变量或配置中心管理，不要硬编码在代码里。
• model名称要根据你申请到的服务填写，不同服务商命名不一样。
• temperature=0.2适合知识问答，减少随机性。
• messages列表用于传多轮对话，系统提示词可以约束回答风格。

如果你使用本地部署的模型，只需要把base_url指向本地服务的地址，例如：

export LLM_BASE_URL=http://localhost:8000/v1 export LLM_API_KEY=not-needed

这种方式把应用和模型服务解耦，底层模型随时可以替换。

4.3 Embedding 模型与向量化

RAG 应用里除了对话模型，还需要一个 Embedding 模型，用来把文本转换成向量。Embedding 模型的作用是让语义相近的文本在向量空间里距离更近。

调用方式也很简单：

def get_embedding(text: str): resp = client.embeddings.create( model="your-embedding-model", input=text, ) return resp.data[0].embedding

需要注意，Embedding 模型和对话模型通常是两个独立的模型，需要分别开通或部署。不同 Embedding 模型的向量维度不一样，常见的有 256 维、768 维、1024 维、1536 维等。你在存储向量时要注意维度的一致性。

5. 完整实战：手写一个知识库问答助手

5.1 需求分析

知识库问答是 LLM 应用里落地价值最明确的方向。它的核心流程是：用户提出一个问题，系统先从知识库中检索出最相关的几段内容，再把这些内容拼进提示词，让模型基于给定资料生成回答。

为什么不能直接把整篇文档塞给模型？

• 文档可能超过上下文窗口长度。
• 无关内容会干扰模型回答质量。
• 每次把全部文档作为上下文，成本会非常高。

所以 RAG 的标准流程是：先切分，再向量化，然后检索，最后生成。

5.2 系统设计

完整流程如下：

用户问题 ↓ 文本向量化（Embedding） ↓ 向量相似度检索（Top-K） ↓ 拼接检索结果 + 问题 ↓ 大模型生成回答 ↓ 输出结果

对应到工程实现，需要完成这几个模块：

• 文档加载：读取本地文本文件。
• 文本切分：把长文本切成固定大小的块，块与块之间保留重叠。
• 向量化：调用 Embedding 接口为每个文本块生成向量。
• 索引存储：把向量和文本保存在内存中，生产环境建议用向量数据库。
• 检索：计算用户问题的向量与所有文本块向量的余弦相似度，取 Top-K。
• 生成：把检索到的文本块和用户问题组装成 Prompt，调用对话模型。

5.3 项目结构与依赖

我们建一个简单项目，目录结构如下：

rag_demo/ ├── requirements.txt ├── config.py ├── main.py └── docs/ └── sample.txt

requirements.txt内容：

openai==1.30.0

我们先在docs/sample.txt里放一段公司产品介绍或技术文档，作为知识库数据来源。这里以一段示例文本为例，你可以替换成自己的文档。

5.4 核心代码实现

先看config.py，统一管理模型配置：

import os LLM_API_KEY = os.getenv("LLM_API_KEY", "") LLM_BASE_URL = os.getenv("LLM_BASE_URL", "https://api.openai.com/v1") CHAT_MODEL = os.getenv("CHAT_MODEL", "your-chat-model") EMBEDDING_MODEL = os.getenv("EMBEDDING_MODEL", "your-embedding-model") CHUNK_SIZE = 500 CHUNK_OVERLAP = 50 TOP_K = 3 TEMPERATURE = 0.2

然后写main.py，完整代码如下：

import os from openai import OpenAI from config import ( LLM_API_KEY, LLM_BASE_URL, CHAT_MODEL, EMBEDDING_MODEL, CHUNK_SIZE, CHUNK_OVERLAP, TOP_K, TEMPERATURE, ) client = OpenAI( api_key=LLM_API_KEY, base_url=LLM_BASE_URL, ) def get_embedding(text: str): """生成文本向量""" resp = client.embeddings.create( model=EMBEDDING_MODEL, input=text, ) return resp.data[0].embedding def split_text(text: str, chunk_size: int = CHUNK_SIZE, overlap: int = CHUNK_OVERLAP): """按固定长度切分文本，保留重叠区间""" chunks = [] start = 0 while start < len(text): end = start + chunk_size chunk = text[start:end] chunks.append(chunk) if end >= len(text): break start = end - overlap return chunks def cosine_similarity(vec_a, vec_b): """计算两个向量的余弦相似度""" dot = sum(x * y for x, y in zip(vec_a, vec_b)) norm_a = sum(x * x for x in vec_a) ** 0.5 norm_b = sum(x * x for x in vec_b) ** 0.5 if norm_a == 0 or norm_b == 0: return 0.0 return dot / (norm_a * norm_b) def build_index(doc_path: str): """加载文档、切分、向量化，返回文本块列表和向量列表""" with open(doc_path, encoding="utf-8") as f: text = f.read() chunks = split_text(text) vectors = [] for i, chunk in enumerate(chunks): print(f"正在向量化第 {i + 1}/{len(chunks)} 个文本块...") vectors.append(get_embedding(chunk)) return chunks, vectors def search(chunks, vectors, query: str, top_k: int = TOP_K): """检索与问题最相关的文本块""" query_vec = get_embedding(query) scored = [] for i, vec in enumerate(vectors): score = cosine_similarity(query_vec, vec) scored.append((score, i)) scored.sort(reverse=True) top_indices = [idx for _, idx in scored[:top_k]] return [chunks[idx] for idx in top_indices] def generate_answer(query: str, context_chunks): """基于检索结果生成回答""" context = "\n\n".join(context_chunks) prompt = f"""你是一名知识库问答助手。请根据下面的资料回答问题。 如果资料中没有相关内容，请明确回答“资料中未找到相关内容”，不要编造。 资料： {context} 问题：{query} 回答：""" resp = client.chat.completions.create( model=CHAT_MODEL, messages=[ {"role": "system", "content": "你是一个严谨的知识库问答助手。"}, {"role": "user", "content": prompt}, ], temperature=TEMPERATURE, ) return resp.choices[0].message.content def main(): doc_path = "docs/sample.txt" if not os.path.exists(doc_path): print("请先在 docs/ 目录下创建 sample.txt") return print("1. 开始构建索引...") chunks, vectors = build_index(doc_path) print(f"索引构建完成，共 {len(chunks)} 个文本块。") while True: query = input("\n请输入问题（输入 exit 退出）：").strip() if query.lower() == "exit": break print("2. 正在检索相关内容...") context_chunks = search(chunks, vectors, query) print("3. 正在生成回答...") answer = generate_answer(query, context_chunks) print("\n===== 回答 =====") print(answer) if __name__ == "__main__": main()

5.5 运行验证与结果说明

运行前先设置环境变量：

export LLM_API_KEY="你的API密钥" export LLM_BASE_URL="你的模型服务地址" export CHAT_MODEL="你的对话模型名称" export EMBEDDING_MODEL="你的向量模型名称"

然后运行：

python main.py

预期流程是：

1. 程序读取文档并切分文本块。
2. 逐个文本块调用 Embedding 接口，生成向量。
3. 进入交互式问答环节。
4. 你输入问题后，程序检索最相关的 3 个文本块。
5. 模型根据检索内容生成回答。

这个实现只用了openai一个依赖，适合理解 RAG 的原理。生产环境通常会把向量存到 Chroma、Milvus、Qdrant、pgvector 等向量数据库，用批量 embedding 提升索引速度，并用异步调用减少用户等待时间。

6. 部署形态与硬件边界：LLM 必须本机部署吗

6.1 “ComfyUI 与 LLM 必须在同一台电脑上么”的类似问题

经常有人在技术群里问：ComfyUI 与 LLM 必须要在同一台电脑上么？这个问题本质上是关于“资源部署边界”的疑问。

ComfyUI 是 Stable Diffusion 生态里的节点式工作流工具，依赖 GPU 做图像生成。LLM 应用可能是调用云端 API，也可能是在本地起一个模型推理服务。两者并不是同一类软件，也没有“必须同机”的强制关系。

关键在于：你采用哪种部署形态。

• 如果 LLM 应用只是调用云端 API，那么 ComfyUI 在本地跑，LLM 在云端跑，完全没问题。
• 如果 LLM 也在本地部署，那么 ComfyUI 和本地 LLM 服务可以在同一台机器，也可以分别部署在不同机器，通过网络互相访问。
• 如果两个都是云端服务，更不需要关心所谓的“同一台电脑”。

判断依据是三个因素：算力资源是否足够、网络是否连通、数据是否允许跨机传输。

6.2 本地 GPU 部署的适用场景

本地部署 LLM 主要为了解决数据安全或长期成本问题。但本地部署并不是免费的，它需要硬件投入和运维成本。

以常见的开源模型为例：

• 7B 参数模型量化后大约需要 6GB~10GB 显存，配合一定内存可以跑起来。
• 14B 参数模型通常需要 16GB 以上显存。
• 70B 参数模型需要 40GB 以上显存，或者多卡并行。

具体数值会因量化方式、上下文长度、部署框架而不同，以你的实际测试为准。这里想强调的是：本地部署的底线不是“能装”，而是“能用”。单用户测试和多人并发是两个完全不同的量级。

如果团队早期没有足够的 GPU 资源，用云端 API 是更稳妥的选择。等验证了产品需求、有了真实客户付费，再考虑用开源模型做私有化交付，这个顺序更符合创业团队的资源约束。

6.3 远程 API + 本地应用的混合架构

在实际业务中，更常见的架构是“混合模式”：

• 桌面端或 Web 端应用部署在企业内网。
• LLM 推理统一走内部模型网关，网关背后可以是云端 API，也可以是本地 GPU 集群。
• 企业知识库、业务数据库和文档存储保持在内网，只有脱敏后的文本片段会发送到模型服务。
• 图像生成类工作流（比如 ComfyUI）根据资源情况部署在独立的 GPU 机器上，与应用服务器分开。

这种架构的好处是每个组件可以独立扩缩容，互不影响。图像生成吃 GPU，聊天问答吃 API 配额，知识库检索吃 CPU 和内存，它们不应该被绑在一台机器上。

所以回答开头那个问题时很简单：LLM 应用不需要和 ComfyUI 在同一台电脑上，重要的是你的模型服务、应用服务和图像生成服务之间网络互通，以及数据流转符合业务合规要求。

7. 常见问题与排查思路

7.1 高频问题排查表

7.2 系统化排查思路

遇到 LLM 应用问题，建议按“输入 → 检索 → 生成 → 输出”四个环节来排查：

1. 先确认问题是不是由用户输入引起的，比如输入了不支持的语言、包含无关指令。
2. 再看检索结果，检查召回的内容是否和问题相关。如果检索就不相关，后续生成大概率也不对。
3. 然后看 Prompt 组装，检查上下文是否被截断、格式是否正确、指令是否清晰。
4. 最后看模型输出，判断是格式问题、长度问题，还是内容正确但表达不符合预期。

排查中最推荐的调试方法是“逐层打印日志”。尤其是 RAG 应用，一定要把“最终发给模型的 Prompt”打印出来。很多时候问题不在模型，而在检索结果和 Prompt 拼接质量。

8. 创业团队切入 LLM 的方向与最佳实践

8.1 值得关注的切入方向

回到文章标题：Startups are chasing the next big thing in LLMs。那么对创业团队来说，哪些方向更值得尝试？

垂直行业的 RAG 应用。通用问答已经被大厂覆盖，但某个细分行业的专业问答仍然存在信息差。比如医疗文献解读、法律条款检索、金融研报分析、设备维修手册查询。这类场景门槛在于领域数据的整理和知识体系的构建，模型本身反而不是壁垒。

Agent 驱动的业务流程自动化。企业里有大量重复性、跨系统的流程，比如售后工单处理、合同初审、简历筛选、库存对账。Agent 可以调用现有系统 API，把原来需要人工往返操作的事情自动化。这个方向的核心不是模型能力，而是流程设计、工具接入和异常处理。

LLM 评测与可观测性工具。随着更多企业使用 LLM，评测需求会越来越强烈。怎么做回归测试、怎么做线上质量监控、怎么评估 RAG 检索质量，这些都是可以产品化的方向。

数据侧服务。很多企业有文档，但文档混乱、格式多样、更新频繁，没法直接做 RAG。提供数据清洗、结构化抽取、知识库构建服务，也是一个务实的切入点。

8.2 需要谨慎的方向

有几个方向，创业团队要特别谨慎：

重复建设“通用大模型”。基础模型训练对资金、算力和算法人才要求极高，头部玩家的优势和规模效应非常明显。除非有特别独特的资源，否则不建议正面竞争。

只做“套壳”应用，没有数据或渠道壁垒。单纯把 API 包一层 UI，没有差异化数据、没有独占渠道、没有深的业务流程绑定，很容易被大厂的功能更新覆盖。

忽略商业化闭环。LLM 应用的 token 成本是刚性的，如果用户付费意愿不高，或者客单价无法覆盖调用成本，商业模式很难成立。

早期就投入私有化部署。在没有验证需求前，购买 GPU 服务器、组建模型运维团队，会严重消耗创业公司的现金储备。

8.3 工程化建议

第一，Prompt 也要做版本管理。把 prompt 放到配置中心或代码仓库里，每次修改记录变更原因。不要散落在代码各处，更不要只在线上临时调试。

第二，RAG 的质量取决于数据治理。文本切分方式、数据更新机制、文档去重、权限控制，这些都需要认真设计。建议每次数据更新后，对检索效果做一次回归验证。

第三，输出结构化，降低集成成本。要求模型输出 JSON 而不是纯文本，可以让下游系统更容易解析。注意设置合理的response_format约束，并对解析失败做兜底。

第四，统计成本和延迟。每个请求记录模型名、输入 token 数、输出 token 数、耗时和错误码。成本上涨通常是突发的，比如某个用户上传了超长文档触发大批量 embedding，没有监控很难及时发现。

第五，建立最小评测集。准备 20~50 个典型问题，每次换模型、改 prompt、改检索参数时，都拿同一批问题跑一遍，人工或自动判断回答质量。这个最小评测集能帮你避免“改坏了自己都不知道”的情况。

第六，重视安全边界。用户输入发送到外部模型前要脱敏；模型输出展示给用户前要过滤敏感内容；系统 prompt 里要约束“只基于资料回答，不编造”。企业内部使用时，还要按最小权限原则控制知识库的访问范围。

9. 下一步学习路线

如果你刚刚开始接触 LLM 应用开发，建议按下面的顺序往下深入：

1. 先理解 RAG：把本文的代码多跑几遍，改改文本切分长度、调整 Top-K，感受不同参数对回答的影响。
2. 再学习 Agent：了解函数调用（Function Calling）、工具定义、多步规划，做一个能查天气、能查数据库的小 Agent。
3. 接着深入评测：学着建立评测集，用客观指标评估回答质量，而不是只靠肉眼判断。
4. 然后研究部署优化：了解 vLLM、Ollama、量化推理，搞清楚本地部署的性价比边界。
5. 最后关注 LLMOps：学习模型网关、Prompt 管理、日志追踪、成本监控，把应用做到生产可用。

方向判断比模型选择更重要。模型会持续迭代，框架会不断变化，但一个团队对业务场景的理解、对数据质量的把控、对工程细节的认真程度，才是真正能沉淀下来的竞争力。现在去写代码、建评测、记录每一次实验结论，比讨论“哪个模型更强”更有价值。