Інструменти керівництва змушують агентного RAG виконувати три кроки замість одного ефектного виклику.

Підсумки значущості, відмінності речень та перевірка підрахунків залишаються нерухомими, доки інструмент керівництва, пошук інструментів та неповні результати не навчать модель послідовності.

Видавець: REACTAPP.TOPДодано на сайт 26 вер. 2026 р.28 хв читання6538 слів

Джерела: Reflections on Tools: Getting Agentic RAG to Take Three Steps-Part 7 of my EDGAR Intelligence MCP journey

У попередніх частинах цієї серії створювалося дерево узагальнень, сухі цифри трималися окремо від мовної моделі, текст був отриманий з графіків, аналізувалося, що змінилося між заявками, досліджувалося, як взагалі знаходити потрібну інформацію, та визначалося, про яку компанію йдеться у запиті. У цій частині йдеться про вузький інтерфейс, до якого насправді доходять ці елементи: короткий блок тексту з описом інструментів, який модель аналізує перед тим, як здійснити виклик.

Три інструменти

Частина 4 аналізувала зміни факторів ризику з року в рік. Передача обох звітів 10-K у модель та запит про те, що змінилося, провалилась не лише через витрати: метод Context Rot від Chroma залишає завдання незмінним та змінює лише довжину вхідних даних у різних моделях — продуктивність погіршується зі збільшенням обсягу контексту нерівномірно, у способах, які неможливо передбачити лише на основі самого завдання. Провали залишаються непомітними: модель, яка повідомляє про шість змін, ніколи не каже вам про сьому. Самі лише позначки на рівні символів не справляються з проблемою перерозподілу тексту; подвійні підсумки ще гірші. Ті методи, які вижили, мали три інструменти, а не два:

L1 для визначення значущості — резюме розділів у стилі RAPTOR (одне стисле описування кожного розділу звіту відповідно до Частини 1). Визначає, які теми змінилися. Один аналіз на кожну сторону. Дозволяє розпізнавати значення, яке неможливо виявити за допомогою парування символів.

Різниця як доказ — позначення на рівні речень, яке вказує конкретні формулювання для кожної виявленої теми. Повністю механічний, повний та підлягає перевірці.

Підрахунок для перевірки — перевірка на те, чи справді формулювання суттєво відрізняються у двох документах. Схожі фрази в обох документах зазвичай означають лише перестановку слів, а не справжню зміну.

Ця тріада все ще правильна. Як абзац статті, вона також є абсолютно неактивною. У ній немає нічого, що могло б активувати інструмент. Модель, яка запитала про зміни у факторах ризику Apple, ніколи не читала цю статтю. У неї є запитання, список інструментів та інформація про ці інструменти. Побачивши diff_filings, її природний інстинкт — це викликати його та описати результат. Агентні системи RAG часто проходять повз це: отримання даних — це легка частина; складною є навчання моделі яких трьох кроків виконати та в якому порядку, використовуючи лише текст, приєднаний до інструментів.

_SECTION_SLUGS = (
    "overview", "routing", "setup", "deal_walkthrough", "diff_workflow",
    "tools", "warmth", "time_axes", "sql_track", "metrics", "alpha", "fields",
    "idempotency", "presentation", "response_bounds",
)


def _split_sections() -> dict[str, str]:
    parts = _GUIDANCE_MD.split("\n## ")[1:]
    assert len(parts) == len(_SECTION_SLUGS), (
        f"guidance has {len(parts)} sections, {len(_SECTION_SLUGS)} slugs"
    )

Якщо інструкції неправильні, інструменти ніколи не будуть поєднані. Якщо вони правильні, але не прочитані, вони також ніколи не будуть поєднані. Решта цього тексту присвятована тому, як зробити такі інструкції завантажуваними, короткими та здатними вижити під час пошуку інструментів.

Вибір, виклик та те, що не є нічим

Використання інструментів поділяється на два етапи, які люди вже вміють називати.

Вибір — це вирішення про те, який інструмент має потрапити до активного набору для цього кроку: визначення маршруту, пошук інструменту, фільтрація каталогу. Запуск — це надсилання структурованого запиту з аргументами після того, як інструмент стає доступним. Фреймворки та API моделей приділяють увагу обом цим етапам.

