Mismo bucle de chat en Ollama sin claves en la nube
Ejecuta la ruta de mensajes en formato OpenAI contra un modelo local para que las tutoriales sigan siendo compatibles sin conexión.
Utilícelo como una versión reestructurada dirigida a los operadores de las ideas presentadas en “Parte 5 — Ejecutar el mismo bucle en Ollama (sin clave API, dialecto OpenAI)”: etapas claras, espacios ordenados para el código y notas de recuperación que perduran tras una transferencia de responsabilidades. La visión general funciona mejor cuando se trata como una superficie medible. Capture una transcripción ideal, un caso de fallo y la nota de reversión antes de ampliar el alcance. Considere esta etapa como un contrato entre las entradas y las salidas validadas. Asigne nombres a los artefactos, defina comprobaciones de éxito y rechace las completaciones parciales silenciosas.
from openai import OpenAI
# Part 2's SDK, different address
client = OpenAI(
base_url="http://localhost:11434/v1",
api_key="ollama", # required, unused
)
resp = client.chat.completions.create(
model="llama3.2",
messages=[
{
"role": "system",
"content": "You are a concise "
"assistant.",
},
{
"role": "user",
"content": "Where are you running "
"right now?",
},
],
temperature=0,
)
print(resp.choices[0].message.content)
msgs = [{
"role": "system",
"content": "You are a concise assistant.",
}]
def ask(text: str) -> str:
msgs.append(
{"role": "user", "content": text}
)
resp = client.chat.completions.create(
model="llama3.2",
messages=msgs, # full history
temperature=0,
)
reply = resp.choices[0].message.content
msgs.append({
"role": "assistant",
"content": reply,
})
return reply
print(ask("Define a context window."))
print(ask("Now for a five-year-old."))
print(ask("Which answer was shorter?"))
# one-time: install from ollama.com, then
ollama pull llama3.2
pip install -r requirements.txt
python examples/part05_ollama.py
Lista de verificación operativa
Al trabajar en la lista de verificación operativa, anote primero el contrato: entradas requeridas, señal de éxito y qué ocurre en caso de fallo parcial. Esa lista mantiene honestas las futuras modificaciones del código.
Preferir unidades pequeñas y verificables en lugar de scripts extensos. Cuando un paso falla, el error debe indicar una única responsabilidad y no un proceso complicado.
Registre el ID de la solicitud, el ID del modelo y la latencia en cada llamada. Sin ese registro, los errores intermitentes del proveedor parecen bugs de la aplicación.
Fije las versiones de las dependencias y anote el resumen de la imagen utilizada en la demostración. La reproducibilidad es mejor que el conocimiento basado en experiencias individuales.
Trate esta etapa como un contrato entre las entradas y las salidas validadas. Asigne nombres a los artefactos, defina pruebas de éxito y rechace las completaciones parciales silenciosas.
Registre el ID de la solicitud, el ID del modelo y la latencia en cada llamada. Sin ese registro, los errores intermitentes del proveedor parecen bugs de la aplicación.
Antes de promocionar el conjunto de herramientas, congele las versiones, capture una transcripción de referencia para la ruta crítica y confirme los pasos de reversión. Los entornos compartidos requieren límites de velocidad, verificaciones de asignación y un responsable claro para la rotación de credenciales secretas. Prefiera una fiabilidad sencilla a demostraciones ingeniosas pero puntuales.
Nota para el lote 25763587d271: mantenga las claves del proveedor fuera del repositorio, establezca un límite para los tokens por sesión y almacene las transcripciones junto a los archivos de prueba para que los cambios posteriores en el modelo sigan siendo comparables.
Para la nota de fortalecimiento 0, defina las entradas, el responsable del paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Prefiera unidades pequeñas y verificables sobre scripts extensos. Cuando un paso falla, el error debe indicar una única responsabilidad y no un proceso complicado.
Detalle de refuerzo 0/681: mida el tiempo de ejecución, la clase de error y el consumo de tokens para esta nota, y luego decida si mantener el cambio basándose en un conjunto fijo de preguntas en lugar de en anécdotas.
Al trabajar en la nota de refuerzo 1, anote primero el contrato: las entradas requeridas, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación mantiene honestas las futuras modificaciones del código. Registre los tiempos y el costo en tokens o consultas junto a los resultados funcionales. La visibilidad temprana de los costos evita facturas inesperadas cuando el camino pasa de la demostración a entornos compartidos.
Detalle de refuerzo 1/681: mida el tiempo de ejecución, la clase de error y el consumo de tokens para esta nota, y luego decida si mantener el cambio basándose en un conjunto fijo de preguntas en lugar de en anécdotas.
La nota de fortalecimiento 2 funciona mejor cuando se trata como una superficie medible. Capture una transcripción exitosa, un caso de fallo y la nota de reversión antes de ampliar el alcance. Documente tanto el camino óptimo como el camino de recuperación juntos. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son mejoras posteriores.
Detalle de fortalecimiento 2/681: mida el tiempo de ejecución, la clase del error y el consumo de tokens para esta nota, y luego decida si mantener el cambio basándose en un conjunto fijo de preguntas en lugar de anécdotas.
Para la nota de fortalecimiento 3, defina las entradas, el responsable de cada paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Trate esta etapa como un contrato entre las entradas y los resultados validados. Asigne nombres a los artefactos, defina verificaciones de éxito y rechace las completaciones parciales silenciosas.
Detalle de endurecimiento 3/681: mida el tiempo de procesamiento de la pared, la clase de error y el gasto de tokens para esta nota, y luego decida si mantener el cambio basándose en un conjunto fijo de preguntas en lugar de en anécdotas.
Lecturas relacionadas
- El bucle de chat sin estado: Llamada a la API de OpenAI a mano en Python — Construya un chat de varias turnos con el SDK de Python de OpenAI gestionando usted mismo el historial de mensajes, y descubra por qué el mismo bucle sustenta la memoria y los agentes de LangChain.
- IA local después de Ollama: Elección de entornos en 2026 — Por qué Ollama es una excelente opción inicial pero un plano de control deficiente a largo plazo — y qué herramientas como llama.cpp, LM Studio, vLLM y otras son adecuadas para cada etapa.