如何实现调用Ollama一次性聊天,不会有历史聊天记录?

环境:

Ubuntu20.04

ollama 0.6.4

问题描述:

给用户总结资料,不同用户会有不同背景资料,总结2次就不用了,有很多接口调用ollama聊天一两次就换个角色,为了不让他们聊天内容混乱?

在这里插入图片描述

解决方案:

为了在使用Ollama时避免不同角色或会话的聊天内容混淆,可以通过以下方法清除历史记录或隔离上下文:


方法一:通过API调用时重置上下文

在每次发送请求时,不传递历史消息或显式清空上下文参数(不同接口可能不同):

import ollama

# 每次新对话时,使用全新的messages数组,不保留历史
response = ollama.chat(
    model='llama2',
    messages=[
        {'role': 'user', 'content': '你这次的角色是厨师,请回答...'}
    ]
)
# 下次调用时重新初始化messages,不携带之前的记录

方法二:使用keep_alive参数控制上下文保留时间

设置 keep_alive 参数为极短时间(如0s),使模型在请求完成后立即释放上下文:

response = ollama.chat(
    model='llama2',
    messages=[...],
    options={'keep_alive': '0s'}  # 关闭上下文保留
)

方法三:手动调用API清除模型实例

如果使用本地部署的Ollama服务,可通过REST API删除当前模型实例(强制释放内存中的上下文):

curl http://localhost:11434/api/delete -d '{"name": "llama2"}'

然后重新拉取模型:

curl http://localhost:11434/api/pull -d '{"name": "llama2"}'

方法四:为不同角色创建独立会话

如果框架支持(如使用编程库),为每个角色初始化独立的会话对象,避免交叉污染:

# 示例:使用不同会话对象
session1 = ollama.chat(model='llama2', messages=[])
session2 = ollama.chat(model='llama2', messages=[])

# 角色A使用session1
session1.send('作为厨师...')

# 角色B使用session2
session2.send('作为医生...')

方法五:修改Ollama启动配置(高级)

编辑Ollama配置文件(通常位于 ~/.ollama/config.json),调整上下文管理策略(需查阅官方文档确认支持参数)。


总结

  • 简单场景:每次调用不传递历史消息(messages只保留当前对话)。
  • 频繁切换角色:使用keep_alive: '0s'或独立会话。
  • 彻底清理:重启Ollama服务或删除模型后重新加载。

本案例具体实现:

import requests
import json

OLLAMA_URL = "http://192.168.28.13:11434/v1/chat/completions"