Існує ще третій етап, який не належить ні до одного з цих: орієнтація — це опис, який пояснює моделі чому інструмент існує у робочому процесі, що має відбутися перед його використанням та як виглядає завершення роботи після нього. Орієнтація — це не вибір між отриманням чи генерацією інформації. Це речення, яке перетворює три окремі інструменти на послідовність дій.

Більшість інструментів ховають інформацію про спосіб виконання завдання у системних запитах, які постійно збільшуються в об’ємі, або ж опускають її, сподіваючись, що назви інструментів буде достатньо. Жоден з цих підходів не є ефективним, коли у вас є десятки інструментів MCP та користувач, який ставить однорядкове запитання щодо двох документів.

Інструмент-керівник

Інструмент-керівник — це інструмент, єдиною функцією якого є надання інструкцій: короткого, авторитетного опису багатоекранного процесу. Він не завантажує документи, не обчислює відмінності. Він повертає текст, якого модель має дотримуватися протягом наступних кількох кроків.

For the full repeatable diff flow see `edgar_guidance(section="diff_workflow")`.

Використання такого інструменту є дешевшим, ніж включення всього процесу у кожен системний запит. Крім того, його можна знайти: пошук інструментів може видасть його, якщо запит стосується змін, а пропустить його, якщо користувач хоче лише один числовий факт.

Інструменти керівництва виявляються некорисними, коли стають другими копіями документації, які постійно змінюються, або коли намагаються самостійно здійснювати пошук інформації. Тримайте їх у вигляді коротких процедурних інструкцій.

Навички вказують на це. Вони не копіюють їх.

Навички (або набори навичок, або посібники для агентів) повинні посилатися на інструмент керівництва за назвою та призначенням, а не копіювати його зміст. Копіювання створює два джерела інформації. Коли метод змінюється — з’являється новий крок перевірки чи нове правило підрахунку — інструмент керівництва потрібно оновити лише один раз. Навички продовжують вказувати: «спочатку викликайте workflow_guidance у разі зміни фактора ризику з року в рік».

For document selection and extraction strategies, use PFW_get_guidance
(see quick reference chart for section selection).

For document selection strategies and multi-document workflows, use
PFW_get_guidance (see quick reference chart for section selection).

For cross-MCP workflows, use PFW_get_guidance (see quick reference chart).

For field selection guidance and token estimates, use
PFW_get_guidance(section='tools').

Ця непрямість здається бюрократичною, поки ви не виправите прихований спосіб збою та не усвідомите, що дванадцять файлів з навичками були б хибними копіями.

Що навчили сервери MCP USPTO про інструменти керівництва

Раніша робота USPTO MCP призвела до тієї ж помилки в іншій сфері: занадто багато інструментів, кожен з привабливою назвою, але жоден без чітко визначеної послідовності використання. Спеціалісти спочатку використовували привабливий інструмент пошуку та пропускали перевірку. Виправленням не стало додавання ще більше інструментів — це були інструкції, які в тексті повернення результатів вказували, у якому порядку дії є обов’язковими та які результати вважаються неповними без подальшого дзвінка.

WORKFLOW: even the substantive-only headline is clause-level and can
still be noisy on a heavily rewritten section. For "what materially
changed" questions, run RAPTOR L1 FIRST — search_filings(level=1,
section_path=<the section>) on each filing to read the two section
summaries and build a short topic list (typically 5-10 items) of what
actually moved. Then call this diff to pin the EXACT clause language
for each flagged topic, and skip every pair that doesn't touch one.
The L1 contrast also surfaces meaning that a cold diff buries in
reflow (e.g. a new tax-law valuation allowance). See
edgar_guidance(section="diff_workflow") for the full repeatable flow.

Уроки, які були застосовані під час роботи з EDGAR:

Інструкції мають бути зручними для використання, а не лише задокументованими у README, який модель ніколи не бачить.
Інструкції мають бути достатньо короткими, щоб залишатися зрозумілими попри додаткові описи, які вводяться після пошуку інструментами.
Інструкції мають вказувати способи збоїв („не зупиняйтесь після досягнення червоної лінії“) так само, як вони описують успішні сценарії.

Інструкції мають залишатися у власності домену — послідовності USPTO не належать до тексту інструменту EDGAR, і навпаки.

Отже, процес роботи перемістився до документації функцій

