企业官网建设流程全解析

1. 项目概述：这不是一份清单，而是一张大模型应用的实战地图

“awesome-llm-apps”这个标题乍看像 GitHub 上常见的那种聚合型资源列表——一堆链接堆在一起，点开是五花八门的项目名。但如果你真把它当普通清单去收藏、去 star，大概率会在三个月后发现：90% 的项目跑不起来，70% 的 README 写得像天书，剩下那点能跑通的，要么严重依赖特定 GPU 型号，要么一升级依赖就报错“ModuleNotFoundError: No module named 'langchain_community'”。我从 2023 年初开始系统性地跟踪、搭建、压测、废弃、重写各类 LLM 应用，光是本地部署失败的 RAG 知识库项目就超过 47 个，其中 32 个卡在向量数据库 schema 设计环节，8 个死于文档解析时的 PDF 表格识别错位，还有 7 个倒在了 query rewrite 模块对中文长尾问句的语义坍缩上。所以，“awesome-llm-apps”真正的价值，从来不是“有哪些”，而是“哪些能真正落地、在哪种场景下稳定可用、为什么别人能跑通而你不行”。它本质上是一张经过千次实操验证的大模型应用可行性热力图：横轴是技术栈成熟度（LangChain v0.1.x vs LlamaIndex v0.10.x vs 自研 pipeline），纵轴是业务复杂度（单文档问答 vs 多源异构知识融合 vs 实时决策闭环），而每一个被标记为“✅ 可投产”的项目点，背后都对应着一套可复用的环境约束、数据预处理规范、fallback 机制设计和监控埋点方案。比如你搜到一个标榜“支持中文 RAG”的项目，它没写清楚用的是 sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2 还是 bge-m3，也没说明 chunk size 是按 token 数切还是按语义段落切，更没提 embedding 向量维度是否与 Milvus collection 预设一致——这些看似琐碎的细节，就是你本地调试两小时却连第一条检索结果都出不来的根源。这篇文章不讲抽象概念，不列空洞架构图，只拆解真实世界里跑得动、扛得住、改得快的 LLM 应用项目，从代码仓库的第一行 git clone 开始，到生产环境的 CPU 占用率曲线收尾。

2. 项目整体设计逻辑：为什么“awesome”必须建立在“可验证”之上

2.1 “Awesome”不是主观评价，而是可量化的工程指标

很多人误以为“awesome-llm-apps”这类项目的核心是“多”——项目数量越多越 awesome。这是典型的技术浪漫主义陷阱。我在某头部电商做智能客服中台时，团队初期也建了一个包含 126 个开源 LLM 工具的内部 Wiki，结果上线三个月后，真正接入线上流量的只有 3 个：一个基于 LangChain + Chroma 的 FAQ 快速应答模块（QPS 1200+，P99 延迟 < 800ms），一个用 LlamaIndex + Qdrant 实现的售后政策动态检索服务（支持 23 类模糊表述映射到标准条款），还有一个自研的轻量级 Agent 调度器（用于协调库存查询、物流追踪、退换货规则三个子服务）。其余 123 个项目全部被归入“技术预研区”，原因高度一致：缺乏可验证的 SLO（Service Level Objective）声明。一个真正值得标注为 “awesome” 的项目，必须在 README 或 benchmark 目录里明确写出三组数字：

• 吞吐能力：在 M1 Ultra（或等效 A10G）环境下，单节点每秒可处理多少条标准 query（如“我的订单 20240517XXXXX 物流停在哪了？”）
• 精度基线：在自有测试集（至少 500 条人工标注的真实用户问句）上，top-1 检索准确率 ≥ 92%，生成答案事实一致性 ≥ 88%
• 资源水位：冷启动内存占用 ≤ 1.8GB，持续运行时 GPU 显存峰值 ≤ 4.2GB（A10G），CPU 平均负载 ≤ 65%

没有这三组数字的项目，无论 star 数多高、作者多有名，我都直接划入“观察名单”。因为 LLM 应用不是学术论文，它的价值最终要折算成客服人力节省小时数、销售转化率提升百分点、或研发需求响应周期缩短天数。我见过太多“惊艳 demo”：前端界面炫酷，输入“帮我写一封辞职信”，三秒生成文采斐然的 Word 文档——但它背后调用的是 gpt-3.5-turbo API，且未做任何 content safety 过滤，一旦用户输入“帮我伪造一份离职证明”，系统真会输出带公章 PS 图层的 PDF。这种项目再“awesome”，也是业务雷区。

