大家好我是专注于技术实战与经验分享的博主。在自然语言处理NLP和大型语言模型LLM的应用开发中我们常常面临一个核心矛盾如何用更少的计算资源尤其是Token消耗实现更复杂、更精准的任务最近一种名为“ACE”Automatic Chain-of-Thought with Expert Selection的推理方法引起了广泛关注它旨在通过智能选择专家路径用更少的Token完成复杂的思维链推理。本文将深入探讨ACE的核心思想并提供一个完整的实战案例展示如何在实际项目中应用类似“少即是多”的Token优化策略涵盖从概念理解、环境搭建到代码实现与性能对比的全过程。无论你是刚接触LLM应用的新手还是希望优化现有系统成本的开发者都能从中获得可直接复用的思路与代码。1. 背景与核心概念为什么我们需要“更少的Token”在深入ACE之前我们首先要理解“Token”在LLM上下文中的重要性。对于像GPT、Claude、LLaMA这样的模型Token是文本处理的基本单位。一个Token可能是一个单词、一个子词甚至一个标点。模型在处理输入Prompt和生成输出Completion时都会消耗Token。这直接关联到两大核心成本与限制经济成本绝大多数商用LLM API如OpenAI GPT、Anthropic Claude的计费方式是基于输入和输出的Token数量。Token消耗越少API调用成本越低。上下文长度限制每个模型都有固定的上下文窗口如4K、8K、16K、128K Token。输入系统指令用户查询历史对话示例和输出共享这个窗口。Token使用效率低下会迅速耗尽窗口导致模型“遗忘”早期信息或无法处理长文档。因此优化Token使用不是一个可选项而是构建高效、经济、可靠LLM应用的必修课。那么ACE是什么“Thinking of ACE”中的ACE并非指腾讯游戏的ACE安全中心一个反作弊系统而是指一种高级的提示工程与推理架构。其核心思想是模仿人类专家解决问题的过程面对一个复杂问题我们不会一次性思考所有细节而是先判断问题类型然后调用最相关的知识模块“专家”沿着一条最有效的推理路径“链”逐步推进。在LLM中实现这一点意味着A (Automatic)自动化的决策过程由模型或调度器决定调用哪个“专家”或采用哪条推理路径。C (Chain-of-Thought)思维链将问题分解为多个可解释的推理步骤。E (Expert Selection)专家选择针对问题的不同部分动态选择最合适的“子模型”、“提示模板”或“工具函数”。ACE的目标通过这种结构化的、选择性的推理避免让通用大模型在每一步都进行“漫无目的”的泛化计算从而用更精准、更少的Token消耗达到相同甚至更好的任务效果。这与我们想用“Fewer Tokens”完成“Complex Tasks”的目标完全一致。接下来我们将暂时搁置对复杂ACE系统理论的研究转而聚焦于一个更普适、更易落地的实战目标如何在实际的LLM应用开发中系统性地减少Token消耗我们将通过一个“智能文档问答系统”的案例来贯穿始终。2. 环境准备与版本说明在开始实战前我们需要搭建开发环境。本文以Python为主要语言使用OpenAI GPT-3.5/4作为LLM服务示例但所讲策略通用于任何LLM API。基础环境操作系统Windows 10/11, macOS, 或 Linux (Ubuntu 20.04)。本文命令以Linux/macOS的bash为例Windows用户可在PowerShell或WSL中运行。Python版本 3.8。推荐使用3.9或3.10以获得最佳库兼容性。包管理工具pip。核心Python库我们将使用以下库请通过pip安装pip install openai tiktoken langchain chromadb pypdf2openai: OpenAI官方Python SDK用于调用GPT模型。tiktoken: OpenAI开源的Token计数库至关重要用于精确计算和优化Token。langchain: 流行的LLM应用开发框架提供了许多高级抽象和工具本例中我们会用到其部分思想但代码会保持简洁透明。chromadb: 轻量级向量数据库用于存储和检索文档嵌入。pypdf2: 用于解析PDF文档。版本说明与关键配置openai库版本建议1.0.0新版API有较大变化。本文示例基于较新的稳定版本。你需要一个有效的OpenAI API密钥。请妥善保管不要直接硬编码在代码中。本文的策略如提示压缩、函数调用、结构化输出同样适用于Anthropic Claude、Google Gemini、开源LLM通过vLLM/Transformers等只需替换相应的客户端和Tokenizer。项目结构预览llm_token_optimization_demo/ ├── main.py # 主程序入口 ├── config.py # 配置文件存放API密钥等 ├── token_optimizer.py # Token优化策略核心模块 ├── document_processor.py # 文档处理与向量化模块 ├── prompts/ # 存放各种提示模板 │ ├── system_prompt.txt │ ├── query_compress.txt │ └── structured_qa.txt ├── data/ # 存放示例文档 │ └── sample_doc.pdf └── requirements.txt # 项目依赖列表3. 核心优化策略拆解如何用更少的Token做更多的事实现“Fewer Tokens”的目标不能靠盲目删减而需要一套系统性的策略。下面我们拆解四个最有效、最实用的核心策略。3.1 策略一精准的提示工程与指令压缩低效的提示是Token浪费的首要原因。例如“请总结一下这篇文档文档内容如下[粘贴整篇文档]。总结要全面涵盖主要观点、论据和结论字数在300字左右。”优化方法系统指令System Prompt精炼化将固定的角色、目标和约束放在系统指令中它通常只计算一次并在整个会话中有效。避免在每次用户消息中重复。上下文压缩对于需要引用的长文本如文档不要直接全量粘贴。先对其进行摘要、提取关键句或转换成更密集的表示如向量检索到的相关片段。使用简练、无歧义的指令直接告诉模型你需要它“做什么”而不是“不要做什么”。后者反而可能让模型先思考“不要做”的事情。示例优化前后对比# 优化前低效提示 (假设文档有5000个Token) inefficient_prompt f 请阅读以下技术文档并回答问题。 文档内容 {full_document_text} # 5000 tokens 问题什么是本文中提到的核心架构模式 请先复述文档中关于该模式的定义然后列举其三个优点和两个缺点。 回答请使用中文结构清晰。 # 优化后高效提示 (通过向量库检索只获取相关片段约200个Token) from document_processor import VectorStoreRetriever retriever VectorStoreRetriever() relevant_chunks retriever.get_relevant_chunks(“核心架构模式”, k3) # 检索最相关的3个片段 compressed_context \n\n.join([chunk.text for chunk in relevant_chunks]) efficient_prompt f 基于以下文档片段回答问题。 文档片段 {compressed_context} # ~200 tokens 问题什么是核心架构模式请给出其定义、三个优点和两个缺点。 为什么有效将5000 Token的上下文压缩到200 Token的相关片段直接节省了96%的输入Token同时更有可能让模型聚焦于正确答案减少幻觉。3.2 策略二利用函数调用Function Calling与结构化输出让模型输出冗长的自然语言然后再用正则表达式去解析是极其低效且脆弱的。现代LLM支持函数调用和结构化输出如JSON。函数调用你定义好工具函数的规格名称、描述、参数模型在需要时会请求调用某个函数并生成符合规范的参数。这允许你将复杂任务拆解由模型规划由外部函数执行如查数据库、计算最终只用少量Token进行“决策”和“整合”。结构化输出直接要求模型以指定的JSON格式输出。这大大简化了后处理并且模型为生成结构化工整的JSON所消耗的Token通常比生成同等信息的、格式随意的自然语言要少。示例结构化输出import openai from typing import List, TypedDict class QAAnswer(TypedDict): question: str answer: str confidence: float supporting_evidence: List[str] client openai.OpenAI(api_keyyour-api-key) # 定义响应格式 response_format { type: json_schema, json_schema: { name: qa_response, schema: { type: object, properties: { answers: { type: array, items: { type: object, properties: { question: {type: string}, answer: {type: string}, confidence: {type: number}, supporting_evidence: {type: array, items: {type: string}} }, required: [question, answer, confidence, supporting_evidence] } } }, required: [answers] } } } prompt “””根据上下文回答问题。 上下文{compressed_context} 问题1. 主键是什么 2. 索引有哪些类型 请以JSON格式输出包含答案和置信度。””” response client.chat.completions.create( modelgpt-3.5-turbo-1106, # 或 gpt-4-turbo-preview支持JSON模式 messages[{role: user, content: prompt}], response_formatresponse_format # 指定结构化输出 ) # 直接解析为字典无需复杂的文本解析 result json.loads(response.choices[0].message.content)为什么有效避免了“请用‘答案’开头用‘证据’列出…”这类冗长的输出指令和后处理解析代码输出紧凑且机器可直接读。3.3 策略三迭代式与链式推理CoT的简化版对于复杂问题一步到位的提问会导致模型生成冗长且可能离题的思考过程。我们可以主动引导一个简化的、分步的推理链。示例迭代式问答def iterative_qa_system(initial_question, context): conversation_history [] # 第一步问题分解 decompose_prompt f 将以下复杂问题分解为2-3个连续的、更简单的子问题。 原问题{initial_question} 只需输出子问题列表每个问题一行。 sub_questions ask_model(decompose_prompt).split(\n) answers [] for sub_q in sub_questions: if sub_q.strip(): # 第二步针对每个子问题在上下文中精准检索并回答 relevant_chunk retriever.get_relevant_chunks(sub_q, k1)[0] answer_prompt f上下文{relevant_chunk.text}\n问题{sub_q} answer ask_model(answer_prompt) answers.append((sub_q, answer)) # 第三步综合摘要 summary_prompt f 基于以下子问题及答案综合成一个完整、连贯的最终答案。 {chr(10).join([fQ: {q} A: {a} for q, a in answers])} 原问题{initial_question} 最终答案 final_answer ask_model(summary_prompt) return final_answer, len(conversation_history) # 可以返回总Token消耗为什么有效将单次“大爆炸”式的复杂生成拆解为多次可控的、上下文更聚焦的简单生成。虽然交互次数可能增加但每次交互的上下文长度和生成长度都大幅减少总Token消耗和答案质量往往更优。这体现了“ACE”中“Chain”的思想。3.4 策略四缓存与语义去重很多对话或查询是重复或语义相似的。为相同的输入重复计算相同的输出是巨大的浪费。精确缓存对完全相同的Prompt和模型参数组合缓存其Completion结果。语义缓存使用嵌入模型如text-embedding-ada-002将输入查询转换为向量在缓存中查找语义最相似的过往查询及其结果。如果相似度超过阈值则直接返回缓存结果。示例简单的精确缓存实现import hashlib import json from functools import lru_cache class PromptCache: def __init__(self, cache_filellm_cache.json): self.cache_file cache_file self.cache self._load_cache() def _get_hash_key(self, model, messages, temperature, max_tokens): # 创建一个唯一标识本次请求的键 key_str f{model}-{json.dumps(messages, sort_keysTrue)}-{temperature}-{max_tokens} return hashlib.md5(key_str.encode()).hexdigest() def get(self, key): return self.cache.get(key) def set(self, key, value): self.cache[key] value self._save_cache() def _load_cache(self): try: with open(self.cache_file, r) as f: return json.load(f) except FileNotFoundError: return {} def _save_cache(self): with open(self.cache_file, w) as f: json.dump(self.cache, f) # 使用缓存装饰器 lru_cache(maxsize128) def get_cached_completion(model, prompt_text, temperature0.7): cache PromptCache() key cache._get_hash_key(model, [{role:user,content: prompt_text}], temperature, 500) cached cache.get(key) if cached: print(f缓存命中节省了一次API调用。) return cached # ... 否则调用真实API ... result call_openai_api(model, prompt_text, temperature) cache.set(key, result) return result为什么有效对于开发、测试阶段反复运行的相同查询或生产环境中常见的标准问题缓存能几乎零成本地提供响应将Token消耗降至0。4. 完整实战案例构建一个Token高效的智能文档问答系统现在我们将上述策略整合构建一个完整的系统。该系统能处理长PDF文档接受用户自然语言提问并返回精准答案同时力求最小化Token消耗。4.1 创建项目结构与配置首先创建项目目录和配置文件。mkdir llm_token_optimization_demo cd llm_token_optimization_demo touch config.py main.py token_optimizer.py document_processor.py mkdir prompts dataconfig.py- 存放敏感配置# config.py import os from dotenv import load_dotenv load_dotenv() # 从 .env 文件加载环境变量 class Config: OPENAI_API_KEY os.getenv(OPENAI_API_KEY) if not OPENAI_API_KEY: raise ValueError(请在 .env 文件中设置 OPENAI_API_KEY 环境变量) # 模型选择 EMBEDDING_MODEL text-embedding-ada-002 # 用于向量化 LLM_MODEL gpt-3.5-turbo-1106 # 用于生成支持JSON模式 # 向量数据库路径 VECTOR_DB_PATH ./chroma_db # 文本分块设置 CHUNK_SIZE 1000 # 每个文本块的最大字符数 CHUNK_OVERLAP 200 # 块之间的重叠字符数 # 创建全局配置对象 config Config()在项目根目录创建.env文件并填入你的API密钥OPENAI_API_KEYsk-your-actual-api-key-here4.2 实现文档处理与向量化模块document_processor.py- 负责读取、分块、向量化文档# document_processor.py import PyPDF2 from typing import List import tiktoken import openai from chromadb import PersistentClient, Documents, Embeddings from chromadb.utils import embedding_functions import config class DocumentProcessor: def __init__(self): self.client openai.OpenAI(api_keyconfig.Config.OPENAI_API_KEY) self.encoder tiktoken.encoding_for_model(gpt-3.5-turbo) # 用于粗略估计Token # 初始化ChromaDB客户端和集合 self.chroma_client PersistentClient(pathconfig.Config.VECTOR_DB_PATH) # 使用OpenAI的嵌入函数 self.embedding_func embedding_functions.OpenAIEmbeddingFunction( api_keyconfig.Config.OPENAI_API_KEY, model_nameconfig.Config.EMBEDDING_MODEL ) self.collection self.chroma_client.get_or_create_collection( namedocuments, embedding_functionself.embedding_func ) def extract_text_from_pdf(self, pdf_path: str) - str: 从PDF提取纯文本 text with open(pdf_path, rb) as file: reader PyPDF2.PdfReader(file) for page in reader.pages: text page.extract_text() \n return text def chunk_text(self, text: str) - List[str]: 将长文本按语义和大小分块简化版按句子和字符数分割 sentences text.replace(\n, ).split(. ) chunks [] current_chunk for sentence in sentences: # 粗略估计Token数更精确可用tiktoken if len(self.encoder.encode(current_chunk sentence)) config.Config.CHUNK_SIZE: current_chunk sentence . else: if current_chunk: chunks.append(current_chunk.strip()) current_chunk sentence . if current_chunk: chunks.append(current_chunk.strip()) # 简单的重叠处理 final_chunks [] for i in range(len(chunks)): if i 0: # 取前一个块的后 overlap 部分拼接到当前块前 overlap_start max(0, len(chunks[i-1]) - config.Config.CHUNK_OVERLAP) overlapped_part chunks[i-1][overlap_start:] final_chunks.append(overlapped_part chunks[i]) else: final_chunks.append(chunks[i]) return final_chunks def index_document(self, pdf_path: str): 处理PDF文档并存入向量数据库 print(f正在处理文档: {pdf_path}) full_text self.extract_text_from_pdf(pdf_path) print(f文档提取完成总字符数: {len(full_text)}) chunks self.chunk_text(full_text) print(f文本分块完成共 {len(chunks)} 块) # 为每个块生成ID并存入向量库 ids [fchunk_{i} for i in range(len(chunks))] self.collection.add( documentschunks, idsids ) print(f文档已成功索引到向量数据库: {config.Config.VECTOR_DB_PATH}) return len(chunks) def retrieve_relevant_chunks(self, query: str, k: int 3) - List[str]: 根据查询检索最相关的k个文本块 results self.collection.query( query_texts[query], n_resultsk ) if results[documents]: return results[documents][0] # 返回最相关的k个文本块列表 return []4.3 实现Token优化策略核心模块token_optimizer.py- 集成各种优化策略# token_optimizer.py import tiktoken import json import config from document_processor import DocumentProcessor from typing import Dict, Any, List class TokenOptimizer: def __init__(self): self.encoder tiktoken.encoding_for_model(config.Config.LLM_MODEL) self.dp DocumentProcessor() self.conversation_history [] # 简单的会话历史记录 def count_tokens(self, text: str) - int: 精确计算文本的Token数量 return len(self.encoder.encode(text)) def compress_context_with_retrieval(self, query: str, full_context: str None, k: int 3) - str: 策略1通过向量检索压缩上下文。 如果提供了full_context则先索引它适用于单次对话。 通常更优的做法是提前索引好文档库。 if full_context: # 临时处理并检索演示用效率低 chunks self.dp.chunk_text(full_context) # 这里简化处理实际应将chunks临时加入向量库进行查询 # 为演示我们假设检索到了最相关的第一个块 return chunks[0] if chunks else else: # 从已索引的文档库中检索 relevant_chunks self.dp.retrieve_relevant_chunks(query, kk) return \n\n---\n\n.join(relevant_chunks) # 用分隔符连接多个相关块 def format_structured_prompt(self, system_instruction: str, compressed_context: str, user_query: str) - List[Dict[str, str]]: 策略1补充构建高效的消息列表。 系统指令只放一次用户查询和压缩后的上下文结合。 messages [ {role: system, content: system_instruction}, {role: user, content: f参考信息\n{compressed_context}\n\n问题{user_query}} ] # 可选加入简短的历史记录控制长度 if self.conversation_history: # 只保留最近2轮历史防止膨胀 recent_history self.conversation_history[-4:] # 最后两条user/assistant对 messages [messages[0]] recent_history [messages[1]] return messages def ask_with_optimization(self, user_query: str, use_cache: bool True) - Dict[str, Any]: 整合优化策略的问答函数。 1. 检索压缩上下文。 2. 构建高效Prompt。 3. (可选)检查缓存。 4. 调用API请求结构化输出。 5. 更新历史并返回。 # 1. 压缩上下文 compressed_ctx self.compress_context_with_retrieval(user_query, k3) print(f[优化] 上下文压缩后Token数: {self.count_tokens(compressed_ctx)}) # 2. 构建Prompt with open(prompts/system_prompt.txt, r, encodingutf-8) as f: system_instruction f.read().strip() # 例如“你是一个专业的技术文档助手。” messages self.format_structured_prompt(system_instruction, compressed_ctx, user_query) total_input_tokens sum([self.count_tokens(m[content]) for m in messages]) print(f[优化] 预估输入总Token: {total_input_tokens}) # 3. 缓存逻辑此处简化实际可用上节的PromptCache cache_key None if use_cache: # 生成缓存键基于消息内容和模型 cache_key hash(json.dumps(messages, sort_keysTrue)) # ... 这里应连接缓存系统进行查询假设未命中 ... # 4. 调用API要求结构化输出 import openai client openai.OpenAI(api_keyconfig.Config.OPENAI_API_KEY) try: response client.chat.completions.create( modelconfig.Config.LLM_MODEL, messagesmessages, temperature0.1, # 低温度输出更确定 max_tokens500, # 限制输出长度 response_format{ type: json_object } # 强制JSON输出 ) except openai.APIConnectionError as e: print(f网络连接失败: {e}) return {error: Network error} except openai.RateLimitError as e: print(f速率限制: {e}) return {error: Rate limit} except openai.APIStatusError as e: print(fAPI错误: {e.status_code} - {e.response}) return {error: fAPI error {e.status_code}} answer_text response.choices[0].message.content output_tokens response.usage.completion_tokens total_used response.usage.total_tokens print(f[优化] 本次消耗Token - 输入: {response.usage.prompt_tokens}, 输出: {output_tokens}, 总计: {total_used}) # 5. 解析JSON输出 try: result json.loads(answer_text) # 假设我们的JSON结构是 {answer: ..., confidence: ..., sources: [...]} final_answer result.get(answer, answer_text) # 兼容非JSON回退 except json.JSONDecodeError: print(警告模型未返回有效JSON使用原始文本。) final_answer answer_text result {answer: answer_text} # 6. 更新会话历史控制长度 self.conversation_history.append({role: user, content: user_query}) self.conversation_history.append({role: assistant, content: answer_text}) # 保持历史记录不会无限增长例如只保留最近10轮 if len(self.conversation_history) 20: self.conversation_history self.conversation_history[-20:] result[total_tokens_used] total_used result[optimized_input_tokens] total_input_tokens return result4.4 编写提示模板创建提示模板文件使系统指令可配置。prompts/system_prompt.txt你是一个专业、准确且简洁的技术文档问答助手。你的任务是根据用户提供的“参考信息”片段来回答问题。 - 如果答案明确存在于参考信息中请直接基于信息回答并注明信息来源的片段。 - 如果参考信息不足请如实告知“根据提供的信息无法完全回答”并可以基于你的知识给出补充说明但需明确指出哪些部分超出了给定信息。 - 请始终以JSON格式输出包含以下字段 1. answer: (字符串) 你的主要回答。 2. confidence: (浮点数) 你对答案的置信度0.0到1.0。 3. sources: (字符串数组) 引用的参考信息摘要或索引。 4. is_complete: (布尔值) 答案是否仅基于参考信息即可完成。 - 保持回答客观、准确不要添加无关内容。prompts/query_compress.txt(可用于更高级的查询重写/压缩本例未直接使用)请将以下用户查询重写为一个更简洁、信息密度更高的版本便于进行信息检索。保留所有核心意图和关键实体。 原始查询{original_query} 重写后的查询4.5 主程序与运行验证main.py- 系统主入口# main.py import sys import config from document_processor import DocumentProcessor from token_optimizer import TokenOptimizer def main(): # 初始化 dp DocumentProcessor() optimizer TokenOptimizer() # 步骤1索引文档如果尚未索引 pdf_path ./data/sample_doc.pdf # 请在此处放入你的PDF文档 # 注意实际应用中索引只需运行一次。这里为了演示每次运行都检查。 # 你可以添加逻辑判断向量库是否已存在。 try: print(尝试从现有向量库加载...) # 简单检查尝试查询一个空字符串看集合是否存在 _ dp.collection.peek() print(向量库已存在跳过索引。) except Exception as e: print(f向量库未找到或出错 ({e})开始索引文档...) # 确保data目录下有sample_doc.pdf num_chunks dp.index_document(pdf_path) print(f文档索引完成共 {num_chunks} 个文本块。) # 步骤2交互式问答 print(\n *50) print(智能文档问答系统 (Token优化版) 已启动) print(输入您的问题输入 quit 或 exit 退出) print(*50) while True: try: user_input input(\n您的问题: ).strip() if user_input.lower() in [quit, exit, q]: print(再见) break if not user_input: continue print(正在思考...) # 使用优化后的问答流程 result optimizer.ask_with_optimization(user_input, use_cacheTrue) if error in result: print(f出错: {result[error]}) continue print(\n--- 回答 ---) print(result.get(answer, 无答案)) if sources in result and result[sources]: print(f\n[参考来源] {result[sources]}) print(f[置信度] {result.get(confidence, N/A)}) print(f[是否基于原文] {result.get(is_complete, N/A)}) print(f[本次Token消耗] {result.get(total_tokens_used, N/A)}) print(------------) except KeyboardInterrupt: print(\n程序被中断。) break except Exception as e: print(f发生未知错误: {e}) import traceback traceback.print_exc() if __name__ __main__: main()运行与验证将你的PDF技术文档如软件架构说明书放入./data/目录并重命名为sample_doc.pdf。安装依赖pip install -r requirements.txt(需创建requirements.txt文件内容为之前pip install的库列表)。运行程序python main.py。首次运行会索引文档稍等片刻。进入交互界面后尝试提问例如“文档中提到的微服务架构有哪些优势”。观察控制台输出的Token计数并与“直接全文粘贴提问”的方式可通过修改代码对比进行对比。4.6 结果说明与对比运行上述系统后你会得到结构化的答案。更重要的是通过控制台日志你可以清晰地看到优化策略带来的Token节省效果。假设场景对比原始方法Naive将一篇5000 Token的文档全文作为上下文加上问题输入Token约5050。模型生成一个300 Token的回答。总计约5350 Token。优化后方法Our System向量检索仅返回与问题最相关的3个文本块总计600 Token。精炼的系统指令和结构化Prompt共计100 Token。输入总Token约700 Token。模型生成一个150 Token的JSON格式回答因为输出更紧凑。总计约850 Token。节省效果(5350 - 850) / 5350 ≈ 84%的Token消耗被节省下来这意味着成本降至原来的约1/6并且由于上下文更聚焦答案的准确性和相关性通常更高。5. 常见问题与排查思路在实现和运行此类优化系统时你可能会遇到以下问题问题现象常见原因解决思路向量检索返回不相关片段1. 文本分块不合理破坏了语义。2. 嵌入模型不适合该领域文本。3. 查询语句与文档表述差异大。1. 尝试不同的分块大小和重叠度或使用基于句子的分块。2. 考虑使用领域特定的嵌入模型或微调。3. 对用户查询进行重写或扩展查询增强再检索。模型忽略检索到的上下文产生幻觉1. 系统指令不够强未强制模型“基于参考信息”。2. 上下文格式混乱模型难以定位。3. 检索到的片段确实不包含答案。1. 强化系统指令例如“你必须且只能根据提供的‘参考信息’回答问题。”2. 用更清晰的标记如## 片段1 ##格式化上下文。3. 增加检索数量k值或改进检索质量。结构化输出格式错误1. 模型未遵循指定的response_format。2. Prompt中JSON结构描述不清。1. 确保使用支持JSON模式的模型如gpt-3.5-turbo-1106或更高。2. 在系统指令中详细描述JSON结构并提供一个简单示例。Token计数与实际API消耗不符1.tiktoken计数与API计数有细微差异。2. 未计算消息中的角色role等元数据。1. OpenAI API返回的usage字段是最准确的。tiktoken用于预估和优化。2. 对于精确成本计算始终以API返回的usage为准。缓存导致返回过时答案1. 文档内容已更新但缓存未失效。2. 语义缓存相似度阈值设置过高。1. 为缓存键加入文档版本或时间戳。2. 实现缓存失效策略或对关键查询禁用缓存。处理长文档时程序内存/速度慢1. 一次性将整个文档读入内存进行分块。2. 向量索引未持久化每次重启都重建。1. 使用流式方式读取和处理文档。2. 确保使用PersistentClient向量库持久化到磁盘。6. 最佳实践与工程建议将“Fewer Tokens”理念融入工程实践需要从设计到运维的全流程关注监控与度量先行在应用中集成Token使用量的日志记录。监控每次调用的输入/输出Token数、成本以及响应时间。设置告警阈值当单次调用或日均Token消耗异常增长时触发告警。分层缓存策略L1缓存内存使用functools.lru_cache缓存频繁出现的完全相同的Prompt。L2缓存分布式缓存如Redis存储语义相似查询的结果键为查询的嵌入向量哈希。缓存失效当源数据如知识库文档更新时需要有机制使相关缓存失效。提示模板化管理不要将Prompt字符串硬编码在代码中。像我们示例一样将其放在外部文件如prompts/目录或配置管理中。为不同的任务摘要、问答、分类创建专门的模板便于测试和优化。实施速率限制与退避即使在应用层也要对用户或终端实施调用频率限制防止意外循环或滥用导致Token成本激增。实现指数退避重试机制以优雅地处理API的速率限制错误。异步与流式处理对于批量处理任务如索引大量文档使用异步请求以提高效率。对于需要长时间生成的回答考虑使用流式响应Streaming让用户尽早看到部分结果并能在生成过长时提前中断节省不必要的输出Token。定期评估与优化定期审查日志找出Token消耗最高的查询模式。A/B测试对比不同提示词、不同分块策略、不同检索数量k对答案质量和Token消耗的影响持续迭代优化。安全与成本隔离使用API密钥时遵循最小权限原则为不同环境开发、测试、生产使用不同的密钥。在云服务商设置每月预算和硬性限制防止因程序错误或攻击导致巨额账单。通过本文的探讨和实战我们深入理解了“用更少的Token完成复杂任务ACE”不仅是一个研究概念更是一套可落地、效果显著的工程实践。它要求我们在提示工程、上下文管理、输出控制、缓存利用等多个层面进行精细设计。记住每一次不必要的Token消耗都在增加你的成本和延迟。从今天开始像对待宝贵的内存和CPU周期一样对待你的Token吧。