def send_message(user_input):
    messages = [
        {
            "role": "system",
            "content": (
                "【角色设定】\n"
                "你的身份是一名资深的方案生成专家,精准提供专业方案生成。\n\n"
                "【任务要求】\n"
        },
        {
            "role": "user",
            "content": user_input
        }
    ]

    payload = {
        "model": "qwen2.5-7b:latest",
        "messages": messages,
        "max_tokens": 8192,
        "temperature": 0.5,
        "stream": False
    }

    try:
        print(f"发送请求: {json.dumps(payload, ensure_ascii=False)}")
        response = requests.post(OLLAMA_URL, json=payload, timeout=30)
        print(f"状态码: {response.status_code}")
        if response.status_code != 200:
            print(f"错误响应: {response.text}")
            return "服务端返回错误,请检查日志。"

        result = response.json()
        choices = result.get("choices", [])
        if not choices:
            return "无回复内容"

        content = choices[0].get("message", {}).get("content", "")
        return content

    except requests.exceptions.Timeout:
        print("请求超时,请重试。")
        return "请求超时,请重试。"
    except requests.exceptions.RequestException as e:
        print(f"请求失败: {str(e)}")
        return "请求失败,请检查网络连接或服务状态。"
    except Exception as e:
        print(f"内部错误: {str(e)}")
        return "内部错误,请联系管理员。"

def collect_multiline_input():
    print("请输入您的问题(支持多行输入,输入单独一行END结束):")
    lines = []
    while True:
        line = input()
        if line.strip() == "END":
            break
        lines.append(line)
    return "\n".join(lines)

if __name__ == "__main__":
    print("欢迎使用简单聊天应用!")
    print("您可以输入问题,我会尽力回答。输入“退出”或“exit”结束对话。")
    while True:
        user_input = collect_multiline_input()
        if user_input.lower() in ["退出", "exit", "quit"]:
            print("聊天结束。感谢使用!")
            break
        reply = send_message(user_input)
        print("AI: ", reply)

上面这段代码是单次独立对话的实现,不会保留任何聊天记录。具体分析如下:


关键设计解析:

  1. 消息列表初始化

    messages = [
        {"role": "system", "content": "..."},  # 固定的系统提示
        {"role": "user", "content": user_input} # 仅包含当前输入
    ]
    

    每次请求都会新建消息列表,仅包含:

    • 固定不变的 system 角色提示(高考专家设定)
    • 用户本次输入的内容(不含历史对话)
  2. 无状态服务

    • 没有全局变量、数据库或文件存储对话历史
    • 每次请求都是完全独立的 HTTP POST
  3. 代码执行流程

    while True:
        user_input = collect_multiline_input()  # 获取本次输入
        reply = send_message(user_input)        # 发送独立请求
        print(reply)                            # 输出后不保存回复
    

典型表现示例:

  • 用户第一次输入

    我考了650分,能上清华吗?
    

    → 消息列表仅包含系统提示 + 这个问题

  • 用户第二次输入

    那我的分数能报计算机专业吗?
    

    → 模型不知道之前的650分信息,因为消息列表被重置


优点与局限:

优点局限
1. 实现简单1. 无法支持多轮对话
2. 节省内存2. 用户需重复提供信息
3. 避免上下文污染3. 无法实现连贯交流

改为多轮对话的方法:

若需保留上下文,需修改代码:

# 在循环外初始化历史记录
chat_history = [
    {"role": "system", "content": "..."}
]

while True:
    user_input = collect_multiline_input()
    # 每次添加用户输入和AI回复到历史
    chat_history.append({"role": "user", "content": user_input})
    reply = send_message(chat_history)
    chat_history.append({"role": "assistant", "content": reply})

这样每次请求都会携带完整的对话历史,实现连续对话。

<think>好的,用户想在MacBook M4 Pro上基于Dify和DeepSeek模型复现汉得AI采购报价智能体的核心功能,需要详细的无代码实现方案和Docker部署配置。首先,我需要理清楚汉得AI采购报价智能体的各个核心模块,然后对应到Dify平台的功能上。 首先,用户提到的核心功能包括接收产品参数输入、生成补充信息建议、重新生成定价需求、匹配历史数据与网络信息、拆解成本构成项、修正大模型幻觉、加载定价模板和存储报价单。这些功能需要逐一拆解,看看如何在Dify中通过工作流和工具链实现。 Dify的v1.0.0版本支持工作流编排,可以连接不同的处理节点。比如,接收产品参数输入可以通过Dify的表单输入节点实现,生成补充信息建议可能需要调用DeepSeek模型进行推理。这里需要考虑如何将用户输入传递给模型,并处理返回的结果。 接下来,重新生成定价需求可能需要结合历史数据和实时网络信息。用户提到需要匹配历史数据,可能需要连接到本地数据库或外部API。Dify支持通过API调用工具,所以需要配置相应的数据源连接。同时,网络信息可能需要爬虫或第三方服务,这部分需要考虑如何集成到工作流中。 拆解成本构成项可能需要模型解析输入参数,并结合预设的成本结构模板。这里可能需要使用提示词工程,引导模型按照特定格式输出,然后通过后处理步骤提取所需数据。修正大模型幻觉是关键,可能需要后处理模块来校验模型的输出,比如设置规则检查或二次验证。 加载定价模板并生成最终报价,这部分需要模板引擎的支持。Dify可能没有内置的模板引擎,但可以通过自定义函数节点或者结合Jinja2模板来实现。存储报价单则需要连接到数据库或文件存储,可能需要编写一个存储节点,将输出结果保存到本地或云存储。 关于Docker部署,用户的环境是MacBook M4 Pro,48GB内存,足够运行较大的模型。需要配置Dify的Docker Compose文件,包括Dify服务、DeepSeek模型服务(Ollama)、数据库(如PostgreSQL)、Redis缓存等。需要确保各容器之间的网络通信,特别是Dify如何调用本地的Ollama服务提供的DeepSeek模型。 另外,用户提到使用Dify v1.0.0.0+deepseek-r1:14b,需要确认Ollama支持的模型版本是否正确,以及模型是否适配M4 Pro的芯片。可能需要在Ollama中正确配置模型路径,并确保模型服务正常启动。 可能遇到的问题包括模型响应速度、工作流节点之间的数据传递格式、存储模块的实现方式。需要检查Dify的文档,确认各个工具链的支持情况,比如是否支持直接调用本地API,或者是否需要通过Webhook等方式连接外部服务。 最后,测试整个流程是否顺畅,从输入参数到生成报价单,确保每个模块的输出正确,并且Docker容器之间的依赖关系正确配置。可能需要编写详细的部署步骤,包括环境变量设置、Docker Compose配置示例,以及各个服务的启动顺序。</think>根据Dify平台特性和汉得AI采购报价智能体的功能需求,以下是基于Dify v1.0.0+DeepSeek-r1:14b的本地化实现方案: --- ### 一、系统架构设计 $$ \begin{cases} \text{Dify 工作流} & \rightarrow \text{数据处理层} \\ \text{DeepSeek 模型服务} & \rightarrow \text{AI推理层} \\ \text{Docker 容器群} & \rightarrow \text{基础设施层} \end{cases} $$ --- ### 二、核心模块实现方案 #### 1. 输入接收模块 **实现方式**: - 使用Dify的`表单输入节点`配置参数模板: ```json { "product_type": "下拉选择框", "material_cost": "数字输入", "delivery_time": "日期选择" } ``` - 通过`参数验证器`实现数据类型校验[^1] #### 2. 智能建议生成 **工作流配置**: ```python Input → [参数清洗] → [DeepSeek推理节点] → [建议格式化] ``` **提示词设计**: ```markdown # 上下文 用户输入参数:{input_params} 历史采购数据:{history_data} # 任务 生成补充参数建议,需包含以下维度: 1. 材料市场价波动预测 2. 物流供应商推荐 3. 替代材料可行性分析 ``` #### 3. 定价需求重构 **Docker服务配置**: ```dockerfile # 历史数据服务 services: history_db: image: postgres:15 volumes: - ./pricing_history:/var/lib/postgresql/data environment: POSTGRES_PASSWORD: dify_history@2024 ``` --- ### 三、关键功能实现 #### 1. 成本拆解引擎 **Dify函数节点**: ```python def cost_breakdown(inputs): model_response = deepseek.generate(f""" 根据{inputs['材料成本']}和{inputs['物流要求']}, 按以下结构输出: $$成本构成 = 原材料 \times 系数 + 人工费 \times 工时 + 物流费 \times 区域系数$$ """) return parse_latex(model_response) ``` #### 2. 幻觉修正模块 **双验证机制**: $$ \text{最终输出} = \begin{cases} \text{模型原始输出} & \text{if } \text{置信度} \geq 0.9 \\ \text{规则引擎修正} & \text{otherwise} \end{cases} $$ **规则库示例**: ```yaml - 规则: 当检测到"不锈钢"且单价<100时 动作: 触发人工复核 ``` --- ### 四、完整Docker部署方案 #### 1. 部署架构 ```mermaid graph TD A[Dify Web] --> B[Ollama服务] B --> C[PostgreSQL] C --> D[Redis缓存] D --> E[规则引擎服务] ``` #### 2. docker-compose.yml ```yaml version: '3.8' services: dify-web: image: dify/dify:1.0.0 ports: - "80:3000" depends_on: - ollama environment: OLLAMA_ENDPOINT: http://ollama:11434 ollama: image: ollama/ollama volumes: - /Users/yourusername/.ollama:/root/.ollama deploy: resources: reservations: memory: 32G pricing-db: image: postgres:15 volumes: - ./pricing_data:/var/lib/postgresql/data ``` --- ### 五、实施步骤 1. **环境准备**: ```bash # 下载模型 OLLAMA_HOST=0.0.0.0 ollama run deepseek-r1:14b ``` 2. **工作流导入**: - 在Dify控制台导入预设的`采购报价工作流.json` 3. **数据连接配置**: ```python # 历史数据连接配置示例 postgresql://user:pass@localhost:5432/pricing_history ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

玩人工智能的辣条哥

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值