2.2 架构选型的本质：在“胶水层复杂度”和“领域适配深度”间找平衡点

当前主流 LLM 应用框架有三类典型路径，它们不是技术优劣之分，而是工程取舍之选：

关键洞察在于：LangChain 的“低门槛”是用运行时不确定性换来的，LlamaIndex 的“高精度”是以学习曲线陡峭为代价的，而自研 pipeline 的“高稳定性”则要求你亲手把每个螺丝拧紧。比如处理一份《医疗器械经营质量管理规范》PDF，LangChain 的PyPDFLoader会把页眉页脚、表格边框线全当正文解析，导致 embedding 向量污染；LlamaIndex 的PDFReader虽能跳过页眉，但遇到跨页表格时会把同一行数据拆成两条独立记录；而我们自研的解析器，先用pdfplumber提取原始文本坐标，再用规则引擎识别表格区域，最后将单元格内容按语义关系重组为 JSON 结构化数据——多花 40 小时开发，换来的是法规条款检索准确率从 73% 提升至 96.5%。

2.3 开源项目的“死亡螺旋”：为什么 80% 的项目活不过 6 个月

我维护了一个追踪表，统计了 2023 年 GitHub Trending 榜单上前 100 名 LLM 项目的生命体征：

• 3 个月存活率：61%（主要死于依赖版本冲突，如 langchain-core 0.1.14 与 langchain-community 0.0.32 不兼容）
• 6 个月存活率：29%（核心死因是作者停止维护，README 中的pip install -e .命令在新 Python 3.11 环境下报错）
• 12 个月存活率：7%（幸存者几乎全是工具链底层项目，如 llama.cpp、ollama、text-generation-webui）

这揭示了一个残酷现实：LLM 应用层开源项目正陷入“快速迭代—用户激增—维护崩溃—用户流失”的死亡螺旋。根本原因在于，绝大多数项目把“功能丰富”当作第一目标，却忽视了“可维护性”这个生存底线。一个健康的开源 LLM 应用项目，必须具备三项“反脆弱”设计：

1. 依赖锁定机制：requirements.txt中不能出现langchain>=0.1.0这类宽松约束，而应精确到langchain==0.1.16+langchain-community==0.0.36，并附带pip-check验证脚本；
2. 环境隔离声明：明确标注最低可行 Python 版本（如Python >= 3.9, < 3.12），禁止使用sys.version_info.minor > 10这类危险判断；
3. 降级通道设计：当向量数据库不可用时，自动切换至 BM25 关键词检索；当 LLM 生成超时，返回缓存中的历史相似答案并标记“[AI 生成中]”。

我在重构公司内部 RAG 平台时，强制要求所有新接入项目必须通过这三项检查，结果上线首月故障率下降 82%，运维同学终于不用半夜爬起来重启服务了。

3. 核心模块深度拆解：从代码仓库到生产环境的完整链路

3.1 文档解析与分块：别再迷信“自动切分”，中文需要规则+模型双驱动

几乎所有 RAG 项目崩溃的第一站，都是文档解析环节。你以为UnstructuredLoader能完美处理 PDF？实测某银行《个人理财业务管理办法》扫描件，其 OCR 识别错误如下：

• 将“第十七条”识别为“第十七奈”
• 把表格中“预期收益率（年化）”识别成“预期收益牢（年化）”
• 完全忽略页脚“本办法由总行零售金融部负责解释”这一关键责任主体声明

更致命的是，通用分块策略对中文业务文档完全失效。LangChain 默认RecursiveCharacterTextSplitter按字符切分，chunk_size=512，结果把一条完整的风控规则：“客户风险承受能力评估结果有效期为一年，到期后须重新评估”硬生生切成两段，前段在 chunk A，后段在 chunk B——检索时用户问“评估结果有效期多久？”，系统只能召回包含“有效期为一年”的 chunk A，却无法关联到“到期后须重新评估”这一关键动作，生成答案变成“一年”，漏掉强制重评义务，引发合规风险。

我的实操方案（已在 3 个金融项目落地）：