Розміщення методу у файлі Markdown, який подобається людині, нічого не дає для моделі. Розміщення його у документації/описі інструменту допоміжного інструменту має значення, адже саме цей текст вставляється під час виконання, коли обирається інструмент.

- `alpha` (default = EDGAR_RAPTOR_HYBRID_ALPHA, falling back to
  EDGAR_HYBRID_ALPHA): only affects the L0 clause collection, which
  carries BM25 sparse vectors. 1.0 = pure dense, 0.0 = pure BM25. Do
  NOT lower it for an exact citation or identifier (a literal
  "$750,000,000", a defined term, "Section 9.1(d)") — keep the default
  and pass `rerank=True`, which supplies most of the precision on a
  short identifier-only query.

На практиці міграція виглядала так: береться абзац статті з трьома інструментами, він скорочується до імперативних кроків, додаються критерії успіху, і це представляється як результат виконання get_yoy_risk_factor_method (назва може відрізнятися). Навички та запити системи вказують лише на цей інструмент. Коли метод у Частині 4 отримав крок перевірки підрахунків, змінився лише результат виконання інструкцій.

Документаційні тексти — це не місце для оповідань. Використовуйте кілька сотень слів для опису процедури, а не цілу есе. Додавайте посилання для людей; зберігайте просту структуру того, що можна викликати.

Шляхи повернення: друга половина речення

Інструмент, який повертає величезний обсяг інформації, не пояснюючи, що робити далі, навчає модель узагальнювати та зупинятися. Шляхи повернення — це друга половина речення: після отримання даних, який інструмент їх підтверджує, який підраховує, та коли можна надати відповідь.

- For a MULTI-YEAR or HISTORICAL question about one company, prefer
  `group=` over a single `cik`: a kind='lineage' group covers the
  whole predecessor/successor chain (so a question that crosses a
  name/CIK change — Avago→Broadcom, Apollo's predecessor — doesn't
  silently miss the older filings) and its members COLLAPSE into one
  issuer block, with each hit keeping its own cik and the block
  carrying `lineage_ciks` for provenance. `resolve_parties_to_cik`
  reports which group to pass.

При багатоетапному робочому процесі проектуйте повернення даних у вигляді часткових результатів та підказок щодо наступних кроків. Це не означає, що інструмент має стати агентом — це означає, що навантаження не повинно виглядати як готова відповідь, поки перевірка ще триває. Крім того, повідомлення про помилки мають розрізняти випадки «жодних змін не виявлено» та «не вдалося виконати порівняння», інакше модель буде вигадувати рівень впевненості.

Той самий механізм, інший процес роботи

Інструменти керівництва не є унікальними лише для зміни факторів ризику. Для прийняття рішень у компанії (Частина 6), вилучення даних з графіків (Частина 3) та створення підсумків із збереженням числової точності (Частина 2) потрібен короткий метод, який можна викликати у разі недостатньої конкретизації запиту користувача. Ця схема повторюється: один інструмент керівництва на кожну групу процесів роботи, навички, які вказують напрямок дії, та результати, які не дозволяють вважати роботу завершеною занадто рано.

AI-RANKED RESULTS — ordered by semantic similarity, not authority. L0 hits
are extracted clause text. L1/L2 hits are AI-generated summaries — take
especial caution with figures ... A claim about WHAT CHANGED, read off two
L1/L2 summaries, is likewise unverified until the distinguishing language
is confirmed against the underlying clause text on both sides.

Використання одного великого інструменту керівництва у різних процесах роботи знову створює проблему, схожу на проблему з системними запитами. Краще використовувати кілька невеликих інструментів керівництва з чітко сформульованими умовами активації в їхніх описах, щоб пошук міг підібрати правильний інструмент.

І ще один, який запускає все це

Деякі сесії потребують дзвінка з консультацією bootstrap перед будь-яким пошуком: яка компанія, які форми, які роки, у якому порядку інструменти. Без цього агенти починають працювати з функцією diff_filings, використовуючи неправильну пару документів.

INTERPRETING THE REDLINE — you can and should tell real edits from chunking
artifacts; do that filtering rather than treating every delta as substantive.
... The word-level highlights are the tell: differences only at the START
and/or END of the clause (or a small leading/trailing add/delete) mean a
realignment, while a term changing in the MIDDLE (amounts, dates, defined
terms, added/removed obligations or conditions) is a real edit.

