أنا مطور لشبكة الإنترنت. عندما بدأت في بناء أنظمة LLL، أشار لي الجميع نحو Lang Chain. "هذا هو المعيار،" قالوا. "جميع الأمثلة تستخدم ذلك." وكانوا على حق - إذا كنت في النظام الإيكولوجي بايثون، لانغ تشين هو في كل مكان.
لكن إليك الأمر: أنا لا أتجنب لانغ تشاين لأنه سيء. أنا أتجنبه لأنه يحل المشاكل التي أحلها بالفعل بشكل أكثر صراحة، وبالنسبة لحالات الاستخدام - C#، الاستدلال المحلي، الخصوصية، التحديدية - الأطر تضيف الاحتكاك بدلاً من القيمة.
هذا ليس منصباً معادياً لـ(لانغ شاين)، بل منصباً عن فهم المشاكل التي تحلها الأطر، وإدراك أنك قد لا تحتاج إليها.
الأطروحة: إذا كنت تفهم المشاكل التي حلت لانغ تشاين، فأنت لا تحتاج إلى لانغ شاين.
لنكن عادلين أولاً، (لانغ تشاين) يتفوق في عدة أمور:
**** يمكنك الحصول على عرض عملي خلال دقائق، أمثلة البدء جيدة حقاً.
بيثون تكامل النظم الإيكولوجية في النظام الإيكولوجي - إذا كنت بالفعل في عالم بايثون / جوبيتر / بانداس، لانغ تشاين يلصق كل شيء معا بسلاسة.
مخفضاً الحاجز - بالنسبة للأشخاص الجدد على LLLMs، فإنه يوفر مستخلصات مفيدة: قوالب سريعة، أنماط الدعوة للأدوات، إدارة الذاكرة، دمج الناقل DB.
Langchhain هو مُجِّل مُرْزِلإنه يسرع الطريق من "لدي فكرة" إلى "لدي نموذج" هذا قيّم.
لكن أيضاً حيث تبدأ المشاكل بالنسبة لي كـ C# أنظمة إنتاج البناء.
قبل رفض الإطار، عليك أن تفهم ما هي المشاكل التي يحلها. لانغ تشاين يعالج هذه القضايا الحقيقية:
السؤال هو: هل تحتاج إلى إطار لحلها؟
لِأَنَّنَا أَنْظُومَةُ إِنْتَشَارِيَّةٌ لِإِنْتَاجِ ٱلْبَنَاءِ بِٱلْإِلْمَالِ ٱلْمُحَدَّدِينِ ، وَمُتَطَلِّبَاتِ ٱلْخِرَايَا ٱلْحَدِّيَّةِ ، وَسُلُوكِ ٱلْحَدِّيَّةِ ٱلْحَدِيدَةِ .
Lang Chain إدارة الذاكرة والسياق بالنسبة لك. هذا يبدو مناسباً حتى تحتاج إلى تصحيح السبب في أن الدافع الخاص بك هو 10،000 رمز أطول مما كان متوقعاً، أو لماذا LLM فجأة لديها الوصول إلى تاريخ المحادثة كنت تعتقد أنك مسحت.
الإطار conconcenatinates الحث، إدارة الذاكرة، والتعامل مع أمر التنفيذ ضمنياً. عندما ينكسر شيء ما، فإنك تصحح سلوك الإطار، وليس سلوك رمزك.
بمجرد اعتماد لانغ تشين، تبدأ في تصميم للملخ لـ لاغ لانغ تشينهيكلك يصبح مرتبطاً بخلاصات الإطار: السلاسل، العوامل، أجهزة الاسترجاع، الذاكرة الواقية.
هذا ليس فريداً لـ Lang Chain -- جميع الأطر تفعل هذا. ولكن في حقل سريع الحركة مثل LLLSs، حيث لم يتم بعد تسوية التجريدات الصحيحة،
لام لام لا تنشين:
وبصفتي مطوراً لشبكة الإنترنت، أفترض ما يلي:
الـ Nnet الموانئ لكنهم يلعبون لعبة اللحاق مع نسخة فيثون، والخلاصات لا تزال تشعر غريبة على C ديوديماتيك C#.
عندما تنتقل من النموذج الأولي إلى الإنتاج، تحتاج إلى:
Lang Chain يُحسّنُ لسرعةِ التكرارِ، لَيسَ صَنْد الإنتاجِ. ذلك رفيعُ للإبرازاتِ؛ هو a مشكلة للإنتاجِ.
ها هو النموذج العقلي الذي أستخدمه: LLLS هي محركات المنطق، وليس محركات التنفيذ.
من حيث المبدأ: السبب في LLLLS. المحركات compute.
هذا الفصل يقود كل ما أبنيه
وبدلاً من الذاكرة التي تدار في إطار العمل، أرسم سياقاً صريحاً لكل طلب:
public class QueryContext
{
public List<ColumnInfo> Schema { get; set; }
public List<Dictionary<string, string>> SampleRows { get; set; }
public List<ConversationTurn> History { get; set; }
public string UserQuestion { get; set; }
}
كل بناء فوري مرئي. أعرف بالضبط ما يتم إرساله إلى LLM لأنني بنيت السلسلة بنفسي:
private string BuildPrompt(QueryContext context)
{
var sb = new StringBuilder();
sb.AppendLine("You are a SQL expert. Generate a query based on:");
sb.AppendLine();
// Schema
sb.AppendLine("Schema:");
foreach (var col in context.Schema)
sb.AppendLine($" - {col.Name}: {col.Type}");
// History (if any)
if (context.History.Any())
{
sb.AppendLine("\nPrevious conversation:");
foreach (var turn in context.History.TakeLast(3))
sb.AppendLine($" Q: {turn.Question} → SQL: {turn.Sql}");
}
// Current question
sb.AppendLine($"\nQuestion: {context.UserQuestion}");
sb.AppendLine("Generate SQL (no explanation, just the query):");
return sb.ToString();
}
لا توجد حالة مخفية، لا سحرية، فقط بنية نصية واضحة، عندما يكون الأمر خاطئاً، أعرف السبب.
بدلاً من السماح لـ LLLLM بتنفيذ أي شيء، أنا استخدمه لتوليد النية، ثم تنفيذ ذلك القصد من خلال المحركات التحديدية:
الدالة LLM تولد SQL. DaDB تقوم بتنفيذه. LLM لا ترى البيانات:
// LLM generates intent
var sql = await GenerateSqlAsync(context);
// Validate before execution
var error = ValidateSql(connection, sql);
if (error != null)
{
// Retry with error feedback
sql = await GenerateSqlAsync(context, previousError: error);
}
// Execute in sandboxed engine
var results = ExecuteQuery(connection, sql);
هذا أكثر أماناً، أسرع، و قابل للتنقيط. LLL لا يمكن تشغيل بالخطأ. DROP TABLE لأنّي أحقّق من صحة الـ SQL أولاً. LLM لا يستطيع تسريب البيانات لأنه لا يرى البيانات أبداً
لقد كتبت مؤخراً عن تحليل ملفات CSV الكبيرة مع LLMs المحليةالبنية المعمارية:
سؤال مقدم من مستخدم سؤال: LLL LL LL / SQL DADDB
وتتلقى LLLC ما يلي:
توليدات LLLLM:
-
ومن ثم فإن النظام:
EXPLAIN (الإخطاء في الشواغس دون تنفيذ)LLLM لا ترى البيانات الفعلية أبداً. إنها فقط ترى التركيب.
هذا ما يسميه لانغ تشاين "العميل" -- نظام يستخدم LLLM لتوليد الإجراءات، والتحقق منها، وتنفيذها، وربما إعادة صياغة على الفشل.
ما عدا أنني بنيته في سطور C# مع عدم وجود إطار:
public class CsvQueryService
{
private readonly OllamaApiClient _ollama;
private readonly string _model;
public async Task<QueryResult> QueryAsync(string csvPath, string question)
{
using var connection = new DuckDBConnection("DataSource=:memory:");
connection.Open();
// 1. Build context
var context = BuildContext(connection, csvPath, question);
// 2. Generate SQL
var sql = await GenerateSqlAsync(context);
// 3. Validate
var error = ValidateSql(connection, sql);
if (error != null)
{
// Retry once with error feedback
sql = await GenerateSqlAsync(context, error);
}
// 4. Execute
return ExecuteQuery(connection, sql);
}
}
لا سلاسل، لا عملات إطارية، لا سحر، مجرّد تخطيط صريح لـ(إل إل إل إل) للإعدام.
مصطلح "العامل" يتم رميه حولنا باستمرار، عادة ما يعني "أي شيء ينطوي على إل إل إل إل إل." دعونا نكون دقيقين.
الوكيل هو:
الوكيل هو: لا توجد مكتبةإنه نمط نمطي
نمط وكيلي في C#:
public class Agent
{
private readonly List<ConversationTurn> _history = new();
public async Task<string> RunAsync(string goal)
{
while (!IsGoalAchieved(goal))
{
// 1. Generate next action based on history
var action = await GenerateActionAsync(goal, _history);
// 2. Validate before executing
if (!IsActionSafe(action))
{
_history.Add(new ConversationTurn
{
Action = action,
Result = "REJECTED: Unsafe action"
});
continue;
}
// 3. Execute through deterministic tool
var result = await ExecuteActionAsync(action);
// 4. Record and continue
_history.Add(new ConversationTurn { Action = action, Result = result });
}
return GenerateSummary(_history);
}
}
هذا وكيل. إنها حلقة مع الحالة، الأدوات، و التغذية المرتدة. كتبتها في 30 سطر. لم أكن بحاجة إلى إطار.
ولكي تكون عادلة مع النظام الإيكولوجي لشبكة نت، أصدرت مايكروسوفت تشغيل تشغيل تشغيل تشغيل تشغيل تشغيل تشغيل تشغيل تشغيل تشغيل تشغيل تشغيل تشغيل تشغيل هذا الغرض تم بناؤه لـ.NET تطويرات بناء إنتاج أنظمة الذكاء الاصطناعي.
وينص الإطار (المعروف سابقا باسم Microsoft.Extensions.AI) على ما يلي:
العناصر الرئيسية:
IChatClient - الواجهة الموحدة لإنجازات الدردشةIEmbeddingGenerator - ادماجات الفيروس عبر مقدمي الخدماتAIFunction - دالة السلامة من النوعمثال:
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddChatClient(builder =>
builder.UseOllama("llama3.2")
.UseOpenTelemetry()
.UseLogging());
var app = builder.Build();
app.MapPost("/chat", async (IChatClient client, string message) =>
{
var response = await client.CompleteAsync(message);
return response.Content;
});
حتى مع إطار مايكروسوفت، أفضّل أن أبقي التركيز الأساسي واضحاً:
لا أريد:
أنا أريد:
(مايكروسوفت) هو أقرب إلى طريقة تفكيري من (لانغ تشين) إنه يحترم أنماط الإنترنت، يستخدم حقن التبعية بشكل صحيح، ولا يحارب النظام البيئي. لكنني ما زلت أفضل كتابة الأوركسترا بنفسي.
متى إلى استخدام مايكروسوفت وكيل إطار:
(أ) متى يمكن الذهاب إلى الإطار غير الإطاري:
الإطار لا يقضي على القرارات المعمارية. لا تزال تختار ما تضعه في السياق، كيف تجمع البيانات، ومتى تعيد المحاولة. إنه فقط يجعل السباكة أسهل.
وتؤدي النظم التي لا إطار لها إلى تقدم أفضل لعدة أسباب:
م م م م خدمة الإستعلام الخاصة بي تعمل تحت 100m لأنه لا يوجد إطار بين LLM و DakDB.
**** أنا أسيطر تماماً على ما يذهب إلى "LLLM" لا تضخّم فوري خفي من الذاكرة المدبرة
**** - عندما يكسر شيء ما، أنا تصحيح رمز بلدي، وليس عكس هندسة إطار سحر.
**** -للنظم التي لديها متطلبات صارمة لبقاء البيانات، معرفة بالضبط ما الذي يترك الآلة مهمة.
سيناريوهات التنفيذ - أجهزة الحواف، وشبكات الهواء، والبيئات المنظمة، وتفترض الأطر الوصول إلى الإنترنت والخدمات السحابية.
**** في المالية، الرعاية الصحية، والحكومة، تحتاج في كثير من الأحيان لشرح ومراجعة كل قرار. "الإطار فعل ذلك" ليست إجابة مقبولة.
كلما كانت بيئتك مقيدة أكثر كلما أردت السيطرة الصريحة
إلى نزع سلاح النقاد: هناك حالات شرعية حيث يمكنني الوصول إلى لانغ تشاين.
مرونات الله -السرعة لطرح الأمور أكثر من الهندسة المعمارية
المُسْرَق - إذا كنت التحقق من فكرة وخطة لإعادة كتابة للإنتاج على أي حال.
الفرق ذات الحجم -إذا كان فريقك يتقن بالفعل في بايثون، فإن النظام البيئي المناسب قوي.
مفاهيم ما تقوم على ما تقوم على -ملخصات (لانغ تشين) يمكن أن تساعد المبتدئين على فهم نمط العميل قبل أن يبنوا نمطهم الخاص
متى المعرفة غير استخدام شيء ما هو قيمة بقدر معرفة متى تستخدمه.
هذا لا يتعلق حقاً بـ (لانغ تشاين) بل بالمفاضلة بين الأطر و المبادئ الهندسية الأولى
الإطارات تعجل المشاكل المألوفة. إذا كنت تقوم ببناء 100 CRUD API، الوصول إلى إطار الكيان أو Daper. تم تحديد الأنماط.
لكن أنظمة LLLM-Power؟ الخلاصات الصحيحة لم تستقر بعد. نحن لا نعرف ما إذا كانت "سلاسل" أو "وكيلات" أو "ريتريتيفرز" هي النماذج العقلية الصحيحة. ما زلنا نكتشف ذلك.
في تلك البيئة، أفضل أن أبني بالقرب من المعدن:
OllamaSharp، Opani SDK)بصفتي مطوراً لشبكة الإنترنت، لدي آراء قوية حول كيفية بناء الأنظمة: عمر واضح، طباعة قوية، متناغمة على طول الطريق للأسفل، حقن تبعية للإختبار.
مستخلصات (لانغ تشين) لا تُخطّط بشكل نظيف لتلك الآراء، لذا لا أستخدمها.
إذا كنت مطوراً لشبكة الإنترنت ينظر إلى لانغ تشين ويتساءل "هل أنا بحاجة إلى هذا؟"، هذا هو جوابي:
تحتاج إلى حل المشاكل التي لا يمكن حلّها - إدارة السياق، تنسيق الأدوات، منطق إعادة الاختبار، القابلية للرصد.
لا تحتاج إلى (لانغ تشاينين) لحلها -خصوصاً إذا قيّمت الصراحة، والطباعة القوية، والإنتاج الصلب على النماذج السريعة.
المبدأ الذي أبني عليه:
"السبب الرئيسي، المحركات تُحسب" "الأوركسترا لك لتمتلكها"
:ببساطة:
"إذا كنت تفهم المشاكل حل إطاري، كنت في كثير من الأحيان لا تحتاج إلى الإطار."
بناء الأنظمة المنطقية في نظامك البيئي، مع قيودك، باستخدام تعابير لغتك. بالنسبة لي، هذه C#، الطباعة القوية، وتدفق التحكم الصريح، وطبقات التنفيذ التحديدي.
بالنسبة لك، قد يكون الأمر مختلفاً وهذا جيد
الهدف ليس تجنب الأطر. الهدف هو اختيارها بوعي، فهم ما توفره وما تكلفه.
اقرأ المزيد:
© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.