1. 预处理层：规则引擎先行

   • 用正则匹配中文标题层级：^第[零一二三四五六七八九十百千]+条\s+→ 标记为section_header
   • 识别表格区域：pdfplumber提取所有rect对象，计算纵横比 > 3 的视为表格，单独提取
   • 清洗 OCR 噪声：构建金融术语纠错词典（如“奈”→“条”、“牢”→“率”、“付”→“负”），用 Levenshtein 距离 ≤ 1 时自动替换

2. 分块层：语义感知切分

   # 替代 RecursiveCharacterTextSplitter 的核心逻辑 class ChineseSemanticSplitter: def __init__(self, max_tokens=384): self.tokenizer = AutoTokenizer.from_pretrained("bert-base-chinese") self.max_tokens = max_tokens def split_documents(self, docs): chunks = [] for doc in docs: # 优先按标题切分 sections = re.split(r'(第[零一二三四五六七八九十百千]+条\s+)', doc.page_content) for i, section in enumerate(sections): if not section.strip() or re.match(r'第[零一二三四五六七八九十百千]+条\s+', section): continue # 对每个章节内容，按句号/分号/换行符切分句子 sentences = re.split(r'[。；！？\n]+', section) current_chunk = "" for sent in sentences: if not sent.strip(): continue # 计算当前 chunk + 新句子的 token 数 test_chunk = current_chunk + sent + "。" token_count = len(self.tokenizer.encode(test_chunk)) if token_count <= self.max_tokens: current_chunk = test_chunk else: if current_chunk: chunks.append(Document(page_content=current_chunk.strip(), metadata=doc.metadata)) current_chunk = sent + "。" if current_chunk: chunks.append(Document(page_content=current_chunk.strip(), metadata=doc.metadata)) return chunks

3. 后处理层：注入结构化元数据

   • 每个 chunk 添加metadata字段：{"source": "policy_v2024.pdf", "page": 12, "section": "第三章 第二十二条", "is_table": False}
   • 对表格 chunk，额外添加table_context字段，存储表头与关键行的语义摘要（如“本表列示 2024 年各期限理财产品预期收益率区间”）

这套方案将金融文档的 chunk 语义完整性从 58% 提升至 93%，配合后续的 embedding 微调，top-1 检索准确率稳定在 91.2% ± 0.7%。

3.2 向量检索与重排序：为什么“Embedding + FAISS”只是起点，不是终点

很多教程告诉你：“装好 sentence-transformers，用model.encode()得到向量，丢进 FAISS 就完事”。这在玩具数据集上确实能跑通，但放到真实业务中，问题立刻暴露：

• 语义鸿沟问题：用户问“怎么查我的基金持仓？”，embedding 向量与文档中“基金份额查询流程”距离很远，因为前者是口语化短句，后者是正式术语
• 一词多义问题：文档中“头寸”指资金余额，用户问“我的头寸够不够买新基金？”时，系统可能召回关于“股票头寸管理”的风控条款
• 长尾覆盖不足：FAISS 的 IVF-PQ 索引对低频 query（如“赎回 T+1 到账失败怎么办？”）召回率骤降至 41%

我的生产级解决方案：Hybrid RAG（混合检索）四层架构

关键实现细节：

• Milvus 集合设计：启用auto_id=False，用业务主键（如policy_id:section_id）作为 vector id，便于精准更新
• bge-m3 微调：在自有金融 QA 数据集上 LoRA 微调，重点强化“查询类”query 与“操作类”文档的匹配度
• reranker 部署：用 ONNX Runtime 加速，单次重排序耗时从 1200ms 降至 210ms（A10G）

提示：不要在生产环境用chromadb，其默认的hnswlib索引在百万级向量时内存泄漏严重；也不要迷信qdrant的“云原生”，其集群模式在跨 AZ 网络抖动时会出现 silent failure——我们实测过，用milvus+pymilvus的组合，在 2000 万向量规模下 P99 延迟稳定在 320ms，且支持无缝扩缩容。

3.3 LLM 生成与编排：Agent 不是魔法，是状态机+工具调用的精密舞蹈

“LLM powered autonomous agents” 这个热词让很多人以为 Agent 就是给 LLM 加个tools参数然后坐等奇迹。真相是：一个可靠的 Agent，90% 的代码量在状态管理、错误恢复和工具契约校验上。以我们做的“智能投顾助手”为例，用户问：“帮我分析下这只基金（代码：000001）和沪深300指数近一年的相关性，画个图”。一个 naive 的 Agent 会：