Під час консультації bootstrap дозволяється ставити уточнювальні запитання через чат, проте все одно забороняється передчасне використання інструментів. Її слід робити ідемпотентною — двічі її виклик не повинен змінювати стан бази даних.

Тридцять п’ять інструментів

Кількість інструментів у EDGAR MCP зросла до приблизно тридцяти п’яти. При такому обсязі неможливо включити всі описи до запиту, а дозволити моделі бачити простий список призводить до випадкових перших запитів. Тож пошук інструментів стає обов’язковим: необхідно включити запит до метаданих інструментів, надати короткий список, а потім дозволити моделі вибрати.

if counts.get("substantive_modified"):
    response["chunking_note"] = AI_DIFF_REALIGNMENT_NOTE

Тридцять п’ять — це не головне; головне те, що інструменти для навігації мають витримати пошук. Якщо опис інструменту для навігації не відповідає критеріям „що змінилося / рік до року / фактори ризику“, він ніколи не потрапить до короткого списку, і ці три інструменти знову залишаться неактивними.

Пошук інструментів та три інструменти

Для робочого процесу з факторами ризику „рік до року“ список результатів пошуку має в першу чергу включати: інструмент для навігації, інструменти видимості L1, інструмент для порівняння та інструмент підрахунку/перевірки. Усе інше є шумом для цього класу запитань.

"revenue is a derived metric — one issuer's consolidated number.
 A multi-CIK `ciks=` list would blend inputs across issuers into a
 figure belonging to none of them. Call once per `cik=` (or pass a
 lineage `group=` for a predecessor chain)."

Налаштування пошуку — це робота над продуктом: синоніми в описах, негативні приклади („не для пошуку окремої компанії“) та набори для оцінки запитань користувачів із очікуваними першими інструментами. Без цього циклу оцінки навігація залишається лише філософським вибором.

Що бачить користувач

Користувачі не повинні бачити інструментальні елементи. Вони ставлять просте запитання та отримують відповідь із посиланням. Унизу у записі можуть бути позначки керівництва → L1 → diff → count. UX продукту може об’єднати їх у позначки прогресу (“перевірка змін”, “завантаження точних клозусів”, “перевірка новизни”) без розкриття назв інструментів.

Input(s) [...] were not tagged by this issuer under any recognized XBRL
concept in the requested periods, so the derived value is 'unknown'
wherever they are needed. Not every issuer reports every line item
(e.g. asset-light filers omit capex), so the same metric may resolve
for an issuer that does tag them.

Коли щось зазнає невдачі, показуйте етап, на якому виникла проблема. “Diff недоступний” є дієздатною інформацією; “агент припустився помилки” — ні.

Сторінки-проксі

Сторінки-проксі, призначені для користувачів, документують ті самі робочі процеси для операторів та аудиторів. Вони можуть бути довгими. Вони не повинні ставати єдиною копією методу, необхідного моделі — адже модель не переглядає ваш сайт документів під час роботи, якщо ви спеціально не передбачите цей механізм.

Per-figure descriptions are NOT produced on this path: charts and images
on these pages carry no annotation, and their absence is not evidence the
page had no figures ... check the linked source image (source_url) before
concluding something is absent from the filing.

Зберігайте посилання на сторінки-проксі та інструменти для керівництва: на сторінці зазначено, що «канонічні інструкції для машин знаходяться в інструменті X», а у описі інструмента сказано, що «людський опис — це URL Y». Розбіжності між ними є помилкою версії.

Відтворіть це самостійно

Щоб відтворити цю схему поза межами цієї серії:

Опишіть метод у вигляді послідовних кроків із назвами інструментів та умовами зупинки.
Зробіть його результат доступним у вигляді тіла повернення інструменту для керівництва.
Направте інструменти на виконання завдань; не копіюйте тіло повернення.
Нехай інструменти для надання доказів повідомляють про неповноту даних до завершення перевірки.
Розмістіть пошук інструментів перед великим каталогом; оцініть точність першого інструмента на наборі золотих запитань.
Використовуйте людські документи як проксі, а не як основне джерело інформації під час виконання.

armth: hits from filings whose summary tree is still cold (L0-only)
trigger background tree builds — `tree_builds_enqueued` in the result
says how many; re-run the search shortly after to get L1/L2 summaries.

