This is a viewer only at the moment see the article on how this works.
To update the preview hit Ctrl-Alt-R (or ⌘-Alt-R on Mac) or Enter to refresh. The Save icon lets you save the markdown file to disk
This is a preview from the server running through my markdig pipeline
Wednesday, 26 November 2025
"Ми створюємо асистента знань, який зробить революцію в тому, як наші працівники отримують доступ до інформації..."
- У 2024-25 роках кожна робота була рекламною, палубою смоли і пропозицією консультації.
Минулого місяця я правильно вимірював себе у комерційному комп'ютерному просторі. і я дійшов досить сумного висновку.
Це майже одне й те саме.
"Головна база знань компанії." "Інтелектуальний документьний пошук." "Майбутній чатбот з промисловими знаннями." Скиньте копію без подиху маркетингу і ви знайдете ту ж архітектуру, ті самі режими помилок, і ті ж розчаровані зацікавлених зацікавлених учасників десь шість місяців на лінії.
Варіанти клієнта чат-аботи особливо цікаві, що можуть стати PR-афішами надзвичайно швидко, коли розробники, які не розуміють вартових, дозволяють їм вільно спілкуватися з публікою. Ніщо не зовсім схоже на те, як ваша підтримка бадьоро пропонує рефінанси, які ви не даєте, створюючи характеристики продукту, які не існують, або на філософську тангенсацію щодо значення існування, коли хтось запитує про відправку часу відправки. Без належного обмеження ці боти, ці боти щасливо обіцяють будь-що, визнайте про злочини, які ваша компанія не чинить, або розробляють сильні погляди щодо конкурентів.
Ось брудний секрет, який ніхто з керівників не хоче чути: Більшість комерційних проектів комп'ютерного інтелекту не є інноваційними.
Перед тим, як піти далі, я не "провидець" або що б не було гіпе-керованим моментом, (здебільш за все - колишні "теорії блощиць," які зручно чергувалися), я програміст з програмним забезпеченням, який будував ці типи систем, управління знаннями, природній аналіз мови, підтримка рішень близько до трьох десятиліть. Я бачив це зображення з експертними системами, з семантичною мережею, з великими даними, з блокциною. Технологія змінюється; модель перевищення та підвищення не працює.
Скиньте маркетологи і ви побачите, що близько 95% комерційних проектів "АІ" належать до однієї з двох категорій:
Це найпоширеніший приклад. Кожне " вхідне розв' язання AI " відповідає такому шаблону:
flowchart LR
A[Documents] --> B[Document Ingestion Pipeline]
B --> C[Vector Database / RAG]
C --> D[Construct Prompts]
D --> E[LLM API Call]
E --> F[Hybrid Search]
F --> G[Response to User]
style B stroke:#ff0000,stroke-width:4px
Ось де все розривається.
"Ми створили ШІ, який розуміє документи вашої компанії і може розумно відповісти на запитання!"
Ви створили пошукову систему з додатковими кроками та оплатою по 10 000 фунтів на місяць.
Ця ще гірша: "Ми тренували нашу власну модель штучного інтелекту спеціально для вашої індустрії!"
Ви взяли чиюсь модель і вирівняли її на наборі даних, який, ймовірно, занадто малий, занадто брудний і занадто вузький, щоб зробити істотні зміни, використовуючи лише базову модель з хорошими імпульсами.
flowchart TD
A[Existing LLM] --> B[Collect Training Data]
B --> C[Clean Data - Maybe]
C --> D[Fine-tune Model]
D --> E[Deploy Model]
E --> F[Discover it's not much better than base model]
F --> G[Keep paying for inference anyway]
G --> H[Hope nobody notices]
Більшість гарних проектів, які я бачив, краще б послужили, витрачаючи ті самі гроші на покращення їх запитів та системи отримання даних.
Давайте поговоримо про цю червону коробку на діаграмі РАГ. Продуктивність документа - це частина, яка найчастіше зазнає невдачіІ це частина, яка отримує найменшу увагу у мерехтливих демонстраціях.
Ось що показує демо продажів:
Ось що відбувається насправді:
PDF - це кошмар. Їх було розроблено для друку, а не для видобування структурованих даних. Кожен інструмент обробки PDF, який я використовував, має різні режими помилок:
І це просто PDFs.
Після того, як ви витягнете текст (вбого), вам потрібно розрізати його для вашої векторної бази даних.
Чудово, ваш контракт на 200 сторінок тепер становить 500 шматків, і комп'ютер не має поняття, які з них пов'язані або в якому порядку вони з'являються.
Чудово, ви тільки що розділили речення навпіл, а вбудовування тепер являє собою нісенітницю.
flowchart TD
A[Original Document] --> B[Chunk 1: This contract shall be governed by]
A --> C[Chunk 2: the laws of the State of California]
B --> D[Embedding: Legal stuff?]
C --> E[Embedding: Geography?]
D --> F[User asks about jurisdiction]
E --> F
F --> G[AI: Based on my knowledge, possibly California, or maybe legal governance, who knows]
Отримую метадані з документів, але отримати їх з документів складно:
У більшості організацій є десятки років документів з непослідовними назвами конгресів, структур тек, які мали сенс для того, хто поїхав 2003 року, і для того, хто поїхав з функціонування, що пропало або невірно.
Дозвольте мені бути чітким: тонкий розтин має своє місце, але спосіб, яким більшість компаній підходять до нього, фундаментально зламаний.
Дрібні вправи вимагають якісних навчальних даних, а більшість компаній їх не мають.
Ваші квитки на підтримку наповнені розчарованими клієнтами, неправильною інформацією від молодших працівників, і крайніми справами, які не відповідають нормальному використанню.
"Ми налагодимо наші дзвінки з продажу!" Ти маєш на увазі ті, де продавці обіцяють продукт, який не може зберегти?
Як ви знаєте, чи ваша точно налаштована модель дійсно краща? Більшість компаній не можуть відповісти на це, тому що:
Я бачив, як компанії витрачають шість місяців на отримання моделі, а потім не мають можливості довести, що це краще, ніж просто використовувати GPT-4 з хорошою системною пропозицією.
Тонке налаштування моделей потребує оновлення, зміни у ваших бізнесах, зміни ваших продуктів. Зміни у ваших процесах. Ця модель, яку ви налаштували у січні, тепер відповідає на застарілу інформацію.
Але оновлення означає:
Большинство компанией подлагают раз, а потом просто живут с дыханием. а все притворяются, что это добавляет ценность.
Не зрозумійте мене неправильно. Існують законні випадки використання:
flowchart TD
subgraph RAGWorks["✅ RAG Works When"]
R1[Well-structured docs]
R2[Clear metadata]
R3[Search + synthesis use case]
R4[Heavy ingestion investment]
R5[Feedback loops exist]
end
subgraph FTWorks["✅ Fine-Tuning Works When"]
F1[Large high-quality dataset]
F2[Base model truly struggles]
F3[Ongoing maintenance budget]
F4[Clear eval metrics]
F5[Already tried prompting + RAG]
end
style R4 stroke:#00aa00,stroke-width:2px
style F5 stroke:#00aa00,stroke-width:2px
Зелені коробки є передумовами більшості проектів пропустити. "Ми вже оптимізували мотивацію та RAG" це в барі для тонких ток-пунтингів. "Поглиблено інвестування" Спусти это и ты строишь на песке.
У той час, як кожен будує той самий трубопровод RAPG, насправді цікаві проблеми комерційного комп'ютера ігноруються:
Найбільші обмеження ефективності ШІ - це не модель, а дані.
Але "експеримент якості даних" не дає вам статтю "Перетворення" Форбс.
Якщо ви скинете в існуючий процес чат-робота комп' ютерного гравця, це не покращить його магічним чином. Процес слід перебудувати навколо можливостей і обмежень комп' ютерного гравця. Більшість компаній просто підключають ШІ до розбитих процесів і замислюються над тим, чому вони не допомагають.
Найкращі ШІ вдосконалюють можливості людини, замість того, щоб замінювати їх. Але це важче продати, ніж "Ай, що робить Х автоматично!"
Люди + ШІ, які працюють разом, вимагають:
Більшість комерційних проектів ШІ ставляться до людини як до вигадки.
По-справжньому цінні програми комп'ютерного інтелекту не є "chatbot на ваших документах." Це додатки, які:
Провідні трубопроводи RAP легкі (простіше, простіші).
Важливим драйвером проектів ШІ є екосистема консалтингової системи:
flowchart TD
A[Big Consultancy Tells C-Suite: You Need AI!] --> B[C-Suite Panics]
B --> C[Consultancy Deploys Army of Juniors]
C --> D[Recommendations: RAG + Fine-Tuning]
D --> E[Build Same Thing as Last 20 Clients]
E --> F[Demo Goes Well]
F --> G[Reality: Real Data Breaks Everything]
G --> H[Consultancy Moves On]
H --> I[Internal Team Struggles]
I --> J[Project Quietly Fails]
J --> K[Nobody Admits It]
K --> A
style G stroke:#ff0000,stroke-width:3px
style J stroke:#ff0000,stroke-width:3px
Адміністратори кажуть, що вони зробили штучний інтелект, інженери застрягли, підтримуючи щось, що ледве працює, і насправді бізнес проблема залишається невирішеною.
Початки потрапляють у дещо іншу пастку. це не консультаційне середовище фінансування.
timeline
title Technology Requirements for VC Funding
2005 : Web 2.0 - "You need social features"
2010 : Mobile - "You need an app"
2015 : Cloud - "You need to be cloud-native"
2018 : Blockchain - "You need a token"
2023 : AI - "You need an AI strategy"
Звук знайомий? нова технологія може бути недоречною для Вашого продукту. вам не потрібен гомін.
У 2017-2018 рр. компанії, які не мали жодного бізнесу на барикаді, були вигнуті жетони в їхні продукти, тому що вони отримали фінансування.
Тепер це відбувається з ШІ.
Запуск - це використання можливостей LLM для продуктів, які не потребують їх, тому що:
Результат: продукти з незграбними можливостями комп' ютерного гравця, які ігнорують користувачі. Спалювані злітно- посадочні смуги під час експериментів, які ні до чого не призводять.
Найгірша частина: Багато засновників знають, що це дурниця.
Якщо ви засновник стартапу, який змушує додати ШІ, запитайте себе:
Якщо це останнє, налаштуйте мінімально життєздатну функцію комп'ютера, яка затуляє коробку, зосередьтеся на тому, що насправді має значення. Не дозволяйте, щоб середовище фінансування відволікало вас від створення чогось цінного.
Ось незручна істина, про яку ніхто в ШІ не хоче говорити: Майже кожен в екосистемі має фінансовий стимул, щоб підтримувати рух гіпе.
flowchart TD
subgraph Researchers["🔬 Frontier Labs"]
R1[Need billions for compute]
R2[Must show progress to justify spend]
R3[Hype generates investment]
end
subgraph Companies["🏢 Tech Companies"]
C1[Need AI angle for valuation]
C2[Must justify AI team costs]
C3[Hype drives stock price]
end
subgraph Investors["💰 Financial Backers"]
I1[Massive capital deployed]
I2[Need exits and returns]
I3[Hype maintains valuations]
end
subgraph Media["📰 Tech Media"]
M1[AI stories get clicks]
M2[Access depends on positive coverage]
M3[Hype drives engagement]
end
R3 --> I1
C3 --> I1
I3 --> R1
I3 --> C1
M3 --> R3
M3 --> C3
Дослідники Для того, щоб виправдати витрати, їм потрібно продемонструвати прогрес, а "прогрес" переводиться у безглузді оголошення про можливості, які можуть або не бути матеріалізованими у практичних програмах. Якщо гіпе помирає, фінансування висихає.
Компаній Оцінка OpenAI залежить від переконання, що AGI знаходиться за рогом. Кожне " потужне " стартапу залежить від того, чи залишиться у гарячому секторі комп' ютер.
Інвестори домінує приголомшлива кількість капіталу у комп' ютерного гравця. Їм потрібні виходи. Їм потрібна музика, щоб продовжити гру достатньо довго, щоб оцінити повернення. Реалістична оцінка майже довгострокових можливостей комп' ютерного гравця призведе до кратерної оцінки по всьому сектору.
Носій як виявили історії з ШІ створюють масивну участь. Обкладинка не отримує клацань. "А я візьму твою роботу" і "АІ прорив розв'яже X" має. Доступ до компаній ШІ часто залежить від збереження позитивних взаємозв'язків, тобто критичним є обмеження на кар'єру.
Результатом цього є самовідновлений цикл гіпе, в якому кожен має причини продовжувати поглинати очікування, і дуже мало людей скористають з того, що говорять правду.
Це не означає, що комп'ютер не є дійсно корисним, це абсолютно так, як я розглядав протягом цієї статті, але розрив між тим, що обіцяно, і те, що передається, є величезним, і стимули всі вирівнюються, щоб тримати цю прірву прихованою.
Коли хтось скаже вам, що ШІ зробить революцію у вашому бізнесі, то запитайте себе: Що вони користають від вас вірити в це?
Якщо ви думаєте про проект штучного інтелекту, ось моя чесна порада:
Не питайте "Як ми можемо скористатися комп'ютером?" Запитайте "Яку проблему ми намагаємося вирішити?" Якщо комп'ютер є правильним рішенням, чудово, але часто це не так.
Перш ніж будувати канал SRAG, полагодьте ваш документ. До того, як ви налаштуєте документ, вичистьте ваші тренувальні дані. Комп' ютерний гравець не розв' яже ваших проблем з даними, - програма підсилить їх.
Не запускайте масивну " перетворення ," створіть невеличкий доказ концепції. Перевірте її за допомогою справжніх користувачів. Дізнайтеся, що насправді працює, а потім розгорніть.
Очищення даних не є захоплюючим, система обробки - це не те, що ви можете демонструвати дошкам, але це те, що визначає успіх або невдачу.
AI не є магією. Поточні системи LLMs галюцинати. RAPG не мають відповідних документів. Малі моделі дрейфують. Встановіть реалістичні очікування.
Будування системи може бути 30% зусиль. Підтримання її, вдосконалення та збереження її актуальності - це інші 70%. Відповідно до бюджету.
Можливо, все, що вам потрібно, це використання інструментів off- shelf. ChatGPT з деякими нетиповими інструкціями може бути достатньо. Не все має бути вимовлено комп' ютерною платформою.
Так, я витратив кілька слів, відкидаючи комерційні проекти ШІ. Ці проекти дійсно можуть працювати, якщо ви наближаєтеся до них чутливо.
Проблема полягає не у RAG або дрібних поняттях, а в лінивій реалізації, нереалістичних очікувань, ігноруванні фундаментальних можливостей. Ось як це зробити краще.
Найбільшою помилкою, яку я бачу, є ставлення до ШІ як до заміни існуючих процесів, а не до покращення. Ваш бізнес вже працює (здебільш за все). Замість того, щоб виривати ці процеси і замінювати їх " потужною " версією, зв' яжіть комп' ютер з комп' ютером (I) з пропусками.
flowchart TD
subgraph Traditional["Traditional Workflow"]
A[Document Arrives] --> B[Human Reviews]
B --> C[Decision Made]
C --> D[Action Taken]
D --> E[Results Logged]
end
subgraph Enhanced["AI-Enhanced Workflow"]
A2[Document Arrives] --> AI1[AI: Extract Key Info]
AI1 --> B2[Human Reviews - With AI Summary]
B2 --> AI2[AI: Suggest Decision Based on History]
AI2 --> C2[Human Makes Final Decision]
C2 --> D2[Action Taken]
D2 --> AI3[AI: Auto-categorise & Log]
AI3 --> E2[Results Available for Future AI Training]
end
Зауважте, що відрізняється:
Це набагато міцніше, ніж "Я роблю все, а інколи і перевірку людини."
Ось брудний секрет: ймовірно, вам не потрібен GPT-4 або Клод для більшості завдань, і вам точно не потрібно надсилати ваші секретні документи на сервери OpenAI.
Проблема кошту
За шкалою вартість API швидко зростає. Напружена система RAG може створювати тисячі викликів LLM на день. При швидкості 0. 01- 0. 03 на 1K- маркерів, це реальні гроші. І, якщо ви збільшуєте, це стає все гірше.
Проблема конфіденційності
Багато організацій не можуть (або не повинні) надсилати свої документи до зовнішніх програм API:
Розв' язання: локальні моделі
Сучасні моделі з відкритим кодом дуже смачні.
flowchart LR
subgraph Cloud["Cloud API Approach"]
A1[Your Documents] --> B1[Internet]
B1 --> C1[OpenAI/Anthropic]
C1 --> D1[£££/month]
C1 --> E1[Privacy Concerns]
end
subgraph Local["Local LLM Approach"]
A2[Your Documents] --> B2[Your Server]
B2 --> C2[Local LLM]
C2 --> D2[Fixed Hardware Cost]
C2 --> E2[Data Never Leaves]
end
for Вбудовування (Шука пошуку вектора RAG):
for створення (Насправжні відповіді "Ай"):
for Завдання з кодування:
Управление местным путем не так трудно, как ты думаешь. Ольямаjapan. kgm, Lama. cpp, vLLM, або Inference- text- generation Я створив декілька додатків (див. нижню частину статті), які показують, що це працює на споживчому апараті.
Вам не обов' язково робити все або нічого. Ви можете скористатися розумною архітектурою:
Локальні моделі для високовольтних завдань з низькою гнучкістю
Хмара API для складного міркування, якщо потрібно
Цей гібридний підхід надає вам вартість місцевих висновків з можливістю моделі хмар, коли ви справді цього потребуєте.
flowchart LR
subgraph Waterfall["❌ The Waterfall AI Project"]
W1[Month 1-3: Requirements] --> W2[Month 4-6: Build Platform]
W2 --> W3[Month 7-9: Integration]
W3 --> W4[Month 10: Demo - Looks Great!]
W4 --> W5[Month 11: Real Users Break It]
W5 --> W6[Month 12: Project Shelved]
end
subgraph Incremental["✅ The Incremental Approach"]
I1[Week 1-2: One Small Problem] --> I2[Week 3-4: Refine + Measure]
I2 --> I3[Week 5-6: Add Capability]
I3 --> I4[Week 7-8: Refine + Measure]
I4 --> I5[Repeat...]
I5 --> I6[Continuous Value Delivery]
end
style W5 stroke:#ff0000,stroke-width:3px
style W6 stroke:#ff0000,stroke-width:3px
style I6 stroke:#00aa00,stroke-width:3px
Під час кожного кроку покрокового підходу ви отримуєте вимірювальну величину. Кожен крок вчить вас чогось. Якщо щось зазнає невдачі, ви втрачаєте тижні, а не місяці.
Пам' ятаєте червоний блок на діаграмі? Ось як це виправити:
Інвестуйте у якість, а не кількість. Краще мати 1000 досконало оброблених документів, ніж 100 000 документів, які неправильно оброблені. Почніть з найважливіших документів і зрозумійте їх правильно.
Використовуйте комп' ютер, щоб допомогти з подразненням. Сучасні моделі зору (GPT- 4V, Клод, LLAVA локально) можуть читати складні документи - таблиці, діаграми, рукописні нотатки - у спосіб, у який традиційна ОРС не може. Скористайтеся ними для створення складних документів.
Збирання циклів зворотного зв' язку. Якщо спроба отримання даних зазнала невдачі, запишіть її до журналу. Якщо користувачі кажуть " це не те, про що говорить документ ," зловіть його. Скористайтеся цим відгуком, щоб покращити ваш трубопровід для продукування.
Прийняття того, що деякі документи не будуть працювати. Не всі давні скановані PDF варто боротися з ними. Іноді відповідь " Ми розберемося з цим типом вручну ," замість того, щоб витрачати місяці на справи з ребрами.
Потрібне робоче рішення комп' ютерного гравця:
} Що більшість проектів роблять} Що в дійсності відбувається? |-----------|----------------------|---------------------| Д_ д. д. д. д. д. д. д. д. д. д. д. д. д. д. д. д. д. д. д. д. д. д. д. д. д. д. д. д. д. ДІ-Ті-Ті-Ті-Ті-Ті-Ті-Ті-Ті-Ті-Ті-Ті-Ті-Ті-Ті-Ті-Ті-Ті-Ті ' . ♪Other repeat ♪Iputed into work} ♪Sheep back ♪ None' sleepous present ta} ♪ It's working" thanks & watching ♪ ♪'Version 1 while' ♪ регулярно оновлює & moep тяг
Модель штучного інтелекту, можливо, 20% робочої системи, інші 80% - це нудні речі, які насправді змушують його працювати в виробництві.
Ви не можете покращити те, чого не можете виміряти. Кожна система комп' ютерного гравця повинна стежити за:
Ці дані вказують на те, де інвестувати зусилля. Можливо, ваше отримання є чудовим, але покоління галюцинує. Можливо, певні типи документів завжди зазнають невдачі. Ви не можете виправити те, чого не бачите.
Ось найважливіша зміна, що відбувається зараз: Епоха "закинути все на GPT-4" і сподіватися на краще закінчується.
Підходом 2023-2024 було просто: отримати найбільшу модель, яку ви можете собі дозволити, все, що ваше контекстне вікно наповнене усім і молитеся. Він працював... на зразок демонстрацій. Для прототипів. Для отримання інвестицій.
Але він не має масштабу, він дорогий і повільний, і все більше, він виходить за межі розумних архітектур.
Майбутнє - не одна гігантська модель, яка все робить. Різноманітні моделі, що працюють разомКожен робить те, що добре.
flowchart TD
subgraph OldWay["The 2023 Approach"]
A1[Everything] --> B1[GPT-4]
B1 --> C1[Hope It Works]
B1 --> D1[£££££]
end
subgraph NewWay["The 2025+ Approach"]
A2[Input] --> B2[Router Model - Small/Fast]
B2 --> C2[Specialist Model A - Extraction]
B2 --> D2[Specialist Model B - Reasoning]
B2 --> E2[Specialist Model C - Generation]
C2 --> F2[Orchestrator]
D2 --> F2
E2 --> F2
F2 --> G2[Output]
end
Це те, що я досліджував у своєму DISE (пряма синтетична еволюція) workthe ідея, що структура б'ється з яскравістюРетельно сконструйований трубопровод менших, зосереджених моделей перевершує одну масивну модель, що намагається робити все.
Те саме мислення стосується Синтезований рушій визначенняComment концепція: використання декількох серверів LLM у послідовності, у яких кожна модель приносить різні переваги. Швидкі моделі для тригонометрії, точні моделі для перевірки, творчих моделей для створення. Кожен з них робить те, що найкраще.
Якщо ви ще не зробили цього, перевірте мою Серія RAG Але ось ключова істина: **RAG сам по собі є формою цього оркестрованого підходу.**Ви використовуєте вбудовування (одну модель) для пошуку відповідного вмісту, а потім використовуєте LLM (іншу модель) для синтезу відповіді.
Наступна еволюція просуває далі:
Кожна модель менша, швидша і дешевша за використання GPT-4 для всього.
Термін "агентичність" запозичено з психології, перш ніж я потрапив у програмне забезпечення. У психології агенція посилається на здатність діяти незалежно, робити вибір і виконувати їх у світі.
Antic AI Замість традиційного шаблона, ви ставите питання, модель створює текстову агентну систему. робити речі. Він може використовувати інструменти, виконувати код, бази даних запитів, викликати API, писати файли і оркеструвати багато-крокові робочі процеси. Різниця полягає у тому, щоб запитати когось про напрям і найняти когось, хто би вас підвозив.
Це останні моделі Антропіки (включаючи Claude Opus 4. 5 Я буквально пишу це за допомогою Code Клода, демонструючи це дуже ефективно.
Ось що робить тих, хто не вміє добре працювати, незручними: якщо ви описуєте інструменти достатньо добре, вам не потрібно коштовно-точно-використовувати, щоб використовувати їх. Сучасні моделі фундаменту надзвичайно гарні на інструменті, які використовуються у скриньці ♪Ви просто потребуєте ясної функціональної схеми і хорошої документації в контексті.
Це величезний зсув з підходу до інструментатора (докладно налаштуйте модель, щоб вона вчилася, коли слід використовувати інструменти за допомогою вимірювальних результатів). Це дорого, потребує спеціалізованих навчальних даних і заблоковує ваш набір інструментів. Альтернативний варіант? Описуйте ваші інструменти, надайте моделі добрий контекст, а потім надайте йому змогу визначити, коли слід використовувати ці інструменти.
Результати часто кращі, бо:
flowchart TD
subgraph RAG["Traditional RAG Chatbot"]
R1[User Question] --> R2[Search Documents]
R2 --> R3[Construct Prompt]
R3 --> R4[LLM Generates Answer]
R4 --> R5[Return to User]
end
subgraph Agentic["Agentic AI Pattern"]
A1[User Task] --> A2[LLM Understands Task]
A2 --> A3[Break Into Steps]
A3 --> A4{Select Tool}
A4 --> A5[Execute Tool]
A5 --> A6{Evaluate Results}
A6 -->|Need More| A4
A6 -->|Done| A7[Return to User]
end
style A6 stroke:#00aa00,stroke-width:3px
Ця агентична модель фундаментально відрізняється від RAG chatbots, і саме тут лежить справжня цінність.
Frammworks на зразок LangChain, LlamaIndex та Semantic Kernel роблять це можливим сьогодні. Ви можете будувати системи, де:
Компания, которые выяснят это, построят ШІ системы, которые на самом деле работают. они все еще пытаются устроить свой путь к успеху или построить еще один chatbot продолжает разочароваться.
Я багато писав про такі моделі:
Що ви будете вивчати? |-------|--------------------------------------------------------------------------|-----------------------------------------------------------------| | Архітектура | DiSE проти Voyager ♪ Why circtured admiction monolic modes ♪ | Multi- Model | Синтетичні механізми визначення * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * | Основи RAG | Серія RAG ♪ Від вбудовування до виробничих систем ♪ | Локальні вбудовування | Семантичний пошук з ONNX ДЗ- дружній локальний вектор шука | Локальні LLM | ДІС ♪ A seycf evoluvign workTore System use local Moderes connected collect ♪ | Симуляція API | LLMapi ♫ Використання локальних LLM для симуляції API для test} | Практична допомога | Будівництво адвокатської програми GPT Реалізація може пройти через@ option: check application application
Технологія існує, формуються моделі, питання полягає в тому, чи ваша організація побудує щось розумне чи дурне програмне забезпечення.
Сучасний комерційний ландшафт ШІ нагадує мені про ранню веб-реалізацію: усім потрібна була "вебева стратегія," тому що вони мусили, не тому, що знали, що з ними робити. більшість з цих веб-сайтів були марними.
Врешті-решт, тими компаніями, які досягли успіху, були ті, хто з'ясував, для чого насправді був потрібен Інтернет, і створили його для цього.
Зараз ми знаходимося в фазі "побудуйте, тому що ми повинні" - більшість проектів німі, більшість - ні програші, ні про які не говорять, це нормально для нових технологій.
Але якщо ви хочете бути одним з тих, хто досягає успіху, зупиніться на шаблоні. Почніть з реальних проблем. Вкладайтеся в нудні біти. І задля любові до бога виправте ваш документ трубопровод, перш ніж звинувачувати LLM.
ШІ - це не проблема, а ваші дані, ваші процеси, ваші нереалістичні очікування.
Виправте їх першими, і можливо, можливо, ваш проект ШІ не буде дурним.
© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.