1. 调用基金工具查 000001 净值 → 成功
2. 调用指数工具查沪深300 → 成功
3. 调用计算工具算相关系数 → 成功
4. 调用绘图工具生成图表 →失败！因为传入的日期范围格式错误

结果整个流程中断，用户看到“抱歉，无法完成请求”。而生产级 Agent 的设计必须包含：

• 状态机定义：用graphviz可视化状态流转（idle → fetching_fund → fetching_index → calculating → plotting → success/error）
• 工具契约校验：每个 tool 调用前，用 Pydantic 模型校验参数：

  class PlotCorrelationRequest(BaseModel): fund_code: str = Field(..., pattern=r'^\d{6}$') # 强制 6 位数字 index_code: str = Field(..., pattern=r'^[A-Z]{2}\d{6}$') # 如 CSI300 start_date: date = Field(..., ge=date(2020,1,1)) # 早于 2020 年不支持 end_date: date = Field(..., le=date.today())

• 降级策略：当绘图失败时，不终止流程，而是：
  • 记录 error 日志（含完整参数 dump）
  • 调用文本分析工具生成相关性文字报告
  • 返回：“已为您计算出相关系数为 0.82，由于图表渲染服务临时繁忙，文字分析如下：...”

我们用langgraph实现该 Agent，核心 state 定义：

class AgentState(TypedDict): messages: Annotated[Sequence[BaseMessage], operator.add] next_action: str # 'fetch_fund', 'fetch_index', 'calculate', 'plot', 'report' fund_data: Optional[dict] index_data: Optional[dict] correlation_result: Optional[float] plot_url: Optional[str] error_log: List[str]

这套设计让 Agent 在 127 次压力测试中，成功完成率 100%，其中 19 次触发降级流程，用户无感知。

3.4 评估与监控：没有量化评估的 RAG，就是一场昂贵的赌博

95% 的开源 RAG 项目缺失评估模块，导致上线后才发现：用户满意度没提升，反而投诉“答案越来越不准”。我的经验是，必须建立三级评估体系：

第一级：离线基准测试（Offline Benchmark）

• 工具：RAGAS+ 自建测试集（500 条真实脱敏用户问句）
• 指标：answer_relevancy,faithfulness,context_recall,context_precision
• 关键技巧：context_recall计算时，用llm-as-judge模式，让 GPT-4 评估“答案中所有事实是否都能在检索到的上下文中找到依据”，而非简单字符串匹配

第二级：在线 A/B 测试（Online A/B Test）

• 方案：将 10% 流量导至新 RAG 服务，对比旧版 FAQ 系统
• 核心指标：answer_click_rate（用户点击答案的比率）、session_duration（会话时长）、escalation_to_human（转人工率）
• 实测案例：某保险 RAG 上线后，escalation_to_human从 23.7% ↓ 至 14.2%，但answer_click_rate仅微升 0.3% —— 追查发现，新系统答案更长但关键信息被埋没，于是我们增加了answer_highlight模块，自动提取答案中 3 个核心数字/条款并加粗，click_rate随即升至 18.9%

第三级：生产环境监控（Production Monitoring）

• 必埋指标：
  • retrieval_latency_p99（毫秒）
  • llm_generation_timeout_rate（超时请求占比）
  • fallback_trigger_count（降级触发次数/小时）
• 关键告警：当fallback_trigger_count > 5/hour且retrieval_latency_p99 > 1200ms同时发生，立即触发p0告警，通知 SRE 团队检查 Milvus 集群健康度

注意：不要用langchain自带的CallbackHandler做监控，它在高并发下会成为性能瓶颈；我们用opentelemetry+jaeger实现全链路追踪，每个 query 的 span 包含document_load_time,split_time,embed_time,retrieve_time,rerank_time,llm_time六个子 span，定位慢 query 一目了然。

4. 实操全流程：手把手带你从零部署一个可商用的 RAG 知识库

4.1 环境准备与依赖安装：避开那些“官方文档不会告诉你”的坑

别信pip install -r requirements.txt能一次成功。以下是我在 Ubuntu 22.04 + Python 3.10 环境下的实操步骤（已验证 17 次）：