Evaluate a math expression EXACTLY (deterministic; LLMs are error-prone
at multi-digit arithmetic). Compute, calculate, arithmetic, math.

EXPECTED_NON_DEFERRED = {
    "guidance.py",
    "resolve_parties.py",
    "edgar_strategic_search.py",
}

# Anthropic's stated range for non-deferred tools.
MAX_NON_DEFERRED = 5

Метод збирається змінитися

Тріада частини 4 не стане остаточним словом у цій темі. Нові методи верифікації, дешевші моделі виділення важливого, краще оброблення перерозподілу вмісту — усе це з’явиться. Якби цей підхід існував лише у есеях та збірках навичок, кожне покращення стало б багатофайловим археологічним проектом. Однак, оскільки він існує у форматі інструменту для керівництва, зміни полягають у одній правці та перевірці на ключових запитаннях.

Use your tool-search or tool-discovery step, but do not CALL any of the
tools it finds. I want to read them, not run them.

1. Search for tools now, by server name and by keyword, and list the MCP
   servers and tools you can reach. If your first look says you have no
   tools, search again before concluding that: with tool search enabled,
   most tools stay hidden until you go looking for them.

2. Pick one non-trivial tool. Show me, verbatim and without summarising
   or reformatting:
   - its exact tool name
   - its complete description text, every line of it
   - its full input schema: each parameter, its type, its default, and
     the description attached to that parameter

   Print the description IN FULL even if it runs to a thousand words or
   more. Do not abbreviate it, do not list its section headings instead,
   and do not tell me to look at the tool result: I cannot see what you
   can see, which is the whole point of this.

3. Then tell me, in your own words:
   - does that text instruct you to call anything BEFORE this tool, or
     AFTER it?
   - does it tell you how to interpret or filter the result?
   - does it tell you to relay anything to me?
   - is there anything in it you would not have done on your own?

Висновок

Agentic RAG — це не просто «отримати дані, потім створити результат». Для виявлення змін у документах SEC це є складеною ланцюгом інструментів, який працює правильно лише тоді, коли моделі вказують — у місці, яке вона дійсно читає — у якому порядку їх використовувати. Три інструменти (підсумки значущості, відмінності речень, перевірка кількості) вирішують наукову проблему з частини 4. Вони нічого не роблять, поки орієнтація не існує у вигляді запитуваного інструменту керування, навички вказують напрямок замість того, щоб копіювати, система відмовляється вважати роботу завершеною раніше, а пошук інструментів може знайти потрібний керівник серед десятків інших.

Якщо бажаєте, можете розглядати вибір та запуск як готові елементи; те, що робить продукт унікальним, — це третій момент: орієнтація. Орієнтація, яка описана у README-файлах, є лише декором. Орієнтація, яка міститься у системних попередженнях, перетворюється на некерований набір елементів. Орієнтація, яка знаходиться у короткому, пошуковому та належному власнику домену інструменті для керівництва, є придатною до використання.

Робота USPTO MCP навчила того ж уроку щодо торгових марок та патентів: дружелюбні назви інструментів без чіткої послідовності призводять до помилкових дій з самого початку. Робота EDGAR успадкувала цей недолік та навмисно перемістила процес роботи у docstrings. Тридцять п’ять інструментів зробили пошук інструментів обов’язковим; пошук зробив якість опису частиною правильності, а не маркетинговим текстом.

Те, що бачить користувач, має залишатися спокійним. Те, що написано на сторінках-проксі, має залишатися повним. Те, що читає модель перед першим справжнім пошуком, має бути коротким, інструктивним та супроводжуватися версією методу. Якщо завтра зміниться метод, потрібно змінити інструмент керування та знову пройти процедуру з „золотими запитаннями“. Не намагайтеся працювати з дванадцятьма скопійованими версіями.

Якщо ви залишите собі одне інженерне правило з цього розділу: ніколи не дозволяйте єдиній копії багатоетапного методу знаходитися в місці, до якого модель не може отримати доступ. Есе навчають людей. Інструменти керування навчають агентів. Навички є вказівниками. Результати — це напівречення, які вимагають наступного дієслова. Пошук інструментів — це брама, яка вирішує, чи буде будь-який з цих текстів допущений до використання.

