尧图网站建设 
林俊旸宣布创办 Pragmatik Labs 的消息这几天在 AI 技术圈引发了不小讨论。相比单纯报道“谁出来了、又成立了一家公司”我更想借这个信号聊一聊背后更值得开发者关注的变化AI 创业正在从“模型竞赛”转向“工程落地”。公司名字里的 Pragmatik很明显在强调“务实主义”。本文不搞八卦不猜融资不编产品细节。我们只从技术视角出发拆解一个务实的 AI 创业公司通常要用到哪些基础设施聊清楚“研究员出来创业之后技术栈怎么搭”这个问题。无论你是后端开发、算法工程师还是准备入局 AI 应用层的开发者这篇文章都可以给你一条清晰的路线参考。1. 从 Pragmatik Labs 看 AI 创业的新信号1.1 为什么“官宣创业”值得技术人关注过去两年AI 圈最常见的创业叙事是“做一个基础模型”。动辄千万级训练成本、超大集群、核心算法团队普通开发者根本够不到门槛。但 Pragmatik Labs 这类公司的出现代表一种新趋势研究方向出身的创业者开始把重点从“训练更大的模型”转向“把已有模型用得更聪明”。不再执着于刷新榜单而是聚焦真实业务里的准确率、响应速度、成本控制和使用体验。对普通开发者来说这是一个好消息。因为这意味着行业里会出现更多面向应用层的工具、开源方案和最佳实践。我们不需要重新训练大模型也可以借助成熟模型构建高质量业务系统。1.2 “务实”这两个字到底指什么英文词根 Pragmatik 映射的是 Pragmatic中文翻译就是“务实的、重实效的”。放在 AI 工程语境下它通常包含几个核心含义同样效果优先选成本最低的方案同样功能优先选延迟最低的链路在模型能力不够稳定时通过流程、校验、兜底来保证业务可用不追求大而全的平台而是围绕具体痛点做深做透。这些原则看似平淡但实际落地时极其考验工程能力。下面展开的这套内容就是围绕“务实 AI 工程”来设计的。2. AI 应用落地中的核心工程问题在真正开始写代码之前我们需要先理解一件事为什么大模型能力强但落地时依然困难重重2.1 基准分数高不等于业务效果好很多模型在公开评测集上表现很好一放进真实场景就“翻车”。原因主要有几个评测集覆盖的场景有限真实业务数据分布更复杂评测关注单轮问答业务中往往需要多轮上下文评测答案不关注格式业务系统则需要结构化输出评测环境没有并发压力生产环境要考虑超时、限流、降级。所以务实型 AI 团队会把“评估体系”放在第一位。没有可靠评估优化无从谈起。2.2 成本与延迟是真正的产品瓶颈一个常见误区是大模型贵所以我选小模型。实际上选型不能只看模型体积更要看任务复杂度。比如做简单意图分类用大模型确实浪费但用传统分类器可能精度不够。务实的做法是分层设计请求类型推荐方案说明高频简单请求小模型 / 规则引擎成本极低响应快中频一般请求中型模型平衡效果和成本低频复杂请求大模型保证复杂推理效果固定模板场景缓存复用完全避免重复调用这套思路叫“模型路由”后面实战部分我会给出一个最小实现。2.3 上下文管理比想象中更复杂大模型 API 通常有上下文长度限制且超长上下文会导致成本上升和响应变慢。真正开发时你会遇到用户问题很长历史消息很多知识库内容很长如何截取关键片段多个工具返回结果拼接后超过窗口限制长对话中过早信息被截断导致上下文丢失。这些问题没有统一解决公式只能结合具体业务做策略设计。3. 务实型 AI 创业公司的基础技术框架不妨把 Pragmatik Labs 类比为一个“务实 AI 创业公司的代表”。不管它最终做什么产品底层技术框架大概率绕不开以下四大模块。3.1 模型接入层解除模型绑定公司如果只依赖某一家模型厂商一旦对方接口变动、价格上调或效果波动业务会非常被动。务实团队通常会做一层模型抽象。这个抽象层至少需要支持统一接口不同厂商的 API 调用方式差异被屏蔽模型路由根据任务类型、成本、性能动态选择模型降级机制主模型不可用时自动切换到备选模型日志采集记录每次调用的模型、耗时、Token 数、结果。下面是一段简化示例采用 Python 实现。该示例用于展示模型抽象层的基本结构生产环境可按需扩展。# 文件路径model_gateway.py from abc import ABC, abstractmethod class BaseLLM(ABC): abstractmethod def chat(self, messages, temperature0.7, max_tokens1024): pass class OpenAIImpl(BaseLLM): def chat(self, messages, temperature0.7, max_tokens1024): # 调用 OpenAI 风格接口 pass class LocalOllamaImpl(BaseLLM): def chat(self, messages, temperature0.7, max_tokens1024): # 调用本地 Ollama 服务 pass class LLMRouter: def __init__(self): self.models {} self.default_model None self.rules [] def register(self, name, model: BaseLLM, defaultFalse): self.models[name] model if default: self.default_model name def add_rule(self, judge_func, model_name): self.rules.append((judge_func, model_name)) def chat(self, messages, temperature0.7, max_tokens1024): for judge, model_name in self.rules: if judge(messages): return self.models[model_name].chat( messages, temperaturetemperature, max_tokensmax_tokens ) return self.models[self.default_model].chat( messages, temperaturetemperature, max_tokensmax_tokens )这段代码的核心思路是调用方不需要关心底层用的是哪家模型只需要调用LLMRouter.chat()。不同策略通过规则函数动态注入。3.2 检索增强生成让模型拥有知识来源RAGRetrieval-Augmented Generation检索增强生成是目前解决模型“不知道”和“乱编”的主流方案。基本流程是将文档切片并向量化用户提问后用同样的向量化模型编码问题在向量数据库中召回最相关的文本片段把片段和问题一起交给大模型要求模型基于片段回答。这里最容易出错的是“切片方式”。过短会丢失语义过长则浪费 Token 且引入噪声。经验做法是先用标题结构切块再对长块做二次切分。以下是一个简单的切分函数。# 文件路径text_splitter.py import re def smart_split(text, max_chunk_size800, overlap100): chars text if len(chars) max_chunk_size: return [chars] # 优先按段落切 paragraphs re.split(r\n\n, text) chunks [] current_chunk for para in paragraphs: if len(current_chunk) len(para) max_chunk_size: current_chunk para \n\n else: if current_chunk: chunks.append(current_chunk.strip()) # 段落太长时进一步按句子切 if len(para) max_chunk_size: sentences re.split(r(。||), para) temp for sent in sentences: if len(temp) len(sent) max_chunk_size: temp sent else: if temp: chunks.append(temp.strip()) temp sent else: current_chunk para \n\n if current_chunk.strip(): chunks.append(current_chunk.strip()) # 简单重叠处理 result [] for i, c in enumerate(chunks): if i 0: result.append(c) else: prev_tail chunks[i-1][-overlap:] result.append(prev_tail c) return result这个切分逻辑不一定完美但体现了务实的关键思路不要一上来就追求复杂算法先把规则处理好再逐步用效果数据驱动迭代。3.3 智能体编排从“单次问答”走向“多步任务”如果产品只是单轮问答不需要智能体架构。但遇到这类场景时编排能力就变得必要用户提问涉及多个子问题需要调用外部工具或 API需要根据数据结果决定下一步动作需要多轮反思或纠错。典型的智能体运行循环可以总结为接收用户输入模型决定是否调用工具执行工具并返回结果模型判断是否继续调用或生成最终答案输出内容并进行格式校验。这里给出一个最小工具调用示例。# 文件路径agent_loop.py import json def get_weather(city): # 模拟天气查询 return {city: city, temp: 26, unit: Celsius} TOOLS { get_weather: get_weather } def run_agent_with_tool(user_input, llm_func): messages [{role: user, content: user_input}] # 第一轮让模型决定是否需要工具 response llm_func(messages, tools[get_weather]) if response.get(tool_call): tool_name response[tool_call][name] args response[tool_call][args] tool_result TOOLS[tool_name](**args) # 将工具结果追加进上下文 messages.append({ role: tool, content: json.dumps(tool_result, ensure_asciiFalse) }) # 第二轮让模型基于工具结果生成最终回答 final_response llm_func(messages) return final_response[content] else: return response[content]现实世界中的 Agent 会比这个复杂得多比如循环上限、并行工具调用、错误重试、结果校验等。但核心思想一致模型是大脑工具是手脚编排层负责协调两者。3.4 评估与可观测性没有度量就没有优化很多团队把模型接入后发现“效果不好”却又说不清哪里不好。这是因为没有建立评估闭环。一个务实的最小评估体系至少包括离线评测集收集 100 到 500 条典型业务问题答案质量评分人工评分或调用大模型评分运行日志记录输入、输出、耗时、Token 数监控指标接口成功率、平均延迟、Token 消耗、错误类型分布。下面是一个轻量的“大模型当裁判”评分函数示例。# 文件路径evaluator.py def llm_evaluate(question, model_answer, llm_func): prompt f 你是答案质量评估专家请根据以下标准打分满分 10 分。 标准 1. 是否准确回答用户问题0-4分 2. 是否有依据没有编造0-3分 3. 格式是否清晰、易读0-3分 用户问题{question} 模型答案{model_answer} 请直接输出数字分数。 response llm_func([{role: user, content: prompt}]) try: return float(response.strip()) except ValueError: return 0.0注意LLM 打分会有一定波动不一定适合所有场景。更可靠的做法是抽样人工复核再与 LLM 打分做相关性分析。4. 从零搭建一个“Pragmatik 风格”的最小系统下面用一个完整示例把前面提到的模块串联起来。主题是“企业知识库问答助手”。为了演示代码做了简化但结构上保留了可扩展性。4.1 项目结构pragmatik-demo/ ├── app.py # 主入口 ├── config.py # 配置 ├── model_gateway.py # 模型接入与路由 ├── retriever.py # 知识库检索 ├── agent_loop.py # 工具调用循环 └── requirements.txt # 依赖4.2 配置文件# 文件路径config.py MODEL_CONFIG { primary: { provider: openai, model: gpt-4o-mini, api_base: https://api.example.com/v1, api_key: your-api-key, timeout: 30 }, fallback: { provider: ollama, model: qwen2.5:7b, api_base: http://localhost:11434, timeout: 60 }, router_mode: rule_based } VECTOR_DB_CONFIG { collection: company_handbook, top_k: 5, similarity_threshold: 0.4 }不同环境下配置会不一样生产环境建议将密钥放到环境变量或密钥管理服务中而不是写死在文件里。4.3 主程序入口# 文件路径app.py from model_gateway import LLMRouter from retriever import Retriever def build_router(): router LLMRouter() # 注册主模型 router.register(primary_llm, OpenAIImpl(MODEL_CONFIG[primary]), defaultTrue) # 注册备选模型 router.register(fallback_llm, LocalOllamaImpl(MODEL_CONFIG[fallback])) # 规则长上下文使用主模型token 超长时降级 router.add_rule( lambda msgs: sum(len(m[content]) for m in msgs) 6000, fallback_llm ) return router def main(): router build_router() retriever Retriever(VECTOR_DB_CONFIG) user_question input(请输入问题) # 1. 检索相关文档 context_parts retriever.search(user_question) context \n\n.join(context_parts) messages [ {role: system, content: 你是一个企业知识库助手回答时优先使用提供的资料。}, {role: user, content: f资料\n{context}\n\n问题{user_question}} ] # 2. 模型生成 answer router.chat(messages, max_tokens800) # 3. 输出 print(回答) print(answer) if __name__ __main__: main()这个流程虽然简单已经覆盖了 RAG 应用的主体链路。实际项目中还需加入缓存、日志、限流、敏感内容检测等模块。4.4 运行与验证先安装依赖pip install requests openai再启动本地模型服务如果没有本地模型也可以直接使用云端 API并把 fallback 配置为另一家云厂商ollama serve ollama run qwen2.5:7b运行主程序python app.py预期流程是输入问题 - 检索知识库 - 拼装 Prompt - 调用大模型 - 输出回答。5. 常见问题与排查思路务实 AI 工程中90% 的时间都在和问题作斗争。下面整理几个高频问题和对应的排查路径。问题现象常见原因解决思路模型回答与知识库内容矛盾Prompt 中资料权重不够高明确要求“仅基于资料回答”并在 Prompt 中突出资料块响应延迟高模型过大或上下文过长使用模型路由长文本任务切块启用缓存并发请求时报 429超过 API 限流加入请求队列、退避重试、动态限流输出 JSON 格式不稳定大模型生成随机性使用约束采样、JSON Schema 校验、解析失败后重试检索结果不相关向量切分不合理调整切片大小增加关键词混合检索提高 TopK多轮对话后遗忘早期信息上下文窗口被截断做消息摘要压缩利用滑动窗口管理历史工具调用返回错误参数格式不一致定义严格工具 JSON Schema做输入输出校验这里要特别强调一个问题很多人遇到模型输出异常第一反应是“换更大的模型”。但在务实团队里正确的顺序是“先查输入、再查流程、最后换模型”。多数问题出在 Prompt 设计、上下文拼装和结果校验上而不是模型能力不够。6. 工程实践中的几条硬性建议根据我接触过的 AI 工程经验有几个建议值得单独展开。6.1 把输入输出全部记录下来生产环境没有日志就意味着没有排障能力。建议至少记录请求 ID 和用户 IDPrompt 拼接后的完整内容模型返回的原始内容耗时、Token 消耗、模型名称解析结果及校验状态。数据量大的时候可以按天分表存储并设置定期清理。6.2 先做缓存再谈优化很多业务问题具有重复性。同一个问题在短时间被反复询问是常见情况。做一层 Redis 缓存按问题的语义哈希或向量相似度作为 Key能显著降低成本。但要注意缓存失效策略尤其当知识库内容更新时要能主动清理相关缓存。6.3 用“最少模型数”解决问题模型不是越多越好。每新增一个模型接入都会带来接口维护、鉴权、数据合规等额外成本。务实团队的做法是先确定业务任务类型用现有模型验证效果只有效果明显不达标时才评估换模型优先通过 Prompt 优化和上下文增强解决问题。6.4 安全与合规不能省无论创业公司还是大厂模型输出都可能涉及风险内容。建议在模型出口前增加一层内容安全过滤。具体包括敏感词拦截输出内容审核拒绝服务式攻击防护操作留痕与审计。6.5 灰度发布与回滚模型升级是有风险的操作。同一个模型隔几天可能因为服务端更新而变化。建议将模型版本、Prompt 版本、知识库版本都纳入配置管理并支持一键回滚。最小实现方式配置管理里多放一个version字段发布新版本时做 A/B 对比观察关键指标后再全量切换。7. 下一步学习路线如果你想在务实 AI 工程这条路上持续深入我建议按以下顺序展开把 Prompt 工程练扎实。这是投入产出比最高的技能。掌握 RAG 的完整链路。包括切分、向量化、召回、重排。理解 Agent 的设计模式。看几篇主流 Agent 框架的源码但不建议直接在生产环境盲目引入复杂框架。建立自己的评估集。把业务中高频问题沉淀下来持续迭代。学习系统设计中的缓存、限流、降级、可观测性。这些通用后端能力在 AI 工程中同样关键。回到 Pragmatik Labs 的官宣上来它真正给技术社区传递的信号不是某一家公司的产品方向而是 AI 行业已经进入了一个“朴素工程力比拼”的阶段。谁能用更低成本、更高效率把模型能力变成稳定可用的产品谁就能在下一轮竞争中拿到主动权。这个趋势对普通开发者是友好的因为工程能力可以被学习和复制。希望这篇文章能帮你少踩几个坑快速步入 AI 应用开发的正确轨道。如果觉得有收获可以先收藏后面动手做项目时随时对照排查。 AI创业转向工程落地：务实技术栈与基础设施拆解
林俊旸宣布创办 Pragmatik Labs 的消息这几天在 AI 技术圈引发了不小讨论。相比单纯报道“谁出来了、又成立了一家公司”我更想借这个信号聊一聊背后更值得开发者关注的变化AI 创业正在从“模型竞赛”转向“工程落地”。公司名字里的 Pragmatik很明显在强调“务实主义”。本文不搞八卦不猜融资不编产品细节。我们只从技术视角出发拆解一个务实的 AI 创业公司通常要用到哪些基础设施聊清楚“研究员出来创业之后技术栈怎么搭”这个问题。无论你是后端开发、算法工程师还是准备入局 AI 应用层的开发者这篇文章都可以给你一条清晰的路线参考。1. 从 Pragmatik Labs 看 AI 创业的新信号1.1 为什么“官宣创业”值得技术人关注过去两年AI 圈最常见的创业叙事是“做一个基础模型”。动辄千万级训练成本、超大集群、核心算法团队普通开发者根本够不到门槛。但 Pragmatik Labs 这类公司的出现代表一种新趋势研究方向出身的创业者开始把重点从“训练更大的模型”转向“把已有模型用得更聪明”。不再执着于刷新榜单而是聚焦真实业务里的准确率、响应速度、成本控制和使用体验。对普通开发者来说这是一个好消息。因为这意味着行业里会出现更多面向应用层的工具、开源方案和最佳实践。我们不需要重新训练大模型也可以借助成熟模型构建高质量业务系统。1.2 “务实”这两个字到底指什么英文词根 Pragmatik 映射的是 Pragmatic中文翻译就是“务实的、重实效的”。放在 AI 工程语境下它通常包含几个核心含义同样效果优先选成本最低的方案同样功能优先选延迟最低的链路在模型能力不够稳定时通过流程、校验、兜底来保证业务可用不追求大而全的平台而是围绕具体痛点做深做透。这些原则看似平淡但实际落地时极其考验工程能力。下面展开的这套内容就是围绕“务实 AI 工程”来设计的。2. AI 应用落地中的核心工程问题在真正开始写代码之前我们需要先理解一件事为什么大模型能力强但落地时依然困难重重2.1 基准分数高不等于业务效果好很多模型在公开评测集上表现很好一放进真实场景就“翻车”。原因主要有几个评测集覆盖的场景有限真实业务数据分布更复杂评测关注单轮问答业务中往往需要多轮上下文评测答案不关注格式业务系统则需要结构化输出评测环境没有并发压力生产环境要考虑超时、限流、降级。所以务实型 AI 团队会把“评估体系”放在第一位。没有可靠评估优化无从谈起。2.2 成本与延迟是真正的产品瓶颈一个常见误区是大模型贵所以我选小模型。实际上选型不能只看模型体积更要看任务复杂度。比如做简单意图分类用大模型确实浪费但用传统分类器可能精度不够。务实的做法是分层设计请求类型推荐方案说明高频简单请求小模型 / 规则引擎成本极低响应快中频一般请求中型模型平衡效果和成本低频复杂请求大模型保证复杂推理效果固定模板场景缓存复用完全避免重复调用这套思路叫“模型路由”后面实战部分我会给出一个最小实现。2.3 上下文管理比想象中更复杂大模型 API 通常有上下文长度限制且超长上下文会导致成本上升和响应变慢。真正开发时你会遇到用户问题很长历史消息很多知识库内容很长如何截取关键片段多个工具返回结果拼接后超过窗口限制长对话中过早信息被截断导致上下文丢失。这些问题没有统一解决公式只能结合具体业务做策略设计。3. 务实型 AI 创业公司的基础技术框架不妨把 Pragmatik Labs 类比为一个“务实 AI 创业公司的代表”。不管它最终做什么产品底层技术框架大概率绕不开以下四大模块。3.1 模型接入层解除模型绑定公司如果只依赖某一家模型厂商一旦对方接口变动、价格上调或效果波动业务会非常被动。务实团队通常会做一层模型抽象。这个抽象层至少需要支持统一接口不同厂商的 API 调用方式差异被屏蔽模型路由根据任务类型、成本、性能动态选择模型降级机制主模型不可用时自动切换到备选模型日志采集记录每次调用的模型、耗时、Token 数、结果。下面是一段简化示例采用 Python 实现。该示例用于展示模型抽象层的基本结构生产环境可按需扩展。# 文件路径model_gateway.py from abc import ABC, abstractmethod class BaseLLM(ABC): abstractmethod def chat(self, messages, temperature0.7, max_tokens1024): pass class OpenAIImpl(BaseLLM): def chat(self, messages, temperature0.7, max_tokens1024): # 调用 OpenAI 风格接口 pass class LocalOllamaImpl(BaseLLM): def chat(self, messages, temperature0.7, max_tokens1024): # 调用本地 Ollama 服务 pass class LLMRouter: def __init__(self): self.models {} self.default_model None self.rules [] def register(self, name, model: BaseLLM, defaultFalse): self.models[name] model if default: self.default_model name def add_rule(self, judge_func, model_name): self.rules.append((judge_func, model_name)) def chat(self, messages, temperature0.7, max_tokens1024): for judge, model_name in self.rules: if judge(messages): return self.models[model_name].chat( messages, temperaturetemperature, max_tokensmax_tokens ) return self.models[self.default_model].chat( messages, temperaturetemperature, max_tokensmax_tokens )这段代码的核心思路是调用方不需要关心底层用的是哪家模型只需要调用LLMRouter.chat()。不同策略通过规则函数动态注入。3.2 检索增强生成让模型拥有知识来源RAGRetrieval-Augmented Generation检索增强生成是目前解决模型“不知道”和“乱编”的主流方案。基本流程是将文档切片并向量化用户提问后用同样的向量化模型编码问题在向量数据库中召回最相关的文本片段把片段和问题一起交给大模型要求模型基于片段回答。这里最容易出错的是“切片方式”。过短会丢失语义过长则浪费 Token 且引入噪声。经验做法是先用标题结构切块再对长块做二次切分。以下是一个简单的切分函数。# 文件路径text_splitter.py import re def smart_split(text, max_chunk_size800, overlap100): chars text if len(chars) max_chunk_size: return [chars] # 优先按段落切 paragraphs re.split(r\n\n, text) chunks [] current_chunk for para in paragraphs: if len(current_chunk) len(para) max_chunk_size: current_chunk para \n\n else: if current_chunk: chunks.append(current_chunk.strip()) # 段落太长时进一步按句子切 if len(para) max_chunk_size: sentences re.split(r(。||), para) temp for sent in sentences: if len(temp) len(sent) max_chunk_size: temp sent else: if temp: chunks.append(temp.strip()) temp sent else: current_chunk para \n\n if current_chunk.strip(): chunks.append(current_chunk.strip()) # 简单重叠处理 result [] for i, c in enumerate(chunks): if i 0: result.append(c) else: prev_tail chunks[i-1][-overlap:] result.append(prev_tail c) return result这个切分逻辑不一定完美但体现了务实的关键思路不要一上来就追求复杂算法先把规则处理好再逐步用效果数据驱动迭代。3.3 智能体编排从“单次问答”走向“多步任务”如果产品只是单轮问答不需要智能体架构。但遇到这类场景时编排能力就变得必要用户提问涉及多个子问题需要调用外部工具或 API需要根据数据结果决定下一步动作需要多轮反思或纠错。典型的智能体运行循环可以总结为接收用户输入模型决定是否调用工具执行工具并返回结果模型判断是否继续调用或生成最终答案输出内容并进行格式校验。这里给出一个最小工具调用示例。# 文件路径agent_loop.py import json def get_weather(city): # 模拟天气查询 return {city: city, temp: 26, unit: Celsius} TOOLS { get_weather: get_weather } def run_agent_with_tool(user_input, llm_func): messages [{role: user, content: user_input}] # 第一轮让模型决定是否需要工具 response llm_func(messages, tools[get_weather]) if response.get(tool_call): tool_name response[tool_call][name] args response[tool_call][args] tool_result TOOLS[tool_name](**args) # 将工具结果追加进上下文 messages.append({ role: tool, content: json.dumps(tool_result, ensure_asciiFalse) }) # 第二轮让模型基于工具结果生成最终回答 final_response llm_func(messages) return final_response[content] else: return response[content]现实世界中的 Agent 会比这个复杂得多比如循环上限、并行工具调用、错误重试、结果校验等。但核心思想一致模型是大脑工具是手脚编排层负责协调两者。3.4 评估与可观测性没有度量就没有优化很多团队把模型接入后发现“效果不好”却又说不清哪里不好。这是因为没有建立评估闭环。一个务实的最小评估体系至少包括离线评测集收集 100 到 500 条典型业务问题答案质量评分人工评分或调用大模型评分运行日志记录输入、输出、耗时、Token 数监控指标接口成功率、平均延迟、Token 消耗、错误类型分布。下面是一个轻量的“大模型当裁判”评分函数示例。# 文件路径evaluator.py def llm_evaluate(question, model_answer, llm_func): prompt f 你是答案质量评估专家请根据以下标准打分满分 10 分。 标准 1. 是否准确回答用户问题0-4分 2. 是否有依据没有编造0-3分 3. 格式是否清晰、易读0-3分 用户问题{question} 模型答案{model_answer} 请直接输出数字分数。 response llm_func([{role: user, content: prompt}]) try: return float(response.strip()) except ValueError: return 0.0注意LLM 打分会有一定波动不一定适合所有场景。更可靠的做法是抽样人工复核再与 LLM 打分做相关性分析。4. 从零搭建一个“Pragmatik 风格”的最小系统下面用一个完整示例把前面提到的模块串联起来。主题是“企业知识库问答助手”。为了演示代码做了简化但结构上保留了可扩展性。4.1 项目结构pragmatik-demo/ ├── app.py # 主入口 ├── config.py # 配置 ├── model_gateway.py # 模型接入与路由 ├── retriever.py # 知识库检索 ├── agent_loop.py # 工具调用循环 └── requirements.txt # 依赖4.2 配置文件# 文件路径config.py MODEL_CONFIG { primary: { provider: openai, model: gpt-4o-mini, api_base: https://api.example.com/v1, api_key: your-api-key, timeout: 30 }, fallback: { provider: ollama, model: qwen2.5:7b, api_base: http://localhost:11434, timeout: 60 }, router_mode: rule_based } VECTOR_DB_CONFIG { collection: company_handbook, top_k: 5, similarity_threshold: 0.4 }不同环境下配置会不一样生产环境建议将密钥放到环境变量或密钥管理服务中而不是写死在文件里。4.3 主程序入口# 文件路径app.py from model_gateway import LLMRouter from retriever import Retriever def build_router(): router LLMRouter() # 注册主模型 router.register(primary_llm, OpenAIImpl(MODEL_CONFIG[primary]), defaultTrue) # 注册备选模型 router.register(fallback_llm, LocalOllamaImpl(MODEL_CONFIG[fallback])) # 规则长上下文使用主模型token 超长时降级 router.add_rule( lambda msgs: sum(len(m[content]) for m in msgs) 6000, fallback_llm ) return router def main(): router build_router() retriever Retriever(VECTOR_DB_CONFIG) user_question input(请输入问题) # 1. 检索相关文档 context_parts retriever.search(user_question) context \n\n.join(context_parts) messages [ {role: system, content: 你是一个企业知识库助手回答时优先使用提供的资料。}, {role: user, content: f资料\n{context}\n\n问题{user_question}} ] # 2. 模型生成 answer router.chat(messages, max_tokens800) # 3. 输出 print(回答) print(answer) if __name__ __main__: main()这个流程虽然简单已经覆盖了 RAG 应用的主体链路。实际项目中还需加入缓存、日志、限流、敏感内容检测等模块。4.4 运行与验证先安装依赖pip install requests openai再启动本地模型服务如果没有本地模型也可以直接使用云端 API并把 fallback 配置为另一家云厂商ollama serve ollama run qwen2.5:7b运行主程序python app.py预期流程是输入问题 - 检索知识库 - 拼装 Prompt - 调用大模型 - 输出回答。5. 常见问题与排查思路务实 AI 工程中90% 的时间都在和问题作斗争。下面整理几个高频问题和对应的排查路径。问题现象常见原因解决思路模型回答与知识库内容矛盾Prompt 中资料权重不够高明确要求“仅基于资料回答”并在 Prompt 中突出资料块响应延迟高模型过大或上下文过长使用模型路由长文本任务切块启用缓存并发请求时报 429超过 API 限流加入请求队列、退避重试、动态限流输出 JSON 格式不稳定大模型生成随机性使用约束采样、JSON Schema 校验、解析失败后重试检索结果不相关向量切分不合理调整切片大小增加关键词混合检索提高 TopK多轮对话后遗忘早期信息上下文窗口被截断做消息摘要压缩利用滑动窗口管理历史工具调用返回错误参数格式不一致定义严格工具 JSON Schema做输入输出校验这里要特别强调一个问题很多人遇到模型输出异常第一反应是“换更大的模型”。但在务实团队里正确的顺序是“先查输入、再查流程、最后换模型”。多数问题出在 Prompt 设计、上下文拼装和结果校验上而不是模型能力不够。6. 工程实践中的几条硬性建议根据我接触过的 AI 工程经验有几个建议值得单独展开。6.1 把输入输出全部记录下来生产环境没有日志就意味着没有排障能力。建议至少记录请求 ID 和用户 IDPrompt 拼接后的完整内容模型返回的原始内容耗时、Token 消耗、模型名称解析结果及校验状态。数据量大的时候可以按天分表存储并设置定期清理。6.2 先做缓存再谈优化很多业务问题具有重复性。同一个问题在短时间被反复询问是常见情况。做一层 Redis 缓存按问题的语义哈希或向量相似度作为 Key能显著降低成本。但要注意缓存失效策略尤其当知识库内容更新时要能主动清理相关缓存。6.3 用“最少模型数”解决问题模型不是越多越好。每新增一个模型接入都会带来接口维护、鉴权、数据合规等额外成本。务实团队的做法是先确定业务任务类型用现有模型验证效果只有效果明显不达标时才评估换模型优先通过 Prompt 优化和上下文增强解决问题。6.4 安全与合规不能省无论创业公司还是大厂模型输出都可能涉及风险内容。建议在模型出口前增加一层内容安全过滤。具体包括敏感词拦截输出内容审核拒绝服务式攻击防护操作留痕与审计。6.5 灰度发布与回滚模型升级是有风险的操作。同一个模型隔几天可能因为服务端更新而变化。建议将模型版本、Prompt 版本、知识库版本都纳入配置管理并支持一键回滚。最小实现方式配置管理里多放一个version字段发布新版本时做 A/B 对比观察关键指标后再全量切换。7. 下一步学习路线如果你想在务实 AI 工程这条路上持续深入我建议按以下顺序展开把 Prompt 工程练扎实。这是投入产出比最高的技能。掌握 RAG 的完整链路。包括切分、向量化、召回、重排。理解 Agent 的设计模式。看几篇主流 Agent 框架的源码但不建议直接在生产环境盲目引入复杂框架。建立自己的评估集。把业务中高频问题沉淀下来持续迭代。学习系统设计中的缓存、限流、降级、可观测性。这些通用后端能力在 AI 工程中同样关键。回到 Pragmatik Labs 的官宣上来它真正给技术社区传递的信号不是某一家公司的产品方向而是 AI 行业已经进入了一个“朴素工程力比拼”的阶段。谁能用更低成本、更高效率把模型能力变成稳定可用的产品谁就能在下一轮竞争中拿到主动权。这个趋势对普通开发者是友好的因为工程能力可以被学习和复制。希望这篇文章能帮你少踩几个坑快速步入 AI 应用开发的正确轨道。如果觉得有收获可以先收藏后面动手做项目时随时对照排查。