1. 创建隔离环境（必须！）：

   conda create -n rag-prod python=3.10.12 conda activate rag-prod # 关键：禁用 conda 自动更新 pip，避免 pip 版本冲突 conda config --set auto_update_conda false

2. 安装 CUDA 工具链（GPU 加速必备）：

   # 下载 CUDA 11.8 runfile（不要用 apt，版本太旧） wget https://developer.download.nvidia.com/compute/cuda/11.8.0/local_installers/cuda_11.8.0_520.61.05_linux.run sudo sh cuda_11.8.0_520.61.05_linux.run --silent --override --toolkit # 验证 nvcc --version # 应输出 release 11.8, V11.8.89

3. 安装 PyTorch（严格匹配 CUDA 版本）：

   pip3 install torch==2.0.1+cu118 torchvision==0.15.2+cu118 torchaudio==2.0.2+cu118 --extra-index-url https://download.pytorch.org/whl/cu118

4. 安装向量数据库（Milvus 2.4.3）：

   # 官方 Docker 部署最稳 docker run -d --name milvus-standalone \ -p 19530:19530 \ -p 9091:9091 \ -v $(pwd)/milvus:/var/lib/milvus \ --restart=on-failure \ -e ETCD_ENDPOINTS=http://127.0.0.1:2379 \ -e MINIO_ADDRESS=127.0.0.1:9000 \ milvusdb/milvus:v2.4.3 # 等待 60 秒，检查日志 docker logs -f milvus-standalone | grep "Milvus is ready"

5. 安装核心 Python 包（精确版本锁死）：

   pip install \ langchain==0.1.16 \ langchain-community==0.0.36 \ llama-index==0.10.45 \ pymilvus==2.4.3 \ sentence-transformers==2.2.2 \ transformers==4.38.2 \ accelerate==0.27.2 \ xformers==0.0.23.post1 \ # 关键：安装 bge-m3 的 ONNX 运行时加速包 onnxruntime-gpu==1.17.3

踩坑实录：曾因transformers版本过高（4.40.0），导致sentence-transformers的AutoModel.from_pretrained()加载 bge-m3 时抛出KeyError: 'rope_scaling'；降级至 4.38.2 后解决。这就是为什么必须锁死版本——开源世界的“最新版”往往是最不稳定的。

4.2 数据准备与向量化：如何让 1000 份 PDF 在 2 小时内完成高质量入库

假设你有一批《用户隐私政策》《服务协议》《产品说明书》共 1273 个 PDF 文件，存放在./docs/目录。以下是生产级处理脚本：

# process_docs.py import os from pathlib import Path from langchain_community.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from pymilvus import connections, Collection, FieldSchema, CollectionSchema, DataType # 1. 初始化 Milvus 连接 connections.connect("default", host="127.0.0.1", port="19530") # 2. 定义 Collection Schema（关键！） fields = [ FieldSchema(name="id", dtype=DataType.INT64, is_primary=True, auto_id=True), FieldSchema(name="text", dtype=DataType.VARCHAR, max_length=65535), FieldSchema(name="source", dtype=DataType.VARCHAR, max_length=256), FieldSchema(name="page", dtype=DataType.INT32), FieldSchema(name="embedding", dtype=DataType.FLOAT_VECTOR, dim=1024) # bge-m3 输出维度 ] schema = CollectionSchema(fields, description="RAG knowledge base") collection = Collection("rag_docs", schema) # 3. 加载并分块（使用前文定义的 ChineseSemanticSplitter） splitter = ChineseSemanticSplitter(max_tokens=384) all_chunks = [] for pdf_path in Path("./docs/").glob("*.pdf"): try: loader = PyPDFLoader(str(pdf_path)) docs = loader.load() # 预处理：清洗 OCR 噪声（此处省略具体清洗函数） cleaned_docs = [clean_ocr_noise(doc) for doc in docs] chunks = splitter.split_documents(cleaned_docs) # 注入元数据 for chunk in chunks: chunk.metadata.update({ "source": pdf_path.name, "processed_at": datetime.now().isoformat() }) all_chunks.extend(chunks) print(f"✅ {pdf_path.name}: {len(chunks)} chunks") except Exception as e: print(f"❌ {pdf_path.name}: {str(e)}") continue # 4. 批量向量化（避免 OOM） embedder = HuggingFaceEmbeddings( model_name="BAAI/bge-m3", model_kwargs={'device': 'cuda'}, encode_kwargs={'normalize_embeddings': True} ) batch_size = 32 for i in range(0, len(all_chunks), batch_size): batch = all_chunks[i:i+batch_size] texts = [c.page_content for c in batch] embeddings = embedder.embed_documents(texts) # 构造插入数据 entities = [ [c.page_content for c in batch], # text [c.metadata["source"] for c in batch], # source [c.metadata.get("page", 0) for c in batch], # page embeddings ] collection.insert(entities) print(f"Inserted batch {i//batch_size + 1}/{(len(all_chunks)-1)//batch_size + 1}") # 5. 创建索引（关键！） collection.create_index( field_name="embedding", index_params={ "index_type": "IVF_FLAT", "metric_type": "IP", "params": {"nlist": 1024} } ) collection.load() # 加载到内存 print("🎉 All documents indexed and loaded!")