Серія продовжується: інструменти розвиваються, каталог зростає, а описи мають залишатися найкоротшими та точними описами того, як ці інструменти взаємодіють. Саме тому агентний RAG виконує три кроки замість одного яскравого запиту.

Конкретний чек-лист для нової родини робочих процесів:

Назвіть інструменти та способи перевірки, які ускладнюють беззвучну невдачу.
Напишіть інструмент для керування, чий опис відповідає способу постановки запитань користувачами.
Зберігайте обсяг повернутої інформації в межах кількох сотень слів опису процедури.
Направляйте користувачів на цей інструмент; забороніть вставку тексту.
Позначайте повернені докази як неповні без підтвердження.
Додайте „золоті запитання“, де першим інструментом має бути саме керівництво.
Посилайтеся на сторінки людського проксі, не роблячи їх критичними для роботи в реальному часі.
Репетируйте зміну методу як редагування за допомогою одного інструменту.

Команди, які ігнорують чек-лист, знову стикаються з проблемою Context Rot ускладненим способом: модель „читає“ обидва документи, вільно говорить, але не помічає важливих змін. Команди, які дотримуються чек-листа, бачать, що агентний підхід RAG стає цікавим у найкращому сенсі — передбачувані кроки, чітко визначені пункти та можливість точної перевірки.

Цікавість — це мета. Блискучі відповіді, отримані за допомогою одного інструменту, — це спосіб, яким користувачі отримують приховані помилки.

Evaluate a math expression EXACTLY (deterministic; LLMs are error-prone
at multi-digit arithmetic). Compute, calculate, arithmetic, math.

Use it over numbers you ALREADY retrieved (e.g. from
query_financial_facts) — it does NOT fetch data. Supports + - * / // % **,
unary minus, and abs, round, min, max, pow, sqrt, log (natural), log10,
log2, exp, floor, ceil, plus constants pi and e. No variables, attribute
access, or other calls (safe AST evaluator).

Examples:
- 5-yr revenue CAGR: "(60922/26974)**(1/5) - 1"
- net debt / EBITDA: "(96700 - 29943) / 34000"
- YoY % change: "(383285 - 394328) / 394328 * 100"
- segment as % of total: "23056 / 81462 * 100"

Returns {expression, result, formatted} on success, or {error, expression}
if the expression is rejected.

Джерела

Основними джерелами для цього розділу є література про ReAct та використання інструментів у якості фону, дослідження Chroma щодо змін контексту як доказ наявності деградації за тривалістю використання, методи узагальнення у стилі RAPTOR, використані у Частині 1, попередні розділи цієї серії EDGAR Intelligence MCP щодо інструментів типу L1/diff/count, а також власний каталог інструментів MCP проєкту та документація до проксі-функцій. Назви пакетів та API постійно змінюються — розглядайте текст інструкцій як версіонований контракт щодо поведінки агента, а людські есе — як коментарі, а не як об’єктивну істину під час виконання.

Чому інертні методи здаються завершеними на сторінці

Технічне письмо вимагає повних пояснень. Переклад, у якому згадуються L1, diff та підрахунок читань, нагадує дизайн-документ. Агенти не читають дизайни; вони читають інструкції до інструментів у межах встановленого бюджету. Саме через різницю між цими аудиторіями більшість „агентських“ демонстрацій тихо перетворюються на прості обгортки для одного інструменту. Щоб подолати цю прірву, потрібно прийняти те, що частину вашого найкращого прозового тексту доведеться переписати у вигляді функцій, а ці функції можуть бути менш витонченими, ніж оригінальні есе.

Орієнтація проти якості пошуку

Покращення ембеддингів, чанкінгу та процесу переранкування допомагає інструментам аналізу даних. Це не змушує модель викликати три з них по черзі. Команди часто витрачають чверть часу на оптимізацію показників пошуку та тиждень на формулювання запитів, а потім дивуються, чому система виявлення змін все одно обмежується лише одним викликом diff_filings. Орієнтація на бюджет як пріоритетний напрямок роботи: описовий текст, синоніми для пошуку, тестування з використанням «золотих» інструментів та перевірка формату результатів.

Історії невдач, які варто зафіксувати

