Make. Build. Break. Reflect.
В удивительнейшее время живём.
- https://typesafe.ai/blog/introducing-system-one-models-and-jev
TypeSafe анонсировали Jev, свою первую "System One" модель - быстрые типизированные решения вместо генерации текста.
- https://github.com/mizorewww/laya-mlx (на минуточку это уже опенсорс!)
а это похожая по духу модель, но от другой компании (Convai Innovations), уже в опенсорсе и с портом под Apple Silicon (eto ya со своим макбуком).
И она меньше гигабайта!
То есть Jev сам по себе проприетарный и закрытый, но концепция уже доступна в опенсорсе - я погонял именно Laya.
Поигрался - весьма интересно.
Пример использования (первым пришло в голову для тестов):
- установить этот опенсорс decision-модель
pip install laya-mlx
- залогиниться в hugging face
- запилить скрипт laya_triage.py
"""Local Laya (MLX) triage of a SQL query; escalate to a Hugging Face LLM only if needed.
Usage:
HF_TOKEN=hf_xxx python ~/laya_triage.py # uses the built-in sample query
HF_TOKEN=hf_xxx python ~/laya_triage.py query.sql # or a query from a file
Optional env: HF_MODEL (default below), LAYA_THRESHOLD (default 0.5).
"""
import os
import sys
import laya_mlx
from huggingface_hub import InferenceClient
HF_MODEL = os.environ.get("HF_MODEL", "Qwen/Qwen2.5-Coder-32B-Instruct")
THRESHOLD = float(os.environ.get("LAYA_THRESHOLD", "0.5"))
SAMPLE_SQL = """
SELECT u.id, u.name, COUNT(o.id)
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE u.created_at >= '2026-01-01'
GROUP BY u.id, u.name;
"""
QUESTIONS = {
"needs_optimization": {
"type": "noul",
"instructions": "Does this SQL query contain potential performance bottlenecks "
"(full table scans, inefficient joins, missing filters on large tables)?",
},
"issue": {
"type": "choice",
"instructions": "What is the most likely performance problem in this SQL query?",
"criteria": {
"missing_index": "The query filters or joins on columns that likely need an index",
"heavy_aggregation": "The query uses GROUP BY / COUNT over very large tables",
"fine": "The query looks optimal",
},
},
}
def triage(agent, sql):
answers = agent.predict(sql, QUESTIONS)["answers"]
p_slow = answers["needs_optimization"]["noul"]
issue = answers["issue"]["choice"]
print(f"[laya] needs_optimization p={p_slow:.2f}")
print(f"[laya] issue={issue} probs={answers['issue']['probabilities']}")
return p_slow >= THRESHOLD and issue != "fine", issue
def optimize(sql, issue):
token = os.environ.get("HF_TOKEN")
if not token:
sys.exit("HF_TOKEN is not set; cannot escalate to Hugging Face")
client = InferenceClient(api_key=token)
resp = client.chat_completion(
model=HF_MODEL,
messages=[
{"role": "system", "content": "You are a senior database performance engineer."},
{
"role": "user",
"content": f"A classifier flagged this query as likely '{issue}'. "
"Explain the bottleneck briefly, suggest indexes, and give an optimized "
f"query if one exists.\n\n```sql\n{sql.strip()}\n```",
},
],
max_tokens=800,
)
return resp.choices[0].message.content
def main():
sql = open(sys.argv[1]).read() if len(sys.argv) > 1 else SAMPLE_SQL
agent = laya_mlx.load() # convaiinnovations/laya, downloaded once to the HF cache
needs_llm, issue = triage(agent, sql)
if not needs_llm:
print("[laya] query looks fine, no LLM call")
return
print(f"[hf] escalating to {HF_MODEL} ...\n")
print(optimize(sql, issue))
if __name__ == "__main__":
main()
- запускаем
HF_TOKEN=hf_Tgar5555555jlOS python ~/laya_triage.py
- и практически мгновенно получаем результат
[laya] needs_optimization p=0.19
[laya] issue=heavy_aggregation probs={'missing_index': 0.0781, 'heavy_aggregation': 0.6264, 'fine': 0.2955}
[laya] query looks fine, no LLM call
Магия магией.
Важно: это триаж локальной моделью (Laya), а не замена ревью!!!
Ни она, ни HF-модель при эскалации не трогают базу, они только советуют. Финальное решение (индекс добавлять или нет) всё равно за человеком!
26 · 954 ·