关键参数说明：

• nlist=1024：IVF 索引的聚类中心数，经验值 = sqrt(总向量数)，1273 份文档约产生 8 万 chunk，sqrt(80000)≈283，向上取整为 1024 更稳妥
• dim=1024：bge-m3 的 dense 向量维度，必须与模型输出严格一致，否则插入失败
• batch_size=32：GPU 显存限制，A10G 12GB 显存下最大安全值，过大必 OOM

实测：1273 个 PDF（平均 8.2MB/个），总处理时间 1h48min，最终入库 79,421 条向量，Milvus 占用磁盘空间 2.1GB。

4.3 构建检索接口：一个可直接集成到 Web 前端的 FastAPI 服务

# api/main.py from fastapi import FastAPI, HTTPException, Query from pydantic import BaseModel from typing import List, Dict, Any from pymilvus import connections, Collection from langchain_community.embeddings import HuggingFaceEmbeddings app = FastAPI(title="RAG Knowledge API", version="1.0") # 初始化 connections.connect("default", host="127.0.0.1", port="19530") collection = Collection("rag_docs") collection.load() embedder = HuggingFaceEmbeddings( model_name="BAAI/bge-m3", model_kwargs={'device': 'cuda'}, encode_kwargs={'normalize_embeddings': True} ) class SearchRequest(BaseModel): query: str top_k: int = 5 filter_source: str = None # 支持按来源过滤，如 "privacy_policy.pdf" @app.post("/search") async def search(request: SearchRequest): try: # 1. 向量化 query query_vector = embedder.embed_query(request.query) # 2. 构建 Milvus 检索参数 search_params = { "metric_type": "IP", "params": {"nprobe": 16} # nprobe 越大越准但越慢，16 是平衡点 } # 3. 执行检索 results = collection.search( data=[query_vector], anns_field="embedding", param=search_params, limit=request.top_k, output_fields=["text", "source", "page"] ) # 4. 格式化返回 hits = [] for hit in results[0]: hits.append({ "id": hit.id, "score": float(hit.score), "text": hit.entity.get("text"), "source": hit.entity.get("source"), "page": hit.entity.get("page") }) return {"results": hits, "query": request.query} except Exception as e: raise HTTPException(status_code=500, detail=f"Search failed: {str(e)}") if __name__ == "__main__": import uvicorn uvicorn.run(app, host="0.0.0.0:8000", port=8000, workers=4)

启动与测试：

# 启动 API uvicorn api.main:app --reload --host 0.0.0.0 --port 8000 # 测试 curl curl -X POST "http://localhost:8000/search" \ -H "Content-Type: application/json" \ -d '{"query":"我的个人信息会被分享给第三方吗？", "top_k":3}'

生产优化项：

• 增加redis缓存层，对相同 query 的检索结果缓存 5 分钟
• 用gunicorn+uvicorn组合部署，gunicorn管理 worker 进程，uvicorn处理 ASGI
• Nginx 反向代理，配置client_max_body_size 10M防止大文件上传失败

4.4 集成 LLM 生成：用 Ollama 本地部署，彻底摆脱 API 依赖

Ollama 是目前最稳定的本地 LLM 运行时，无需折腾llama.cpp编译。以下是我们的部署实践：

1. 安装与模型拉取：

   # Ubuntu 安装