Зафіксуйте ті невдачі, за які ви вже заплатили: припинення роботи після досягнення критичного рівня, який вказує лише на зміну форматування; довіра до подвійних підсумків, які приховують суперечності; сприйняття реорганізації як чогось нового; надання відповідей до завершення розгляду справи компанією; змішування послідовностей даних USPTO з сеансами EDGAR. Кожна невдача стає окремим обов’язковим пунктом у інструкціях та окремим ключовим запитанням, на яке не буде відповіді у разі ігнорування цього пункту.

Економіка токенів для керівництва

Відповідь на запит довжиною триста слів є дешевшою, ніж вставка двох документів типу 10-K у контекст „на випадок потреби“, а також дешевшою за системний запит, який перераховує всі процеси роботи. Вона також дешевша за витрати на підтримку некоректних, але зрозумілих відповідей. Оцінюйте керівництво так само, як оцінюєте пошук: час відгуку, кількість правильних результатів під час пошуку за допомогою інструментів та частка успішної перевірки — а не лише те, наскільки витончено звучить текст.

Управління

Хто може редагувати інструменти керівництва? Ставтеся до них як до конфігураційних файлів для продакшну. Вимагайте перегляду змін, зберігайте історію та блокуйте об’єднання, які змінюють керівництво без оновлення базових запитань. Оператори, які читають сторінки-проксі, повинні бачити той самий ідентифікатор версії, який інструмент повертає у рядку заголовка. Коли під час аудиту запитають, чому агент використав три інструменти, потрібно посилатися на версіонований текст керівництва — а не на аргументи з Slack з минулого місяця.

Що не варто додавати до керівництва

Не використовуйте тут секрети, URL-адреси середовищ із обліковими даними чи інформацію, притаманну конкретному користувачеві. Не включайте повні фрагменти документів. Також не використовуйте складні правила, що сягають обсягу роману. Обов’язково вкажіть порядок дій, умови зупинки та назви наступних інструментів. Якщо якась деталь призначена лише для людей, залиште її на сторінці проксі.

Взаємозв’язок із графами у стилі LangGraph

Деякі команди кодують ці три кроки як жорсткий граф без можливості вибору моделі. Це є допустимим та часто безпечнішим підходом. Інструменти керування стають корисними, коли вам все ще потрібна модель для розв’язання недостатньо описаних запитань, але метод має залишатися знайденим серед багатьох інструментів. Графи та інструменти керування є взаємодоповнюючими: граф може реалізувати метод після його вибору; інструменти керування допомагають у виборі та забезпечують чесність гібридних агентів.

Ескіз інструменту оцінки

Підтримуйте таблицю з запитаннями користувачів, очікуваним першим інструментом, класом послідовності інструментів та забороненими інструментами для раннього завершення. Запускайте цей механізм після кожної зміни інструкцій. Якщо точність використання першого інструменту знижується, припиніть процес створення. Щотижня перевіряйте транскрипції на наявність відповідей, які були надані без підрахунку. Опублікуйте простий дашборд, щоб відділ продукту та відділ інженерії мали однакове розуміння поняття „агент виконав три кроки“.

Щодо найменувань

Називайте інструменти так, як це потрібно для пошуку: дієслова, які вводять користувачі (explain_yoy_risk_factor_method), кращі за винахідливі внутрішні назви. Описи мають містити синоніми: зміна, дельта, порівняно з минулим роком, фактори ризику, Пункт 1A. Корисні також негативні позначки: „не для актуальних котирувань акцій“, „не для узагальнення в одному абзаці“.

Масштабування за межі однієї серії

Як тільки кілька доменів матимуть інструменти керування, створіть невеликий мета-індекс: домен → назва інструменту керування. Не об’єднуйте домени в один інструмент для написання есе. Саме через міждоменне забруднення поради USPTO потрапляють у сеанси EDGAR. Зберігайте індекс простим та зрозумілим.

У частині 4 було доведено, чому один інструмент є науково недостатнім. У цій частині показано, чому правильний науковий метод все одно не функціонує без можливості отримання орієнтаційних даних. Читайте їх разом: інструменти без керування є неактивними; керування без інструментів — це лише формальність. Разом вони є основою для того, як агентний RAG отримує позначку „агентний“ у завданнях, які карають за бездіяльність.

Перед надсиланням змін до пояснень проведіть репетицію: безпосередня сесія, ключове запитання, підтвердіть, що пояснення є першим інструментом, переконайтеся, що L1 працює з обох сторін, перевірте, чи запитується різниця з вказаними поясненнями, переконайтеся у правильному підрахунку спроб, переконайтеся, що відповідь, видима користувачеві, посилається на пункти та зазначає процедуру перевірки. Запишіть ідентифікатор транскрипції поруч із версією пояснень. Якщо якийсь крок пропущено, виправте опис чи пошук перед тим, як святкувати покращення показників отримання інформації.

Оперативний додаток: сценарій репетиції

Перед надсиланням змін до пояснень проведіть репетицію: безпосередня сесія, ключове запитання, переконайтеся, що пояснення є першим інструментом, переконайтеся, що L1 працює з обох сторін, переконайтеся, що запитується різниця з посиланням на конкретні пояснення, переконайтеся, що відбувається підрахунок спроб, переконайтеся, що відповідь, видима для користувача, посилається на відповідні пункти та зазначає процедуру перевірки. Запишіть ідентифікатор транскрипції поруч із версією пояснень. Якщо якийсь крок пропущено, виправте опис чи пошук перед тим, як святкувати покращення показників отримання інформації.

Оперативний додаток: сценарій репетиції

Перед надсиланням змін до пояснень проведіть репетицію: безпосередня сесія, ключове запитання, підтвердіть, що пояснення є першим інструментом, переконайтеся, що L1 працює з обох сторін, перевірте, чи запитується різниця з вказаними поясненнями, переконайтеся у правильному підрахунку спроб, переконайтеся, що відповідь, видима користувачеві, посилається на пункти та зазначає процедуру перевірки. Запишіть ідентифікатор транскрипції поруч із версією пояснень. Якщо якийсь крок пропущено, виправте опис чи пошук перед тим, як святкувати покращення показників отримання інформації.

Оперативний додаток: сценарій репетиції

Перед надсиланням змін до пояснень проведіть репетицію: безпосередня сесія, ключове запитання, підтвердіть, що пояснення є першим інструментом, переконайтеся, що L1 працює з обох сторін, перевірте, чи запитується різниця з вказаними поясненнями, переконайтеся у правильному підрахунку спроб, переконайтеся, що відповідь, видима для користувача, посилається на пункти та зазначає процедуру перевірки. Запишіть ідентифікатор транскрипції поруч із версією пояснень. Якщо якийсь крок пропущено, виправте опис чи пошук перед тим, як святкувати покращення показників отримання інформації.

Оперативний додаток: сценарій репетиції

Перед надсиланням змін до пояснень проведіть репетицію: безпосередня сесія, ключове запитання, підтвердження того, що пояснення є першим інструментом, перевірка того, чи працює L1 з обох сторін, підтвердження необхідності отримання відмінностей із зазначеними поясненнями для пари, перевірка кількості запусків, підтвердження того, що відповідь, видима для користувача, посилається на положення та містить інформацію про перевірку. Запишіть ID транскрипції поруч із версією пояснень. Якщо якийсь крок пропущено, виправте опис чи пошук перед тим, як святкувати покращення показників отримання даних.

Оперативний додаток: сценарій репетиції

Перед надсиланням змін до пояснень проведіть репетицію: безпосередня сесія, ключове запитання, підтвердіть, що пояснення є першим інструментом, переконайтеся, що L1 працює з обох сторін, перевірте, чи запитується різниця з вказаними поясненнями, переконайтеся у правильному підрахунку спроб, переконайтеся, що відповідь, видима для користувача, посилається на пункти та зазначає процедуру перевірки. Запишіть ідентифікатор транскрипції поруч із версією пояснень. Якщо якийсь крок пропущено, виправте опис чи пошук перед тим, як святкувати покращення показників отримання інформації.

Оперативний додаток: сценарій репетиції

Перед надсиланням змін до керівництва проведіть пробну роботу: безпосередню сесію, «золоте запитання», переконайтеся, що керівництво є першим інструментом, переконайтеся, що L1 працює з обох сторін, переконайтеся, що запитується різниця з вказаним назвою парного керівництва, переконайтеся, що відбувається підрахунок спроб, переконайтеся, що відповідь, видима для користувача, посилається на положення та зазначає процедуру перевірки. Запишіть ідентифікатор транскрипції поруч із версією керівництва. Якщо якийсь крок пропущено, виправте опис чи пошук перед тим, як святкувати покращення показників отримання даних.

← Усі статті Надіслати бриф